add -strict option + some bugfixes

[agraef]

As promised. I think that it makes sense to keep the old behavior as the default. Thus handling of multiple occurrences of the same variable in matching is now disabled by default, but the new -strict option enables it.

[agraef]

Added a few more bugfixes. Feel free to ignore commit 50e9561 if you really want to allow the argument of setchannel to be a 7 bit (rather than a 4 bit) value.

One question concerning MIDI value ranges I'm still pondering is whether there should be an option to have MIDI data bytes clamped to the 0..127 range (or 0..16383 for pitch bend). Currently they will wrap around if OSC values become too big or too small. E.g., in some cases it might be useful to write something like

/foo f, x: controlchange(0, 1, x*128)

to have x=0.5 mapped to 64 (customary center value in MIDI) rather than 63 (as would be the case with x*127). But then x=1.0 gets mapped to 128&0x7f = 0 which isn't usually what you want. This could be solved by clamping the value to 0..127 (i.e., taking min(127,max(0,midival))) rather than taking it modulo 128. What do you think?

[agraef]

Feel free to ignore commit 50e9561 if you really want to allow the argument of setchannel to be a 7 bit (rather than a 4 bit) value.

I decided to revert that commit after all, since it isn't consistent with the way channel values are handled in other parts of the code.

[ssj71]

I think that probably makes more sense to clamp the value. It seems more consistent with other programs. I can't think of a program that wraps the number if over or under a limit.

[agraef]

I can't think of a sensible use case for wrap-over either. I'd say that the same applies to the arguments of setchannel and setvelocity (as well as the corresponding command line options).

The only argument against clamping that I see is that it becomes a bit messy, since the different kinds of arguments have to be considered: channel value (0-15), ordinary data byte (0-127), status byte (first arg in rawmidi, 0-255) and pitchbend (0-16383). That's quite a bit of hidden magic.

There's also the special case of setshift which should be left untouched as it is now, since it's simply a note offset. However, I think that at present the filtering isn't implemented properly either, since the shift value is simply added without making sure that the result is again a valid data byte. Neither clamping nor taking note numbers modulo 128 makes much sense musically IMHO. The way I'd implement this is to reduce a note >= 128 by a multiple of 12 so that it falls into the highest octave, and likewise map notes < 0 into the lowest octave. Does that sound sensible?

All right, I have to teach courses today, but I'll have a go at it tonight. It shouldn't be too hard to implement.

[agraef]

Ok, there you go. I implemented the clamping of MIDI values as described, and also fixed up the midi filter stuff (transposed notes that fall outside the 0..127 range aren't output any more, and note-ons with zero velocity are now properly recognized as note offs).