Random values/names for [poly~] arguments… problem!
I’ve had a look around the forum for some time now, and either I don’t understand solutions to this problem that seem to have been posted, or they’re just not working for me…
I have buffer, info and groove objects inside my poly~ all with the argument #1 on them. This way, when I add the argument "loop1" on to the poly~ in the main patch all the objects with #1 inside the poly are given that argument. Great, I get that….
But I can’t seem to find a way to have a randomly generated names for the poly~ argument that replace the "loop1" argument when the patch is loaded.
Basically I want random names for the buffer, info and groove objects each time the patch is loaded…
Any solutions?? This has stumped me… :(
I use #0 when I create b-patchers. When you create an instance of #0 it will automatically generate a random number for every instance (that will not be the same as every other instance). I think this might work for you, but I’m not sure…
if you want the poly voices to have different names, you need to do that inside.
and because you want to have a pair of buffer and play with the same random name,
you need to do the name generation from outside the buffer and play objects.
[t #0_] [t #1]
in the poly should give you a pair of
[buffer~ 6301_loop1] and [play~ 6301_loop1]
in the first voice and a pair of
[buffer~ 6302_loop1] and [play~ 6302_loop1]
in the second voice.
(of course you wont _see the names)
I always recommend sending a "bang" to [thispoly~] to report the instance number and then using [sprintf] to create a unique name so if you want you can access these buffers or objects from outside of your [poly~] patch intuitively.
Well, that works so far as it generate random number for the buffer, info and groove each time!
Great, but now I get the message "no buffer~". So it seems poly~ doesn’t like it. :-/
I was wondering if there is a way via [thispoly] or [thispatcher].
Thanks for the suggestion/help bwu, but no cigar!
Any other ideas????
The project is in Max for Live. The idea being that the same patch can be loaded into multiple midi tracks. Currently, because the buffer has a set name any sample loaded into it will appear in every instance of the patch….
Ok, I solved it – thanks both to Roman and Luke.
Inside poly~ I did the following:
[thispoly] and [random 10000] (which goes to the right inlet of the [sprintf])
[sprintf set %id_%1]
[buffer~] [info~] [groove~] and the right inlet of a [message box] going to the waveform object – triggered by a bang when a file is loaded.
Cheers guys… I get my head round these this eventually. Thanks for the help! :-)
i wish that inside poly you could do something like #N- to get the poly instance number rather that the thispoly sprintf stuff
@Rezo220: you don’t really need a random number, what you want is something unique, regardless of what it is. The danger with random is that identical values can occur in different voices. What Roman points out is the best solution, as far as I understand your problem. The #0 will be replaced by a unique numerical value. This value can be used to name the buffer and all references uniquely. In max for live the #0 is replaced by — (three hyphens). Indeed, as your instrument can be instantiated on different tracks, the poly instance number will not work. A buffer can not have an integer value for a name, so you should turn it into a symbol: —buf, —bike, —_ or the like.
That helped clarify things a little for me. Plus, last night was a long night. :-)
I have replaced my previous solution with the one you suggest.
----------begin_max5_patcher---------- 774.3ocyW1saaBCEG+5To9NXwTuKKxe.DX2sq1KvtqJph.lTOA1QXmsjUs9r O+APnoIMoIDZkp5w9Xiyw+3uOb7S2dyHu4h0ToG3af6AiF8j1yHqOimQMNF4 UlrNsHQZmnWpnrjxUdiqGTQWqrC7CJmVknnRPUBOSTB3Ik5N4hJv8yWkmSqd dV6SkK3Jy31m76Urjh1g3qJY7Bpx9ygZ7xxrSUL+WeE2cphUpl4B6t34Io1E mz3bYhJ8QFewCUzTkaKiifSfiAHr0PfXiAGLABl0cojr+ZWJT3Dn08+t8FiU aFe4X6mOxj.8eJAXg.v3RVFErQrRSskhhMOOaR6yTv3zTwJt8Aw8AJQGCk6g Z9FBool6+9HiwmbUfFm9GcT9Zlo.eA1KRoX+C.f1ImJJDUtMNbRTDlDPFqag Pjo3.SqvXHJNTShtDXehsZr4LDK1LBuCfMiVr1uKrTaVRcqjmGX1UAoOzOLk LXLEM8ELc5GDS0o4jIKnuFpRpB.mmni4BgX46lt38P2nsJ14KdIH8mBChM3C 21ZpeLD6HZDjDukKG3My9zsPnCqNTiHVSzmFgqbYESmtGXX8cx6j8GpCBGbg bXsdN9SV1gBQRlQG2KIHBBFNtFEz7M8wfP3EPU6t+JPVFOW7LvnYQ8CbIGJ8 azwqDh3NqaNjGb1jJWKVz04nEMLo0153TZbU91ltDKasT8BgIGp9S7aUzT2J MCht.gHia4jwbEP0hJg32z2OnH6qNcxY.Jbr6a4AVSf+EPJIaA2DusstB7p9 hM8hvBEdF7h.qyvYUV9Whxp8L39y04VQ6kP18Ji13xLvNHTpuFSZyx2j5GzI 1xnREimnXBdmYYNg0cVOxxxn7WbujRV1Rg9LPcj7VuYO4fyT35wCNSUAe.A2 oQtc2BetBN+OjfaW0Te8Z0O17QRjKQEJxusW+fzvSIpM2F.fF922mTvgOtX7 7JzamsTM6I9XWMLa6MfaVT3ftYwtK6RPa6MfaVaQlC4tstL9n31d8SFe+SN0 vkcHy3Pa9OPQWp6w -----------end_max5_patcher-----------
I had to put an argument for [info~] as it has to have one, but this get renamed with the message [set whateverthenewnameis] is sent.
I starting to understand this [sprinft] object and it’s functions now… but all that code is challenging. Another steep learning curve to overcome….
Thanks again guys…
Yes, however your patch will work properly in max but not live. Moreover you don’t need to know the poly voice number, and sprintf is a little ugly and preferably avoided. This might (I didn’t test extensively) in max and live.
----------begin_max5_patcher---------- 575.3ocyVFsjaBBEF9Z8ofw1KS1QvDCo2z2hdSmc1gnXV5nPpfoocmsO6EPh 0tqgUaSc2ISD4Hn+74+wCODFDsSbhJi.e.7YPPvCgAA1Pl.At9AQUjSYkDoc XQb52D69Rzh1KonmT1vJPo42437lJQipjprSJwEsPvUR1OnlXP3MwtvsiT88 CzVgDEsv8GbqaHGHpr6Y782USyTsiBEuReG.nUwllUo1N5y6lCK2pLsZWBSh 5IANox9jh9DsNmvI8DMieVyPSrGCCMGVLR1jIppnb0yfSCm80FJ3HoDv3fR1 Q5vbJ1OmNTSk5aOQwD7dfHAhLqc3JaSr6fOz0MCKAgNPdI1gdCwN8T96P2.9 GLtc06Z15EBvYABWH4ZesPbj9SvGGdsilX5kjsmSJMIXtyFQZlyxjtwGk1NY Hkb8fDiWHtHhvSDQEkBhxPnRlz11EXLm3GnvM2rdQm8ClX6cAhheMsc6ZJJn 0WMaWGd1Q368inDn0lkZsdoHedtMyBgpnRIYO8YHRRUf2CuaX.AmZYuwTtCZ Kzst8C33gYR5jYB554Zp0qKp9a0pqiqYr6C.t0hj0XelkjWyzIs8O23i.KWt bNLLHbuh7XnOtfdSvk2EOe4Qtx9Xuea4eqnu8NpKfve5FrspxD+OYkTzTmcd M3RiA+VW4Tohwsa9q2XL6rs2ftmkmS482PTEK+fPmM5z.31AewMVI8jG2vZZ 67KI3KHI77KIzKHoMypjFy6szYUQnQnnY1b+eVQ5NOF9KTxRVVB -----------end_max5_patcher-----------
The patch before works great in both Live and Max. Just been pushing it to the limit and no crashes or anything unusual….
Why is sprintf ugly?
I haven’t been worried about voice numbers at all. That’s what poly~ takes care of anyway….. isn’t it?
> Why is sprintf ugly?
It assigns memory for each symbol it creates, which is not being cleared until you quit max. In this case that would not be an issue of great importance. But when you start generating a lot of symbols (eg a timer) this can really cause problems.
Ok, well thanks for all the help jvkr.
I have adopted your latest recommendation and will probably stick with that…
Since it’s working, time to move on!!!…. :)
Lots to do remaining!
I gotta get live/max for live.
"Since it’s working, time to move on!!!…. :)"
the next problem is already waiting for you.
Yep – the next problem is already upon me…. and there’s ten more after that! :-)
Forums > MaxMSP