poly~ target failed ?

Jul 22, 2012 at 5:42pm

poly~ target failed ?


how can I ensure that only a specific instance of a poly~ patch will receive a message ?
It should be possible to do with the “target” message followed by the instance number. But if you have more than one source that sends messages to specific instances then sometimes a message fails to arrive its target !
One message source could be a midi interface or metro and another source could be a user interface.

Can someone help me to avoid this ?


Test patch:

– Pasted Max Patch, click to expand. –

and the patch inside poly~ (“InsidePoly_IntegerMatch.maxpat”)

– Pasted Max Patch, click to expand. –
Jul 22, 2012 at 7:25pm

I am not sure what you are seeing on your end… this seems to work fine for me. I have the metro running creating 100 messages per 20ms and I am clicking those buttons on the right getting even more messages while also messing with the scheduler… I don’t get any reports in my window about not matching.
I guess my question is how this situation is a real world example. When would you ever need to send hundreds or thousands of messages per second to poly~??

Jul 22, 2012 at 7:47pm

Hello MIB,

thanks for testing. Indeed this example is for testing only. But it would not make much sense, if I paste my real world example here. It should be as simple as possible…

And yes it has something to do with the scheduler, I think.

The question is: How should I design a system which has a user interface and internals that both generate messages for a specific instance of poly~ ?

Jul 22, 2012 at 10:52pm

ok … i must say i dont get your example patch, especially when it
comes to the defer object which doesnt really do anything at the
place here it is.
and i am also a bit unsure what one should exspect inside the poly
when nothing but the target messages are sent.
properly targeted “nothing”? :D

about how to design a safe system … that is always tricky, at one point
there is always the limit for what can be done in a software.

just dont run in the trap to design it unsafe in order to get more data through
a thread as possible with a safe system, which i think is what you are trying
to do here. :)
if you need n times 100 numbers within 1 ms or one vector, and it doesnt work
wihtout defer, get a either faster computer or redesign your application so that
you need less data!

if i am not wrong, it should be easy for this task to set up safety rules:

1.) make sure that every message to a voice comes “bundled” with
its target message – they must by any means be successive messages.

2.) do not deferlow some messages while others are not, or the order of
events can get scrambled.


Jul 22, 2012 at 11:58pm

Hello Roman,

thanks for your answer.
I have noticed (on my system) that under certain circumstances a message does not arrive the poly-instance for which it was intended. So I have built a simple patch which prints “DOES NOT MATCH” into the max window when a message has arrived in a wrong poly-instance.
In my test patch the correct poly-instance would have the same instance number as the integer sending to the 2nd inlet.
What would you think, when “DOES NOT MATCH” would be printed in the max window ? Something has come between selecting the target and the corresponding integer, right ? But how is that possible ? And how can I avoid that ?


Max 5.1.9 (via M4L)
Live 8.3.2
Core2 CPU T7200 @2MHz

Jul 23, 2012 at 12:34am

I think what Roman was suggesting is that all messages are “packed” into one list and sent to the instance thru one inlet. This way you know that everything is sent right after you send the “target” message.
Something like this might get you started to think in the direction discussed above… that is if I interpreted correctly…

– Pasted Max Patch, click to expand. –
Jul 23, 2012 at 12:37am

Remarks for the test patch:

1) If max does not see the patch “InsidePoly_IntegerMatch.maxpat” the patch cord to the 2nd inlet will be deleted !!!! It is essential that the 2nd poly inlet gets the left most integer of the [t i i] object.

2) give many (fast) mouse clicks on one of the bang-buttons while the metro is running or midi notes come in. This increases the probability that an error occurs.

Jul 23, 2012 at 10:52am

I’ve never worked with poly although I should probably take a look at it as I suspect it might allow me to handle the Eigenharp much better.

However, I would point out that MIDI, in its original design, sends out events at about 1 per millisecond and even a third faster than that if no status byte is needed. As soon as you start sending out a few controller changes along with pitch bend messages while playing a keyboard with aftertouch, you’re easily going to be sending hundreds of messages/second. That ignores any processing you might do that adds to this data or perhaps multiple players and a few sequencers.

If you’re using OSC from the outside world, the data rates can be way higher. The data rate for the Eigenharp (for example) is 2KHz per key (it’s continuous because data is being generated continuously when touching a key) so you can easily have thousands of events per second.

I guess my question is how this situation is a real world example. When would you ever need to send hundreds or thousands of messages per second to poly~??

Jul 23, 2012 at 2:14pm

thanks dhj for pointing that data rate stuff out.
The purpose of a slightly raised message rate in my example patch is to increase the probability of scrambling messages from different sources. In real world applications nobody would know when a click on a user interface is or is not allowed with respect to other messages from other sources. So it is of course unavoidable that messages from different sources must be put into the scheduler at higher rates sometimes. But what are the circumstances with respect to poly~ to avoid scrambling definitely?

Jul 23, 2012 at 8:30pm

well let me put it like this: this is not a poly~ issue, it is all about how you generate the data.

i didnt see that second connection from the trigger which goes into the “select”, hence my
comment. i understand now. :)

so lets get a bit more concrete, when exactly do you run into trouble with the target? does
that also happen when you for example run 2 metros?

i would understand with deferlow, but everything else should work and either stay in order
or end up on a stack overflow.

you should try to to the same test without that poly subpatcher and see if it makes a difference.

Jul 23, 2012 at 8:51pm

“In real world applications nobody would know when a click on a user interface is or is not allowed with respect to other messages from other sources.”

from my understanding (but i am not an extpert for this kind of thing) you do:
the mouse status is requested every 20 ms, and the dataflow it triggers is in
the main thread until there is a [delay] or [line] or [metro] in the way.

