Paul

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

Basically I want random names for the buffer, info and groove objects each time the patch is loaded... 

Any solutions?? This has stumped me...  :(


random-valuesnames-for-poly-arguments-problem

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.

[buffer~ 6301_loop1] and [play~ 6301_loop1]

[buffer~ 6302_loop1] and [play~ 6302_loop1]

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.

[loadbang]
[t #0_] [t #1]
[sprintf %s%s]
[prepend set]
[buffer~] [play~]

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!

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. :-/

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.

[thispoly] and [random 10000] (which goes to the right inlet of the [sprintf])

[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! :-)

[loadbang]
to
[thispoly] and [random 10000] (which goes to the right inlet of the [sprintf])
to
[sprintf set %id_%1]
to
[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.

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

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.

The patch before works great in both Live and Max. Just been pushing it to the limit and no crashes or anything unusual....

I haven't been worried about voice numbers at all. That's what poly~ takes care of anyway..... isn't it?

https://cycling74.com/forums/buffers-name-conflicting-in-instatiations-of-same-device

I have already asked that once a time
https://cycling74.com/forums/buffers-name-conflicting-in-instatiations-of-same-device


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.

I have adopted your latest recommendation and will probably stick with that...

Since it's working, time to move on!!!.... :)

I have adopted your latest recommendation and will probably stick with that...
Since it's working, time to move on!!!.... :)

"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! :-)

Yep - the next problem is already upon me.... and there's ten more after that!  :-)


Random values/names for [poly~] arguments... problem!