Bugfixes in midi->osc conversions

[agraef]

In particular, the first commit fixes a glitch in my rev. e344a5d which caused recorded OSC values to also be used if the actual argument was a constant or range. Seemed like a good idea at the time, but didn't work out so well and also contradicts the documentation in default.omm.

The second commit makes sure that we only use the MIDI channel number (rather than the entire status byte) when converting midi argument #0. (The third commit does the same for non-linearity checks on the MIDI side.) Seems like this one has been there for a long time (ever since midi->osc support was added), but I only noticed it now when testing some examples for the documentation of the midi2osc map format that I've been working on.

The fourth commit reverts my rev. 0d895bc. That change also seemed a good idea at the time, but as it turns out, it gets in the way if a variable is used both in the first (channel) argument and the second or third argument of a midi message, because the channel argument typically has a much lower resolution (being a 4 bit value) than the second or third argument. So in fact the previous behavior of using the last variable occurrence on the rhs of a rule is preferable.

Last but not least, the fifth commit accounts for the rounding of midi arguments in non-linearity checks on the rhs of a rule. In conjunction with the fourth commit, this makes -strict mode work much better in midi->osc conversions.

[agraef]

Would also be nice to have a new point release with this changeset, as it contains important bugfixes and really makes -strict work much better in midi->osc conversions.

[ssj71]

great catches. Thanks!

[agraef]

Thanks! How about a new point release?

[ssj71]

Done!