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 Store

Audiobus is the app that makes the rest of your setup better.

Controlling Atom 2 using AU parameters

TLDR: Using AU parameters to control Atom 2 seems to be more effective for me than using the built-in triggering, based on having used them for the first time this weekend. I’ve included an AUM demo project (do not use the *WithClear template without reading the warning at the bottom of this post!). Testing shows it has the following advantages:

  1. Record directly into patterns without stopping the transport. This is the main benefit, I think.
  2. Solid when doing consecutive switches. Finally gives me reliable looping of pattern switches.
  3. Straightforward setup with no CCs/PCs used or scripts required for converting between notes and PC/CC.

This looks like it will replace my favoured use of hold notes to trigger Atom. I haven’t used it for a full song yet but it has passed my “does it play 1/64th notes at the start and end of each consecutive pattern?” test and so should be reliable. Blueveek had mentioned possibly adding a recording mode which would let you record into patterns while triggering them, so this post may just be an interim solution.

If you are already doing this then I’d like to hear your experiences/tips/additions.

You can look at the project for details but the main points are:

  1. The project contains an Atom instance called CTL. This is a simple example of a controller which is set up to trigger play all instances - 4 bars of pattern 1 followed by 4 bars of pattern 2.
  2. The AUM transport needs to be running even if you are controlling via an external source.
  3. Launch + Play Pattern are triggered by the same note. This is the key to reliable triggering.
  4. The Play Pattern trigger uses velocity to select one of 16 patterns per instance. I have included a Session Notes AU state in the project for reference but in case you don’t have it, here are the per-pattern velocity ranges (I have a printout next to my iPad :smile: )

One advantage to using a range of velocities is that you do not need to be as precise when setting in whatever app you are using as the controller.

  1. I have included a Record trigger, which is always one note higher than the Launch + Play Pattern note. You can use this to enable gated recording for any pattern and do not need to stop the transport to change which pattern is being recorded to - drag the record trigger note to the note above the pattern select note you want to record to AND you need to manually set the pattern you want to record so that it has “focus”. The playing pattern is not necessarily the one in focus! If you have recorded something and you can not hear it play back then you have almost certainly recorded it into the wrong pattern.
  2. The Record trigger note must be slightly shorter than the Launch/Play Pattern note. If you try and set them to the same length then funky things can happen as REC needs the Launch to have triggered first. I use a 1/64 gap at the start and end but you could experiment with making this smaller if you really need to. I have got up to about 300bpm before the REC trigger would start to randomly skip.
  3. I tried to replicate this setup in apeMatrix but I could not see a way of using notes as automation triggers. It lets you use CCs and the accelerometer to send triggers but not notes, odd.
  4. Obviously no mixdown using this. You can emulate the behaviour in DAWs which let you send AU automation but I have not found a satisfactory workflow. MTS comes closest but you are stuck with drawing in the automation rather than sending simple notes, it worked but was not going to scale.

Some notes about the AU parameter settings:

  1. You might want to use a different channel per instance, it is possible that this could improve triggering responsiveness if each channel is processed in parallel. You could then use multiple controllers or one that uses multiple Atom channel layers.
  2. You can add multiple control sources, not just the Atom CTL instance. External controllers just need to send notes to the AUM port and you can then select this as the control note source.
  3. I tried setting Record to the same note as Launch/Play Pattern but it soon causes the instance to get out of sync.
  4. Change the notes used if you want something closer to the middle of the piano, though if you do this then the template DAW projects below will need to be changed accordingly.

I’m quite excited about experimenting with this setup. The lack of reliance on scripts/CC/PC means that you can be flexible about what you use as the controller - basically anything that sends notes and has a way of modifying velocity of the notes can be used. If you use a fully-featured DAW to host the controller data then you can jump around the timeline at will and also record live audio alongside the controller track. Hosting AUM + DAW in AudioBus would be a good idea to quickly switch between apps.

Edit: added a template with a pattern clear on the note above REC for each track. Be careful with this one as it will clear in-focus patterns if you have note preview on in your orchestrator app and are moving the note around (i.e. “clear pattern” could be sent to multiple instances if you drag notes around with note preview on).

