Ableton Prints Recordings Where It Thinks You Heard Them

I guess this design must be intuitive for many users, but it confused me for a while.  If you have a setup with anything but a miniscule audio buffer, monitoring through a virtual instrument witha few latency-inducing plugins in the monitoring chain, you will hear a fair amount of monitoring latency when you play a note.  The same goes for recording audio.

When recording a MIDI clip, I expected that Live puts the actual MIDI events when I played them — which it doesn’t.  It shifts the MIDI notes later in time to match when you actually heard the output sound — trying to account for your audio buffer delay, the latency of your virtual instrument, and any audio processing delay from plugins in the downstream signal path.  There’s one exception to this — it doesn’t worry about delays you might hear due to any “Sends” your track is using.

So your MIDI notes (and CC’s) are recorded with “baked-in” delays the size of your monitoring chain latency. I’m going to call this baked latency.

To be fair, Live’s manual goes into the reasoning behind this in some detail, and offers some suggestions for working with optimal MIDI timing. I wanted to find out what this entails.

I’m guessing most artists working with MIDI will also quantize the crap out of these notes anyways, effectively gridding-away the baked latency. However, if you actually want to hear Live try to play back the notes when you hit them – say if you are trying to record some precise rhythmic passages by hand — you have to minimize (or eliminate) any of this record latency compensation that Live is doing for you.

Whether the Options menu “Delay Compensation” feature is enabled or not, any devices that are monitored through Live — MIDI tracks, Audio Tracks, or Audio Instrument MIDI tracks — have a delay the size of your audio input buffer baked in.

In addition, if “Delay Compensation” is enabled while recording, the additional latency due to any audio devices in your monitoring signal path will be baked in.

Thwarting Ableton’s Kind Efforts To Bake Your Latency

I’ve found a few general methods for this.

1) Don’t Software Monitor

In my experience, this is always the best option, if it’s possible.  All of the following work:

• Record an outboard MIDI synth to a normal MIDI track. Monitor mode should be set to “Off” (yes Ableton will still bake latency for MIDI tracks with monitoring enabled!).  Use local control on your MIDI device, and monitor it directly through something like a mixer or a soundcard monitoring feature. Edit and tweak the clips to your liking. Then record your synth’s outputs via normal Audio tracks with monitoring disabled.
• Record a hardware-monitored outboard MIDI synth to an External Instrument track with Live’s Monitor mode set to “Off”.  Freezing the resulting clip(s), and option-dragging them to an audio track will give you a nice tight recording with well-chosen loop position.
• Record audio tracks with Monitor set to “off”.  Use direct monitoring facilities on your audio interface, or a mixer.

or 2) Temporarily Turn off Delay Compensation

If you have to record using software monitoring (eg. your soundcard doesn’t support direct monitoring, you’re using a virtual instrument, and/or you need to monitor through some plugins), you can minimize latency by reducing your audio buffer size.  If you have latency-inducing devices in your monitoring chain, turning off Delay Compensation under the Options menu will help keep your recorded clips rougly where Ableton actually received then — not shifted late for you.  They will still be delayed by your audio buffer size in an effort to minimize jitter (as explained in the manual’s chapter “MIDI Fact Sheet”), but at least the “device” Delay Compensation shift won’t be added.

This method may not work if you have a complicated signal chain on other parts of your track that will now sound cacophonous with latency compensation disabled during your tracking session.

or 3) Bite The Bullet, But Minimize Latency During Recording

If you have to have delay compensation enabled, and you have to software monitor, then the general rule of thumb is to minimize latency.  Keep your audio buffer size tiny.  Don’t put any plugins on the master.  Don’t put any plugins on tracks you’re recording on.  Having plugins or audio devices disabled often isn’t enough — you have to actually delete them for Live to completely take them out of the latency compensation chain. Live will still bake in your audio input buffer latency, but at least it will be minimal.

Ableton Doesn’t Latency-Compensate MIDI Clock Out

No matter what it’s doing to your recordings, it doesn’t bother to delay compensate MIDI clock signals at all.  So if you have much latency in your system, and you’re monitoring an outboard sequencer that’s slaved to Live, and you’re monitoring that sequencer audio via a bunch of plugins, you have to put in large negative delay adjustments for Live’s MIDI Clock Delay or things won’t line up.

And if you change your signal path at all, you’ll most likely have to hand-tune that delay parameter again — for all outputs that care about MIDI Clock.

