It would be nice if 0 velocity could be set for note on as this is a (imvhp) very common method for managing rather than a separate translator for a note off event…or am I missing something.
The coding of mtp is great…so I gather there is something else at play?
Hi,
I have a script for handling note-on or note off messages.
It recognizes either 8x with any velocity or 9x with velocity 0 as a note-off message
It is set up to send 9x pp 00 as note off always, which is handy for most controller LED control.
Incoming: oo pp qq
Rules:
// target MIDI channel
ss=9
// Look for Note On or Off message
rr=oo&224
// If not 128 then it must not be a note message
if rr!=128 then exit rules, skip Outgoing Action
// Look for MIDI channel ss
rr=oo&15
// Wrong MIDI Channel
if rr!=ss then exit rules, skip Outgoing Action
// set note velocity (LED)
tt=127
// Look for note-off
rr=oo&240
// if 0x80 then it is a note off make velocity 0
if rr==128 then tt=0
// if velocity is 0 turn off the LED
if qq==0 then tt=0
// set outgoing channel to 1
// note on 0x90 MIDI channel 1 =0
oo=144|ss
Outgoing: oo pp tt
If you want to send a note-on with velocity 0 as a note off message you can use a local variable in the outgoing message with rules
Rules:
qq=0
Outgoing : Note on Note pp velocity qq
However MT Pro will complain if you try to put velocity 0 in the outgoing message.
I think because this is technically another form of Note-Off by MIDI standards.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Thanks Steve
Yep…I came up with similar but its more about operational consistency and the midi standard, last time I looked defined 90 0xnn 0 also as a note off esp when release velocity is not relevant.
It gets confusing/sticky with mtp because of the following
The unit is actually issuing that standard yet mtp tweaks it to be a note off
ie even when using the note on trigger with a value of 0 (as var), it ignores the note off and is looking for note off event
So what Im saying is that it would be nice to have both so that it addresses the majority case (by far imvho as only my d70 issues note off + release velocity and I have a fair spread of gear over the years 
(like you???)
Request noted. Thanks for the suggestion!
BTW if you send 90 30 00 to MT Pro it will be registered as note-off with 0 velocity and not as note-on zero velocity since that is part of the MIDI standard.
Same for 80 30 00.
Right now, MT Pro always sends 8n pp qq as a Note Off message unless you code as MIDI raw.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Thanks Steve
Yep thats exactly what Im saying.
BUT
Would be so nice if incoming midi was parsed verbatim (or at least a preference) … i = 0 and all that stuff hehe. Maye even allowing ‘0’ but with a warning or something.
Im often forgetting the quirk and having to add another translator or paste extra code…not a showstopper but just elegant!
Cheers
I’ve asked Florian to review this post. Thanks again for the suggestion!
1 Like
We tried to make:
- Raw MIDI: by bytes
- MIDI messages by name: by meaning (semantics)
So when selecting Note On, it cannot trigger on e.g. 90 40 00, because that is, by definition, a Note Off. Sometimes, it is difficult to make the user interface consistent, but here I see no other option.
On the other hand, adding an input selector “Note On or Off” is a good idea and already on the feature request list.
Also, it’s not nice that you have to resort to raw MIDI if trying to send a Note Off message by using Note On with 0 velocity. Will think about it.
Thanks!
Thanks Florian; its difficult either way.
Current implementation is prob wider case…so my suggestion would be a preference flag eg ‘note on includes velocity 0’ so that users specifically make that handling case and are responsible; instead of an error appearing in ui for 0 val, it changes to a note off reminder?
Do you have a use case where you’d want to receive Note On with 0 velocity but not Note Off?
I don’t think there should be a MIDI device that differentiates them.
Its more about what is reported in the midi in/log window being consistently handled eg
90 02 00
Is the note event that is sent when i release the keypad etc
Ie 90 02 7F
Then
90 02 00
I simply thought that it makes sense to perceive and manage them verbatim?
Cheers