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.

What Ableton Link info does AUM get from looper app, and what does it provide to AUv3 (e.g. Mozaic)?

edited August 2020 in General App Discussion

Hey everybody

I'm using AUM as the "central" of my looping apps:

  • It sends to (and receives from) Group The Loop (GTL)
  • It hosts Mozaic where I can intercept, modify, and generate MIDI signals

Everything is synced using Ableton Link. And in Mozaic I can use the @OnNewBar, @OnNewBeat events, as well as the HostBeatsPerMeasure to do stuff synced with GTL.

What I'm missing though is an event that is triggered when GTL's cursor is set back to the beginning of the played group. As far as I understand, this is dependant on the longest loop in the current group, and it's called "general phase" according to the people in the GTL forum, where I asked a similar question, and Jack (the creator of GTL) answered:

GTL and AUM share tempo and phase info via Ableton Link. So AUM does not know the individual loop lengths in GTL but it does know the general phase. Ableton Link phase allows the apps to keep sequences in time. For example, if you have two 8 bar loops they will start playing at the same time. As GTL can have many different loop lengths so only the longest even loops are reported to the Ableton Link session. It's possible to change this in Settings -> Clock Settings -> Sync Quantum. If you change the Sync Quantum to 4 bars, for example, GTL will always remain in phase with 4 bar sequences in other apps.

Presumably AUM sends timing info to its AUv3 plugins so if GTL and AUM are phase aligned via Ableton Link this information should be relayed to the plugin in AUM.

So: where is the @OnNewPhase event! Or how can I retrieve this info in AUM/Mozaic?

Thanks a lot.
Joshua

