Sending MIDI CC MSB-LSB message(s) to an external synth

[oor]

I am a newbie to the technicalities of working with MIDI messages.

Problem:
I want to send the following message to my Moog Matriarch: “Set glide time to 15039”.

I read in my Moog Matriarch manual that to tell my synth to set a Glide Time, I have to use the MSB CC Number 5 and the LSB CC Number 37 and a value between 0 and 16383.

I have googled around a bit, and cannot find a simple and complete description on how to achieve this kind of sending MIDI message(s).
Putting together what I have found here and there, I have come to the following tentative solution:
First send a MIDI message 5 with the value 58 and then immediately after, send a MIDI message 37 with the value 191.
Or in Sonic Pi speak:
midi_cc 5, 58, port: “moog_matriarch_35”, channel: 1
midi_cc 37, 191, port: “moog_matriarch_35”, channel: 1
How I got to the numbers:
15039 converted to hexadecimal: 0x3ABF
The most significant byte (MSB) is 0x3A, which converted to decimal is 58
The least significant byte (LSB) is 0xBF, which converted to decimal is 191

As this whole story seems a bit cumbersome (the least), I am by no means convinced that I have found the correct solution. There are at least the following reasons for being a bit confused and in doubt:

• Cumbersome method
• I thought a MIDI message value would have to be in the interval 0 to 127, and 191 falls outside that range.
• What if Moog Matriarch only receives a CC 5 58 and not the other message (CC 37 191)? (Or the other way around)
• Does Moog Matriarch have a timeout and forgets about one of the messages if the its “companion” is never received?
• Does the sequence matter? (First CC 5 and then CC 37 or first CC 37 and then CC 5)

I have used Moog Matriarch in my example, but I take as granted that the problem pertains to any synth.

So please correct me, anyone.

[nlb]

hi @oor

i don’t know if that post can help you

Midi_cc to select bank and qsynth

Hi i’m back with good news under windows 10 [image] this script is working for me # Testing midi and qsynth - nlb with big help from Robin Newman - 09-12-2019 # spi version : v3.1 # os : windows 10 # qsynth : 0.5.5 https://github.com/JoshuaPrzyborowski/Qsynth-Windows-Builds # soundFont : Arachno SoundFont - Version 1.0.sf2 https://www.polyphone-soundfonts.com/en/files/27-instrument-sets/255-arachno-soundfont # port loop midi : loopMidi 1.0.15 puts version use_midi_defaults port: "loopmi…

[oor]

I’ll have a look at it next week, thanks so far!

[Hussein]

Hi there

a couple of things.
MDI is a serial protocol, so your msg 1 immediately followed by your msg 2 would seem to be the right way to go.

Secondly, as you’ve already got the hex values you could look at the following in SPi commands:
midi_raw or midi_sysex. Both should be capable of meeting your reqs.

Hopefully some of the above will get you closer to your solution.

[oor]

I think I have come closer to a correct solution now. The 7 rightmost bits of the value are sent with the LSB CC
and the bits number 8 through 14 (inclusive) (counted from right to left) are sent with the MSB CC.
Which changes my concrete example above to:
15039 == ob0011 1010 1011 1111
lsb == 0b0011 1111 = 0x3F == 63
msb == 0b0111 0101 = 0x75 == 117
Or in Sonic Pi speak:

midi_cc  5, 117, port: “moog_matriarch_35”, channel: 1
midi_cc 37,  63, port: “moog_matriarch_35”, channel: 1

I may still be wrong, so please correct me if I am on an erroneous track.

[pashultz]

On my understanding of Sonic Pi’s timing model, statements that aren’t separated by a sync or sleep are scheduled simultaneously—do you know for sure these two messages are always received in the order they’re written here, or is there the possibility of a race condition?

Please forgive me if the answer is obviously “no”! I haven’t worked with external MIDI much but hope to in the future.

[robin.newman]

You can always put a short sleep between the two. Maybe sleep 0.1 or 0.05

[oor]

Thanks for the sync hints to you both! btw: Does anyone know whether the message sequence has anything to say at all? (LSB first vs. MSB first)
And also:
If the external device receives only one of the messages, will it wait forever for its “companion”?

[samaaron]

Just to be clear, there is currently no guarantee of the order of deliver of MIDI messages with the same (or very similar) timestamps. This is because the timestamps are used to schedule the MIDI messages in the future which happens concurrently - so depending on the clock resolution of the scheduler (which is architecture specific but around 10ms I believe) and the difference of time stamps, there is indeed a potential for a race here.

What I might do if I wanted to make sure multiple messages were sent at similar times in strict sequence would be to use the time_warp function to increment the time of subsequent message. Something like:

midi_cc  5, 117, port: “moog_matriarch_35”, channel: 1
time_warp 0.01 do
  midi_cc 37,  63, port: “moog_matriarch_35”, channel: 1
