MIDI MMC Messages & Writing Drivers

Hi, I’ve been playing around with writing my own modules, and the first serious one is a module to use my Arturia Drumbrute or BeatStepPro as the master clock, as well as replicate the two buttons for “stop” and “pause/play” via midi.

I had no problem bringing the clock in, but reflecting the button behaviour has been problematic.

The buttons on the Arturia have 3 states:

  • Stopped - Stop button is lit, sequencer reset to beginning
  • Playing - Pause/Play button is lit, sequencer playing
  • Paused - Pause/Play button is flashing, sequencer is paused where it is

The issue is when in the playing state pressing either button results in the same Midi system message (stop) being sent. At this point there seems to be no way to determine which button has been pressed. (now this can be dealt with using reset on start, but I’m trying to show the button status in the rack module)

So a bit of snooping on the midi from the BeatStepPro showed me that MMC messages were being sent of the correct type (Play, Pause, Stop) but these weren’t coming out of the midi driver in vcvrack.

And then I found this bit of code in rtmidi.cpp, line 42

		// Users have reported that some MIDI devices can send messages >3 bytes. I don't know how this is possible, so just reject the message.
		if (message->size() > 3)
			return;

Looking at the midi specs MMC messages are 6 bytes long, so that’s why they are dropped.

I’m a beginner at MIDI, module development AND C++, so any/all of the above might be wrong, but I have a few questions:

  • Are there any plans to add MMC support in future (v2/3)?
  • Are Arturia devices unusual in their use of this (hence no support)?
  • What’s my best option going forward ? I’m currently thinking about writing a midi driver to cover just what I need - clock & MMC

Anyways, this has been a learning experience, so might just write the driver for fun…

Info on MMC here.

I’m surprised it rejects messages larger than 3 bytes, since just a few lines up SysEx messages are explicitly not ignored… I wonder if that’s a bug.

I suspect that for now your best bet will be writing a new midi::Driver that’s essentially the same but without that message size check.

Hi Joe and welcome! No direct answer but maybe some useful links…the discussion on this issue mentions both the 3-byte limit for MIDI messages and the fact that Rack ignored System Exclusive MIDI messages (this was June 2019):

Also possibly related:

I also have an Arturia Drumbrute in my setup that I’d like to use as main clock, so I’m interested - and available should you need testers at some point.

Thanks, from that first link I can see it was intentional.

I’m currently trying to figure out how to write a midi driver so I can let these messages through…

Hi. I have some insights on this topic.
These MMC messages seem to be a special type of SysEx messages. Rack’s default MIDI driver does not support SysEx messages, or more precisely, as you noticed: No MIDI messages longer than 3 bytes. According to Andrew this has been addressed and will be available in Rack v2.

Writing you own MIDI driver is possible, I did write two myself (one “Loopback” driver for testing purposes, one for Expert Sleepers ESX-GT8).

There are two caveats though:

A bug in Rack v1.1.6 causes a crash on exit if you register your own MIDI driver. It can be easily fixed in a custom build of Rack but the last official version will crash.

Second, the rtmidi-instances are not accessible through Rack’s API. If you want you own MIDI driver with SysEx support you need to instanciate and connect rtmidi in your plugin. I don’t know how much work this would be or if it’s even feasible. It might be easier to use your own build of Rack which supports SysEx natively.

In Rack v1 this topic is a bit of a dead end, I’m afraid. At least if rely on the official build v1.1.6.

2 Likes

Thanks for the additional info. I had seen your post about the segfault, and I was going to ask you if you found a workaround - but i guess not.

I’ve got my own driver working now - it also exposed another bug I’ve noticed before:

Two competing drivers (internal or external) for the same mdi device causes a crash - I assume this is well known enough to have been recorded and potentially fixed for v2?

The only issue on Github I could find was this:

I’ve added a bit more info on it.

The only workaround right now is compiling you own build of Rack. It is just reordering a few lines for proper deallocation of the resources, details can be found in the GitHub issue.

This is well known. Some MIDI device drivers allow use in multiple applications the same time but most of them don’t. I’m speaking about Windows here, I don’t have much experience on MIDI with other OS.
Either way Rack shouldn’t crash but I have no knowledge if this will be fixed in Rack v2.

Thanks Ben, yes I’m currently building Rack to fix that issue.