Comments

  • edited August 2021

    .

  • edited July 2021

    Here is a work-in-progress Xequence 2 project to use with the AUM project above, which may or may not speed up the sequencing of patterns:

    It uses a bespoke drum map which I’m not sure is saved with the project so that is also attached.

    Each track has a patterns lane and an arranger lane. The idea is to duplicate clips from the patterns lane, drag them to the arrangement lane, and then resize the clip using X2’s clip stretching function to match the length of the Atom pattern. This lets you “paint” patterns to the timeline for each track without the need to worry about setting note velocities

    There is a special muted REC clip for each track. The note inside is slightly shorter than the length of the clip. The idea here is to drag it over a pattern on the arrangement lane (again resizing to match the pattern clip length) and unmute the clip to have the pattern play with REC enabled. There is also a RecAll clip on a separate REC track which will trigger record on all instances but if you use this then you need to specify a pattern for every track otherwise tracks will be left in launched state. Note that you still need to ensure that the pattern you are recording to has focus as changing the pattern being played does not change the pattern with focus and it is this that gets recorded to.

    Using this workflow you can build up your Atom patterns without stopping the transport.

    Edit: One of the nice things that X2 lets you do is join clips so once you have a few sequenced in the arrangement lane then you can select them all and join them to create a larger clip. This can then be duplicated/aliased so you can build up larger sequences from smaller ones.

  • Awesome cheers for sharing

  • edited July 2021

    Thanks @Poppadocrock.

    Using an external app to orchestrate falls down a bit unfortunately as there is no automated way of clearing a named pattern so that you can do another take. I played with the clear pattern trigger last night but found that it only affects the in-focus pattern (i.e. the one you last physically selected from the pattern list), rather than the playing pattern. I wanted to do something like this:

    This would play pattern 1 with record enabled and then clear the pattern and loop if you did not stop the transport (which you would do when you got your good take). Unfortunately you would need to remember to go into AUM and make sure pattern 1 was in focus first, otherwise you would accidentally delete some other pattern in that instance - too dangerous!

    Edit: the same problem is there for REC - you need to focus the pattern you want to record to so there is more switching between apps than I would like.

    I have attached the NS2 equivalent of the Xequence 2 template which has the clear pattern support. It will need the second AUM template in the original post which includes the clear pattern configuration.

  • edited July 2021

    BM3 template is attached. I think this is my favourite so far as I could store the Atom pattern triggers as BM3 track patterns which can simply be dragged onto the timeline:

    There is also a Clear pattern track. Be very careful not to double-click any of the Clear patterns otherwise they will trigger and clear whatever pattern is in focus. The Clear function can be useful if you have a part you are trying to nail, e.g.

    I was going to do Cubasis next but to be honest I don’t think it will improve on the BM3 workflow.

    I’m going to try and use a few of these environments in anger. I suspect the only one that won’t drive me crazy will be the native AUM one but even then I wonder if the very strict recording trigger is going to miss too many start notes and note tails to make it worth arsing about with.

  • Updated BM3 template to also include per-track record clips as it turns out that you can overlay patterns from the same track. This matches the X2 and NS2 way of doing things and might be easier to use in some circumstances.

  • edited August 2021

    It is a pain disconnecting and reconnecting my nanoKey to each instance for recording. To help with that I have added mfxStrip. With this, all Atom instances receive MIDI data from mfxStrip but only the track corresponding to the channel you select in the mfxStrip knob will receive the data:

    You can connect your nanoKey to mfxStrip and this routes from its default channel 1 to whatever you select in mfxStrip. I found this trick in an old post by @wim, so thanks for that!

    Note that the knob value rounds to the nearest whole number so 6.5 is actually channel 7.

  • edited August 2021

    .

  • Balls, RecAll leaves launch enabled for tracks that don’t specify a pattern :disappointed: When disengaging Record then Launch is left engaged. If you want to use RecAll then you will need to provide a pattern for every track, perhaps leaving pattern 1 blank and using that for the tracks you are not recording into, otherwise they will continue playing whatever pattern was last selected for that track. Looks like using the per-track record may be a better option with this limitation.

  • edited August 2021

    Updated the NS2 template to include a REC lane. I think stacking the record patterns may be the best route forward, e.g.

    or

    Normally you will want to record the same tracks in the next song part so you would just shift the stacked record clip along the timeline and draw a new set of patterns.

  • Stacking individual REC clips works well, plus NS2 per-clip mute to the rescue!

  • edited August 2021

    I have updated the standard template in the original post to introduce a recording lane. The purpose of this is to inject a Record trigger each time the track receives a Launch trigger from your orchestrator. Using this may mean your orchestrator does not need to use record trigger clips. It is most effective if each piece of music you record to is the same number of bars for each ‘scene’.

    To enable recording for a track, activate the Atom instance in the recording lane corresponding to the track you want to start recording to, e.g.

    You will need to ensure the following are true for this to work correctly:

    1. The note length in the recording lane Atom instance must be smaller than the smallest clip being triggered. If you have a 4 bar recording note but are playing a loop in your orchestrator containing a 2 bar clip followed by a 4 bar clip then this will not work as all Record triggering must occur within the boundaries of a Launch. You would need to either record only the 4 bar clip or manually add record command clips in the orchestrator and bypass the record lane Atom instance.
    2. You will see that the recording note starts slightly late and is cut slightly short of the total bar length. If you manually resize the note then this must still be the case. If the note does not contain these gaps then the recording trigger will not work correctly and the launch trigger will also fail to reset between clips.

    Recording will not start until the next clip is launched but you can hit the record button in Atom to manually enable it for that take if you do not wish to wait.

    To save time resizing clips you can try changing the Atom 2 playback tempo multiplier. For example, a 2 bar clip would work with the default 8 bar recording note played back at 4x speed, a 16 bar clip would require 0.5x speed, a 4 bar clip 2x speed. Probably due to the scaling, you may find that this does not quite trigger recording correctly, in which case try bringing in the end of the recording note a little more.

    The above is less relevant now as I have added multiple default record note lengths as patterns inside recorder instances, for convenience. See a few posts down for more info.

    Remember that this will trigger Record for all patterns played on that track so if you want to record into a particular pattern and not the others then you need to ensure your playing timing is tight, loop only the clip you want to record to, or use manual record triggers in the orchestrator.

  • @MisplacedDevelopment said:
    I have attached a new version of the standard template which introduces a recording lane. The purpose of this is to inject a Record trigger each time the track receives a Launch trigger from your orchestrator. Using this may mean your orchestrator does not need to use record trigger clips. It is most effective if each piece of music you record to is the same number of bars for each ‘scene’.

    To enable recording for a track, activate the Atom instance in the recording lane corresponding to the track you want to start recording to, e.g.

    You will see that by default the recording Atom instances contain an 8 bar record command, which is routed to AUM MIDI Control. You will need to ensure the following are true for this to work correctly:

    1. The note length in the recording lane Atom instance must be smaller than the smallest clip being triggered. If you have a 4 bar recording note but are playing a loop in your orchestrator containing a 2 bar clip followed by a 4 bar clip then this will not work as all Record triggering must occur within the boundaries of a Launch. You would need to either record only the 4 bar clip or manually add record command clips in the orchestrator and bypass the record lane Atom instance.
    2. You will see that the recording note starts slightly late and is cut slightly short of the total bar length. If you manually resize the note then this must still be the case. If the note does not contain these gaps then the recording trigger will not work correctly and the launch trigger will also fail to reset between clips.

    To save time resizing clips you can try changing the Atom 2 playback tempo multiplier. For example, a 2 bar clip would work with the default 8 bar recording note played back at 4x speed, a 16 bar clip would require 0.5x speed, a 4 bar clip 2x speed. Probably due to the scaling, you may find that this does not quite trigger recording correctly, in which case try bringing in the end of the recording note a little more.

    Remember that this will trigger Record for all patterns played on that track so if you want to record into a particular pattern and not the others then you need to ensure your playing timing is tight, loop only the clip you want to record to, or use manual record triggers in the orchestrator.

    I will need to do some further testing and will replace the version in the original post with this one if all goes well.

    Thank you for this. What’s the outcome if you don’t own mfxstrip?

  • @gusgranite you would need to reconfigure the routing the way you wanted it so that your controller can talk to each track.

    At the moment they all listen to mfxStrip on different channels but if you had a keyboard or app that could manually change channels then you could just connect an instance of it to every Atom instance and you would be good to go.

    If you are not planning on recording more than one track at a time then there would not be anything wrong with connecting your input device to all instances and make them all listen on the same channel. You would just need to be careful about which tracks are being recorded to.

    The big hump to get over is making sure the pattern you want to record to has focus as the playing pattern is not necessarily the one that gets recorded to.

  • edited August 2021

    .

  • edited August 2021

    Uploaded version with different length notes in the recording Atoms for convenience. Mapped as follows:

    P1 - 1 bar
    P2 - 2
    P3 - 4
    P4 - 8
    P5 - 16
    P6 - 32
    P7 - 3
    P8 - 6
    P9 - 12
    P10 - 24

    Added a separate project containing a demo orchestrator to test out the different recorder lengths. You should just be able to launch it and toggle the recorders it to see them in action. Note that the default bar lengths of the clips is different depending on the recorder it is testing.

  • edited August 2021

    Note that if you import this project into an existing AUM session then you will need to manually reconnect the record note instances AND CTL controller instance (if you are using it) to MIDI Control as AUM does not seem to preserve these connections from the project:

  • I realised that the template that demonstrated the recording function was not very useful for getting a song started so I have renamed it *Demo and changed the default to have:

    • Pattern 1 selected by default
    • All instances default to 4 bars per pattern
    • Recording Atoms have the 4 bar note pattern selected
    • Demo instance contains a simple 2 x 4 bar trigger which plays pattern 1 then pattern 2 of each instance

    With this setup you just need to attach instruments to Atom instances and hit play to start working on a piece.

  • edited August 2021

    Auria Pro project, thanks to Transpose function :smile: Auria seems to recalculate the clips at the start of each loop so if you add one then it will not start to trigger until the next loop. Hitting stop does not seem to send note offs so if a clip is playing when you stop the Auria transport then it will continue in AUM. You should therefore try and stop when no clips are playing otherwise you’ll need to reset the launch state, or just ignore the tracks that should not be playing until the song retriggers the correct state.

  • Cubasis I think is the last of the clip-on-timeline based DAWs I own. Again, Transpose was very useful.

    Project size is tiny compared to Auria.

  • This just makes me mad, because it looks like fun but I don't understand a lick of it. LMAO - can you make a youtube video?? Preferably one with quick cuts and edits, with memes that flash on the screen to coddle my shallow attention span.

  • @ElkwoodDarrow said:
    This just makes me mad, because it looks like fun but I don't understand a lick of it. LMAO - can you make a youtube video?? Preferably one with quick cuts and edits, with memes that flash on the screen to coddle my shallow attention span.

    :smile: I had forgotten about this. No, it was mainly something I did as a challenge to see what was possible. Far too clunky to use in reality and have since switched to LK and GarageBand Live Loops but it was fun getting to know some of the iOS DAWs a little better. If a “record-while-triggering” mode is added to Atom at some point in the future then I may revisit but for now it is one for the “it kinda works but…” drawer!

  • @MisplacedDevelopment sorry to dredge this up, but do you know if there’s a way to choose which pattern you’re recording into without opening atom2? I’m using au params for switching (play) patterns, launching, and toggling record in atom 2 instances, but I can’t see a param for switching pattern focus for recording.

  • @gregsmith said:
    @MisplacedDevelopment sorry to dredge this up, but do you know if there’s a way to choose which pattern you’re recording into without opening atom2? I’m using au params for switching (play) patterns, launching, and toggling record in atom 2 instances, but I can’t see a param for switching pattern focus for recording.

    I’m afraid not, as far I as could tell. It made the use of pattern switching via parameters actually quite dangerous since you can easily clear or record into the wrong pattern. An option to set the focus to follow the currently selected pattern would done the trick.

  • @MisplacedDevelopment said:

    @gregsmith said:
    @MisplacedDevelopment sorry to dredge this up, but do you know if there’s a way to choose which pattern you’re recording into without opening atom2? I’m using au params for switching (play) patterns, launching, and toggling record in atom 2 instances, but I can’t see a param for switching pattern focus for recording.

    I’m afraid not, as far I as could tell. It made the use of pattern switching via parameters actually quite dangerous since you can easily clear or record into the wrong pattern. An option to set the focus to follow the currently selected pattern would done the trick.

    Thanks. Fortunately it’s not a showstopper for what I’m trying to do at all. Just would have been convenient. But as you say, it’s pretty dangerous. At least atom2 has undo.

Sign In or Register to comment.