I’ve been giving some thought lately to the features I would most like to see in a future Audulus plug-in. At one point I thought multichannel audio might be nice, but after thinking about the issue, I realized that none of the macOS or iOS DAWs I had access to supported more than 2 channels of Audio for a given track. For iOS apps using the IAA or Audiobus interface, it is possible to assign different pairs of inputs and outputs to a track, but you are still limited to 2 per track. It would be great if Audulus supported multiple channels over IAA and Audiobus, since only a single instance of Audulus can be running, but with an AUv3, multiple instances are possible, so there seems little use for more than 2 channels, since each instance would not be able to communicate with the others.
I would love to see better MIDI support with channel specific triggers and knobs. I would also like to see the Audulus plug-in have a pre-defined block of parameters presented to the host, which could be accessed from within a patch. I don’t believe there is any way to create parameters “on the fly” since I think they are read when the plug-in is loaded prior to actually loading an Audulus patch, but if there were a block of perhaps 16 values linked to a node in Audulus, it would simplify control and automation of the plug-in.
I am pretty sure that at some point soon I will want to control Audulus with a physical controller, not just the screen. I would like some very elegant way to put the screen in a ‘mode’ where it becomes some sort of metering/selection/gesture record visual cue.
Instead of simply hovering the screen over the area in the patch based on a knob you touch, it would be nice if there were a separate, more static way to interact – given that in the case where you have, say, 16 knobs, you need cues to quickly know what the knobs do. But I don’t particularly like the idea that the screen needs to fly around the patch.
So, my thought would be to treat ‘interfacing’ as a totally different grouping than patch building. On this view, there would be interfacing building, so to speak. This takes the informational registers to be as important as signal routing, which I think would push the forefront of performance design into a whole new paradigm.
At the same time “fully customizable” isn’t always a good thing. It’s not for everyone. Myself, I like things that are very tweakable, but I also really appreciate a universal (somewhat closed) system. I think this is one of the big justifications of the “DAWless” movement.
What I have done lately just with standalone Audulus + elektron + hardware is bringing a lot of joy. Right, so once I do all of the hard work of routing my equipment I would like to be able to create control/visual feedback performance interface…overlay?
This device is created for ‘controllerism’ (it is controlling Traktor Pro). But I think it would be just as good for people who like to produce music by jamming it out, instead of programming.
If my wish came true, mapping never feels like programming – unless otherwise needed.
I’ve looked at the twister before and it seems to be a very capable unit. Personally I would much prefer to control a patch in a performance situation using some type of external controller rather than the screen. While I love the Audulus interface for patch design, it leaves much to be desired as a performance controller.
I see two separate use cases for controlling Audulus. In stand-alone mode I believe that a bi-directional MIDI interface will prove to be the most effective. For full functionality this would require MIDI out as well as MIDI in, so that changes to onscreen Audulus knobs and triggers can be reflected by an external physical device. Channel specific knobs and triggers, as well as support for 14 bit CC values would be useful as well. OSC would be another possible protocol, but would probably require significant additional coding.
MIDI could also be used for controlling Audulus as a plug-in, but there is an additional protocol available as well. Plug-ins can present a set of modifiable parameters to their host application which can then be used to control the plug-in via control surfaces or DAW automation. Sets of these parameters can be saved and recalled as presets allowing one to fine tune a plug-in. For the typical plug-in, these are usually hard coded by the plug-in designer and represent the state of the various controls in the plug-in. For Audulus this presents a challenge since the parameters aren’t fixed but vary by patch. By defining a fixed set of parameters that could be accessed by the DAW and Audulus, you could provide an additional way for the DAW and the Audulus plug-in to interact. Additionally, since the DAW isn’t required to display the Audulus graphical interface in order to be controlled, Audulus could potentially disable UI processing when the UI was hidden thus saving a substantial amount of CPU time.
Agreed.
This seems like a basic human right.
This is very important if you want to move some units with the iOS crowd.
I just spoke with one of the guys at DJ Tech Tools and asked if they would be willing to send a test unit. He is going to speak to his staff tonight and it sounds like they would be excited to send out a unit, given how established Audulus is. Is there any chance that we could have it sent to you, since you are the MIDI guy around here and beta testing Audulus 4?
I will probably buy one but I value all of your hard work and would like to know your take on it with one sitting in front of you. Is that something that interests you or am I going about this wrong?
I’d love to test one out! I’m looking forward to testing the beta of the new AUv3 as soon as Taylor is ready. At this point V4 is probably a while off. There’s the AU and a Windows update in the pipeline first.