Yes, that's what I want, proper mono mode, with opt. auto glissando when 2+ notes are played.
Maybe it's a feature enhancement.
That's the abstraction I'm working on.
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.
On Sunday, May 15, 2016, Matt Barber <brbrofsvl@gmail.com> wrote: > [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. > On Sun, May 15, 2016 at 4:47 AM, William Huston <williamahuston@gmail.com> wrote: >> >> 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]) >> 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) >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >> > >
--
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)