end

I’d then play around with the value to make sure it’s as large as possible whilst still being useful for your use case to reduce the chance of a race condition. So, if you can afford to put it up to 0.02 then that would pretty much guarantee a strict ordering.

[oor]

@samaaron

MIDI messages with the same (or very similar) timestamps

Thanks for lots of good sync advices!
But Qt, SP, Ruby, Erlang, SuperCollider etc. aside: General MIDI question: I have still not been able to find out neither whether the sequence of the two messages matters nor the acceptable time lag between them nor missing companion.
Anyone?

[samaaron]

Unfortunately I don’t think there’s a general answer to this question. I think it’s entirely dependent on the hardware receiving the midi messages. Different hardware will behave differently.

[oor]

@samaaron

Unfortunately

A pity!
Thanks anyway!

[Hussein]

Have you tried a MIDI monitor like MIDIView?
Might remove some of the guess work?
Doing a reverse process, how about wiggling the controller on the synth and capturing it via MIDI into a DAW and look at the raw midi message?

[oor]

A good idea, actually. Only that it seems to send a differnt CC out than what it expects in.
Documented glide time CC in:
MSB 5, LSB 37, (0…16383)
Monitored:
(MSB?) 5, (0…127)

I am a bit confused. I should maybe try to find a Matriarch forum, inspired by @samaaron’s comment.

[Hussein]

I’ve had a look at the Matriarch’s midi implementation chart and here’s what I think.
Glide On - using a value of 63 or lower turns it off. Values of 65 or above turn it on. There is no LSB for this parameter.

midi_cc 65, 58, port: “moog_matriarch_35”, channel: 1 (turns it off)
midi_cc 65, 70, port: “moog_matriarch_35”, channel: 1 (turns it on)

Glide time is MSB cc 5 and LSB is cc 37
midi_cc 5, 100, port: “moog_matriarch_35”, channel: 1 (MSB) I don’t think you need to send a value but you’ll need to explore this.
midi_cc 37, 15039, port: “moog_matriarch_35”, channel: 1 (LSB) I think you use the full value rather than midi 0-127.

I don’t have a Matriarch so I am somewhat in the dark as to behaviour. As Sam has mentioned, even if I tested this on another keyboard there is no guarantee that if it worked for me that it would work for you.

I’m not sure what firmware you’re using but always best to update.

Hope some of this helps.

[oor]

The value part of a CC message is 7 bits. Max value is hence 0b0111 1111 == 0x7F which is decimal 127. 2 messages full of bits, 14 of them al together gives the number 0b0011 1111 1111 1111 = 0x3FFF which is decimal 16383, which is also given as the max in the Matriarch manual. So two messages are certainly needed.
On the other hand, Matriarch uses a resolutioin of 127 in their MIDI CC out message and only uses CC Number (MSB) == 5. (MSB and LSB are irrelevant notations when only one message is required, so it actually does not matter how you name it.)

[Hussein]

Yes, I saw somewhere that for the Matriarch MSB/LSB is for their internal mapping. Sending is irrelevant.

Last try. Do you use a DAW? If so, which one?

[oor]

Primarily Cubase 12, eventhough I have Reason 12, Reaper, Abelton Live Lite and Fruity Loops installed as well.

[Hussein]

OK. Can you send the same control messages from your DAW to the Matriarch? With/without using the Midi Remote?
Can you set Cubase to receive messages from Sonic Pi?
Can map the incoming Sonic Pi message to Cubase, and then use Cubase to pass the message on? Perhaps using the Midi Remote script. Would that work? It’s a kludge but might be an interim solution until it’s resolved?

I have a Monome Norns which is a host. So when using a DAW, which is also a host, the two hosts do not communicate. Therefore, I use a bi-directional Host-Host midi interface. This solves the problem but I’m not sure this is your issue but just putting it out there. You could have a look at this video where I use the host to host device along with various midi controllers in Ableton.

[oor]

I don’t know whether I actually have a problem or not. E.g. I get the glide to work by sending LSB and then the MSB using the algorithm I have ended up with:

ccLsb = 37
ccMsb = 5
value = 15039
lsbValue = (value & 0x7f)
msbValue = (value >> 7) & 0x7f
midi_cc ccLsb, lsbValue
time_warp 0.01 do
	midi_cc ccMsb, msbValue
end

The Matriarch actually changes the glide time. I just want to get confirmation that the way I am doing it is “according to the book”.
Reasons i am not sure whether there may be some quirk in what I am doing:

• I am new to sending 14 bits CC out, I am on thin ice.
• The glide time seems to change seemingly somewhat unpredictably for certain values. That may be of Matriarch settings reasons I have not fully understanding of… Although “on the average” the glide time increases when increasing the value step by step from low values through 16383.