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.
Comments
If the FX nodes get a channel filter, i see no problem the simplified variant - it‘s just different. A note range filter for FX nodes is probably not necessary.
A new step needed is that one would need to specify the channel at the midi sender au/app/fx, which is supported by nearly ever midi souce i have.
I found the exception in FAC Envolver which just sends its CCs on channel 1 - but Fred could change this...
(or as work-around one drives the main node on channel 2 and whatever the envolver controlled with channel 1, or changes envolvers CC to a number not used by the main node and both use channel 1)
What i would in AUM
I know it is easy to ask, and for me AUM is alteady a top tool as it is now
Thanks
Is this like giving each channel its own midi port? Would these be visible outside of AUM, or still just AUM Destination?
I like this idea. It keeps the workflow simple. The idea of mapping related midi on the individual channels is very intuitive and familiar and even DAW-like. I vote a “yes” for this.
On a different note, I would suggest making the existing MidiMatrix larger. It seems way small for the amount of stuff we are routing through there these days. If I didn’t need to scroll around in there so much would be nice.
Agree with you, the matrix in AUM is good, just make it more accessible with a larger floating window
They already have, if the FX node says it can receive MIDI. Note range filter is useful for some effects, for example vocoders.
Actually the "standard" is for AU plugins to ignore the channel and receive omni, unless it needs to (multitimbral multipart synth etc). The host can then filter the channels as the user wishes, without having to touch any settings inside the actual plugins.
The last two are definitely planned at least
Proposed solution:
1) Allow AUM faders to be programmed to control CC streams as well as audio. It would be cool to use an AUM fader to change a parameter on, say, Rozeta Particles.
2) Expose AUM's midi curves to CC control. There would be three possible CC controls for each curve: left side, right side, and overall level. That way we could use a LFO to modulate or invert the curve.
What do you guys mean when you say “nodes” ?
It makes me think of a modular system. Are there nodes somewhere in AUM already?
Yes, the idea was not to have them as visible ports outside of AUM. But one can easily imagine adding more than the single "AUM Destination" virtual port of really needed.
Yeah. The thing is that I'm thinking about replacing it with a more intuitive "list of connections". I think the matrix works great for a couple of sources and destinations, but when they get many it tends to get a bit confusing IMHO. Lots of tracking the arrow-lines with the eye while scrolling to see where they go..
A connection list would simply contain clear and easy to read rows of "AMidiSource -> SomeDestination". Tap a +-button to add a connection. Swipe an existing connection to remove it.
But maybe I'll need to have both, because it seems a lot of you have fallen in love with the MIDI matrix
A "node" in AUM is anything you load into a "slot" - like a synth, filter, file player, effect, bus send, mic input, IAA output, everything.
The last point above is actually about dedicated MIDI slots, for non-audio nodes (such as Rozeta)
Yes, please keep Matrix as an option in settings. I love it. My current set up needs a huge matrix with scrolling, so a full page option would be great, but in any format, I would be keen for it to remain.
Your diagram of the simpler midi source flow makes sense.
Excited to see where you take AUM next.
It’s integral for my current set up, so thanks!
Two things that would make the setting up of MIDI controls easier would be some sort of activity indicator on the destinations to show that there's a MIDI signal getting there and making that fly-out menu a bit more sticky. It's really frustrating having it disappear when you hit anything on the main screen, particularly when you've had to drill down a couple of levels and then scroll through 800 parameters.
If the "channel selector/filter" remains per-node, I'm not sure I can even dream up a problem that the proposed change would cause.
yeah looks like anything which can simplify workflow yet keep the same possibilities of control is a good thing
So the diagram seems better with the new option.
I would also like to see quicker access to the matrix and a wider view, I have a lot of ports when connected to hardware. You could introduce colour in the matrix lines to make it easier to track different ones maybe, like coloured patch cables. eg when you press a connection it changes colour so you see it stand out etc.
Looking forward to channel presets and midi nodes especially too. And midi recording? That would be great.
@j_liljedahl Can we get the ability to choose the channel when sending midi externally?
Oh, i just didn‘t notice them until you mentioned
I think you misunderstood my remark - i did not reflect about the receiving AU (which should receive omni so no setup is needed) but AU‘s/IAAs generating midi. Most of them default to send on midi channel 1.
Since your whole idea simplifies the midi routing for most use cases, these two simple, additional steps for complex setups don‘t really matter.
Oh, yes that's right.
The current state suits my needs. I find it simple and intuitive.
I'm likely speaking from a perspective of someone who's constantly trying to catch up with evolution as opposed to making music.
It is, and it is what I was referring to in my previous post