Yes, that's what I want, proper mono mode, with opt. auto glissando when 2+ notes are played. <br><br>Maybe it's a feature enhancement.  <br><br>That's the abstraction I'm working on.<br><br>I'm trying to implement a 6-element linked list, with push/pop (front of list), shift/unshift (end of list), and delete... it's possible, but challenging. Lot of work. <br><br>On Sunday, May 15, 2016, Matt Barber <<a href="mailto:brbrofsvl@gmail.com">brbrofsvl@gmail.com</a>> wrote:<br>> [poly 1 0] means that until its note is released, all incoming notes between onset and offset of the only voice's note should be completely invisible to it (that's what "one-voice polyphony with no voice stealing" should mean, I think). I don't think it should suddenly output the values of another note that happened to have been depressed and held in the meantime. I think what you're looking for is something different from the voice allocation in [poly]; you're looking more for assigning note priority in monophonic instruments. If I'm understanding you correctly, in order to do what you want with [poly], you would need to manage a very large internal polyphony to keep track of all the potential voices that could be being sustained when a voice receives a note off. <br>> On Sun, May 15, 2016 at 4:47 AM, William Huston <<a href="mailto:williamahuston@gmail.com">williamahuston@gmail.com</a>> wrote:<br>>><br>>> Sorry, Sourceforge is blocked for me.<br>>><br>>> I noticed that when using [poly 1 0] (note stealing off)<br>>> when I would smash multi-note chords and release notes,<br>>> sometimes I would be left pressing a note,<br>>> yet the output of [poly] is silence.<br>>><br>>> I thought this might be a bug with the Windows MIDI driver,<br>>> but it is definitely a bug with [poly], because with higher<br>>> values of N, [poly N 0] knows the correct notes<br>>> remaining.<br>>><br>>> See attached ZIP file.<br>>> There is an HTML+image included which explains<br>>> how to run the patch to demonstrate the issue.<br>>><br>>> The problem is there is a race condition.<br>>> Lets say you smash the following chord:<br>>> ("smash" means play all notes as simultaneously as possible)<br>>><br>>> 24 26 28 29 31 33  [C-D-E-F-G-A]<br>>><br>>> Now the value which will be latched by [poly 1 0] is random.<br>>> Let's say it is 28.<br>>><br>>> Now we release 33, 31,29 .... ALL GOOD!<br>>> Now release 29.<br>>> NOTE 24, 26, 28 are still depressed!<br>>> [poly] doesn't know what to do here, and releases 28, ALL NOTES OFF.  Yet I am still holding down 3 notes.<br>>><br>>> The problem here is how do deal with this condition is ambiguous.<br>>><br>>> Should [poly] have "highest note value" priority? (and jump to 26)<br>>> Or "lowest note value" priority? (and jump to 24)<br>>> Or "order received" priority? (and jump to to the latest received of [24,26])<br>>> Or maybe "reverse order received" priority? (and jump to the earliest received of [24,26])<br>>><br>>> I would request a feature enhancement to provide some way to set<br>>> the mode of poly (new inlet, message to inlet1, and/or starting parameter) to chose one of these four modes.<br>>><br>>> In the meantime, I think I can code my own version of what I need as an abstraction.<br>>><br>>> Thanks Miller and everyone who contributes here for such an awesome tool/toy!<br>>><br>>> BH<br>>> --<br>>> --<br>>> May you, and all beings<br>>> be happy and free from suffering :)<br>>> -- ancient Buddhist Prayer (Metta)<br>>><br>>> _______________________________________________<br>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>>> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a><br>>><br>><br>><br><br>-- <br><div dir="ltr"><div><div dir="ltr">--<br>
May you, and all beings<br>
be happy and free from suffering :)<br>
-- ancient Buddhist Prayer (Metta)<br></div></div></div><br>