Forums > MaxMSP

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

April 19, 2011 | 11:41 pm

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



bwu
April 20, 2011 | 12:04 am

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…


April 20, 2011 | 12:15 am

 
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
 


April 20, 2011 | 12:23 am

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.


April 20, 2011 | 12:27 am

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


April 20, 2011 | 12:35 am

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


April 20, 2011 | 12:55 am

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


April 20, 2011 | 10:04 am

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


April 20, 2011 | 12:38 pm

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


April 20, 2011 | 1:45 pm

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…


April 20, 2011 | 2:44 pm

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

April 20, 2011 | 3:22 pm

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?


April 20, 2011 | 7:31 pm

I have already asked that once a time

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


April 20, 2011 | 7:45 pm

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


April 21, 2011 | 12:59 am

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!



bwu
April 21, 2011 | 3:14 am

I gotta get live/max for live.


April 21, 2011 | 3:56 am

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

the next problem is already waiting for you.


April 21, 2011 | 1:39 pm

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


Viewing 18 posts - 1 through 18 (of 18 total)