So I’ve had a Ruin & Wesen MiniCommand for a little under a year, but haven’t been using it as much as I would like because it didn’t integrate well with my setup — until last night.

The standard way to use the MiniCommand is to connect it in a closed MIDI loop with the device in question — which makes it hard use in a computer-based MIDI setup with a sequencer. There are ways around this, eg. daisy-chaining the MiniCommand between the computer’s MIDI interface and the device you want to control, but I have found that this introduces some small timing delays (enough to drive me crazy).

Standard way to use the MiniCommand with a Machinedrum. Where’s the computer?

The trick to get this integrated with your computer is to use a software patchbay to route the MiniCommand to/from whatever device you want to control.  I’d tried a few ways of doing this (Logic’s environment almost worked, forget about Ableton, MidiPipe didn’t work either), and finally found the elegant free program Midi Patchbay.

Sure enough, I was able to create a patch from the MiniCommand to the Machinedrum, and another going back the other direction.  All of the crazy low-level SYSEX MIDI information transfers worked again, so things like kit names and machine assignments were transferring correctly.

Furthermore, as far as I can tell this works fine in parallel with Logic, you don’t have to rewire anything to send the MiniCommand new firmwares, and it doesn’t do a thing to the MIDI Clock timing (since it’s no longer daisy-chained).

I might even get a chance to start learning to create firmwares now!

(Images from Ruin & Wesen site)

Here’s a sound clip from my machinedrum with a simple sawtooth note and a resonant lowpass filter being modulated down over a quick sweep. It’s played four times, each with increasing amounts of sample-rate reduction applied:

increasing srr

This sample looks like this in a sonogram (I used the Sonogram View plugin that Apple includes with XCode). Horizontal axis is time, vertical is frequency:

Notice that as the aliasing (reflected frequencies) increase with the sample-rate reduction effect, you begin to see multiple copies of the filter sweep. This creates the lovely, complicated “alien voice” sound. Here’s a short MachineDrum loop I was playing around with when I realized what was going on here:

alien-autopsy-192

And for the Elektron-heads reading this, here’s the MD sysex for that pattern+kit:
alien-autopsy-md.syx

PS: the wikipedia article on aliasing has a good rundown on the details of this phenomenon.

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.

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

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.

MD Recurse Test 01
Patience… it gets really cool from around 1:00 on.