Apologies for posting this query on this forum.
I’m not getting answers from the Googles.
To those familiar with MIDI:
If I send a MIDI msg with a value out of range, such as B0 07 82:
Generally do devices ignore such messages?
Is the MIDI Spec designed to specifically ignore such messages?
Have I just been lucky that these messages have not caused an EDM Chernobyl yet?
I have a situation where the sending device must send a message, and generally will send a valid message, but I’m trying to figure out the best/simplest way to make it a null or ignored message if certain prerequisites are met.
And yes: I’ve tested it and so far everything has been ignored. I’m also not experienced enough to know if perhaps any other portions might cause some disturbance, although I’m pretty sure anything preceded with B0 will take all 3 bytes as one unit and when it can’t do anything with it, will toss it. But - I don’t know what I don’t know.
The MIDI spec very clearly instructs devices to ignore
unimplemented, known status bytes and their data
undefined status bytes
data bytes note preceded by a proper status byte (except for running status)
…but then it also instructs not to send any undefined bytes. Which is of course vitally important for device manufacturers to follow, but private local use is a different game entirely.
If you can do so, the “proper” way to send a message that no commercial product will look at is a SysEx with manufacturer id 7D, which is reserved for non-commercial/research use.
Edit: except that wasn’t really the question, sorry! You asked about CC values out of range. I’m just feeling dumb/blind now - isn’t B0 07 82 CC#7 aka volume? How’s 82 out of range for that?
Actually my question was lacking background. Im throwing a bunch of MIDI CCs at the Pyramid but if i format the output with multiple msgs I might run into the situation i want to nullify one of those msgs. I was hoping i could keep my plan to format outout for 4 msgs in each translator.
Thanks for the MIDI Spec snip. For some reason i was only finding info on proper msgs and now “what not to do”. LOL
Thanks!
I think i might have to find another way around just to be safe
not following a spec always opens you up to ‘it depends’ on the implementation.
with midi din you could read this ‘error’ in one of 2 ways
i) CC#7 with value 132 ,> 127 so ignore
OR
ii) CC #7 , missing value (!) , Note Off channel 2 (0x82) with velocity of what ever followed next.
now you might think ii) is pretty dumb, since its likely followed by another control message (8bit=1)
but midi din is a serial protocol… so its not going to ‘wait’ to see that byte to make that decision.
so… as per opening sentence, you are open to the vagaries of the implementation!
(and thats even assuming a good implementation, and there are plenty of rope-y ones )
notice I deliberately said midi din above…
this is because USB midi does not get sent like this… with usb all midi data get sent as 4 byte packets. so in the above case, it can only really be read as (i) - so ‘theoretically’ your safe, they should choose to ignore… (buy hey, id not be surprised if the odd thing choose to do something like ‘mask’ it )
I was looking at 82 and thinking it’s smaller than 127, so what’s the problem? My brain has this annoying tilt towards decimal even though it was totally obvious from the context that we’re talking about hex. But man do I feel like a complete moron now
Anyway, the behavior in such a situation is actually defined in the spec:
Except for Real-Time messages, new Status bytes will always command a receiver to adopt a new status, even if the last message was not completed.
So assuming devices actually follow that, the 0x82 should be considered as Note off, but as long as it’s followed by a legit message, the Note off will also be simply discarded. I think. Considering how this day is going, I wouldn’t count on that too much though
Never gave much though to USB as all my stuff has been DIN so far, but that difference is an interesting point.
Edit: in the light of the above spec snippet, I suppose the safest choice for an invalid value might well be EOX (0xF7) as no data is expected to follow it, and any device needs to be able to ignore an EOX not directed at them.
Sorry. Instead of putting a MIDI msg in hex as an example I could have used 0x82 or even just used a more obviously hexadecimal value. MTPro switches hex values to decimal in translator rules and that constantly confuses the fk out of me.
Thanks for your input.
The more complex the response gets, the .ore i question my direction as i believe simpler leads to fewer headaches down the road.
yeah, it’s one of those cases, where what you would expect to happen, happens - but for the wrong reason. unfortunately, this is why so many midi implementations are a bit ‘shoddy’, because its quite forgiving in many respects - and so incorrect assumptions get made.
(remember din is like this, because it was over fairly unreliable serial connections when it was first created - so things er’d on the side of caution)
I suspect USB will be a cause for inadequate testing of DIN in the future e.g there is no concept of running status for usb.
anyway… as with any protocol, you follow the rules, or you suffer the consequences…
the consequences are usually pretty horrible… (like much of sloppy coding)
basically, it’ll work fine for weeks/months - until you forget all about the ‘hack’ you put in place,
then you’ll plug in a new device, and it’ll act wierd - and you’ll pull your hair out wondering why…
until hours latter - you suddenly remember that ‘quick fix’ you put in place
