Some Thoughts on Tempo Sync in Audulus

midi
ableton-link

#1

I’ve been thinking quite a bit lately about tempo synchronization between Audulus and other external apps. There have been a number of posts related to Ableton Link and other synchronization technologies, and I thought I would share my thoughts on how these technologies might be implemented in the Audulus environment.

There are three primary tempo syncing methods in common use today. The oldest of the three is part of the MIDI standard and is commonly used to sync tempos between multiple hardware devices and software controlling hardware devices. There are two MIDI clocks in use. The first is MTC or Midi Time Code which encodes the absolute time and is sent with a rate of between 24 and 30 frames per second to align with commonly used video frame rates. The second is the Midi Beat Clock which is tempo dependent and and divides time into 24 pulses per quarter note. There is also a Song Position Pointer that specifies how many 16th notes have passed since the start of the song. With MIDI sync, one device is typically designated as the master clock source and other devices sync to the clock provided by the master.

The second method is used with both AU and VST audio plug-ins and is also supported in IAA (Inter-App Audio). In this case the plug-in can retrieve both a raw “transport” time and tempo information in the form of time signature, tempo (BPM), and current position relative to beat and measure. The host software is the master and provides timing to the plug-in. Audulus already provides access to the raw transport clock via the Time node.

The third mechanism which has gained in popularity in the last few years is Ableton Link. This is a protocol and accompanying software developed by the Ableton company to allow various musical applications running on the same or different platforms but connected by a common network to synchronize with each other. Unlike MIDI sync or traditional plug-in sync, Link does not have a single master clock. Each device maintains its own timebase and any device can request an alteration of the tempo or request to start and stop the session. Similar to the other methods, Ableton Link provides an application with tempo, beat position and position within a “measure”.

Because the three technologies are fairly similar in concept, with Ableton being the most complex from an implementation perspective, I believe that the strategy used to implement Ableton Link should be able to encompass the other methods as well.

The first question is what new functionality would be added to Audulus by implementing external synchronization? It’s already possible to synchronize various modules within a patch by using a shared clock and clock signals can be received from and sent to external sources via the existing I/O capabilities. However existing capabilities do not allow one to easily sync tempos with other applications, DAW software or MIDI connected hardware. With plans in place to expand the MIDI capabilities of Audulus and an AUv3 in development, I thought now would be a good time to consider how sync might look in Audulus.

Ableton Link has implementation requirements that will dictate some elements of a potential sync node. Enabling/disabling Link (and presumably MIDI) will most likely need to be done within the settings menu rather than at the patch level. Assuming that Link is enabled and a session is available on the network, what inputs and outputs should we expect? Link provides beat, time and tempo to session participants and participants can send tempo change requests, a synchronization quantum (roughly time signature), and start/stop requests. One consideration of Link implementation is that when a client joins an existing session it must adopt the current tempo and should only request a change in response to user action. This precludes using a tempo input on the node attached to a knob or something else that would request an initial tempo value on loading a patch. Rather the sync node should align itself with the current tempo received from Link. It would be useful to have some mechanism for requesting a tempo change which is accessible in a performance environment, perhaps up down buttons on the sync node or located elsewhere on the UI. The same considerations apply to stop/start requests.

What outputs would be useful? I would suggest that a clock at the beat frequency, one at 24 per quarter note and one at the sync quantum should be provided. Additionally the current tempo, beat, time signature and position within the measure should be available as outputs, as well as a run/stop gate.
There are two existing nodes which would primarily be involved in synchronization, the delay node and the phasor node. The delay node is the basis for most time related audio effects and the phasor is the fundamental building block for most LFO’s. Ideally there would be some mechanism to optionally synchronize these nodes to some division of the beat clock. Perhaps an input which if not zero, would represent some number of 24 ppqn clock pulses. This input would override the Hz and sync inputs if non-zero and a sync source was available.

Similar timing data is available from MIDI and plug-in environments which should lend itself to using a common approach for all three methods. With MIDI, Audulus could potentially act as a sync source (given appropriate MIDI out) as well as a client. Plug-ins only act as a clients and so would have no active inputs to the sync node. I might note that the sync methods are typically mutually exclusive. Ableton strongly recommends that enabling Link should disable other sync methods to avoid conflicts and provides mechanisms to operate within an AUv3/IAA/Audiobus environment where it supersedes other sync mechanisms.