Comments

  • @josh83 said:
    Hey everybody

    I'm using AUM as the "central" of my looping apps:

    • It sends to (and receives from) Group The Loop (GTL)
    • It hosts Mozaic where I can intercept, modify, and generate MIDI signals

    Everything is synced using Ableton Link. And in Mozaic I can use the @OnNewBar, @OnNewBeat events, as well as the HostBeatsPerMeasure to do stuff synced with GTL.

    What I'm missing though is an event that is triggered when GTL's cursor is set back to the beginning of the played group. As far as I understand, this is dependant on the longest loop in the current group, and it's called "general phase" according to the people in the GTL forum, where I asked a similar question, and Jack (the creator of GTL) answered:

    GTL and AUM share tempo and phase info via Ableton Link. So AUM does not know the individual loop lengths in GTL but it does know the general phase. Ableton Link phase allows the apps to keep sequences in time. For example, if you have two 8 bar loops they will start playing at the same time. As GTL can have many different loop lengths so only the longest even loops are reported to the Ableton Link session. It's possible to change this in Settings -> Clock Settings -> Sync Quantum. If you change the Sync Quantum to 4 bars, for example, GTL will always remain in phase with 4 bar sequences in other apps.

    Presumably AUM sends timing info to its AUv3 plugins so if GTL and AUM are phase aligned via Ableton Link this information should be relayed to the plugin in AUM.

    So: where is the @OnNewPhase event! Or how can I retrieve this info in AUM/Mozaic?

    Thanks a lot.
    Joshua

    Phase just means start of measure I believe. Ableton link doesn't transmit timeline info but has phase so that clients can sync up their measures

  • edited August 2020

    So what exactly does @OnNewBar do? It is triggered whenever the current loop restarts? Or when the currently selected clock length is reached again?

    Any other idea how to receive this information from GTL then? Maybe GTL could send some MIDI info?

  • @josh83 Mozaic’s OnNewBar is triggered at each host bar start.

    In AUMs small timing line seen in the top left below the current host bar and host beat numbers, that happens at the moment when the timing line changes from completely full to completely empty - but only if AUMs timeline is running.

    I just checked - with Ableton Link enabled and a Link enabled app in the background, the bar graph runs and resets even if AUMs timeline is stopped - but no OnNewBar is triggered in Mozaic.

  • Thanks for checking that out.

    I need to precisely change some settings in GTL at the end of a "general phase" (respectively at the start of the next one), for example when I want to switch between the Tonebridge effects on my guitar.

    It seems I will have to do some trickery in the background to be able to trigger some MIDI as close to the end/start of GTL's "general phase". My current idea is that the user has to time his/her input (button press) to change this setting inside the last bar of the running "general phase", and (if I understand correctly) I then can simply use the @OnNewBar event to apply those settings to GTL.

  • wimwim
    edited August 2020

    Or, maybe manually set the longest loop length in Mozaic, then count bars?

    You can also make your own "quantum" of a longer length, if one bar is too short. For instance, you could keep track of how many bars have played and...

    if (barsPlayed % 2 = 0) and (eventPending = YES)
      eventPending = NO
      // Do something...
    endif
    

    You might find some inspiration in https://patchstorage.com/toggle-channels-on-bar-divisions/ by @_ki .

  • _ki_ki
    edited August 2020

    For switching presets i would suggest to fire the needed midi commands not ‚right on the new bar‘ where they need to be applied, but a tiny bit before that.

    For this purpose, i use the OnMetroPulse event and in that event first check the HostBar (to be one less than when i want to send) and then check the CurrentMetroPulse to be one before the end.

    @OnLoad
      ppqn = 4
      SetMetroPPQN ppqn    
      pulsePerBar = HostBeatsPerMeasure * ppqn
    
      triggerBar = 3
    @End
    
    @OnMetroPulse
      Log HostBar,{:},HostBeat, { - },CurrentMetroPulse 
    
      if HostBar = triggerBar -1 
        if CurrentMetroPulse = pulsePerBar-1
          Log {Just before the new bar 3}
        endif
      endif
    @End 
    
    @OnNewBar
      Log { ---- New Bar }
    @End
    

    With a ppqn of 4 PulsePerQuarterNote) and a 4/4 timing, you get 16 pulses per bar. The example code fires 1/16 before bar 4. If you want to act 1/64 or 1/128 before the bar, use a ppqn of 16 or 32.

    The HostBar internal count starts with 0, so the code actually waits 4 bars.

    .

    I needed to use this ‚trick‘ when switching Step Poly ARP pattern - otherwise the very first note of a bar still used the old pattern definition.

  • Yeah I thought about that possible problem too, @_ki. AUv3 effects need a moment to load, depending on their heaviness. Tonebridge loads pretty fast, other ones load slower. Thanks a lot for providing this code. Why do you use @OnMetroPulse instead of simply @OnNewBeat (while somehow counting the beats)?

    For a midi effect your code seems very suitable. For an effect that relies on "live" audio data (like a distortion amp, e.g. Tonebridge) it's very important that the switch happens not too early, otherwise there will be artefacts in the end of the "previous" loop. I thought of the following: when switching the Tonebridge preset, I would 1) fade out the guitar, 2) switch the preset, 3) fade in the guitar. 1) and 2) would happen at the very end of the "previous" loop, 3) would happen right at the beginning of the "next" loop.

    Sounds a bit complicated, but let's see what I can accomplish with the given situation. :smile:

  • _ki_ki
    edited August 2020

    OnNewBeat happens every quarter note - as you mentioned its not adviable to change presets too early - for instant the pattern change of StepPolyArp happens immediately so it would change about a quarter before it should happen.

    The provided code fires 1/16, 1/32 or 1/64 or 1/128 before the next bar. Too short for a new note to sneak in while to switch happens. At the bar, the new pattern is applied, so sequenced new notes play with the new pattern.

    .

    The problem isn‘t only the time needed for the pattern switch itself - as said this happens instantly in most plugins. Its in the midi routing between the AUs and hosts, and the order the message are delivered to the destination.

    Even if in all the everything happens instantly in all the AUv3s involved (midi note generator, pattern change event generator and the receiver doing the pattern switch and playing the note) you run into problems when looking at what internaly happens in a midi event timeslot.

    The midi generator is playing its note right on the bars timeslot, the pattern change plugin is playing right on the bars timeslot - but both messages have to be delivered by the host to the receiver. The order inside the midi event queue depends on the order of plugin execution. All AUv3 run in the same thread and i think there‘s another thread for the hosts midi sending. You can‘t really influence the order of AUv3 execution, its up to the host - and it maybe differs from initial session setup to later loading the same batch from a session preset.

    So if the note generator is executed first, then its note will be first in the input event queue of StepPolyARP and the pattern change is the second event for the same timeslot. StepPolyARP runs through this event queue in order - so the note will play with the old pattern, then the pattern change happens - all in the same processing timeslot. SPA would need to first look through its queue and scan for pattern changes to execute these with priority - but it doesn‘t do so. Most dev‘s don‘t account for this very specific problem when implementing midi automatable pattern change.

    .

    I expect the same thing happen with other AUv3 plugins that offer pattern switching via midi and that also eact to midi input (Arps, tranpossition) and whenever there are two different input sources for the note change and pattern change.

    And it probably also occurs for AUv3 parameter changes. In AUM these also go through the midi event delivery queue system before arriving at the receivers AUv3 parameter callback. And it‘s not even arriving in the midi event queue, where the note may have already arrived and has been handled.

  • Thanks for the exhaustive explanation. I understood only a bit of it, but it's good to know that there are things to look out for. I will just see how I proceed...

  • _ki_ki
    edited August 2020

    Instead of using OnMetroPulse one could also setup an OnTimer event - but do to asynchronity from timer to the hosts beat time steps, this would need to run twice as fast as the MetroPulse variant to garantee a specific time interval before a new bar (shannon theorem).

    With OnMetroPulse and a wanted time interval of 1/32th, the ppqn is 8 to produce 32 steps of the event, independant of the host tempo which lets say is 120bpm or 2000ms. The OnMetroPulse events will happen every 62.5msecs.

    If you would setup a timer interval of 62.5, the OnTimer will also happen every 62.5msec - but there will be a phase difference between the two as the timer does not start right on the bar. It could start up to 62.4msec after the bar - and using this ‚bad phased timer‘ would fire the message only 0.1msec before the bar, not 62.5ms as we intended to achieve.
    So one needs to set the timer to 31msec and start 3 ticks before the new bar is expected - resulting in an timer interval from 91 to 62 msec befere the bar, depending on the phase of the timer vs the metro pulses. The ‚62ms before bar‘ target is met in any phase.

    And additionally you have to adapt the TimerIntervall with every tempo change.

    .

    Thats why its for this use-case its a lot easier to use OnMetroPulse. No timing adaption and synced timing.

    .

    BTW: I‘ve done both, so these statements are no speculation but lessons learned

Sign In or Register to comment.