[PD] [poly N 0] bug

Matt Barber brbrofsvl at gmail.com
Sun May 15 22:11:55 CEST 2016


[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 at 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.*
>
>    1. Should [poly] have "highest note value" priority? (and jump to 26)
>    2. Or "lowest note value" priority? (and jump to 24)
>    3. 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)
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160515/ebc7fd69/attachment.html>


More information about the Pd-list mailing list