attn c74 thispoly~ misbehaviour
if I send thispoly~ a bang it will report instance number. good.
but if I send a mute 0/1 message the instance is also reported. annoying– it shouldn’t do this
also if I make another instance of thispoly~ in the same abstraction (to be used in a poly~) then this other instance will report it’s instance number when the first instance is banged, even though it is not connected to anything
maybe this is a bug
Actually, I think that the report on mute is a good thing. It allow for further management of voices / polyphony.
chris, ok, fair enough– but to get around that I created another instance of thispoly~ and it would also output in parallel to the thispoly~ that was being queried, even though it wasn’t sent a message or bang directly.
edit: also this behaviour (outputs instance number when muted) is not documented– probably should be
What are you trying to accomplish? Perhaps you should post the patch that you are having trouble with.
well i needed to get the instance number independent of mute messages, so I wanted two thispoly~ objects (one for muting/unmuting & setting busy state, and the other for querying what a particular instance was doing at a particular point in time), but in the meantime i’ve devised a workaround– the problem, or inconsistency, is illustrated here:
edit: my first post is misleading– the dual [thispoly~] output only occurs with the (mute) message, not with the (bang)– I can kind of understand the logic, but it would also be more consistent if only the instance that is sent a message is able to respond…
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 564.3ocyVErbaBCD8L9qXGNa2AjASbuzo82nSmNBXisZAIFjH0tYR+1qzBTa mfcbI1I4hDZkztu2aWIw8S77SUaPsO7Q3qfm28S77HSNCdci87K4axJ3ZZY9 YpxRTZ7m1NmA2XH6Z9cHXVKzPE2jsdp8aTBMZD3ZfWupwsK3VUMHjZQt0LTo J116mBgDyTMRxYrNixlRgr.MTjC6LVUiZqq3FgR98ZLyzhdFK7CASgvnHWWP WC7sctR0X58UPmUQNgcU5OlE0ijaURijWhzLetVvKfunJx6mlXmPtZuPGE6h FiQw+labcyY6EamG0heSdLzhRm0GlLw0L8Ep5kMFDJQsluBAwcpehZvxypFi qCRUl0N81vkYndJjxkqriObcxhszhyTRaNvf4+aGylA17IkTERCJyw7OMXBK 9TIrmU5mebo+DpNiMmD7.JWGFSIgjfKqtawdJV6e9zi8T5kLJ5EF2wKhkcCV tG6ZCpYaE1tAegq9.7c4X+2aZvhQoAIIsRP3asDzcBa3ieACJMrAklvAJOXi q9nstewRWa6kdgImRatnBRZiwnj+G0DCPb1IX2hjcjiEz2dbx0kwGS0M9KKX dRl0com68o+7xp6CG4Ye5sjkD8iiN65dW2E8j+UUaRhF2kBwWUsgVC851i9s HBJN6GJXZUScVer5R4vN3jiZiPR+rxdqI4f0rVjmix8ebrTjWorHtCBGov9b QjSneVHs30ERryQkhdUwzUGR1AOL4uPOtuqr -----------end_max5_patcher-----------
As an easy workaround you can use the [grab] object. This will prevent the connected [thispoly~] from outputting the instance number.
Notice that any other dual [thispoly~] in the patch will still output!
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 531.3ocuVErbaBCD8L7UrCmodPBvD2aNW58dMSlLBPAqNfDCRz3jLoe6EIL0 wNlXvUwWjfUhUu2SucGd00wKUrkJ8fuC2ANNu553XBoC3r6cGuJx1rRhzrMO N8IQ5u776WRQ2pLgqaXbE7iet91gkdTvUbRE0r75FFobXEdaEiWRUlDh1Erl nx1v3EOzPyT8.JNbQfOfBi0SIH8HNXQ.b+97HZUCIJ3cmqj8h4bQ3ECgY4Ff zg8uszSG5MWW8fuM3sEIMdkFyvpD8XTr0Hcn0I8Z6QZDF2SzXKyZjEYsZCSV KJe9OV+xNwXziiL18UiRa7onM5jzNb.I8et54ZZ+I50cy442OA2aOwongjZ8 J+fU5oat4L1A7jsCwiJKZM4xDjLQUEUKpGoHRxuof1y.FB528LkCsRJPj.oo nU+UvihFfwkr7tvf1cMjmRFmlIZ4piY3gJKbqnLetx6tBLi2C0Kug34UscRa WzkTsUQkRRA8C5WUqhBAyzSgOmmJwXoh5K0RFkynIy4D73dpKxOk1pTB9r6f trmRA+qX4SKYPejHiyiTBuvpMK9B5jhFbyAVtUZRzrakZNSSA7Q+YkA253GJ YRQaS1PRGZeC6gdNUpXbhh0YK1uoC2yFVdNk+9x0JVdsnCa6vvH2eSERwS.Q KupHRewbVHgt5hD5LH5HX+kqR3InRwWUHMED8eoRcu7l6eQZSge6 -----------end_max5_patcher-----------
thanks mudang– my workaround was clumsy gating; using grab is more elegant.
still, this ‘inconsistent’ behavior should be documented
Personally I feel thispoly~ should NOT be outputting an instance number when sent mute messages.
Gating thispoly~’s output to remove rogue instance reports in response to a mute message indeed feels clumsy.
If one DID want instance reports after sending mutes, sending a ‘bang’ to thispoly~ after sending any mute message is trivial
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 754.3oc2Xt0aaBCEG+YxmBO+bVkswbauUsmpT2K6lzzTUDI3l3IvDEb1RWU2 m8gsgzjVH0gzQY8EhvWHmyuy47+X31QNvo4aXEPv6.eG33b6HGG8PpAbpt2A lEuYVZbgdYPA6W4S+AbrYJIaiTOrDf.SA35wEqyxWKSYR8lbqFkmnWa49eKI rdol0IuYIyXFPtPBGCfSiEyU+ptEbU0hWFKmsfKlOYEalzrdWOxYnw.LFo9g 5quI7Lz18bctPJhyzOd34q3wovclof+a8L5su034hZaGqF6tQiTWFeZLJMON w3UMAIbCPJnUHoeNVfkPMOpPzqDp32cpPHl7CDdnik4wRF.CP1iEuVwxgSTB hzTHfpqeBdlQBoCHYVdVFSoB7.l79K+xG9z2ZlHnGSD7VMlFbaJUqWPbUW8Q CfDAY974oLqi23nCpfdnPNEoixDcDmfputcKmrqjwJJhmydT.7HxlQcLalFZ bGcb0yDW8eQylao.e4J1RlHAjsVZePmP5FVph3Tcodv.V1StfWrLO8l+zLRH MfD5ScRBKKGvT5N4LurzoMEvO+wK95Eme4arWCL3.ZfXSsuK9+VMPuNqAhCi 1W8a3oAhc6VwN1KzzQ2enqA15aLzDMPc+XeXyw9h7uus2vT9qSMEh5XZhoBf 5Mz6IrpzuXG.IMzTn82tT0Pvlbk.yAHBGtXoz0Zq7ogFAGpOfqthHP2Fv084 1iqFrH9mrjIklR4e6jXobEeZYDsnxuqbbGnZlI0s+T+gP8DZj8LANt3Hjc76 3Atzvr5cLBd0izi+Xa3S8TaUxWXCi+mdpM8iDlxEO7SkoMK036Srh70qlU6N 0esKv8VVBqPxEwRdtX2E4s2hVvSRXhcqly3IKyKwRkQ.tpw32QYS3mxln8qM QskS39kSjAVryyFNg5WNEXiME1ubx2BaB2ulDwFL0ukcpOkzSaSj90lrIx41 qY3Xap5h5UJEM3xuUul1.yjro46CL6gPb6TjJKu4tQ+EpIhXAA -----------end_max5_patcher-----------
As with any behavior that has been in place for a long time, a change would mean that many old patches might break. Since this is not a bug, but just the way poly~ has always worked, I really doubt that it will change.
the fact that 2 or more instances of the same thispoly~ output in response to (mute) when sent to only one of the instances, while only the instance being banged responds to (bang) is inconsistent and appears unintended, and therefore possibly a (fairly benign) bug.
Fixing this behaviour would not necessarily break existing patches (they could be easily modified if the tiny percentage of patches do break), but would make patching less of a headache and less of a time-waster.
Consistency of behaviour is something that has been occasionally overlooked in the history of the development of max. leading to unfortunate legacies (such as gate)– I think it is better to fix inconsistencies at the expense of a few patches not working properly, than having idiosyncracies that are unexplained and waste enormous amounts of patch time ‘debugging’ and then trying to work around .
I guess I’m still not understanding the use case for this, but at any rate, thispoly~ is designed to reflect the state of specific instance of a poly~ patcher. If there are two thispoly~ in a patcher, and of them didn’t reflect the state I would find that somewhat inconsistent. It’s sort of like the ezadc and ezdac, which change to reflect the state of the MSP system.
Couldn’t you just put a change on the thispoly~ output?
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 492.3ocyV9saaCBEF+Z6mBDpWlVY7+RytaWsa1aPU0D1llvjAhLGuktp1m8Z N1tIsKIizEYka.4CXy22uyAvOEFPKLaDVJ4Kj6HAAOEFDfgbABFdNfp3aJq4 VbZzRiRIz.cV+XfXCfw+Zs0PfF4uj75wA0sJotV.3ax1FzzBiQiFhtlCkqj5 k+nQTB85I+1ahlQXIyccyicswrahH2O7JxJbgME+75jnwk7AiFzbk.G56skx JN4aMbckX2YXk+AmAq6q5h9bXnqYlmLPK9c2p9WHnbEWuTbBlOYHZeH3w0hd mSoyHToCx8cuY48Po3bDL4IttriRo3ESJkJZAvnOAbvNDNJ535QgvsnuShVf 1OZrcuPfQ+LY7VUgn4D7R7g7xPZ8eZo975fkxhNZdM4Rn5u1vqPWMEI7TVeN F6xyNFcxlT3.lkKqEmCF32FeVhG07r3OSMuRXs7smm8VhV0BBxUr85w3Syi9 Xv7TbG.ZS1hCXvzKgc.vJocso9wWNimS34w+w3kj8n5PaDX4mEHgeZZsT+w+ a.UmK96Im0z1TN5pwqgHaUXkvBRMGjc2UryjRd2jVIqpD5c+gAkrZsoiNChf b+dyi9poLOjjieSnj51z5glRmVMkdAxobeJmVLoZxuRb1+gl5d34vWgH+j6c -----------end_max5_patcher-----------
I just needed to keep track of the last voice used, so the poly~ sends out its instance number when it’s activated, so I thought the easiest way to do this was have a (mute 0) going to one instance of thispoly~, and (mute 1) going to a different one, so that the responses of thispoly~ to the (mute 0) and (mute 1) messages were split. In retrospect there are a number of (simple) solutions, using [grab], [gate], or in your example [change], but even though the workarounds to the thispoly~ behaviour are simple, it was annoying to me at the time, because I mistakenly assumed a certain behaviour, based on the principal of encapsulation, and therefore had a bit of trouble working out why my otherwise fabulous patch wasn’t working…
I don’t think the ezedac example necessarily applies here because it sets and gets system-wide global states, whereas thispoly~ is local to its enclosing poly~ instance; but I understand it is probably working according to a planned scheme/paradigm/protocol, and is therefore ‘not a bug’.
Thanks for your input btw, appreciated
Forums > MaxMSP