same is with midi, when it is comsing to max it is the high priority thread until
there is something which changes that (or globally turned off)

Jul 24, 2012 at 9:39am

So as I understand it, to avoid scrambling of target messages the user/programmer has to ensure that messages from sources with different priority are sent mutually exclusive. But I’m not sure how this could be implemented.

Jul 27, 2012 at 6:17pm

I am back ! :-)

I have captured the screen while my(?) “target problem” occurs.


Below the video you can click on “2:46 , 5:48 , 6:34 and 8:40″ to skip waiting for the error.

-Ableton runs on CPU core 0 and core 1. The video capturing runs on core 4.
-the automatic clicks on the buttons have been generated with a AutoHotkey script.

Jul 27, 2012 at 8:01pm

Hi Stan, can you be specific about what you’re trying to do? I’ve used poly~ for pretty high through-put granular samplers, and haven’t had trouble with this, but…

As mentioned earlier, in the real world, it’s pretty unlikely that you’re going to be dealing with something as fast as Uzi–which executes in the same scheduler thread, IIRC—that’s not at signal rate. What are you doing with the poly~ patch, and does it have to be setup with fixed targeted voices? (very often the answer is no, and you’ll be much better off if you pack everything in a big list and stick the “note” message at the front of it, letting thispoly~ take care of the voice handling)

From what I’ve found, if what you’re trying to do isn’t idiomatic to the problem, you’re more likely to encounter things like this.

Jul 27, 2012 at 9:04pm

Hi Peter,

I need a storage system for my M4L plugin. And the special requirement is that the effect parameters are organized in parameter sets. At the end i want trigger with a midi note a certain parameter set that is then used to create the voice in a (dsp) poly~. The parameter set is selected via the pitch of the midi note.
My first approach was the coll object which can host the parameter sets. The disadvantage of coll in a M4L plugin is that its content cannot be stored easily with the ableton live set. All the existing workarounds are not sufficient for me.

So I thought about poly~ for hosting my parameter sets: An instance of poly~ hosts some pattr objects. And with the target message I want select a certain parameter set. Now the “challenge” is that while some instances are used for voice generation at the same time a user interface is used to manipulate one of the parameter sets.You can imagine what happens if the target message does not reliably switch between the poly~ instances….. some of the changed values will not arrive in the correct parameter set. Thats what I have noticed on my system and what I tried to point out with my example patches.


Jul 28, 2012 at 12:07am

try this as a quick and dirty solution to make it work:

parameter int (connected to rightmost inlet of pak), voice number int (connected to middle inlet of pak)
[list target -1 0]

the paramter int must trigger the list object via t b i.

repeat this for all parallel input sources. some with delay, some as is, some with defer
and deferlow, just as in your patch above.

then connect all of them to

[zl slice 2] (or ecils, i dont have max here)
[poly~ test]

and the scrambled order symptom should be gone.


Jul 28, 2012 at 1:54pm

Thanks Roman for your suggestion. But I don’t think (if I understand you right) that this would change things in principle.

Have a look at this video:


Jul 28, 2012 at 7:58pm

Hi guys.
I must first say that I couldn’t open your patches, so I’m not sure I’m giving you relevant information – sorry about that.

If I understand correctly, your problem is that you first send a “target n” message, and “immediately” after that another message that is supposed to be routed to the nth voice of the poly~. The problem is that if you have overdrive on AND the messages you are sending to poly~ run in different message threads (e.g., some come from the mouse and some from a MIDI instrument) at some point it may happen that things get messed up like this:
main thread: “target 1″
scheduler thread: “target 2″
scheduler thread: “message to 2nd instance”
main thread: “message to 1st instance”

There is no way to prevent two messages in one thread from being interrupted by messages in the other thread. There’s worse than this: even _inside a max external you might find out that the two threads can interact in unexpected ways.

There might or might not be an easy solution, but in principle if you turn off overdrive your troubles should be gone. You can’t do this in M4L, though.

Something which might or might not work, according to what happens in the rest of your patch, is having the instance number as the first element of the message to be routed, and then using something like this (doesn’t work in Max 5)

– Pasted Max Patch, click to expand. –

The other possibility is forcing all the messages to run in same thread, by deferring high priority messages (which will worsen the timing of the MIDI stuff) or moving to the scheduler low priority messages. For the former, use [defer] or [deferlow], for the latter use [del 0] or [pipe 0].


ps: [uzi] works in either thread, according to who it was activated by…

Jul 28, 2012 at 8:18pm

Hello Andrea,

WOW, thank you for that enlightening answer. That really makes sense!!!

I will think about…….


Jul 28, 2012 at 8:45pm

Hi Stan.

I’m glad it helped…

Yes, this threading stuff can be a real pita – and at the same time it is crucial for all the time-critical stuff, such as MIDI, so you can’t just lightheartedly turn off overdrive and get rid of it. And with M4L and, under some circumstances, Max6 it’s even worse, as you can have different scheduler threads for different patches…

I tend to consider myself a sort of a veteran of this stuff, and I have written externals doing rather wild things with threads, and yet I found myself in a deferlow nightmare with [detonate] just some days ago…

There is some documentation around on this subject, but it is rather technical and I never really understood it until I read some quite geeky literature about how operating systems work and had the chance to get first-hand information from some C74 developers.

I definitely think C74 should provide some less advanced docs about this, with real-world examples such as yours… or maybe someday I might decide to write a tutorial for my students, in which case I’ll surely make it available for free ;)


Jul 29, 2012 at 5:59pm

Concluding: My poly~ target problem is solved.

For completeness I have made another boring video.


Thanks again to Andrea, MIB, dhjdhjdhj, Peter, broc and Roman.


You must be logged in to reply to this topic.