Some Discussion About AUv3 For iOS



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

area1: trigger1, trigger 2, trigger3, knob1, knob2, area11, area12

subpatch1: subpatch11, subpatch12:subpatch121, subpatch122
subpatch2: subpatch21: subpatch211, subpatch212; subpatch22


A snapshot would definitely be great for performances !!!


Just wanted to point these threads out to people who haven’t seen them yet:


@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:

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 :slight_smile:


:expressionless: 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.