Bug with MIDIdef chan argument

I think I have stumbled across a bug in which the chan argument for MIDIdef does not properly respond when set equal to nil. Regarding the chan argument, the MIDIdef help file reads:

“An Integer indicating the MIDI channel number for this MIDIdef. This can be an array. If nil, the MIDIdef will respond to messages received on all channels.”

However, this code produces some unexpected results. To test this code properly, a MIDI controller capable of sending note-on messages on different channels is required.

Is this a bug, or is this intended behavior? I’m on SC 3.10.3, OSX 10.14.6.

Eli

//init/cleanup
MIDIIn.connectAll;
MIDIdef.freeAll;

(
//basic note-on def
//successfully responds to all channels
MIDIdef.noteOn(\x, {
	arg vel, num, chan, src;
	[vel, num, chan, src].postln;
});
)

MIDIdef(\x).chan; //returns nil, as expected

(
//overwrite def at key \x
//now only responds to messages on channel 4
MIDIdef.noteOn(\x, {
	arg vel, num, chan, src;
	[vel, num, chan, src].postln;
}, chan:4);
)

MIDIdef(\x).chan; //returns 4, as expected

(
//overwrite to respond to all channels again
//***but STILL only responds to channel 4***
MIDIdef.noteOn(\x, {
	arg vel, num, chan, src;
	[vel, num, chan, src].postln;
}, chan:nil);
)

MIDIdef(\x).chan; //returns 4, unexpected behavior (or is it?)

I think this is worth logging as an issue.

Currently, when updating a MIDIdef, ‘nil’ means “keep the previous value.” But, as noted, ‘nil’ is also supposed to mean “accept messages from every channel.”

So we have the same token with an ambiguous meaning. This kind of ambiguity in a programming interface is, objectively, incorrect.

hjh

Thanks, James. I submitted this as an issue on github.

Eli