The final consideration is what to do when no sync source is available. I would suggest that the sync node remain functional and and operate as a free-running oscillator. This would provide a convenient “master” beat clock with subdivided outputs for a patch if desired. It would be necessary in any case with Link enabled since Audulus could potentially be the first device to start a Link session. A default tempo could be established for the app or possibly even saved with each patch.

I would like to stress that these are solely my opinions and do not represent any intent on the part of the Audulus developers. I have no knowledge of any future development plans other than those that have been made public on the user forum.


#2

I will reply to this at greater length later, but we are definitely going to add Ableton Link to Audulus 4.

The only question is how it will be implemented. It will definitely be a node of some kind, but what kind of inputs and outputs it has is up in the air.

But you bring up an interesting point, if not directly - Ableton Link is for syncing Ableton and other devices together. It doesn’t work for linking hardware to Audulus. It’s worth it to explore other options for creating non-DAW-specific link options.


#3

I understand that no decisions have been made regarding the eventual implementation of Ableton Link. I thought I would add my two cents worth for your consideration. Having looked at Ableton Link, sync in AUs, VSTs, IAA and MIDI, I think that a common approach to syncing is possible. Ableton will definitely be the most challenging since it requires dynamically adapting to a shared tempo, but the libraries Ableton provides should shorten the development time. Once the necessary Audulus code is in place to support Ableton link, I think the other sync mechanisms will be relatively simple to implement. I can’t imagine an expanded MIDI library without some form of MIDI sync. MIDI Sync is also used with Audiobus and can be used with IAA, although it’s not the recommended approach. It’s certainly the most flexible of all the approaches since it can be used with both hardware and software. I hadn’t played with the Time node until today, but after playing with it, other than having to enter the tempo, time signature etc. manually rather than getting it from the DAW, its should be possible to build a sync unit using the transport time already available. Of course that won’t help with sync outside the plug-in. I plan to play around with it in the near future and I’ll post anything useful.


#4

I like your approach of working from the most complex protocol and then using that as the lowest common denominator so that patches can be created while at the Audulus settings level, the user can set their sync protocol and the patches will still work rather than having to create patches which are sync protocol specific.

Link and MIDI sync protocols will not be identical so having modules or nodes that support what they have in common would be ideal as would those which are specific to each protocol to maximize both patch flexibility and specificity.

In iOS you can have: standalone link or MIDI sync; hosted by IAA with link, MIDI, or host sync; hosted by AU where the host app controls sync; and Audiobus 3 sync (Audiobus 4 will soon be beta testing).

Link isn’t just a software protocol, it can be used for hardware too and I anticipate this to become more frequent in the future.


#5

There’s certainly no reason why Link couldn’t be implemented in hardware. In fact check this out for Eurorack Rigs! : http://cdm.link/2017/02/now-can-sync-ableton-link-eurorack-open-board/


#6

Excellent post @stschoen. Great overview of the sync methods and I like the suggestions.

I believe that the strategy used to implement Ableton Link should be able to encompass the other methods as well.

This is my hope as well! I’d like the same patch to be compatible with all sync methods.

A default tempo could be established for the app or possibly even saved with each patch.

Yes, I think we may introduce a global tempo/transport, which Link would affect. I’m hoping we can do this UI without using up much screen space. One thing I love about the Audulus UI is how there are few controls outside of the patch itself.


#7

I did some preliminary investigation using the time node in the current AU plug-in, but discovered that there appears to be some “noise” in the output. I was using the condition time == 0 as a gate and even when the transport was stopped I was getting activity on the gate. Additionally, although the timing was for the most part pretty accurate, I would occasionally get a missed beat. The same patch ran flawlessly using the Timer, so I suspect it’s a glitch in the time node. Certainly not worth fixing in light of the upcoming revision to the AU. I would see the transport time node being deprecated and integrated into the sync node in any case. Other than enablement for the various sync methods, which probably belongs in the tools menu, I don’t see sync taking up any UI at all other than the space for the node.
After playing with the prototype, I believe that a single node could serve to implement sync in Audulus. You could configure and persist the default tempo and time signature internally inside the sync node much as the MIDI channel and mode is currently set on the keyboard node. In this way patches not requiring sync would not incur any additional overhead or lose any screen space. If no sync node were present in the patch you could bypass any sync processing. At load time you could check to see if a sync node were present in the patch and which if any sync methods were enabled and take appropriate actions. On exit from the patch you would then exit the sync session. For simplicities sake, it might be wise to limit a patch to one sync node or if more than one node were allowed, mirror them internally.
I’ve requested access to the Ableton Link SDK for iOS, but I haven’t heard back as yet.