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

Apr 19, 2011 at 11:41pm

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

Hi all…

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… :(

#56427
Apr 20, 2011 at 12:04am

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…

#202352
Apr 20, 2011 at 12:15am

 
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.

something like

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

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) 
 
-110
 

#202353
Apr 20, 2011 at 12:23am

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.

#202354
Apr 20, 2011 at 12:27am

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

#202355
Apr 20, 2011 at 12:35am

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

#202356
Apr 20, 2011 at 12:55am

Ok, I solved it – thanks both to Roman and Luke.

Inside poly~ I did the following:

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

#202357
Apr 20, 2011 at 10:04am

i wish that inside poly you could do something like #N- to get the poly instance number rather that the thispoly sprintf stuff

#202358
Apr 20, 2011 at 12:38pm

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

#202359
Apr 20, 2011 at 1:45pm

Thanks jvkr…

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.

– Pasted Max Patch, click to expand. –

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…

#202360
Apr 20, 2011 at 2:44pm

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.

– Pasted Max Patch, click to expand. –
#202361
Apr 20, 2011 at 3:22pm

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?

#202362
Apr 20, 2011 at 7:31pm

I have already asked that once a time

http://cycling74.com/forums/topic.php?id=28527

#202363
Apr 20, 2011 at 7:45pm

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

#202364
Apr 21, 2011 at 12:59am

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!

#202365
Apr 21, 2011 at 3:14am

I gotta get live/max for live.

#202366
Apr 21, 2011 at 3:56am

“Since it’s working, time to move on!!!…. :)”

the next problem is already waiting for you.

#202367
Apr 21, 2011 at 1:39pm

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

#202368

You must be logged in to reply to this topic.