I’ve been seeing remarks on Facebook regarding the possibility of implementing Audulus as AUv3, so thought I’d check this particular thread, to see how it might (or will?) be implemented in the not-so-distant future. I’d imagined being able to load individual modules and position them within a chain in AUM whether they be generator/instruments, or effect processors. The idea of being able to open modules that are available in the user library here through the forum, without necessarily having to edit or stitch together the modules within a single instance of the currently available IAA shell seems like it’d simplify matters considerably. Looking forward to it!
1 Like
The AUv3 is in alpha right now - it’s working but not quite ready for beta testing. We’ll announce when it’s in beta and the timetable for release when we know more! 
1 Like
My motivation is to be able to create patches in Audulus that are able to appear similar to conventional music creation apps so that users who aren’t into programming will be able to easily use the Audulus patch as they would any other app they’re used to using.
Currently, Audulus seems more oriented towards people who are more interested in the audio programming side of app development whereas I would like to have a platform on iOS where the GUI could be equally sophisticated.
Rather than nodes exclusively focused on audio processing, there’d also be nodes to facilitate linking controls together in a relational structure for a GUI.
A video isn’t the best way to demonstrate such a proposal and perhaps an html structure which is more interactive would be.
Given the tepid response by @biminiroad I didn’t want to waste my time on such an effort as it seems there’s probably zero chance of something like my proposal becoming a reality in Audulus as all of the demos seem more focused on complex patches with lots of wires and collections of modules strung together which are overwhelming to many potential new users or to users who just want to create music with patches with minimal time invested in learning how to use patches.
My impression is that the Audulus development team is focused on a programmer oriented market and will not be willing to invest in the GUI support needed to make the patches accessible to the general iOS musician.
I have no interest in defending my proposal to the Audulus developers as they’re either willing to broaden their market or believe they need to focus on the market they currently have. What I would like to have in Audulus might not match up with their road map for the future but I certainly don’t see my desire to have a deep and user friendly GUI and audio programming environment on iOS going away either.
1 Like
I really think someone will do this, if not Audulus then Pd somewhere. It seems like such a great way to make a custom plug in. I was messing around with VCV and looking at the developers community over there. If you could “bounce down” your modules into a compatible format, builders in Audulus could sell their wares to VCV people.
I hope so. Audulus as a visual programming language is great and magnitudes more accessible to new users than traditional text based programming environments. AU is much more reliable than IAA, remembers your setup, and can use more than one instance of an app. These conditions along with the already planned improvements in functionality for Audulus 3 and Audulus 4 along with the increased capacity of iOS devices and the Files app can all contribute to the synergy of what improved GUI functionality and flexibility can bring to the table.
The vector based nodes/modules with nested patch levels is unparalleled on iOS so the ability to establish GUI relationships using similar tools for traditional app usage people are familiar with could leverage the existing tools and bring things to another level.
People who already use Audulus would no longer need to encourage people to get over the programming hump to use Audulus and the complexities of patches would not interfere with the ability to use them as a sophisticated GUI approach would allow the patch user to focus on understanding how to use it within the context of what they already know.
Patches could be enhanced by users who are able to apply their graphic and GUI design talents to create polished intuitive patches. In patch design, as with music, it is great to be able to create something others can engage with versus being limited to a small audience because they can’t relate to what you’re trying to accomplish. Ideally people can take the patches and use them in ways that go beyond what you’d originally envisioned as they make them part of their own creative process.
1 Like
Some interesting ideas, and a good presentation. I like the idea of being able to switch views, and on-screen help would be very useful.The SVG icons allow for a compact display, but sometimes can be a bit obscure. Have you looked at TouchOSC? Using it as a control surface for Audulus provides many of the same features as your proposal. It uses tabbed screens rather than icons to switch views, but it also supports multiple displays. It also allows you to define the size of touchable UI elements, and has a wider selection of control types. It fully supports multi-touch which I regard as essential for a practical performance environment. The UI design process is a bit cumbersome and does require a Mac or PC, but it does allow you to separate the performance UI from the Audulus engine. Currently. there is no way to send any information from Audulus back to TouchOSC, but I’m hoping that with two way MIDI support the integration between TouchOSC and Audulus will become seamless enough to allow it to become a practical performance surface for Audulus. It works as-is but is not as seamless as I would like. Of course, I would love to see something similar built in to Audulus, but given the very limited development resources available, and the long list of improvements already planned, I wouldn’t expect anything in the near future. Multi-touch and a better lock mode would certainly help, and I think you may see improvements in that area. Personally I would love to see Audulus support OSC which provides a richer interface to remote control sufaces, but I’m not holding my breath. Thanks for all your work. You have some excellent ideas and ultimately our discussions help shape the direction that Audulus will take in the future.
2 Likes
There are other MIDI control surface design apps on iOS I prefer over Touch OSC as I can design the surfaces all on iOS rather than have to design the surface on a PC and port it over to load in Touch OSC.
I do hope that at some point Audulus can add GUI oriented nodes. I understand its their business decision.
I do think at some point an audio programming environment with a user GUI that has deeper programming than has been offered by the modular apps thus far will happen.
1 Like
Which ones do you like? I stumbled on TouchOSC for use as a remote control for Reaper which is the DAW I use, and the MIDI functionality was just an extra bonus.
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.
4 Likes
Sounds great, looking forward to these new features.
MIDI Designer Pro 2, TB MIDI Stuff, Lemur, and KRFT.
2 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like