HarryK

I'm running into some trouble with stuck notes. I'm using a foot controller to send MIDI messages to Max and then I send those messages to a MIDI processor. The input - channel 1 - also outputs to 6 channels, to build a chord with each note on a separate channel. The chords are built with transposition "ctlout" messages, so the MIDI isn't really "messed with" in any real way - there's no immediately apparent reason for notes to get stuck.

So, I'm trying to further debug things. What are some options? Are there implementations of speedlim and borax that might do the trick? What about issues related to CPU speed and how it communicates with multiple devices? Part of me suspects the issue is how my computer relates to the outboard MIDI processor.

I'm running into some trouble with stuck notes.  I'm using a foot controller to send MIDI messages to Max and then I send those messages to a MIDI processor. The input - channel 1 - also outputs to 6 channels, to build a chord with each note on a separate channel. The chords are built with transposition "ctlout" messages, so the MIDI isn't really "messed with" in any real way - there's no immediately apparent reason for notes to get stuck.

So, I'm trying to further debug things. What are some options? Are there implementations of speedlim and borax that might do the trick? What about issues related to CPU speed and how it communicates with multiple devices?   Part of me suspects the issue is how my computer relates to the outboard MIDI processor.


midi-stability

The most common reason for stuck notes in a multi-channel MIDI setup is, that a note-off goes to another channel than the note-on belonged to. As a result, the original note will ring forever. You may check your patch with this in mind.

You say, that you are splitting channels – are you sure, that you always take the note-off with you? With static splitting this should be ok, but if you do some switching or multiplexing you might run into the "lost note-off" problem.

Do not use it while you deal with notes. [speedlim] steals events, which is the whole purpose of this object. You would lose note-ons and note-offs in a random pattern.

Yes this can help. But if the patch is as simple as you say (only splitted channels) I rather think you lose your note-offs somewhere in your basic design.

Make sure that your note-ons and note-offs go always to the correct channels. Repairing that after it happended is possible, but most likely leads to killed notes which do not necessarily fit to the musical context.

[speedlim]
Do not use it while you deal with notes. [speedlim] steals events, which is the whole purpose of this object. You would lose note-ons and note-offs in a random pattern.

[borax]
Yes this can help. But if the patch is as simple as you say (only splitted channels) I rather think you lose your note-offs somewhere in your basic design.

Make sure that your note-ons and note-offs go always to the correct channels. Repairing that after it happended is possible, but most likely leads to  killed notes which do not necessarily fit to the musical context.


Well, there is no channel-switching - it is one MIDI channel in, send to 6 fixed channel outs. The pitch is only changed by a "transpose" message, not by breaking up the MIDI message with Max objects.

As far as I can tell, I don't seem to have the same problem on a PC - so I'm assuming its related to some sort of conversation between my computer and the MIDI interface. Are there larger scale system settings that might be adjusted?

Well, there is no channel-switching - it is one MIDI channel in, send to 6 fixed channel outs. The pitch is only changed by a "transpose" message, not by breaking up the MIDI message with Max objects. 

As far as I can tell, I don't seem to have the same problem on a PC - so I'm assuming its related to some sort of conversation between my computer and the MIDI interface. Are there larger scale system settings that might be adjusted?


I don't know about general Mac settings which affect MIDI throuput. Maybe the MIDI interface is not good or not 100% compatible to your operating system.

Checking for stuck notes is easily done by [borax] – the third output should never stay at a value greater than zero.

1. You can check at your MIDI input in Max, to tell if the footcontroller or the communication line are faulty.

2. You can check on each output channel of your Max patch.

3. Finally, if you have a multi-port interface, you can check your output MIDI interface by feedback: Connect the output to an input of the interface and get the notes back to Max where [borax] waits for them.

If all three tests run successfully without showing held notes in [borax] – mhm – what remains? The sound module?

Stuck notes can also be a side-effect of a MIDI loop. While working with MIDI it is always a good idea to have a tool like "Midi Monitor" running. Beside the incoming and outgoing notes it shows you all other events and a loop becomes visible by a continuous stream of events.

1. You can check at your MIDI input in Max, to tell if the footcontroller or the communication line are faulty.
2. You can check on each output channel of your Max patch.
3. Finally, if you have a multi-port interface, you can check your output MIDI interface by feedback: Connect the output to an input of the interface and get the notes back to Max where [borax] waits for them.

BTW:
Stuck notes can also be a side-effect of a MIDI loop. While working with MIDI it  is always a good idea to have a tool like "Midi Monitor" running. Beside the incoming and outgoing notes it shows you all other events and a loop becomes visible by a continuous stream of events.
http://www.snoize.com/MIDIMonitor/


Along the lines of the principle suggested by Peter Ostry above, another common source of stuck notes is transposing note-ons, but not transposing note-offs in the same amount. This will happen if the transposition value changes mid-note, which could very easily happen if your transpositions are provided algorithmically. I'm betting that's the source of your problem.

Here's an abstraction you might find useful (from the Max 2.0 tutorials). It stores the transposition of note-ons, and looks them up to apply the same transposition to the corresponding note=offs.

Along the lines of the principle suggested by Peter Ostry above, another common source of stuck notes is transposing note-ons, but not transposing note-offs in the same amount. This will happen if the transposition value changes mid-note, which could very easily happen if your transpositions are provided algorithmically. I'm betting that's the source of your problem. 

Here's an abstraction you might find useful (from the Max 2.0 tutorials). It stores the transposition of note-ons, and looks them up to apply the same transposition to the corresponding note=offs.


MIDI Stability