Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Host with automation routing
Was wondering if something like this exists, a host that can route an automated parameter from one plug to another plug.
Like in AUM instead of having to deal with MIDI and never know which CC,channel to use we could just select a direct binding.
Ex:
From PlugX ParamA to PlugY ParamB
From PlugX ParamV to PlugZ ParamD
...
We could even save a lists of connections as presets, and on recall, the host would just connect automatically or ask which instance if there are more than one.
Sorry if this has been discussed before, then thanks for a link
Comments
I don’t think that exists. Would be cool if it did, though
I would love to see something like this. Seems a host like AUM could make a dynamic list of AU automation targets available to AUs. So, for instance, something like Rozeta LFOs could just present that list of targets directly in its UI in place of selecting a MIDI CC. Prolly not a trivial undertaking.
ModStep has a lot of configuration templates kind of along these lines.
@syrupcore
Exactly and I don't know what's used for parameter values in au3, 32bit or maybe 64, at least much smoother than 7 bits MIDI.
If I had to build a host (I'm glad no one asked), I would use only automation, even for notes (of course with a wrapper for plugs that don't support it yet).
Instead of sending notes, cc, pw,... I would send events with unique id and as long as it exists you could control anything for it, eg. event 32 set gain to x, event 32 set pitch to 444, hertz
Would keep current automation for the global stuff, no change.
@brambos Afaik you never builded a host ? Would be funny if you where known for the man who killed MIDI
@espiegel123 I thought I had ModStep but nope, although I think it's MIDI to automation, while I'm thinking automation to automation (look ma, no MIDI)
An automation recorder/editor AU would make AUM a nearly complete end to end production environment for me, now that apps Atom and Enso filled the few remaining voids.
@ZenEagle
I don't know if it's currently possible with au3 as is, but if a plug could get info about that "parameter to parameter connection", it would be fairly easy for a plug to be an automation recorder/editor, without having to use MIDI.
If the recorder/editor(au3 plug) knows that it's own param User01 is connected to SynthA - Osc 1 Octave, then it could display it directly in the editor.
And with the connection idea, you could, on the same "page", control parameters from different plugs(synth and fx) and see their real names.
This wouldn't be a problem for the host, but I don't mind seeing 3rd party solutions as well, but again not sure that there is currently a function for that in au3.
yeah, I've been dreaming of something along these lines as well. Maybe worth sending a feature request to Kymatica?
For me its less about replacing MIDI (127 steps is usually plenty for my caveman music making) and more about laziness making things quicker and more intuitive. When I'm assigning a Rozeta LFO to a CC and then routing Rozeta LFO to some AU and then assigning that LFO CC to some AU parameter, it can be a bunch of fussing about. I just wanna pick the (named) target directly from the source and get on with it.
Actually, a feature along these lines, "MIDI Capability Inquiry", has been adopted as a part of the MIDI 2.0 spec. Along with niceties like named parameters from targets being available on MIDI control sources, this would also allow for two devices to use higher resolution control data, among many other possibilities. So I guess I just want everything to preemptively update to MIDI 2.0.
https://sonicstate.com/news/2018/02/07/midi-capability-inquiry-midi-ci-spec-adopted/
https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange
I've been ready for MIDI 2.0 since 1983
Go head, your english sounds better than mine.
Beside the connection we need a range as now, but maybe also a mirror function, turning a knob on one plug would move it in the other direction on the destination.
The parameter could first land in Mozaic or else and there we can chew it to our needs before forwarding it.
@syrupcore
At least for the connection between 2 parameters the host can already do it, no need for new spec, and another 30 years ... don't think I'll make it
Not on iOS, but I made Tunafish on windows 15 years ago.
(So I've already learned not to make that mistake again)
You can join your superpowers with Matt Borstel (who did that mistake
) I think you two merged together, what powerful company that would be !!!
I remember @j_liljedahl once mentioned the idea of changing the AUM midi routing matrix into a more flexible tabular form. I think the current matrix works fine, though, but perhaps this routing of AU parameters from plugin to plugin would fit well with the tabular design? Create a row for a source AU parameter, then add as many columns as you like for its AU parameter destination(s).
The problem with controlling an AU parameter with the values of another AU parameter is that there's no mechanism to read an AU parameter with precise timing. So, read-only AU parameters are not a good way to send values out of a plugin. Better then to use some custom MIDI protocol to send the actual timestamped data out of the plugin. read-only AU params could still be used to announce which outputs are available.
Indeed. Apple re-confirmed this a few weeks ago when I inquired about it.
@j_liljedahl
How bad is it, buffer size quantization ?
My MIDI keyboard isn’t sample accurate either.
Even worse, there's no way to read the AU param value in a realtime safe way from the audio thread either, otherwise it would be quantized to buffer size, which wouldn't be too bad - one could even divide the system buffer into smaller chunks and run those plugins there, with more CPU overhead but higher timing resolution.
But, not possible. So custom protocol over plugin->host MIDI is the only way I see.
Ok, forget running an oscillator using parameters, but it would still be useful to do some minimal patch changes. A plug could "record" some param changes while we are tweaking a synth/fx and then send them back on playback, even a beat or two before, would be fine.
Anyway not trying to force you, and thanks for the explanation
Hmm, just thinking out loud, as obviously the problem is with reading the parameters from a plug.
For MIDI only plugins I noticed that we have 2 unused audio buffers that could just be used for communication between the host and the plug.
With some clever encoding we could pass a "lot" of info even in a 64 sample stereo buffer.
The host could even pass the plug list and parameter tree info to the plug on request.
Edit: Afaik the buffer wouldn't have to be the audio buffer size, could be a larger buffer, based on the audio buffer and the number of connections and the desired precision. So hundreds of parameters could be passed on each sample