max 4.63 - [gate] - dynamically changing number of outlets

you could do it with scripting - but you might be better served with forward and receive.

What exactly do you want to do?

J.

thanx for listening to me, john.

i dynamically creating instances of a certain patch in a poly object. basically this poly object spits out certain displayed data, like panning and pitch.
now when i dynamically change the number of instances with the poly object i would like to dynamically change the number of outlets on a connected gate accordingly.

well, that's about the idea.

i guess that scripting would be a way to go.
nevertheless, if there'd be a way to go without i'd be happy to follow that first, as i didn't touch scripting at all yet and need to just have my patch ready for performance soon.

thanx again,

jrp
p.s. say hi to alex czinzel (from janek), if you meet her...

Sounds like you want to be able to send your values (panning and pitch, maybe others) to any of an undetermined number of places, and you don't want to "hardwire" those since you can change the number of poly~ on-the-fly. lots of ways to go about it, including many I'm sure I don't know about. Each method will have its pros and cons.

Instead of using a gate for your info, how about a coll? Use the poly~ index to write the info in the poly~ to a coll that's shared on the main patch level. Then when you want info from (say) #45, you ask the coll for it and then send it where you need. To ensure you wouldn't get "old" data from a past poly~, you'd want to figure out a good time to clear it (probably when you change the # of poly~, clear it before you write any new data), and/or put a maximum on the number box you use to access the coll data. If you ask for an index that's not there, you won't get anything, so no problem in that direction.

Depending on whether you want the data easily viewable, you could separate it into single units (panning, pitch, etc.) and use an itable or multislider (for each unit) on the main patch level to view it, instead of a coll which would have lists of data for each entry. Then you could also use the itable/multisliders to set the values in the polys~, with a bit more work... just watch out for recursion, use a "set" at some point in that loop.

--CJ

CJ, you boiled it down precisely.
As i am using a Wii remote to direct the whole patch i probably will not get in danger of loops. During performance there will probably be no computer monitor to look at, as the machine shall be somewhere hidden from the public and my own eye.

Nevertheless i am now looking into dynamically creating display elements for dynamically created instances of my main [poly~], just in case

The coll idea sounds like a way to try out to save certain data inside the [poly~] instances. Now it seems, that to displaying this data outside the [poly~] i will have to look into scripting. As i am a complete newbie (besides the usual web programming experience) in this it will probably need some days to get there.
If you have any suggestions in that direction i'd be most thankful to hear them.

Thanx very much for looking into this.

jrp

I don't think you need scripting - I have made you a patch showing three ways to get random data out of poly. I still don't quite understand what you are trying to do but maybe you'll post a patch if you get really stuck!

The patch is made in max 4.6.3 but should work in 5 if you are on that. It might look a bit of a mess in 5.

The poly~ puts out random numbers and letters

if you are interested in dynamically creating display elements you might like the forward / receive method illustrated

all the best and I'll say hello to Alex next time I see her,

J.

--> The coll idea sounds like a way to try out to save certain data inside the [poly~] instances. Now it seems, that to displaying this data outside the [poly~] i will have to look into scripting.

As I understand it, wherever you use a coll with a certain name, it's the same coll. So if you use a coll inside the poly~, plus have one outside with the same name, you can access it from outside, and write data to each entry from each poly~.

Instead, though, I'd go with a multislider for each piece of info rather than a coll. Below is a sample patch with a part to go in the poly~ and another to go outside. There's no actual poly~ file in the example, so you'd need to patch together the relevant bits into your poly and main patch, but it should be straightforward.

It shows how to gather/send each piece of data (like panning, pitch, etc.) to and from each poly~ to one central object (a multislider for each data piece, with # of sliders = # of poly~s). This way you can monitor and/or set each value list from a central location no matter how many poly~s you have. In this case, changing the value from within the poly~ only *sets* the relevant slider, not causing output and recursion; but change the multislider and the values are sent to the poly~ normally. You could do it either way and avoid the loop as long as one of them uses the "set" message.

Note that presets or pattrs on the multislider will "work", but they remember how many items are in the list when you store them. So if you recall one and your total poly~ number has changed, which sounds likely, you'll get funky results. I'd avoid using them in a dynamic case like this, though they are great in other situations for lists that you want to manipulate and mangle :)

--CJ

oops, forgot you're not on 5. I attached a screen shot too.

LJ!
Thank you very much for the effort!
I looked at your patch, which is lovely and currently teaching me loads about max, as a soft of newbie.

Now i have one question:

Could the number of display elements in the pink display dynamically be changed according to the number of voices/instances of your [poly~]?
i would like to display data for all instances at once (max 20). When the number of instances/voices changes, data displays should appear or disappear accordingly.

I know it's a tough one. Thank you very much again for looking into this!

jrp

CJ, i am still looking into this, it seems that your solution would work with the graphical display (e.g. sliders etc.) of data very well.

Your solution is nice for the graphical display of multiple instance's signal panning for instance (right what i needed, apart from dynamic styling/GUI issues), thank you very much!

Now I had asked Leafcutter John in my message before, if he could think of a way to dynamically adapt the number of non-graphical (e.g. number displays) on screen to the current number of voices/instances used in the [poly~].

This is because in my main patch i want to display the length, momentary pitch, panning and signal level of a groove object within the poly instances at once. Some of those displays make more sense to work with in a live situation, when they display numbers instead of a slider per instance.

Very thankful for any suggestion and the time you take for this!

jrp

CJ & LJ: i am looking into scripting now. it seems that for the task it might be the ideal tool, and i could reactivate some coding skills i haven't used in a while.

i'll will certainly post results here!

jrp