Would it not be also frustrating to have to un-group something just to move one element, then regroup it to move it as one again? And if everything in the group is exactly where it needs to be without needing to move any element, at that point, why not make it a subpatch?
In the cases, I am thinking of, the tap or two to ungroup wouldn’t be a problem. And subpatched won’t work without a lot of additional work because user interfaces of subpatches disappear when subpatched AND you then have re-arrange exposed interface items. Creating and editing the ui of subpatches is a buzzkill as much as I love Audulus.
@biminiroad: I just ran into one of those cases where being able to have objects ‘grouped’ without having to re-select each time would have save a bunch of frustration. I have a bunch of LEDs, inputs and text fields that need to stay together at two levels: an input, LED and text label go together – as well as a bunch of those. The situation was I needed to change the number of input/LED/text groups to add a couple of options in one patch. It would have been nice to be able to move the whole panel of LED/input/text groups at once and also the individual groups (by ungrouping the whole panel of things when I needed to add or rearrange the group.
Ideally, one wants to be able to have nested groups (i.e. group an LED/input/text set as a group and also be able to group together those elements into a larger group). Most object-based graphics apps have such functionality.
To add to the frustration, it doesn’t seem like multiple selections work when in edit ui mode – but maybe I am missing something.
A related thought occurred to me which maybe is discussed in this thread but I missed it: it would be great if Audulus had separate patch-design and ui-design modes. Patch-design mode would the the mode that currently exists. In ui-design mode, you get to arrange things the way that you want them to appear when you are using a patch. This way you could rough-in the user ui look while in a subpatch so that when going up a level to the subpatch’s container, the ui is basically there – rather than having to go through that painful process of going back and forth between parent and child to get the user interface straightened out.
I love Audulus and feel like refinements like this will make it much more usable especially for non-experts.
Is this difficult to do with lasso?
We’re going to do something in A4 where you can move things on a module’s panel together as a group, but I don’t know if we’d do this for nodes. Maybe this is what you’re talking about?
We don’t want to add too many things that would require extra UI or potentially confuse new users when they enter a patch and everything is moving around like a unit.
A nested group situation would add to the UI considerably, too, unfortunately.
I don’t know if anything I do with rearranging nodes themselves is “expert” - I try to be neat and have a clear flow of signal and I just do that as I build usually. I’ve mostly done that since I started Audulus though I have gone through a couple different styles.
What I mean by expert is that through a lot of experience, you have probably developed methods that reduce your inefficiency when arranging and rearranging elements within Audulus. When I was trying to figure out how to do some things, I happened upon a post from you talking about the difficulties you were running into having to bounce back and forth from the main level to inside a subpatch. I am in that phase right now. I imagine a lot of users encounter that and many probably give up.
I am getting better at knowing what order I should try to expose elements to make it less painful – and I am sure that I will get better. But, I’ve been at this point with Audulus before and given up – and I have read (on other fora) about people being intrigued but giving up (at least on iOS).
It is my belief that this could be improved pretty immensely without a hugely different ui.
Anyway, I won’t harp on it, but I really think that one could expand the active user base if the flow were refined to be a bit less frustrating.
I love Audulus.
1 Like
Btw, Xequence on iOS has a brilliant mechanism. It can recognize whether a file has been auto-saved or manually saved. And it is possible to get back to the manually saved version if you need to. I imagine that what this means is that when you manually save, it makes a copy somewhere that it can restore if you need to. It also provides a Save As.
I gather from the dev that it was not terribly painful to implement – and it has been a godsend a number of times.
Yeah, presets or some way of saving recallable snapshots is really need to make this usable for a lot of people. As I work with cool synths like 0-Toast or the Audulus Easel I am trying to get working, I find combinations of settings that are amazing and I hate to have to save a complete version of the file just to snapshot the settings.
[Whoops! I thought I was replying to the user who wanted node grouping!]
Although my top level UI on my projects tend to be pretty compact, I tend to spread out my internals quite a bit to isolate subsections, which makes the lasso sufficient to grab things for moving.
There was discussion recently about functionality that allows for exposing a subpatch’s UI in a containing patch, then moving that exposed UI around the containing path’s UI as a completed unit. I personally can’t wait for that feature, which I think is coming in A4.
3 Likes
That should be user-buildable in A4 
3 Likes
Man, I’m gonna have to reprogram my Elekton brain if we are gonna go with A4 as Audulus 4.
2 Likes
Corruptor of youth, I am!
1 Like
I know there was a plan in Audulus 4 that we would no longer be able to directly attach a wire going into knobs. This makes me wonder how it would be possible to build something where, when an input is connected, a knob is ignored.
One way I could see this being solved is some way in a patch to detect when an input is or isn’t connected. I believe now that an input not connected would have a value of zero, but I wonder if there could either be a special output on “input” or a node that can determine whether there is an input.
Sorry if this is off topic. I love Audulus and am so excited to see what Audulus 4 will bring.
Yes, you’ll be able to do that with normalization, which we’re implementing in A4!
1 Like
Great to hear! I’m excited to see what comes!
1 Like
In addition to normalization, I would love to have the ability to set a knob or toggle via an input. I’m not talking about overriding the knob as is currently the case. I would like to be able to set a value for the knob that would persist. I envision it working in the same fashion as a S&H node. You would have a clamped 0-1 input and a trigger. The intent is not to allow for modulation of the knob, which would be accomplished with a normalized input, but to allow the patch to permanently alter the knob’s value. Think of the motorized faders on analog mixing consoles. By storing a set of knob and toggle settings, you could easily switch between “presets” for a patch so long as no wiring changes were required.
2 Likes
Is what you’re asking for really just individual module presets? Or is there something special about it being “motorized”?
What I’m really asking for is the ability to write to a knob as well as read from it. After writing a new value, the knob position and output value would update, but more importantly the new value would persist in the same way that adjusting a knob manually is saved across reloads of the patch. We currently have no way to store any data other than the position of knobs and toggles and any numeric values entered into an expression node. All of these are manually entered. There is no way for the patch itself to store any data. I used the “motorized” analogy to illustrate what I had in mind, and the preset example as a potential application. With the ability to write to a knob, it becomes an indicator as well as a control. For example, lets say you have an endless encoder on a MIDI device that sends increment and decrement MIDI messages. Currently Audulus has no way to implement this type of signal to control a knob. You would have to read the knob then modify it’s output value and create some type of display to indicate the current value rather than simply look at the knob. Or what if you want a self centering knob (slider) for a pitch bend. If you could write to the knob it would be fairly simple. I would like two outputs a 0-1 value and a gate for currently touched and two inputs, new value and trigger.
5 Likes
BTW all of this could happen at low frequencies not at audio rates. As I said I’m not looking to modulate the knob as much as turn it programmatically.
1 Like
Is anyone familiar with the Reaktor Blocks style of knob modulation interface. You have a bipolar horizontal fader that appears below the knob, which gives attenuation when you assign a source. Form, for example, has a really nice navigation setup.
It would be interesting to imagine an Audulus toolkit that allowed for not only rack style synth designs, but also clean routing faces.
2 Likes