Stan

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.

and the patch inside poly~ ("InsidePoly_IntegerMatch.maxpat")

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.

and the patch inside poly~ ("InsidePoly_IntegerMatch.maxpat")


poly-target-failed

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~??

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~??


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~ ?

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

and i am also a bit unsure what one should exspect inside the poly

when nothing but the target messages are sent.

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

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

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

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!

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.

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 ?

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


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...

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...


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.

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~??


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?

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?


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

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

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

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.


"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)

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)


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.

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.

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

Remarks:
-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.


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.

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.


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.

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.

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)

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.

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

and the scrambled order symptom should be gone.

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

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

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

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

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:

scheduler thread: "message to 2nd 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)

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...

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"

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


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

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 ;)

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.

Concluding: My poly~ target problem is solved. 

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


OK --- I think I just ran into this issue and it's a bit of a show stopper. Is it in fact always the case that when overdrive is enabled, target simply doesn't work?

In my example, I have a single object sending a MIDI message to separate instances in a poly. If overdrive is enabled, then only the instance on the LEFT is triggered.

If this is true, then it's not possible in practice to address individual VST~ instances in a poly~ since overdrive needs to be on for decent response times.

Thanks to a suggestion from Andrew Pask yesterday, I was able to solve the problem completely by NOT using 'target' but rather by using send/receive objects with names that contain the instance number within a poly. That way you can directly "reach in" to the desired instance. This works just fine with overdrive.

Figured I'd mention this solution for the next person who has the problem.

"how can I ensure that only a specific instance of a poly~ patch will receive a message ?"

this is what i've used for years because it was suggested on these forums back in the max4 days, from within i control muting as well:

(i've found in max6, though, target is actually working great for me with overdrive on... but i don't attempt to send more than just velocity(i never 'target' the 'midinote' or 'note' message, just a single integer for velocity(and the instance number for 'target' is mapped by midinote number)... other parameters are changed by 'target' as well, but they go in through the other inlets other than the left one... dunno... i still prefer controlling poly~ from within using similar things to the above patch... but finding this new behavior for 'target' seems interesting/encouraging...)

edit: oh i c in the vids, you send 'target' through left inlet, then triggered message through other inlets, i don't know if it makes a difference, but i generally send "target $1, $2" messages straight through any inlet all at once(sometimes i require a message to be sent like "rec 1", in which case i just use "target $1, $2 $3" for those specific inlets).

ignore me if my 'target' ramblings don't make sense, others have given you enough ideas to run with :)

edit: oh i c in the vids, you send 'target' through left inlet, then triggered message through other inlets, i don't know if it makes a difference, but i generally send "target $1, $2" messages straight through any inlet all at once(sometimes i require a message to be sent like "rec 1", in which case i just use "target $1, $2 $3" for those specific inlets).
ignore me if my 'target' ramblings don't make sense, others have given you enough ideas to run with :)


make sure you dont have the usual thread/order problem.

when you have an incoming message in high priority, and you use this to trigger its preceeding target message, no problem should appear.

order of messages is something easy to miss in very idiosyncratic system. stay more linear with things like this. :)

@RAJA ---- yeah, your example uses send/receive including an instance number. I've essentially done exactly the same thing except more generalized so that each receiver knows the poly ref and instance ref and the kind of event it's supposed to receive. Attached is a small section of this. The point is so that the container that holds polys with VST instances is able to receive standard MIDI events and all the conversion gets done inside. I've completely eliminated the use of 'target' now, it was failing reliably!

@ROMAN ----all the incoming messages are of the same priority (they were coming from the same external MIDI keyboard for example) and they trigger the target message and then the appropriate MIDI message is sent, in one go. This worked fine in non-overdrive mode (so the 'logic' was correct) but failed when the events were sent to two instances "simultaneously". Using wireless has solved this entirely. My system is not idiosyncratic :-)

With the existence of the above, I can then create extremely simple performance patches such as this one which sends notes, aftertouch and sustain pedal info to the third instance of the second poly~ in my synth bank and also sends just notes to the fourth instance of the first poly in my synth bank.

The goal was to have enough infrastructure created so that it becomes really simple to create song patchers in the spirit of Apple Mainstage.

poly~ target failed ?