I’ve set up Bome MIDI Translator (BMT) to sync subordinate devices being controlled by MIDI Timing Clock so that they start on a bar (or 2, 4, or 8 bar) boundary. Here’s the details, for anyone with similar isssues …
My issue has been starting devices that take their MIDI Timing Clock from my Push3: How to start Subordinate devices at the start of the next musical bar of the music that is already playing on the Push3. Many systems provide this ‘aligned to the bar’ feature: Ableton Live, Loopers such as the RC-505, etc. However, the MIDI Transport Control commands - Start, Stop, and Continue - know nothing of music bar or cycle boundaries. Syncing different devices has been a long-standing problem for me. With my Push3 playing, I have to punch [Start] on my Digitakt 2, NDLR, and RC-505 mk2 at the exact start of a bar (or other cycle). If I get it wrong in a live setting, it’s pretty glaring.
My solution uses a handful of translators in BMT and touch-pads on a Novation Launchpad Mini Mk3 (LMM3):
The BMT code recognizes a [MIDI Start] command from the Push3 and then begins counting [MIDI Timing Clock] (F8) pulses from the Push3.
Pads on the LMM3 let me select the meter (4/4, 2/4, 3/4, 6/8) and length of the cycle (1, 2, 4, or 8 bars). Based on 24 pulses per quarter note (PPQN), I can determine the length of my cycle in pulses.
When my counter reaches the length of my cycle, I wrap it back to 0. This is a ‘Cycle Start’ event.
When I hit an LMM3 pad to start a subordinate device, the BMT code waits till the next Cycle Start and then issues the [MIDI Start] to that device.
Also, I use the LMM3 in Programmer mode so that I can set the pad colors at will. These color tell me the state of the device: Red for "Device Stopped, flashing yellow for ‘waiting for Cycle Start’ and then, after the devices is started, it pulses a soothing color in time to the meter.
One issue is that some (most?) devices do not respond to a [MIDI Start] command unless there is already a stream of [MIDI Timing Clock] (F8) messages flowing. I do have one addition LMM3 pad for each device which lets me turn on/off the stream of [MIDI Timing Clock] messages to each of the devices. I had imagined that, in situation where I have a relatively fixed BPM, that I could dispense with [MIDI Timing Clock] messages altogether, dial in the BPM on each device, and simply issue [MIDI Start] commands as needed. No dice.
Took a couple of hours to get all this set up and tested in BMT, but well worth the effort!
Thanks to @FlorianBome and @SteveC for early feedback when this was in the ‘drawings on a napkin’ stage.
Fun … and it’s allowed me to build the Rig I’ve always imagined.
Prior to Bome, I was doing everything in Cantabile, which is great for many things, but MIDI is (A) not as easy to do as in BMT and (B) suffers from latency and jitter because all MIDI passes through the ASIO buffers.
Now that the ‘Sync to the Bar’ issue has been solved (worked flawlessly in a 1hr show on Sunday), the next issue has reared its ugly head: MIDI Jitter.
I was primarily running a Looper (Boss RC-505mk2) and a D2 (Elektron Digitakt 2) receiving MIDI Clock through Bome MIDI Translator (BMT) originating from a Push 3 Standalone (Push3). My Sync to the Bar system started them at exactly the right time (on an 8-bar cycle, in fact).
But then … both the Looper and the D2 perceived changing tempos, I believe due to jitter in the MIDI stream. My path for this show was TRS out of the Push3 to a MIDI Hub, then USB to Bome Network on a Laptop in the Rig, then LAN to a PC workstation running Bome Network, then internally to BMT, then back over the LAN to Bome Network on the Laptop, then USB to the D2 and the Looper. Yes, a long chain of links simply begging for jitter. I observed the tempo on the D2 (derived from the MIDI Timing Clock pulses) range from 90 to as low as 87.8 and up to 93.
I have tried more direct paths … running the BMT project on the laptop … and things were tighter (less variation). However, but any variation causes auditory havoc with these units. Unfortunately, I laid down a core loop early on, and every time I went back to it, I heard the Dzittt Dzittt Dzittt of the Looper trying to ‘slice’ my loop to make it fit the ‘new’ tempo. The D2 does much better after a tempo has changed, but has a characteristic ‘Zhooop’ (like a flying saucer departing) whenever the tempo is in the process of changing. I heard this repeatedly during the show.
OK, so … solutions?
My only idea is to:
Use a use a hardware pulse generator - an ERM (now Floating Point) MultiClock unit.
Send CV clock pulses from the Push3 using one of the foot pedal jacks (each foot pedal jack can act as two unbalanced audio outputs) as the master time clock for the MultiClock.
Send each of the my units timing-dependent units MIDI clock over DIN5 from the MultiClock.
Send all other needed MIDI traffic (like Start and Stop) from BMT to those devices over USB.
Fortunately, the specs for each of the receiving devices say that they will accept MIDI on both DIN and USB simultaneously. Hope that works …
Any thoughts or experience with such a system is appreciated.
Is your MIDI Hub a Blokus MIDIHub? If so, there is a possibility that as you create pipes through different processing algorithms, there may be some jitter introduced. I have not experimented with jitter on anything however.
Is your LAN on Ethernet or WiFI? WiFi will certainly introduce jitter due to it’s inherint nature of sharing radio waves and competing for bandwidth. You shouldn’t have this problem for ethernet unless it has a lot of audio or video traffic as well. It is usually best to use separate networks for MIDI if ethernet traffic is heavy with audio or video. Lower buffer sizes or bit rates could help as well at the cost of possible audio artifacts (for buffer sizes) or audio quality (for lower bit rates)
Some USB drivers can introduce jitter, especially if you are going through USB hubs.
The short you can make your MIDI path, the better because every link will possibility introduce buffering or processing time.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
MidiTech MIDIFace 4x4 … I don’t know too much about this hub, other than the stuff seems to arrive.
LAN on Ethernet
LAN is Ether … I don’t go near WiFi for any Rig stuff, except the the config stuff for guests who want to configure their feed from my CQ20B mixer.
a lot of audio or video traffic as well.
Which certainly happens when we are livestreaming a session! We are currently limited to 36 mbps upload, so traffic is ‘light’ compared with the local LAN speeds. However, Fiber is being installed (as I write this), so we’ll have more like 500 mbps upload. This will allow me to use FarPlay (a low-latency musician collaboration system), but requires maybe triple or more the bandwidth of a one-way livestream …
Some USB drivers can introduce jitter,
I have, of necessity, two USB hubs in the chain I described …
I have BMT and a bunch of soft synths (Cantabile, SWAM, Surge, VCV rack) running on a workstation that is ‘across the LAN’ because the Laptop that is local to the Rig cannot tolerate any more load. It’s already running OBS Studio, Nestdrop, FarPlay (which takes about 2x OBS), TotalMix, Bome Network, and some other stuff I am forgetting.
I’m seriously looking at the MultiClock route … it seems like a nice solution, as long as all my devices can take MIDI on USB and DIN simultaneously …
