more GUI oriented
I agree! Expect some REALLY COOL stuff in this direction in Audulus 4 
Fancy DIY SVG graphics can be a real drain on patches if you’re not careful.
We can cache the unchanging SVG graphics as an image, improving performance. With lock mode preventing zoom (fix forthcoming, sorry) this could be really nice.
Sounds great, looking forward to these new features.
MIDI Designer Pro 2, TB MIDI Stuff, Lemur, and KRFT.
Your video sparked some great discussion at the weekly meeting between me and @Taylor - what do you think of this proposal?
We should implement a help mode for Module UIs that displays tooltip information about what knobs, buttons, and displays do.
The Help Mode would be invoked by an icon at the bottom of the screen, similar to Timing Mode.
In Help Mode, you can tap on any module UI element and a text box will pop up explaining what that element does or displays.
The text box would be editable by users so they could create their own tooltips. By default, though, the text box would open without being editable to prevent accidental changes to information.
In Help Mode, none of the knobs or buttons could be interacted with. This would make it easy to see what a knob’s function is without accidentally disconnecting a wired connection.
Some of the other things you suggested could also be implemented by adding a preset mode. What do you think of this proposal?
Audulus should have a preset function. One way to implement it would be to add a “bookmark” function that takes a snapshot of the patch as it currently is and stores it as a kind of sub-file.
When a user bookmarks the patch state, it would prompt the user to name the bookmark/preset.
These bookmarks could be navigated with a < > arrow icon set at the bottom of the screen.
This would also make tutorials really nice and compact where you could move from one element of a tutorial to another without having to have a large sprawling patch with duplicate elements.
It would be ideal to have a preset system that works on both the patch and module level.
A patch level preset could be used to navigate steps in a tutorial, or to change routing of modules. In this way, you could have an entire performance loaded up in one patch that can easily switch between different synths and sets of modules without having to exit the patch, find the next patch you want for your performance, and load that. You could simply snapshot each state and navigate between them like a setlist.
A module level preset would be used to navigate through stored knob/button settings. This would be essential to keeping presets stored when a module is created. If the presets are at the patch level only, then you could not create a module in a new patch and still navigate through its individual presets.
I like the idea of a help mode. It’s always best if you can present help at the point of need. Have a look at the help for GarageBand for one possible approach. A pop-up text box would also work fine. I also like the idea of a preset system, but I’m a bit confused by the description of the patch and module level presets. How would you access the module level presets? If there is only one set of arrows then it would seem that you would only be able to access the patch level. Not sure how this would work.
I’ll second Paulinko suggestions. This is something I already proposed in the old forum. A performance mode is lacking. There’s already an « expose » option, why not a « perform » ? All items with the perform option would be displayed in a performance mode window. Everything that is not necessary for performance would be removed and that GUI could be rearranged for performance only. This would be the simplified and multitouch GUI used for AUv3. Exit unecessary cables, knobs, etc. and everything would be locked and adjustable with no need to zoom in, just like any standard VST and AU.
Obviously preset snapshots are mandatory too.
With this you’ll get a new user base, not interested in building patches, just using AUs and presets.
This is a great idea - I’m just wondering how we’d do it though? How would Audulus know which controls you’d want for a performance? Do you want the sequencer controls exposed, or just the filter cutoff and a couple other parameters?
The solution might be instead of having a separate mode to have a way to expose upwards controls that are inside a subpatch. The controls would be grouped and you could move them around where you want.
Because right now you can make a patch performance ready by attaching knobs to knobs and then grouping them into a performance patch, but its onerous laying it all out again. Does that make sense?
In the nodes / sub-patch sub-menu, click or tap on « perform » (similar to »expose »). This way Audulus knows that this item will be displayed in the performance (AU) window.
That sounds great - I think the only challenge will be how to let Audulus know what to expose about the labels/lights inside the knob, but maybe there can be some algo that detects any node within the perimeter of the knob and expose that upwards also.
As you point out, it is currently possible to group a patch, expose the controls you would like to have available, arrange them to your liking, and use that as a performance patch. Unless of course the controls are in a sub-patch already and can’t be exposed second time. Perhaps the answer is not a new mode, but the ability to expose a module’s UI as a unit, including the controls, graphics, lights, meters etc. This would allow one to construct modules with a UI that can be reused. As it stands, modules can be re-combined, but modules that require user input have to be positioned at the patch level. By allowing module UIs to be re-exposed, it would be simple to group a selection of modules, lay them out as required and only have visible the controls needed for performance. Coupled with a better lock mode, multi-touch and a preset system, you would have a practical performance tool that could still be easily reconfigured when required.
We could do that - I thought about that when responding - but what if you just want a control here or there from each thing? If you exposed everything together in a group it would be pretty much the same as not exposing.
I think the answer might be to have both modes - because it would be useful to expose an entire module UI and move it around as a group, but it would be also great to do what others are suggesting and expose just individual controls.
I see your point, I was trying to keep things simple from an organizational perspective. What about a hybrid approach. Allow UI elements to be re-exposed but selectively. You could select a module and expose it as a group or select the individual elements one by one and expose them. You would still only have one mode, it would simply depend on what was selected at the time you chose expose.
Yeah sorry thats what I was picturing as two modes - if you expose the whole module it moves as one, but if you expose each element individually you could place them wherever.
The only complicating factor is what to do when something is connected to a knob internally. Does it just get disconnected? You could end up with a situation where a wire is coming from within the patch and just going up to the knob without the wire coming from anywhere.
I think the simplest approach would be to dis-connect the wire, maybe with a warning prompt.
The help and presets both sound like good ideas.
The GUI tree structure and the patch tree structure (how sounds and/or logic are implement in the patch) could be linked.
In terms of GUI, I think it would be good to have a way where you can arrange a GUI template and then map the GUI controls to the controls in the patch. The GUI controls would work as an alias for the controls in the patch. In this way you can reuse/modify viable GUI setups and simply link them to the appropriate controls for a particular patch rather than having to go through the current hassle of going back and forth between the GUI level and opening the sub patch setting knobs, lights, and triggers in particular states to be able to correctly label and identify controls. Patch controls could be associated with one or more GUI controls but not vice versa.
Different GUI views could share some elements in common. A particular patch could have several GUI views associated with it and the preset system could designate which GUI view would be the default. Being able to chain GUI views would be useful as a trigger or knob could recall a preset so that you’re not just limited to a linear organizational structure for your GUI.
There would be a mode where you could click on a GUI element and Audulus would open up the part of the patch it’s connected to and highlight the control it’s linked with to simplify GUI programming and trouble shooting. It would also make sense for Audulus to let you know which GUI controls are not linked to controls in the patch and/or have links that don’t exist in the patch.
Using this approach, basic GUI setups/modules/templates can be utilized as starting points and the user would modify them and then link the GUI controls to the patch controls. There’d also be a way to setup a dummy GUI area where all or selected controls/displays of a module in the patch would go.
For multiple elements like sequencers where you have multiple buttons, it’d be nice to be able to do GUI copy where you’d paste the arrangement of sequencer buttons in the GUI. Being able to GUI copy elements of a GUI into another GUI view should allow you to still maintain the reference to the elements in the patch.
Another way would be in the patch you’d have an add to GUI option for the selected control/display node (element), or module. There’d be a menu which listed the GUI views in the patch, you’d select a specific GUI view, have the option to add a new element or module or link to GUI control. If link to GUI control is selected, you’d then be presented with a list of controls in the selected GUI view that match the control (trigger, knob, light, etc . . .) or a GUI area along with the name of the GUI control (e.g. low pass filter cutoff) or area and you’d select whichever controls or area in the list to link to the patch control.
With modules it’d be nice to get into a mode where you can select individual elements and go through the GUI assignment process described in the preceding paragraph.
With a mix of element (button, trigger, display node . . .) and module level tools for linking to GUI views, GUI areas within a specific GUI view, and GUI controls within a specific GUI area, there’d be maximum flexibility and minimal effort needed to design and update patches with GUIs.
Here’s an example structure with GUI views and current subpatch structures:
Main Patch
GUI default
area1: knob1, knob2
area2: trigger 1, trigger 2, knob1, display1, area21
area3: display1, knob1
GUI2
area1: trigger1, trigger 2, trigger3, knob1, knob2, area11, area12
subpatch1: subpatch11, subpatch12:subpatch121, subpatch122
subpatch2: subpatch21: subpatch211, subpatch212; subpatch22
subpatch3
A snapshot would definitely be great for performances !!!
Just wanted to point these threads out to people who haven’t seen them yet:
https://audulus.trydiscourse.com/t/auv3-update/741/
https://audulus.trydiscourse.com/t/audulus-auv3-is-in-beta-now/760
https://audulus.trydiscourse.com/t/auv3-tutorials-and-presets/784
@Taylor and I talked today and because of the inconsistency in the way that each host handles AUv3’s, we’re going to have to make some kind of custom UI for our AUv3. As you might imagine, Audulus is unique in the AUv3 world, and there isn’t an existing framework we can just drop into to make it happen.
This will delay the launch of the AUv3, but I promise it will be worth it!
In the meantime, I’ll continue making AUv3 effects and plugins for people to use once it comes out. The good news is we’ll be able to have a folder hierarchy and more expansive lists of plugins. If you want your patches to be included in the AUv3 release, please contribute here:
https://discourse.audulus.com/t/auv3-tutorials-and-presets/784
It would be awesome if people could take the existing modules in the module library and create presets for them. Just check out the tutorials for each type of AUv3 and go from there. It can be as simple as a nice preset that you found with an existing module or series of modules, or even an entirely new effect or instrument!
Let’s build this out so that Audulus becomes the best AUv3 available
Ok, guess I’ll survive.
Do you have an estimate of how long creating the AU UI may take?
It makes sense that Audulus would be more complex than other apps to convert to an AU. I do like the ability to organize presets into folders. Hopefully you’ll be able to access the same set of presets from all AU hosts rather than have to recreate them for each AU host app.