What Ableton’s Doing Behind The Scenes On Playback

This behavior all kind of makes sense in Ableton’s world-view of latency compensation: on playback, shift pre-recorded clips early to anticipate for playback delays. I’ll call this early playback. It has the greatest effect when “Delay Compensation” is on, adjusting for high-latency plugins in the signal path.

External Instruments MIDI, internally-routed MIDI, and audio tracks clips are all shifted early on playback. MIDI clips on tracks routed to an external MIDI interface aren’t played back early, probably because it’s not obvious how they’re being monitored.

MIDI clock output is kind of an unknown, external thing, and it’s not clear how much you’d want to offset if by.  As I mentioned above, it’s not shifted early.

Strangely, the metronome in Live seems to be added post-Master fx, so whether device delay compensation is active or not, it will always be playing “on time”.

Try this — create a set with a single beat loop in an audio track.  Put a ton of latency-inducing plugins on your master channel.  Turn on the metronome.  Make sure delay compensation is active.  Your beat and the metronome should sound in-time.  Now disable delay compensation.  Your beat should sound late, but the metronome is still “on-time”.  With delay compensation active, your beat’s audio was being shifted early to account for the processing delay from the plugs.

This device delay compensation on playback is usually your friend — it can keep a set with tons of realtime audio processing in near-perfect sync.

So What About The Machinedrum or Monomachine?

When recording the Machinedrum and the Monomachine, I’ve currently opted to software monitor since I like recording a bunch of discrete outputs from them, and my audio interface doesn’t support mixing multiple inputs for direct monitoring.

However, I have a template set that basically has no plugins in those devices’ monitoring path, and I start composing songs with my audio buffer set to 32 samples.  The latency is constant and known, so I’ve compensated for what little there is using the MIDI Clock Delay parameter.  And I don’t mess with it unless I have to change my audio buffer size. Basically, I’m using Option 3 from the section above.

I don’t put plugins on the Master until well after I’ve recorded the MD and MNM to audio, and I don’t monitor the MD or MNM through plugins.  If I’m recording their MIDI output, I don’t record monitor the input track (suggested in the Live manual).

If I’m going to use the MNM as a synth responding to MIDI notes from Live, I either use the audio + midi track setup, or an External Instrument track.  

With these precautions, I think I’ve come pretty close to an optimal setup for working with these machines in Live.

Add a computer DAW into the loop, and you introduce jitter, latency, and general zaniness to the equation.  And it’s not trivial — this is obviously-missing-the-downbeat, shoes-in-a-dryer kind of bad.  I tested the jitter / latency by ear, as well as by recording audio clips and measuring the millisecond offsets from the expected hit times.

I don’t think this is fundamentally a slow computer / poor setup issue either — I’m running a good interface, using a tiny 32 sample audio buffer. The rest of the setup is an i7 Intel Mac running OS X 10.6.3, Ableton Live 8.1.3, Emagic Unitor 8 midi interface and an Elektron TM-1 TurboMidi interface for the Machinedrum.

Below is a journal of what’s working, what isn’t, and my theories on why…

Method 1: Ableton Live as Master, using External Instruments

This seems like the way Ableton would want you to set this up.  It’s what the External Instrument is made for — routing midi to– and audio from– an outboard MIDI device.  However, it has a number of drawbacks when working with these machines:

• Latency depends on whether they are in “active” monitoring mode.  I didn’t realize that in Ableton, having a track in “Auto” monitor mode — but not record armed — has different latency than having it in “In” monitor mode, or having it record armed in “Auto” mode.  This makes it hard to monitor a beat coming from the outboard sequencer, yet have record armed for another track in the song: the audio for the outboard gear will sound late.
• If you try to get around this by leaving the track set to record monitor “In”, it’s like leaving your device always record armed, which can make it hard to avoid sending undesired MIDI events along.
• The Machinedrum’s internal tempo fluctuates +/- a few BPM.

Sync is done pretty standard: Ableton output sync is enabled for the TurboMidi interface the Machinedrum is plugged into, with a trial-and-error tuned MIDI clock sync delay of around –9 ms, and “Song” MIDI clock type.  I still found that this method — even in Record armed mode — had slightly higher latency values than the methods listed below.

Method 2: Machinedrum or Monomachine as MIDI Master

