[metro] to [sel] not working so well
So here is the starting function to a greater project. First an aside, should [uzi] work better than [metro] of 1? I am not into the grotesque nature of [uzi] any way.
About the patch: Think of it as 3 vertical groupings (left to right), the test/abstract, the actual function, and the stop control. The goal of the starting function is to produce integers with specific timing between each output, (I was using [metro] to give the delay but then it became more logical to base the delays off of actual feedback of the rest of the patch. Specifically off of a [line]’s output). I have made some cleaning edits and that seems to have improved the functionality of this but by no means is working correctly (as well as cleaning wasnt supposed to improve anything besides the removal of visual clutter).
The current problem that I see is metro is not remaining on. I see no reason why the initial bang should bang everything else. It seems like I should only be giving [counter] 1x bang and thus only step through one number and the stop [metro] function should not take place. Is select a horrific object that in principle is great but otherwise fails?
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 2728.3oc2bs0aiaiE94jeEB94TAd+x7xhzECVTfEYVzsnOr6TDHay3nN1RFR xIyzh9eeIorrjcjhnSnj0rnnChosoNmOdteNz+40WMad5WU4yB9Pv+M3pq9y qu5J6RlEtZ+quZ1lnutXcTt8iMKQ8b57ee1MkuUg5qE1kyCVmtHZ88YpbUwe OcWRgJ69e7169GUex3k1Om969CDZ0hOjlTjDsQYeqayhiVW8NI61DmrVUXen v8KtMpXwiwIqzOkEEkDMCiC4TAlgtI.BEg.NVxo5+lACA2Df.gffeqdOS2UT sofFzPd7eXoAHJDXV8ut9Zy+biiXx7cEEoIswojykeH.lgtoFVoj7eUlnZmJ Wp3aaUkayr4QIqlE7auAlYiJOOZk5Emvz13OzYdRh5lywLrgYIR6AGFEZNEE 8x4md70Ef71.itOYAm6IKRhr7GfdoNY6jYvhykYfRhULkHldLC6rYFtkK3.x ziYNaCHLXoXFCcoXlEoa1nRJdgAje4QUv7n73EAwKUQeHXWtlxCxUq0zdPTd PTP9ywZ9IHOMnP+YiS1tqHHV+FqeN5a410x0lXBznUvyOFUX9tl2W+.2FkY1 rhS9lOnV+03n4qUgeN4yIebct54GUYpfeJ3wnmTAQIAwOX9FIAJ86o+3pkls 4yVt+yyzefk5WjjV7i1WGVwSqiSTKLN4LLlrxRT1p4VGKGLB07fD3OedDXnf g4b8Aq0YAjZOkgH9X3rqK+CfVDeQB+4ePhEgPs6Qjwu..DR26oeh3ony3hVs NctNvnEQIKTqu++7we9SsATL+IdbDP0LjHLd7BIpKi.O8u9m2d2G+PPdQ51Y tn3f7Xvhx8lCap0bgiPDgdiLAgcoru6njdGA+i.d+7DhaJjSFuS0NPhrfRo7 6K1kk7ojtPBn7LQBP+AOW50GR3NJVLr1D6xHPTvb8tqxzd5WuqHNMQ6CV6Kd ipHK8u4jUAnvioPRogP.jPLVFfVmIR3k2RoNVFcpzlXbbCQ7nGDt1mJGI.Bg FDj7PN.Kn7Q1jYW3R5VUVTQZlN5tzLa3dV4F2.Ih+.ILhTZ7gTa7YJfOZ4lE qS0QyZhNddzhuDraaPzpn3D2fHjG0r35vz.kEmAywgDBAHQSDbJJ4aA5mnIS gzGLfkiVd7p+KQHAC3Bl1zMgLszyVEqyPJVmYVv7tAlsl58kTDYLhejADVUJ JDs9gjSjbMOZ4plLUCb0iFzgBZH.yzw6ZfRqiQl3xCnpMaK9VS64GkEI5bwX FGUiwHmvXtGwXs0u8O88PL0VWKSNFWTaeEp7hyWdkJq3FJksGA6DFYCQp7Gg hWVA0kwKMJ9Oml8E2rI5wTzfPbEhfM0y.QAHcfYb93AKcUfi6as.+drBGFy9 zJ6Vb72EkAutWNuIqyb7DKK1hZucGwlPe5dBWC.RsYT.EPMIeP7bRaucvoHc 0p0p1.h5jVcNHGP6A437g91nLMda5mnJwTK2lp6ufmiMdS8qHNjetrrPvBYL AwvluIVdLZs.RfeOFmAfZA2ITWJs6XaI9w8mcZ5g.uf5jiE.tTnUk2WD9Iqo ZH37kiObbO8LT2HN5lgl4wi4FR6HhLDJjLlI.QXHDwXDasQ5DHp12EoqSyJ2 u8gTJHl+Eoibvn6.arCMELzXL0XBg+p.5MdtaEZues6+C4wBmPwhPz9Q1vzM 7CMxoO+en2h+uaF.YumB12RvVgJrGKfBPVUZxl0OgQmDk288U9aBB4u5eS0A U1ZEKmHUBuCnZ2eD2Jx.8mUrFhP6qtccmi5.RvsY6hRoHLxlSLFJH3ZSYTYq VvbVy7l2QTauhH35nD08EYwqVoxtS+F+6hnrBM17qwKUo2+q29ysh7.+IS1T 4EVKRhPnorHY69Ug.pGiepgC.roRgHAGP++aOqmXTDc+mt6islrAyiMEjfMC B.UZPCZi1TzqEfK7HS3HT4wxNQohJcUHG1.ol.0MNJXwipEewzkhyraW.3vz qBjDGxPbl4uG0dUzoxkSCYCEi7YG2A0JWMEYvvIgxUmkvghO6QWkvjG3Uj1U VUD6euTBGJR7dpZUSw8oUoJaMYMpOGlLi+YSaI3xPt..PxumxSKysQRhd1yX 1qYWX+T1AYGTSf3oQDecUyrlyh2QvB16S2eyrXKApKdAy5FUz4KzJr.GlPgQ X1I0BYpNTq1PPBfsANPw.ANZAmJCPT3joQIcZ3w8aCEV.8XcPjvCWGJhTTaB hJm1g7eN3Ev6t2XXZHUH.P7HeywNmgoGykdT2pgfh4xlMwll9tvkenMiNXJw iNpfVIBBmV6nZZeCCZsfMXJviXx9f.IxCZI8VBg2ZPfCYoD5zjB1q0ruVyBR J8iSjW7bjyqJIpMtlaWu99e5teos1ByGl9Wv37CynFDwFQ7X2l4prVuyM7go oVTcrtU5I8VcDjCoH6pNjIy4gHOpEkdjC.AzVwwyUhg5HNhaD.SuhLj2FXU8 +9tED1ry6HCcNcXD7XzPDSHQPM1ICodEtNskMu+j16xGeat349b7MZTq2FUE eh3ku+KNWizRe0x+xGnd1u+5ywHSfqOGG7tl9.1T6NReavCpHcvJJyUY1TWl 82m4B8YVf4wkauIys8ese4jgXmtcxr2pEo4qNpObRgDZaMrjCwPa+33TD.YG LcF7..aX3i9hPBSqGZaur1uI.W1nYBQvOtSds9CqfUR7nAsauLp.4jz4CQKT ulFdiCX6tYg3S9USwRXl0O9TOOcW1hJ4kJa+A3CD0RUdQbhcdza7gLSUaPMk +X7xkpjlT8x3bSPB1Sv1UnNK5A0C8XCPdLIHXODjwevHQOleiSZ7n53.iLsn Ga5eMPwgjfLiDb+.DZz.Hacq6mf.iFAYqOQ+GYhQjf.tPPrQTl1IDZ7TxPtn jgFuSrSdTcPOrIF9.FQAHWHH6TLMVVEATmLKNhxzLrSBQ7Qjh3tPQ79B9XS7 xso5fj2GRFkvqqssvLg9TJwjdrN4NVYhe0KW+vGY15Tivujsd4DtQEPJpbHL IXLgZiz9vNzCLTU8MBjDR0QJCes0MkdYeIrzOGSlw0KM.PladjN0ydOPlvBT TFQPObgNkWPhmM0h3n2fDOQhBiJkDzBVZIQs5iog9niWZHvWtzICW3ixjYPw WGoH94Y3xz5f5heJO.xGoIeX8g.oM8hte4lS39A0wNj4htEFbdHMlhBYUSzF fEhDLooTCDtnk0G.jlf.Sr.VHNk1T+TzwlfoXRoCKHWhLWeJ8eg4X.73x5L1 oRbZrPCexMvdiDb7nH6T533Q8ThhniXFW1w7peJBJlX00neJ5TSgkdvI.vgA dfXlsYjDJfcuNhCqGHqF9mpWe.TtsSpoGBS7THfXg.LPG.LPBLWL+8nR8RCB 2vbvvvowx0iEWI.A41BuCXXlT1Rjumx85SUpI6n5YfxbE5.stDg0bVgnk2mr pkFLLp+ZmMdkZ3zXM7jZ3QQdnE9fbtVI5Tcqp0GBjFiFjHsXxFQTQCEnRgmi izpZ8Afu3tbbwG4FtzuIL33QPtTsB6ssZjHH6uTA8Gdh4mzgoUw7f7QDibih FwL0HNQQD3HRQtDBGa7DibqbmB7DSSaDqHr82Sqg6Hqr68Qa29jJKe+dZokY ah98xXnX2XeYbR4Ks63rL0SwUedw0lc6ut9+AFKLEqA -----------end_max5_patcher-----------
The logic of this patch is too convoluted for me to trace right now, but in general select works fine. Some general advice:
Although I’m a little unclear about the goals behind using metro or uzi in your patch, I would generally stick with metro until you know why you would want to use uzi (although a 1ms metro value is faster than practical.) Metro is not staying on because you hit it with a stop message from your "a feature to stop initial bangs" section. As an aside, you may want to learn the onebang object.
Your reliance on send and receive reduces reliability, because order of s/r are not well controlled. It also reduces readability for people unfamiliar with your patch. Send & receive also have a (very slight) performance penalty over using patch cords. Sending redundant messages (e.g. global_cancel_ZERO and global_cancel_BANG) strikes me as bad style. I would send one bang message, global_cancel, and turn it into whatever was needed at the receiving end.
ok. I will explore [onebang] more. I was starting to suspect the s/r were not organized too well. As is, I can have one patch open with the same s/r as another and cause problems.
I do very much enjoy giving primitive within the name or what should be passing through the s/r. Thus I dont connect and send something incorrectly. At any rate, at a human’s speed of analyzing s/r, they seem lovely. Shame they are actually bloody useless en masses. Is there a suggested max?
Lastly, if you follow the logic, the stop message should not hit the metro until the counter is at 5.
Thanks for your input.
If you use #0 as the prefix to any name, it will allocate a number unique to that patcher instance, for example #0_myName might resolve to 1234_myName.
Send & Receive are useful in their place, but you have to keep in mind that the order through them is not defined. In a large patch you have to be careful of this.
You’re correct that the counter is counting to 5 very quickly before it stops. I should have hung a print object on the output before I commented. Could you re-state what you think the problem is?
Thanks for the advice!
I found [gate] (basically like onebang) to reduce this and I was trying to basically selecting a float again (located else where in the patch). The problems have been resolved!
I think most of my logic is trying to force a greater continuum (with the assumption that [t b b] will really give enough time for the first bang to take effect before the 2nd bang goes off). I know it is risky but I try to test often to see that it is holding true. Mostly I am trying to keep track of my primitives in order because s/r do not care what is traveling through them (but I do!).
I will explore # in more depth. Thanks again for the direction!
Forums > MaxMSP