Clocks.

So yeah, since I started playing out earlier this year and rocking with the Miami/Ft. Lauderdale locals, I’ve been talking process a lot and thought it might be cool to share some highlights from my own. This first installment is about the damn MIDI clock. If you haven’t had to deal with managing it manually, good for you.

One thing about a hybrid solution to anything, you’re always in for some bullshit. If you’re reading this you probably already know that my software is built to send MIDI note and CC messages to the DAW (in my case Reaper), where they can be routed however the user sees fit. That’s all great…as long as you don’t actually have to sync anything. If you just have a bunch of instruments waiting to receive MIDI and play notes, you don’t need to worry about a clock. Locally, CC messages ensure that the DAW and Aleator tempos always match. That means that any time based effects, LFOs, arpeggiators…all of that will be matched up. But what if you want to send MIDI data to an external source that needs to know BPM (e.g. Eurorack)?

The two primary methods for managing the MIDI clock are MTC and MIDI beat clock. MTC is a tool more meant for managing time codes for film and generally, keeping track of frames/seconds/minutes/hours within media. MIDI beat clock is really focused more on sequencing and MIDI device synchronization, so that’s the weapon of choice here. The MIDI clock defines real-time messages for clock/tick, start, continue and stop. I already use Leslie Sanford’s C# MIDI Toolkit to manage MIDI functions within the Aleator (very old but hey - still works) and all of these messages are already available in that library here. Nice - another developer did the hard part like a decade ago and I just profit, right?

Nope. I don’t know about other DAWs, but Reaper doesn’t play nice with this use case. If I attempt to send real-time messages to the host (DAW) from the Aleator along with the other data, I never see it; it just goes into the ether. Clearly this specific scenario is an edge case - there is a lot of bitching about clock/syncing difficulty within Reaper but not so much about controlling the clock from a VST plugin…which I suppose makes sense. What an idiotic thing to attempt. You can slave Reaper to an external clock though - so after I observed real-time events disappearing on the way up to the host, my next idea was to use a virtual MIDI cable and attempt to fool the DAW into thinking that the time code info coming from the Aleator was coming from an external MIDI device. Great idea!

Except for one thing. It seems that the virtual cable can only be connected to one device at a time if that device is Reaper. If LoopBe is enabled within Reaper, it will be inaccessible to the Aleator when attempting to send events (you’ll get the “device already in use” error at runtime). This was happening even though the device was only registered for output in the Aleator and input in Reaper. Not to mention that even if it worked, we now have Reaper synced to Aleator/LoopBe’s clock; I’m pretty sure it can’t be master and slave at the same time, so more than likely there’d be no way to get the clock messages to the interface and we haven’t solved anything. This would also lead to all kinds of shenanigans programmatically managing the transport in the DAW…I just wasn’t prepared for all that.

So we can’t send real-time events to Reaper, and there’s no easy workaround locally. I gotta jump through some hoops for these loops. Behold my configuration heading into late summer/early fall 2025:

The preferred path is annotated in red, the alternative I got working is in green. What a pain in the ass this was. Instead of just sending real-time messages to the DAW and letting them flow to/through the interface with everything else, I need a separate MIDI device to receive them and merge them with the notes and CC data downstream.

Good - more equipment, more cables…longer setup time. Just what I was looking for. The shit’s gonna hit hard though, hopefully it’s worth it. This was mostly a solution/architecture problem - from a pure development standpoint, there really wasn’t a lot going on, just the addition of a few lines of code in my Session and MidiProcessor classes and the creation/assignment of the output device itself.

This is supposed to be a dev log though, so I’ll touch on the few additions there were. The method for setting up the MIDI device works like this:

Sending messages is so simple it’s barely worth mentioning. I will talk specifically about clock ticks though, as there is some nuance there. We discuss clock resolution in terms of PPQN (pulses per quarter note). My internal clock has a resolution of 96 PPQN, but it’s standard to send clock messages at 24. That means that for every 4 of my internal clicks, I’ll send one externally…

And there we have it, clock ticks flowing to Eurorack directly from C# while Reaper is running (I’ve configured Mutant Brain to send clock ticks out on gate 12):

Huh, I thought this was gonna be short one - sorry. Next I’m gonna figure out how to apply scatter to my snares from code so I can sound like Aphex Twin. Assuming I can get it to work, I’ll do a deep dive here. See you out there.