<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>Hi William,</div><div><br></div><div>I think that [poly] is not buggy. What confuses is that MIDI is a serial protocol, I mean that if 6 notes are </div><div><span style="font-size: 12pt;">pressed at the exact same time they would be passed one after the other in the MIDI message. And when you play </span></div><div><span style="font-size: 12pt;">a chord the order of the notes are not clear to YOU but in fact they are ordered.</span></div><div><br></div><div>Test your patch at low speed and ordered, you will see it works exactly as it should.</div><div><br></div><div>(send a “clear” message to all poly objects, or close and reopen the patch)</div><div><br></div><div>Play and hold in order: C, E, G, C2, E2, G2. Then release in backward order.</div><div><br></div><div>Now do a:</div><div><br></div><div>[notein]</div><div>[pack 0 0]</div><div>[print]</div><div><br></div><div>Play a chord, you will see the “same” order that [poly] sees. This will explain why you think that there is a </div><div><span style="font-size: 12pt;">bug, or the Trial-1 Trial-2 inconsistency (which is not).</span></div><div><br></div><div>Hope this helps,</div><div><br></div><div>Lucarda.</div><br><font face="Courier New, Courier, Monospace" size="2">Mensaje telepatico asistido por maquinas.</font><br><br><div><hr id="stopSpelling">Date: Sun, 15 May 2016 20:06:02 -0400<br>From: williamahuston@gmail.com<br>To: brbrofsvl@gmail.com<br>CC: pd-list@lists.iem.at<br>Subject: Re: [PD] [poly N 0] bug<br><br>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" target="_blank">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>
<br>_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list</div> </div></body>
</html>