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 ?
----------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-----------
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
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.
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)
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…
----------begin_max5_patcher---------- 1436.3ocyYszaiaCD9r8uBB01KsYCHond3hdnEsnnnXOTzG6kMKLnkXb3VYI AI5rIYw1dn+w6PRYEIaKK4rJB4hr4PwgeyGmGjTeb9LmUY2IJcPeK5snYy93 7YyLhzBlU0dlyF9cQI7Ryq4jJ9P1p26bgsKk3NkQboHAgQjcxuNKUkx2HL88 CERdxtdR2tQllHTFs49nvrsp8klyUQ2HSWurPDorXjv7uDeAh3xz+XaPwWhQ uqZLV0ntOWXGfyJd5ZmKd7Wm5WUiwR4ClWjPAMYEKiMfFLxWQBbzx9z745GW 74wPwhHYr3LIH5QIHR+DDNbnDjLUcVbBdD4DoJiOJtLmfQntFpfRZvH5++TX D7wXjvQjP9FjK641EohPHgd5eboW5MxDB0eDYjBdZb1FXlvSEu3qMJjOazcT nzQjWxQ4YI2+OKK2tpTIUaUmapExQ4Gb27iO0D.4RZjfoUpk9SdT6aaTunnx rqraPCxDwshhRYVZCHNygmm2P7rFCQSVuOynH+KpEISshv0hJD2J2MdOqPXI X9tN2YiAlXBBYg0Ev3IvBaXjvp05jrn+VD2T+NY4hTYZdgnTjp3ppIpt6Xw0 7sIpkGmgZ2+07HQmC9nqqybVWHiyR0fn0H0h2McPoAqs40zXLuQJO+HCtDri skq3EZhaUhnQLE3Flkkztq50JvalmJ2vUBkzBVJtVoxM4ElnlFSjHkC53lxn hrjjVpx1ysGomXX4LR7AYr5FitZRkvqKy2sD3TyQwx0hRUaYJ95x1RZsenl9 YMCSaI+Tgq6ExZL8F8z8JZWQqcGw1YVs.8p9ByS6tlZFydh31CJ764rStICV UHzSjlLVVmVKtSqkLDq003oSqe1xZOHKtSqtaZwMwWT1lMhzJ+miPDOFSkHS 6xExfXc+GmgJy1VDsCVUH.0F8f6sRlVmg4s0qM6+h2HiiaGQaCBJ0gT1jWmz JhEPBAPCQ2uLhC4psyF5cyal5zojeqHdI.AXEXIWoJjqfJQk6mWe.ovNQW8m 8riP9ilNsKsbXtfSlUFpBrhmTUGqF3GMay7GI4wo1uBsBsZTJ2S6tbOKnwtg NLyQOmz5bNQAaT2.M44deh18AQsmjvt84w8DVtOCae1eZXEhsPie33etymzl m2HJK4qEGFAwKVKTnubpbVVXpE4E1+YJNKNgLlbxafsQE5SQ+DJE9mKKT2Nj hxP+K7OFagtMVKcA1Gd5S7Q+F5G0scWf9Sze.+iRb0sC7QEnsneAcGzxCSzx L8vXdnWC+FDp0iuanYyadd5VvttQeE5JGuqbzsb0yAlogxBez2idE56LSA1. LLlh9KHMHnXJw.LFLzfqz0AuLvm.ytFGtnHc6.8bSBYf9gWkQAzJQ+GJA8yf R.kAVsdT9Ht987bQuAcKLkv6R7z3yXTK7PeALGXC77QWalhPlFlAz.iwaUiA eLyTFXjCF6cvHcMijoMIeiESQ+tV6lgQHZILrmA2gvp.nDWOioQQaP+5t0K8 1Ghx1Z2Jh+y80I4QZ3+xXFu4vfwxAdwSw+E1ggBpzO7hb8ecYt04qFTQt5ta XJi4UE9PBZcQ117QI4DsWqu5hO7b627O2aP0aDYksOHGsqAp+qXNv7js37ug 4yrv1XVs+qMYFIS0kLaK1ODN55jL9YwJzmkqPDOULicWygjweaPM4Ey3ZedS KMs+4LqHqCNeYXyiM1wYKaczxCOV4gGo7fEsghFR.LUjdfCkNs3oO5gLcvAO D3DLY3wcHvAOYvYOGiN7d7mN73O.7DNYvwa.ngMc9xjWVvYHtNSmmyKprxCI In6KJ23EsJi7r52LjkJh6jlRtuBnjILrhMD7LgEzGTIKxzxOetQ5ajw4YvtH q1Bnmu4BIcwlOqumWcqGmlNvuc2j68oV0PeuOw5ded08+zpf19z7+GvVQlXJ -----------end_max5_patcher-----------
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.
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?
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.
"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)
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 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.
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.
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)
and the scrambled order symptom should be gone.
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)
----------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].
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…….
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 ;)
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.
----------begin_max5_patcher---------- 604.3ocyU98aSCCDG+4j+JN4m.oPkS5uV4sI3kJARHV0dggPtwWa8Tpcjs6u XZ72N1NIzzsNs0BH3g5z674695O9R7cwQjopsng.uE9BDEcWbTTvk2QTscDY IaadAyDBijqVtDkVRR0bVbqM3exBzf.iy0nw.Bowxj4HjALIeuYJ3ltDysh0 XwNPMCXPopX2OtQdib7LPsF0bsaRPX.TxlVf7Dvt.kfR5Vf6e6SlRFrKvY1D 3UsJovOgKA4LC9ZelLpURNx6.tRLFLaD17Eg0pzbT6kgMHe6FEnldqSe903b xrs0tKSGTy855vfrZw74nF4MTpPHwbmFBnpesS4pkBYAZCbMs1YIyIMgb92z NQTctjMnaGZBjMrm+Q2QT+CuA705EMSIsR1RLbPboVvJZJrfG741SuY.YecU qrMEl1jC87oA6NzVY0H9dHqoYcndu2GG6GR9MaV9332OFjJq+vDv0tPL.4Dw RWZfG8G5GS6GnRF8ToRu+ATQhabk9QP45ql7I2qBWsSZW74sv0oP1wYxKnWo aMU5cdTYzyPkGvfZ24pBktRGo95R+0PpW.+MIU5ISpdYWzlT8nc5eNjp6+2j 5xKnzIpxO39b06TZ7nTh9rsSoULh93topsrcWIVs.BI4I9cZXM83Xc3KFqMv 7IvZPMgOK+fK+BPv6+PV6t.Qm2rGqEHrGCbzXERlUnjshYzAwrPv4nrMv4BS 3Btfuidl+mTMcOS0TgJVYo6pYScJCBw0.daEtGjDLExJyvacDMtVzDe3bivz t9Kqq4Zkt5ze6ECHw95be7OA+N7DaC -----------end_max5_patcher-----------
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:
----------begin_max5_patcher---------- 389.3ocyTEsSCBCE8Y3qnoI9FtPYHa5a9cXLlBz45BzRZKSlKyucauEbaFSX SWL6k1bO2C8dtmdKaCCv4xNlFid.8DJHXaXP..4.B5iCv0zthJpFngEr2j4q vQ9TFVmAf0MJtvr.oYFzMUkZYMyrjKTRyRlZfcC0TXAe8EEqv3KZ5rIwQnYy cqjrL2VR7jXzy8ehr0TwLlMMLOeL9qTKjBil+NjfjX+ROLuDDjUj2lhOfpfV CTwOp3zpgLh1ZtvVAn4H6A800i5.2EF5Vh9atz3NAA5DD49KqSL8ZyIpjzxb p30wMDXzHKdb+.NtyvSRt17D6CFcirZyGiZJoD25cyG2TrOJwQ9syvZHWDqI 4.qAJNthK99eafdzgereoksphgln+sLZeeVxzFtfZ3RwAbldDmk7xRFjdnCK 4ZZdEC5y3e7d6TUC4DTS5+lZRNA0P9kpwewQaZVyT59iDDhcjdkT4ByhfPtv GBCCXEaMef+L.gprCyF6jbqxOO0kkhCc0YW3mjAvFlH -----------end_max5_patcher-----------
(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 :)
- This reply was modified 1 year by R∆B!D Raja.
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 :-)
----------begin_max5_patcher---------- 1383.3oc0as0aaaCE9YmeEDJnu4ZPRwKR6sfr8P.ZKBVG5vv5PfrDSLyjoDj nykVz8ae7hchycU6HZE+Pj8Qhxe76b32gmib99dihlVcknMB7Kf+FLZz22az HmIqgQK+7nn4YWkWl05trn7p4yEJczX+4zhqzN6+kncL3Hv+pptzbHuZQYAn QrnU.zyDf1r4BP8EfYhFwpgVJUBy0obiGuzXclNelTc1IMhbsGWbDZBbL.Gy sGPTn8Pb7DH3eVNH0h4RUoP6PHZowSqT5V42DNaXyXVZt4roVSvarXFc0B8p guxprvMspld96IQqcKUlYh6LGzHyJirm3G6sm8Oi2RF7yKlV6l9.cEPpjZy8 2feCKlKjWHZZAmV0.xJKAe7ne8Hf3ByMoEjoJ.16n4XqcfYfu74+vL7VclJW .tTpMzInsxv+VnW.pqJu9+9p5qpCZNq0dbeD38fiMVAexbA+t3TiIrwzQdH3 +1xmkoThxG02gfOsyCimPg3DXxX.iLI17BEabhbpyWRPgyKhec8hJwkl65Cb h0MhZgwkTWt3rUmziK800BOmDEcyb9wB24FJaLfBSrTThO1Gtg7zcYEzCYEN JHzxxX3shQHbGiPR6YFAN7YjzDmVHgyBAivRCBizV2HU5SAsBM3csm7gprhi Mqhjp+zngYkl1tnGJ1yRzdlrRBCYA1Gdxgdc+nWVLgAcZubhQzExeEYfGQnk weFFX4YxqJqZ7PzIvAsnzkX2kQn2BpL4FONqIa91sryGJgHI8bnDc3qDQiSt IAOgmFB4HJeWHG8QYg7v6tInsfoVFAQY8LUwF9QPHV7jDRJJAazovAIEOIYW DA8kpxEyeMHIHwE7f6aVJ8MPvSLdRRZJg6xvSBRvyNQ94XoYtOUbax9sfmh8 IZIw8LQw1ED0AmpEM5pE4y1PlBBmjRR4P9XPLK1yTj9kohieCrRacdIIH0cD SBBsnASeRJYZl5rNmUGC8oy64nEbX1VX8E1RLVFybbi3T4Ua+FevDeieP87F evjcg1ympzh1MijX9xRS7BN3dtqOr2XQPb98Wj0+QPgoegkUYENQlMWAZMxw nHyLunrw.Fre4GDMPhy6idF84nw+jLTxsMgl7ZtHC+PFJrcMyH+7thStnUa6 ue60J8rsesFh4JGC8RwR3sLVJY3u8Gu9bLLHa7ILUXnmIacOLnmjQj1mRk+v y1gUzsI3sEZfVJAwg86BLDMLO7hhYmOwrvZxbYgbxgGB3f8wuBkwSo1ldFmF OgQiYXZetBCwCWWoscJ62rObxOHa0OSuowoNAXNY4ddh621Ry+4ZKMbBmfPb lssznDRLhXeGmxRXwu5co9NQX0qJ0eyCyVqZeZJ8lV+aa63s6ip2h0XgeUY1 MU8u4j1ZE3xhoNULLy1Sx3.PZLb3IMksbkMlu7YDY9mjOMII.jDoi64z8s69 MJbueZKtog09cYt1pEM4qlzq1bK31IQgnUKUYZYkZsKJ8NWyLYQgPst1SgrM aZovAe3i5B6NbPc.OlcQAPgAOrN.Gqdan3G9vBO1tO7h3w1zugDdHrAFdRGV 3gNv3mgFbnCL7jDN7zkrE2Cz8IdtmxxSH+DP7zI+ENX3gPGVoKHcIcJIf3oK oSQgS+gjzE7DP9IsK9qvo+P6R7CMb7CsywOnADd3CK73DoFP3woOGF7zopKB Vz78RLsyyVv5R1KV317LqKpy1eT0gBOcQclEN+UmWrGH3.6h6BEN7fFVtqtD MiwCK3Dtnmz6jD3IxjRQAEOcouXaBZ7cQLqt19+d0xaoCHQyyN2+XBXiceTp 7ez0xxnFwExUWO2YIqIelTKx0KZ7cr7pDVzd1umer2+yS5vrQ -----------end_max5_patcher-----------
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.
----------begin_max5_patcher---------- 401.3ocuSEsaBCBE841uBBO2YfpUq6MydeYYt3KKKKXKahoBMTpqNi+6q.Em ZZl51zG.BGNv8bObuq88fSEUzBH3Vvy.Ou09ddFHMfWydO3BRURFovPCxoeH lNGFXORQqTF3Iie5AQ1pwq3pYOVAlfA8bbxIpjYL96uJoIJanFF0qCJ.DGGo WvwX8RHpCB7Ryk3kKX7LpxDTb2Fz2DbUA6SpALr9RaIKJUN1NTVpQY0p8FbH bmWfSVXdA3HIij4NIQjIjV4YjCZ6DVqKMoM995of+lUM5db0cBI0cfU5pU4T azgvfVFaclVryA8zdAXvvAFWsemnexMQmiY1uEyDcVloyBuLl4g0cgftviZT Ws5tn+yxNiFgYL9gMrlDUiuu8UHJkItZJ2GG36TMkVnXbhhI36RJbORyXooT 9toWJqfLMiZRRTqejmkdhNhdh1iyEWN3SPN3qmbPmfb9MeV1ZIRd9Rprn4IM Jotoatsdzz4Cq6FrawlsR5Rli+.CBQV2jop6vJk1p6p39Pecb13+EzLbvsH -----------end_max5_patcher-----------
Forums > MaxMSP