Why not flip it around?  Set the Machinedrum to send MIDI clock and transport control, tell Ableton to listen to sync on the TurboMidi input, and hand-tune the MIDI clock sync delay until things line up.  I ended up with an delay value of –26 ms — pretty large!  This method works as expected, but still has some issues I don’t love:

No dice.

Method 3: Machinedrum Internal Sync Only, Receiving Transport Control From Live

Nice idea — it would mean the MD could use its own rock-steady notion of what a given BPM means, yet I could start/stop the sequence from Ableton, and jump around in the Arrange window.

This didn’t work very well — I ended up getting start offsets that made the MD run substantially behind Ableton, and without any subsequent clock updates that would sync things back up.

Method 4: Live as Master, using discrete MIDI & Audio Tracks

This is how I’m rolling for now.  It seems to have the best blend of controllable integration into the Live workflow, acceptable latency and jitter, and flexible MIDI recording and playback for all tracks of the outboard gear.

• Live sends Sync out to Machinedrum and Monomachine. In my setup I’m using a MIDI clock delay of –9 ms for both.
• I create audio tracks for each input from the MNM and MD, and set them to Monitor “In” mode for lowest latency.
• Midi is routed via dedicated MIDI tracks — one per channel I need to send to.  If you don’t want Live to bake in latency on recorded midi clips, make sure monitor mode is set to “Off” for these.

Here’s the Monomachine portion of the setup: (click image for full size)

Using this setup, I’m getting jitter of less than 1 ms.  Strangely, it seems to alternate back and forth within that range every other quarter note.  I’m not getting perfect phase-sync on every downbeat, but at least the “band” is reliably, roughly in time now.

Misc Notes

• The Machinedrum’s TurboMidi mode doesn’t seem to have a substantial effect on all of this.  I’ve noticed that it seems to slightly delay or rush the overall timing, which I’ve compensated for in the MIDI clock delay parameter when I’m using it.  However, it doesn’t seem to have any better or worse jitter performance than non-TurboMidi enabled mode.
• If you want to be tight like Hybrid or BT, then get ready to drag some warp markers on your bounced audio tracks until everything’s all sample accurate.  Or sequence your drums using audio hits in the Arrange timeline. I’m fine with things being pretty darn close for now.
• Switching Ableton to use “Pattern” mode MIDI clock seemed to result in clock drift over the course of each measure. By the end of the measure beats were all over the place (relatively speaking — they were still within 5 ms of the correct time).

That’s it.  If you’ve read this far and have any tricks to get this stuff working better (without resorting to expensive hardware panaceas), please let me know!  In my next blog post I’m going to write about Ableton’s interaction between latency compensation, different methods of monitoring, and MIDI Clock output.

I’m giving a brief presentation at the Bay Area Computer Music Technology Group (BArCMuT) meet-up tomorrow, un-officially as part of RubyConf 2009 here in San Francisco.

Here’s a link with downloads and code from my talk.  It should be all you need to get started, if you have a system capable of running Ruby, and a copy of Reaktor 5+ (this should work with the demo version too).

Ruby mono sequence example:

Ruby polyphonic drums example:

Leave a comment below if you have any questions, or cool discoveries!

So this is another example of using the MD’s internal sampler to create a recursive “feedback loop” of sampling and resampling and resampling.… This has a tendency of psychedelically twisting the underlying beat.  The way this stuff sounds has really surpassed my wildest dreams.

MD Recurse Test 02 by chakaharta

If you’re a Machindrum SPS-UW user, there are two tricks to getting this working nicely:

• Use the last four slots to setup two sample record machines, and two sample playback machines.  Interleave the recording and playback so you get coverage of the entire measure.  For example, have R1 sample the first half of the measure, and P1 start playing at the second half of the measure. Likewise, set R2 to record starting at beat 3, and have P2 triggered at beat 1.  This is important to get the proper density of sampling to make this work with full feedback.  I did this with a 16-step pattern, but it would probably work similarly when extended for longer loops.

• Use a Control All machine (or function-knob twists) to mangle the synthesis parameters, and optionally the insert effects to mess things up.

Please share this post, or check out my music on SoundCloud if you like what you hear!

Photo courtesy Patrick Denker.

mdFractTest01.mp3
Patience… it gets really cool from around 1:00 on.

1. Mono Is Awesome

I’ve heard this one a million times, but never actually tried it. This article does a great job describing the hows and whys: The Secret Benefits To Mixing In Mono. Among other great insights — if you sum to mono and listen through a single speaker, you get less room and cross-speaker interference.

