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)
[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]) 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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
Hi William, I think that [poly] is not buggy. What confuses is that MIDI is a serial protocol, I mean that if 6 notes are pressed at the exact same time they would be passed one after the other in the MIDI message. And when you play a chord the order of the notes are not clear to YOU but in fact they are ordered. Test your patch at low speed and ordered, you will see it works exactly as it should. (send a “clear” message to all poly objects, or close and reopen the patch) Play and hold in order: C, E, G, C2, E2, G2. Then release in backward order. Now do a: [notein][pack 0 0][print] Play a chord, you will see the “same” order that [poly] sees. This will explain why you think that there is a bug, or the Trial-1 Trial-2 inconsistency (which is not). Hope this helps, Lucarda. Mensaje telepatico asistido por maquinas.
Date: Sun, 15 May 2016 20:06:02 -0400 From: williamahuston@gmail.com To: brbrofsvl@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] [poly N 0] bug
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
-
Lucas Cordiviola -
Matt Barber -
William Huston