As Pro Tools continues to remain the standard currency of session interchange between composers, recording studios and post-production houses, many composers are finding project workflow can be improved by running Pro Tools in conjunction with their writing systems in their personal studios.
Doing so allows composers to treat Pro Tools as a tape machine, laying down stems from their composition DAW into a multitrack session format suitable for live musician recording at a studio - and then bringing the recorded sessions back to their composition studio for editing into a format suitable for delivering to post-production.
Whilst this is - to a large extent - possible with time-stamped WAV files exported from the composition DAW, such a process can be time-consuming and prone to error. Consequently we are seeing more composers building Pro Tools layback into their regular workflow, by inserting a Pro Tools system between their composition DAW and monitoring.
Whilst care needs to be taken to avoid adding unwanted latency to the monitoring with this addition, care should also be taken to ensure that, during printing of stems, the playheads between composition DAW and Pro Tools are in sync - so that a timecode-locked cue in the composition DAW appears at the correct timecode position in Pro Tools.
This requirement is even more stringent when multiple passes of a cue are required to transfer all required tracks from composition DAW to Pro Tools: if the timecode lock between systems is not accurate and repeatable, then the tracks will not all be accurately time-aligned in the Pro Tools session.
Given a recent conversation between some of our professional clients, we decided to investigate this topic further and perform some tests so we really understood exactly what the systems were capable of.
If you just want to learn the outcome of our tests, you can skip straight to the conclusion here.
MTC
Whilst the world of digital audio technology has introduced us to all manner of new wonders, the ability to lock two different DAWs together still relies on an older technology: MIDI Timecode (MTC). Whilst we might now be able to feed a thousand channels of digital audio down a single network cable, synchronisation is still decidedly old-school.
The original MTC specification was created by two engineers from Digidesign in 1987 - just four years after the original MIDI specification was standardised. Prior to the widespread adoption of computers for audio, an audio-band SMPTE timecode (also known as LTC - Linear Timecode - as it was striped on a linear tape track) was used to synchronise tape machines and video recorders - and its uncanny ability to bleed into unwanted audio signal paths was one of the banes of the studio technical engineer’s life.
Timeline Lynx-2 synchronisers, commonly used for synchronising professional audio and video tape machines.
Using a Timeline Microlynx to synchronise a tape machine to an MTC output from Cubase.
MTC has, over the years, gained an unfair reputation for not being very accurate compared with a ‘traditional’ audio SMPTE signal - and some users consequently advocate using a SMPTE signal to connect two DAWs together. However, the situation is not entirely black and burst white:
Whilst it is true that a congested MIDI path could cause some variation in the timing of MTC signals, a sufficiently well-developed MTC interpretation engine should be able to smooth these out without significant issue. Additionally, the proliferation of fast computer interfaces available for transmitting MIDI from one system to another affords an easily-available non-congested MIDI pipe - allowing MTC messages to be transmitted with high timing resolution;
Likewise, whilst a SMPTE signal potentially offers 80 points in every frame for ensuring that the receiving unit is in sync, MTC only guarantees that there is a reliable sync point every 2 frames. Whilst this might have been a problem in the days of mechanical tape machines whose only speed reference was an incoming SMPTE feed, today’s digitally-controlled and digitally-locked DAWs do not need such resolution in their timecode stream;
In general, using a SMPTE signal to connect two DAWs together will require conversion from and to MTC at each end anyway - thus negating any potential benefits offered by the increased timing events that a SMPTE signal offers.
There are also a few proprietary systems available for improving the sync between two DAWs - but they are limited in their application:
Pro Tools|HDX and Pro Tools|HD Native support the Avid Sync HD interface, which provides a proprietary connection into the HDX PCIe card / HD Native interface. By using such a proprietary protocol, Avid can avoid sending timecode messages through the MIDI layer of the host OS and thereby claim ‘near sample-accurate lock’;
Pro Tools systems can link together using Avid’s Satellite Link feature - though each system requires an Avid Sync HD interface (and Pro Tools HD hardware) to achieve ‘near sample-accurate lock’. Of course, this only allows the synchronisation of multiple Pro Tools systems;
Steinberg’s VST System Link can link multiple Cubase or Nuendo systems for ‘sample-accurate synchronization’. Of course, this only allows the synchronisation of multiple Steinberg systems.
Given that, in our experience, the composition DAW is rarely the same as the delivery DAW (usually Pro Tools), we will not be testing these proprietary setups.
What to test for?
Synchronisation is a surprisingly subtle art - there are many factors which may or may not play a part in whether two systems are ‘in sync’ or not.
The factors that we are going to consider here are as follows:
Positional Accuracy: Is the audio output being delivered at the expected time in relation to the timecode output - or is, for example, the audio output being played late with respect to the timecode output?
Positional Offset Variation: Is the relationship between audio output and timecode output consistent between each pass, or does the relationship vary (all other factors being equal)?
Plug-in Delay Compensation: Does the relationship between audio output and timecode output vary according to the amount of plug-in delay present in the mixer of the composition DAW?
Audio Buffer Compensation: Does the relationship between audio output and timecode output vary according to the size of the audio buffer set in the composition DAW?
Timecode Master vs Timecode Slave: Does the composition DAW behave any differently, depending on whether it is the timecode master or timecode slave?
Alternative Timecode Options: How else can a timecode output be derived from the composition DAW?
Whilst drift can also be a concern (where two systems start off in sync, but then drift apart as they continue over time), this will not be covered here: with two digital audio systems correctly clocked, drift should not be an issue as the common audio clock ensures they are always running at the same speed, and thus cannot drift apart.
The testing setup we’re using is as follows:
The composition DAW has a constructed audio file which plays a spike every second. Running from 01:00:00:00, we should expect to see a spike occur at every seconds marker (as in hours:minutes:seconds);
Logic Pro X with the test project loaded, with a spike at every second on the timeline.
Detail of the spike, showing its exact alignment.
The composition DAW plays out this audio file through a high-quality audio interface, into a second high-quality audio interface connected to a second computer running Pro Tools. The connection is made digitally, to avoid (admittedly small) timing measurement issues caused by smearing of the spike due to the reconstruction filter in the DA converter, and allowing us to easily measure down to the sample level;
Digital vs analogue recording of the spike - the analogue recording is slightly smeared, making it more difficult to measure its alignment.
The composition DAW also plays out MTC, which Pro Tools receives and chases. We’re using ipMIDI to pass 25fps MTC from one system to another. Whilst some people have concerns about the accuracy of such a setup, our tests have shown there to be no significant difference between using ipMIDI and ‘traditional’ MIDI interconnections;
By default we’re using a 64 sample I/O buffer on both the composition DAW and in Pro Tools, both running at 48kHz sample rate;
Six passes are made where Pro Tools records the incoming audio against the incoming MTC from each DAW.
Whilst there are other factors that may have an effect on the measurements (such as whether the composition DAW always plays all tracks synchronously, or whether different audio channels always arrive in sync through the interfaces), these effects are likely to be very minor and, whilst of academic interest, do not help inform the real-world application we’re considering here.
Our test system.
The Testees
The DAWs that are going to be tested here are:
Apple Logic Pro X 10.4.8
Steinberg Cubase Pro 10.5.12
MotU Digital Performer 10.11
Avid Pro Tools 2020.3
Cockos Reaper 6.08
We were also going to include Presonus Studio One 4 Professional 4.6.1, this being a DAW this is gaining some popularity amongst Pro Tools refugees. However, Studio One’s timecode capabilities are very rudimentary:
Although it can send MTC, it did not do so with the correct hour offset in our tests;
It cannot chase MTC at all.
So let’s get going…
Test 1 - Positional Accuracy
This test will judge how far off the target position a recording has been made, by looking at the discrepancy between the seconds markers in the Pro Tools grid and where the recorded spikes land in the timeline.
With six passes being made, we’re using the average of the six to determine a measurement for each DAW. In an ideal world, this figure should be as close to zero as possible.
Six record passes in Pro Tools.
Here’s what a typical recording looks like closeup, highlighting the difference between the recorded spike and the timeline position where it should have landed:
Measuring the offset from the start of the spike to the seconds marker in Pro Tools.
And here’s what we found for each of the DAWs:
So although each DAW was using the same hardware and same MIDI-layer software to send MTC to Pro Tools, the range of offsets varied considerably from one DAW to another.
In ‘real’ terms, these offsets are relatively small: Digital Performer’s comparatively large offset here still only corresponds to 4.5ms, or 0.1 frame at 25fps/48kHz.
As to why there might be variations in this offset between the different DAWs: for the moment putting any possibility of bugs in the DAW aside, this could be accounted for with differing buffering practices between the applications. Even though each DAW has been configured for a 64 sample I/O buffer, this is not to say that they each handle this in the same way as each other - or that the buffers between their audio outputs and MTC outputs are handled equally.
It is notable that the DAW with the closest offset is Pro Tools itself: it rather makes sense that Pro Tools would have consistent handling of playback and recording such that it ends up in time with itself.
Whichever setup is used though, it would need to be calibrated for correction for a given set of audio hardware and software - but this calibration should not need to be repeated for every project file used…
Test 2 - Positional Offset Variation
Digging deeper into the measurements from the previous test, this looks at the spread of offsets across the six passes for each DAW. Even in the presence of an offset in the recording, if this offset is consistent then it is easier to correct for - but a wide range of offsets can result in the timing between recorded passes being very loose. In an ideal world, this figure should be as close to zero as possible.
Here are the raw measurements for each recording pass:
And here’s the range of each DAW’s offsets:
Already it can be seen that one popular DAW performs significantly more loosely than the others… This can be explained with the likely presumption that, given its MIDI sequencer heritage (and persistent ancient MIDI engine architecture), Logic is running the MTC generation from its MIDI engine, which has a resolution of 960 ticks per quarter note; at 60bpm (at which our project was running), this equates to a maximum resolution of 50 samples - just as we have measured. Whilst that was sufficient with the original release of Emagic Notator Logic in 1993, it doesn’t really cut it 27 years later…
It is interesting to note that the tightest lock - from Pro Tools - at 7 samples variation is within the bounds of lock of a high-quality SMPTE-based synchroniser, which would typically lock to within 0.01 frame (or 19 samples). So much for the supposed inferiority of MTC…
Test 3 - Plug-in Delay Compensation
This test is to be compared against Test 1, but with the presence of a delay-inducing plug-in in the composition DAW. What we would expect is that any delay in the audio path is mirrored by an equal delay in the timecode output - so they still emerge from the composition DAW synchronously. (We ensured that the plug-in delay compensation feature in the composition DAW was enabled, so the DAW ‘knows’ that it should be compensating for delays in the mixer.)
For this test, we inserted a Waves L3 Ultramaximizer plug-in in the main stereo output path of the composition DAW; this adds 3840 samples of delay to the audio output - but we should still expect to see the positional offset mirror that which we found in Test 1.
Digital Performer with the test project, and Waves L3 inserted.
Eyes down for a full house:
Did you spot the difference? ;-) Logic has not compensated for the addition of the plug-in in the output path at all - and now the sync offset is 3840 samples late - 80ms, or 2 whole frames at 25fps/48kHz. This is in spite of a setting (new in Logic Pro X 10.4.5) that is specifically for applying Plug-in Delay Compensation to the sync outputs:
Logic Pro X with ‘Plug-in Delay Compensation’ enabled for the MTC output.
Looking at the variation in offset between each pass:
Most DAWs are consistent with the first set of tests - except Digital Performer, whose variation goes up by a factor of 4 - we don’t know why that might be.
Test 4 - Audio Buffer Compensation
The tests so far have been conducted with an audio buffer of 64 samples on the composition DAW; for this test, we’re looking to see if setting the audio buffer to 512 samples makes any difference to the positional accuracy.
Again, we would hope that the composition DAW correctly compensates for delays through its audio output in order to ensure that the timecode generation is still in sync.
If you don’t want to know the score, look away now:
This is suddenly not looking very good: 60% of our testees are now in the wrong place - only Cubase and Reaper appear to have correctly compensated for the buffer size, whereas:
Logic and Pro Tools appear to have not attempted to compensate at all;
Digital Performer appears to have compensated twiceover, and is delaying the timecode output by two buffer lengths instead of one…
And someone’s going to be red-faced when you look at the spread in offsets across all the passes:
Whilst the other four reflect their original spread (within measurement error), Logic appears to have gone to the pub and left the work experience student just throwing out a timecode stream with no respect to how the audio buffer frames line up against the timecode frames. This results in a variation between passes of 9ms, or 0.2 frames at 25fps.
Logic Pro X spike ‘alignment’ with a 512 sample I/O buffer, recorded in Pro Tools.
Test 5 - Timecode Master vs Timecode Slave
Generating timecode and chasing timecode are two very different operations - and it’s not true to generalise that the behaviour for one will be reflected by the other. So let’s look for any difference in behaviour when the composition DAW becomes the timecode slave in the system, chasing an incoming timecode feed from Pro Tools.
Given that an incoming timecode stream is a consistent signal (once it has been correctly interpreted and locked against), it should be possible for the composition DAW to align its playback chasing such that audio output is in sync with the incoming timecode feed - accounting for mixer delays and plug-in buffers.
Cubase with the test project loaded.
This report just in:
The big changes here are that Logic is significantly more ahead of the beat than it was previously, and that Digital Performer’s accuracy has worsened considerably.
And with the Waves L3 Ultramaximizer added onto the stereo output:
Compared with the tests run with the DAW as the timecode master, the big difference apparent here is that Digital Performer is now not compensating for the delay on the stereo output channel - just like Logic. They also still have the sloppiest syncs.
…And this time with the I/O buffer increased from 64 to 512 samples:
Again, Digital Performer appears to be overcompensating for the buffers and Pro Tools does not appear to be compensating at all. But now, at least Logic appears to be significantly more on-the-beat - although its consistency is still lacking: in those terms, Logic is now falling off the barstool, whilst Digital Performer has just arrived and is now getting the next round in.
So - with the notable exceptions of Cubase and Reaper - all the DAWs under test here exhibit inconsistencies when running either as timecode master or timecode slave, apparently often due to processing buffer delays in the audio engine not being equally applied to the MTC engine.
Good alignment of Reaper spikes recorded in Pro Tools.
How can this be improved upon?
Test 6 - Alternative Timecode Options
Moving the timecode generation into the audio engine could in theory remove all the variables from the composition DAW: assuming multitrack playback is accurate from the DAW and the audio output paths are correctly timed, the click should arrive at the audio interface outputs at the same time as the timecode.
This can be achieved by:
Adding a SMPTE audio track to the source project;
Feeding this SMPTE track into a SMPTE-MTC conversion unit, which is then used to drive Pro Tools just as before.
Although software SMPTE-MTC conversion applications are available, we’d suggest running with a dedicated hardware unit, to eliminate the likelihood of further complications with buffer delays. A suitable unit includes the splendid Rosendahl mif4 unit - but in our tests, we’re using a Digidesign Sync I/O configured as a standalone converter.
Converting SMPTE to MTC with a Digidesign Sync I/O.
The SMPTE audio track can be easily created thank to the wonderful Pehr Hovey at http://elteesee.pehrhovey.net . If you end up using this, be sure to throw him a monetary contribution for server costs from time to time!
Once the SMPTE file has been generated and placed in the project, we can see the waveform corresponds exactly to the timeline:
SMPTE file loaded into Logic Pro X.
Let’s see how we do (plotted on the same scales as the original timecode master tests):
…And with the Waves L3 Ultramaximizer on the stereo audio output (not used on the timecode audio output):
…And with the I/O buffer set to 512 samples instead:
Thankfully, this is now mercifully consistent - the audio does not appear to shift with relation to the timecode, either with plug-in delays or with varying buffer sizes, for any of the DAWs under test.
Additionally, some DAWs feature a timecode generation audio plug-in:
Here’s how they fare too (with a 64 sample buffer, and no plug-ins inserted):
Curiously it’s Cubase that stumbles a little here: its live timecode generator plug-in is less tightly-locked than a printed SMPTE file - though it’s still only 0.01 frame variation.
Conclusions
Reaper is rather an unlikely winner in this setup: in every test, its sync capabilities were unflappable. So it’s rather a shame that it’s a pig to use for composition - but it does highlight what is possible with the available technology, if the developers of the big DAWs chose to apply themselves to improving their offerings.
Reaper with the test project open.
In the land of realistic composition DAWs, Cubase scores most highly - it performed consistently well across the tests - and certainly much better than the market-leader, Logic (amongst our client-base anyway).
However, when using a printed SMPTE track to feed a SMPTE-MTC converter, each of the DAWs performed equally well.
But isn’t this going to be a problem, having to create a new SMPTE file for each project file which starts at a different timecode position?
Thankfully no.
Pro Tools allows you to offset the timecode position of the session against the incoming timecode; this allows you to:
Always use a printed SMPTE track which starts at 00:59:40:00, placed at -4 1 1 1 with the first 5 bars running at 60bpm;
Set the External Timecode Offset in Pro Tools so that it always expects 01:00:00:00 timecode at the start of the cue.
Setting the External Timecode Offset in Pro Tools.
This way, you only need a few timecode files to hand - one for each frame rate and sample rate you’re using, and perhaps a couple of different lengths to cover extremely long cues.
This is all very well and good - as long as your cue always starts at 1 1 1 1; if there’s an indeterminate amount of lead in, up to a sync point (and nominal cue starting position) at 5 1 1 1 (for example), then you’ll have to do some maths to add the timecode difference between 1 1 1 1 and 5 1 1 1 to your 01:00:00:00 timecode feed into Pro Tools.
In summary:
Logic Pro X:
MTC output is much less accurate than it could be;
Does not perform Plug-in Delay Compensation on the MTC input or output;
Does not perform buffer compensation on the MTC output;
MTC input and output are much much less accurate when running with larger buffers;
Internal video playback is not accurate, and is affected by the presence of plug-in delays and large buffers (see below).
Cubase:
Performs very well;
Built-in SMPTE Generator is slightly less accurate than a printed SMPTE audio file.
Digital Performer:
MTC output is less accurate in the presence of plug-in delays;
Does not correctly perform buffer compensation on the MTC input or output;
MTC input is less accurate than it could be;
Does not perform Plug-in Delay Compensation on the MTC input;.
Pro Tools:
Performs very well generally;
Does not perform buffer compensation on the MTC input or output.
Reaper:
Performs exceptionally well.
…but all DAWs perform well when outputting a printed SMPTE audio file into a SMPTE-MTC generator.
Further Abstract Quagmires
Will the sync be any better if I run my composition DAW and Pro Tools on the same computer?
No.
The timecode still has to traverse the same path to get out of the composition DAW, no matter whether Pro Tools is on the same computer or not - so it will still be subject to the same problems.
Will using a Sync HD on my Pro Tools system help?
Sort of.
You can use an Avid Sync HD as the SMPTE-MTC converter in the setup we’ve detailed above, and with Pro Tools|HD hardware the sync will be as tight as it’s possible to get at the recorder end. However it’s a tall order for the setup to improve on the existing accuracy of 5 samples variation between record passes.
With an MTC output from the composition DAW, the Sync HD will not help at all when it’s being fed an out-of-time input, which it cannot correct for..
Is MIDI Clock better than MTC for this?
No.
MIDI Clock is a tempo-driven sync signal, designed for syncing a musical slave (such as an external sequencer, arpeggiator or drum machine) to a master system. We need a tempo-independent signal.
Can I use ReWire to help?
No.
You cannot run Pro Tools as a ReWire slave, so it would not help in locking Pro Tools to the composition DAW. About the only promising avenue we found was that Reaper can be run as a ReWire slave - allowing you to output SMPTE from Reaper’s timecode generator in sync with the host DAW.
But…
ReWire, aside from potentially becoming deprecated (indeed the latest version of Reason does not support ReWire at all…), transmits a tempo-driven counter from master to slave application - rather than a sample-driven counter. Consequently in the presence of tempo changes in the master project, Reaper’s timecode output drops out intermittently and does not provide a sufficiently stable feed for Pro Tools to chase.
Instead of setting the External Timecode Offset in Pro Tools, can I just set the timecode start point of the SMPTE file in my DAW?
Sort of…
Whilst it is possible to timecode-lock regions in some DAWs, in practice this can cause problems:
| No | Although individual regions can be SMPTE-locked, they do not stay where they should when changing the project start time causes the region to start before -8 1 1 1 |
|
| No | Individual regions cannot be timecode-locked, and changing the project timecode gives the option to move All Regions or No Regions to the new timecode - but a region can happily exist substantially before the project start and play at the expected time |
|
| Yes | Although regions cannot be timecode-locked, they can be given a timestamp, and then moved to that timestamp. Doing so correctly truncates the start of the region if it occurs before the sequence start |
|
| No | Regions cannot start before the session start time | |
| Yes | Regions can be set to any timecode position, even before the project start time |
Can I instead use a SMPTE-striped video file and play that in my composition DAW?
Sort of…
This is possible - and allows you to fully offset the SMPTE file from the project start time. But some DAWs insist on importing the video file’s audio tracks as audio regions - so then we’re back where we were.
Of our test DAWs that play the video file’s audio tracks without extracting them first, here’s how they fare (again, plotted on the same scales as the original tests as far as possible):
…And with the Waves L3 Ultramaximizer on the stereo audio output :
…And with the I/O buffer set to 512 samples instead:
As Logic is still performing with all the precision of a betacarotene-fuelled 8-week old cockapoo puppy, there is also the possibility of running the video file inside a VidPlay software instrument plug-in, which does correctly handle plug-in delays and buffer changes - but in our tests, although it was commendably stable most of the time, about 10% of record passes were ~600 samples off.