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