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 ?

cheers
Stan

Test patch:

----------begin_max5_patcher----------
1101.3oc2Y97iiZCEG+bVo8+gWQ8PqTZD1FRfdq6s4Pk5gdqypUjfCiaA6Hv
rYxtp8u8ZrgrISI.6vuR2K3Dahyyedee98v7429lEVaEOSyrfeF9CXwhOq5Y
gtuhdVT0wBqjfm2EGjouQqchjDJWZsrbPI8Yod.zpUqP11mGXufK4AIT8f+R
JKH97P77DFOlJ0yH5hdE4xptsq5lEpmAw1+7mHjySwgTZlxLBjLA+CozcRyp
fXuxdIPbWWzXWdAd+k1TF6SZaBgWc9+3Pfb2SLdzEyjuYlbbKZb1TbEqmK8O
4ue6aJZUMK6L43zipEw+Ebgz8zzFvF7NQb3WE6P0wNbaryw1QuJwt0COyef7
zAp49srtAXsaDrDCYwUtphqHudQ1apIkomfj7XI6PLEjornHZJjIxS2Qyf.I
HehBYJXCRlh3ioxE0F8c8zZVzZu1kt3lIrqlod54vAYbp9iDfUbKrhriJ.sa
CfHeM+v98NzWKfAjQf56M.g9MHPMZxOxBfDVHaLQH1uUDVxPBp+LjL8PbepH
AxyTehwkzz8A6nvOjDvOA6hY69qre77OMlwo6D4b8uGOlL2q0ccczvF41ajS
tB4n0NlDX8h4RQTTLs2IevartYVDVgW38MrtL4iPaL4K7ptNFJo2kKgG1CAf
ZIsUoiBRSYeTkpfKj.SlAOZINxezBjAoQTc5Ctpe3HKNF1RgT5AQpTsgHiqS
sn9SUiwCEGejWu1iLlZO2VqVxjrA6g6u3yjU2oxYomQmQxM86J1V5g1KJh1U
X.vfXObPDe5eTo7yjffGepvoTrvAoP6PJ8aGYxm9Rt+xY56ldODZi0qG0j0k
kNMDn9V0lJgsidkoX6au4v1.dzqqLSjQIhMauhICPYl2BR4ehAM+jOM.Jb8f
hTCn7ZgSK+R60ap9JvlQb4hF.rsMWJE7dKSPNcVlTWPS4FSl0kCo55+ikCH2
IPOPFd8PiOGbr33nugCBYMvOSqy5KelVW7cTTCtOQMkqquohZHSPTSkdXBhZ
TklRY7AMloNrgwMWA+xqZ5SpGjo7lMj6mfHLpWod77+lKHxeJR8X31TDDkPk
oB.Orfq1siGkZcupT2AI6ybKvVOA5qoqxFIv.1ftEMtFl41ocnecaMaNRYR4
YvPV41aVkPyxBhn0.Kyyn+8nQOXzYnKCr7LpbbtrLv0ihjxbPGOvyXgzeS84
O7.WRino+ZgUsRMEJyaviTq8Tlr5AnJKSBc6WBjwOnORlW9hJ0yaw.ufel2u
Soirpde3hi0JjlIYb8ggc4cQt9tdhEFR4WsrSXgGDpfnRKoI2Z2MNbmLNz7X
bELA2lw4NO1l+8qsQ5lS0eVLNbmBGd4RXpLtMchb1yijytKF25Yw1b6hoU3S
QeMlVwaQRkq2wFWzP13d9aChQ6zUidFDhcxW6MO1Vm1dAOOAId2woLbuissN
EKfbmsMWPsYaNyhosdZboEcnZ9WPZ0EM+
-----------end_max5_patcher-----------

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

----------begin_max5_patcher----------
585.3ocyV97aSCCEG+blz9evxmKSwNsMc6BZBPhKvNvtgPQNIdsFkXGE6.cL
A+si+QbaVW5ZgjN3ReRum8Keee5W6jGN+r.XpXMUBAWA9LHH3Acl.aNSl.eh
.XIYcVAQZWHLSTVR4J3j1hJ5ZksPtfJApUT.iaVCiuDvaJSo0fRhJaUaIohv
yn9JudSaJXbZlnga60Le16DbEmTRsOfqqYjhMaP2AFufprpB0IqnQ4SG5Syx
scPj90Wc4lNTUSk5IgnXBdRMMS4.ABc4EgS.n3XSHr8GvW5pII6GVMgMk8sy
Lk5otSql55zTjMLegMfQltY2zOO+LSTGlLb9uCagmPFNG1GLP3mEFQQyry+L
WHzFvgCBFkTojrj9TXD9GO939GeTOiOZa2cqTceE0MjPX+FkCwlVZDYsawNB
sXPngS+tVqOkLU0LtB71ad2mR93M2l7gqu8Mu+T5UV.G.OhCcVlnQvqrOfHo
EikYA2y7Oc+dkTBeIbxeqmAOyAGmaIN5hYmLDw3.7X4Q56.UzXedxyFmMJBs
0932jj7MZdh9gq2SBQopYoMJ26BC1hm.noTh+NWidgtJs3cTwbgfj67DmNTi
OfcbHWe0h643S3oU0JlrRTb+uFKH02YVz9gDy7pWWXPnxcS+7v8hJW2seWzt
eglsslB6.PonoNyKT+Kp.cL84TohwsevSmUs3wKZEKOmxez04kr7JgdjaExy
825QqM88h.zgj1tCvKj1PGC1rZC8hqsniQaS++EaS+mPM7Q8O5folIgN7aP1
Pp+p
-----------end_max5_patcher-----------

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

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.

-110

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 ?

cheers
Stan

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

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.

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

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.

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)

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

https://vimeo.com/46500783

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.

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.

cheers
Stan

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.

-110

Have a look at this video:

https://vimeo.com/46535733

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)

----------begin_max5_patcher----------
409.3ocwTFsaBBCEF9Z3onoWyHzhntc2dNVLKUnpGCzRnUmNi6Ye1CfS2zDE
IY2zS5+4vo+8qsry2iNUuQZnjWHuQ771464gRNAul4dzBwlzbgAKiVHMFwbI
MnNmUtwh5bRSFhUSLxTsJi.JiUnROV7LsxZfOktOfwCiZjUqJ.UtzhK.+GQ8
JaqJqQsVxtsTV6YJkLoIEjg9POc4SImtfJQAVL80JPj2loTXSW.p4uWISs08
JlMLLIfLxYLBaTLFFGFQl39j899tgfGDSrSwzLnxX+2nzfNQIdBRomGg3I4w
njR9wAm7GHUcXCzC3feUbDbEjv63EmAHEFxbg3wtQdT+hD6BvTpy2908fE18
gEPYcjwEtDbXcCNCPpvhwPxkgCtbzbP86+EgMzoeNwL5UUos1t4EOI5noyjF
KnDVPqNoF9Y0r.xxjX5VzkAFwzbItgit3I2s5lA8faJfrR8gihFfDyicO6XC
4gmz4dywrazwrNvu5CWQY4ZYkooknQNbweotxMcX.NET0SwNRqjqg15S7cca
u+2..6xi5B
-----------end_max5_patcher-----------

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

hth
aa

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

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

I will think about…….

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

Cheers
aa

For completeness I have made another boring video.

https://vimeo.com/46576696

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