2. FX Halos

This is a great trick for time-expanding effects like delays and reverb. In a word, duck your effects sends by the signals feeding them.  The gradual release of your ducker / compressor creates a “halo” around the dry sound, as the effected tail glides up into the mix. This article does a great job describing how to set this up in Ableton Live.

3. The Law Of “Common Fate”

Learned this one from John Chowning, the father of FM synthesis, at a BArCMuT talk.

Gestalt psychology turns out to be a goldmine for some making abstract works of art (like electronic music). The law of “common fate”, according to Wikipedia, is: “Elements with the same moving direction are perceived as a collective or unit.”

Chowning’s example had to do with applying vibrato to FM string sounds, but it has applicability all over the mixing process.

For example, when “pumping” pads, hi-hats, and basslines in syncopation with the kick drum, the principle of “common fate” suggests your brain will gel them into a unit — providing more contrast between the upbeat and downbeat.

4. Embrace Subtle Delays

This is related to the previous point on “common fate”.  I’ve found it’s very useful to use a short “ambience” ‘verb, and send low levels of many parts of the song in order to “seat” everything in an acoustic space.  Again, this is an old trick, but I found this article illuminating in knowing what my brain wants to hear.

5. If You Make Dance Music, You Need To Be Able To Monitor Down To 28 Hz

And unless you’re in a really, really well-setup room with no neighbors, that means getting a good pair of ‘cans.

After extensive research into every pair of headphones I could find, I narrowed the field down to the Ultrasone HFI-550’s. Got mine off Amazon for $89.  All I have to say is – 50 mm drivers (they don’t make the 550’s anymore, but the HFI-580’s are similar).  I feel these come the closest to replicating the sound of your track playing over a nice club system — especially in the bass department.  They didn’t sound great when I first got them (compared to a 4 year old pair I’d borrowed from a friend), but I’ve been burning them in with medium-loud pink noise and the bass extension is loosening up nicely.

If you can hear the sub-bass, you can mix the sub-bass. Simple as that.

Today I’m re-releasing my first solo album, from way back in the days of 2000–2001.  It’s a multi-faceted collection of electronic tunes, meandering from ambient chill-out, to wobbly breaks & bass, to loungey four-on-the-floor house.

I just finished fully remastering the album (so it should sound pretty good in your car), and have included some nice album artwork. Check out the player above, or follow the links over to Bandcamp to download the tracks. I’m asking three dollars for the album, roughly enough for a nice pint of brew. If you don’t believe in paying for music, enjoy the streaming version.

As always — if you like my songs, I’d appreciate it if you hit up the “ShareThis” gizmo below and help get the word out!

Super Broken by chakaharta

Mundae by chakaharta

Background

Inspired by an article on CDM, and Terran Olson’s work in particular, I dug into creating a slightly more general version of fractal set synthesis.

In essence, you use a bank of sliders to give the program a wavetable “seed”, which is immediately subdivided into sound — each sample is replaced by a copy of the wavetable, multiplied by the old sample value, and so on.…

This recursion continues until the desired length of audio data has been generated. The initial value always begins at “1″.  For a seed of “1 0.5 1″, you get the following as the first three steps:

1 =>
1 0.5 1 =>
1 0.5 1 0.5 0.25 0.5 1 0.5 1 =>
1 0.5 1 0.5 0.25 0.5 1 0.5 1 0.5 0.25 0.5 0.25 0.125 0.25 0.5 0.25 0.5 1 0.5 1 0.5 0.25 0.5 1 0.5 1 => …

Try it

Click the thumbnail below to run the applet in your browser (requires Java):

Or get the downloadable application version here (so you can save out audio files):
Mac OS X version
Windows version
Linux version

If you’re curious about how this was written, the public git repository for this project lives at:
http://wiki.github.com/jdnorthrup/fractalwavetablesketch

Thoughts

Initially, I found the whole idea that the music can be self-similar from the waveform level, up to the “LFO” level, up to the rhythmic phrase, to the overall flow of a passage of sound — rather mind-expanding.

Interestingly, the sounds produced from this can sound spectacular through deep reverbs and other processing. They’re almost the same amplitude at all frequencies in their range, quite unlike natural harmonic spectra. Try running a steep resonant bandpass across some of the more complex sounds.

If you do anything cool with this app, please send me a link!

Sonograph of a fractal sound.