#13 make note-offs match note-ons with zero velocity in MIDI->OSC mapping

[Albert Graef]

See https://bitbucket.org/agraef/osc2midi/commits/c5ba977

The suggested change makes proper note-off messages (0x8n status) match config pairs involving note-ons (0x9n status) with zero velocity in MIDI->OSC conversions.

Rationale: According to the MIDI standard, on the writing end it is really up to the implementation of a particular MIDI device, driver or application whether note-offs are emitted using the 0x8n status or as note-ons with velocity 0. Also, it's often convenient to represent both note-ons and -offs using a single OSC control which emits a zero value for the latter.

Therefore it's always a good idea to accept 0x8n in lieu of an expected 0x9n message with velocity 0, and this is what the suggested change adds to the try_match_midi routine in pair.c.

[ssj71]

I'm a little hesitant about this patch only because it is not explicitly doing what the mapping states. Could there be some situation that the user would want to distinguish between a note-off and a note-on with velocity 0? I guess not. I think I'll apply the patch as is for now and should any user request that in the future, add an extra command line option to toggle this behavior.

[Albert Graef]

I'm replying to this in email because SF is in static offline mode
currently.

On Tue, Jun 2, 2015 at 5:00 PM, ssj71 ssj71@users.sf.net wrote:

I'm a little hesitant about this patch only because it is not explicitly
doing what the mapping states.

I understand. But any other way to get this behavior is horribly awkward.
E.g., consider the following rule (generated from my msgtest.touchosc
example):

/1/fader2 f, val : noteon( 0, 60, 127*val );

This just works in OSC->MIDI conversion, and the MIDI->OSC conversion also
works except for the note-off 60 case. ALSA will always convert this to a
proper note-off which then fails to match that rule. So to make that work
I'd have to add a second rule:

/1/fader2 f, val : noteon( 0, 60, 127*val );
/1/fader2 f, 0 : noteoff( 0, 60, 0 );

But that doesn't work either, because this will now generate two note-off
messages in the OSC->MIDI conversion. So I'd also have to modify the first
rule in order to make sure that it doesn't apply to the val==0 case. Which
is awfully convoluted for such a simple thing.

The proposed change gets rid of all these complications. I really think
that it's the right thing to do here. And it's also in accordance with the
MIDI spec which mandates that a MIDI processor should be prepared to deal
with proper note-offs and zero note-ons in a consistent fashion. If
anything, this is an idiosyncrasy of the MIDI protocol, but it's a
well-known one, and anyone who is familiar with MIDI would expect it to
work that way IMHO.

Could there be some situation that the user would want to distinguish
between a note-off and a note-on with velocity 0?

I can hardly imagine what that might be. In any case, this kind of
flexibility would come at the cost of having to jump through a lot of hoops
to make the common cases work as expected.

I guess not. I think I'll apply the patch as is for now and should any
user request that in the future, add an extra command line option to toggle
this behavior.

Exactly. Procrastinating on rarely used features is a good thing(TM). :)

Albert

--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef@gmail.com
WWW: https://plus.google.com/+AlbertGraef