Sorry, Sourceforge is blocked for me.
I noticed that when using [poly 1 0] (note stealing off) when I would smash multi-note chords and release notes, sometimes I would be left pressing a note, yet the output of [poly] is silence.
I thought this might be a bug with the Windows MIDI driver, but it is definitely a bug with [poly], because with higher values of N, [poly N 0] knows the correct notes remaining.
See attached ZIP file. There is an HTML+image included which explains how to run the patch to demonstrate the issue.
The problem is there is a race condition. Lets say you smash the following chord: ("smash" means play all notes as simultaneously as possible)
*24 26 28 29 31 33* [C-D-E-F-G-A]
Now the value which will be latched by [poly 1 0] is random. Let's say it is 28.
Now we release 33, 31,29 .... ALL GOOD! Now release 29.
*NOTE 24, 26, 28 are still depressed!* [poly] doesn't know what to do here, and releases 28, *ALL NOTES OFF. Yet I am still holding down 3 notes. *
*The problem here is how do deal with this condition is ambiguous.*
- Should [poly] have "highest note value" priority? (and jump to 26)
- Or "lowest note value" priority? (and jump to 24)
- Or "order received" priority? (and jump to to the *latest received*
of [24,26]) 4. Or maybe "reverse order received" priority? (and jump to the *earliest received *of [24,26])
I would request a feature enhancement to provide some way to set the mode of poly (new inlet, message to inlet1, and/or starting parameter) to chose one of these four modes.
In the meantime, I think I can code my own version of what I need as an abstraction.
Thanks Miller and everyone who contributes here for such an awesome tool/toy!
BH
-- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)