jayrope

is there any way to dynamically change the number of outlets of a gate during a patch running?

went thru helpfiles and tuts, checking [route] and switches, too. couldn' find a way to do this.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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,

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

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

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

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

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

I looked at your patch, which is lovely and currently teaching me loads about max, as a soft of newbie.

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!

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.

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.

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!

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.

It is possible to script the neccesary [route], [unpack], [number] and [message] boxes but its quite a bit of effort. Why exaclty do you want them all separately? Personally I would go with a [coll] and [jit.cellblock] method. If your maximum number of voices is 20 you can resize the [jit.cellblock] to the number of rows you need quite easily and all the data will be in one place for you to read from.

Hi, please don't rename the thread, as it messes up reading the mailing 

Hi, please don't rename the thread, as it messes up reading the mailing 
list a fair deal.

Hello CJ, i want them separately just for reasons of easy use during a live performance (not to be distracted by elements without data). I actually just found a solution, as dumb as it is, among the tutorials for max 4.63. Tutorial 49 shows exactly what i was dreaming of.

I'll get in there nw and send results for sure.

oops pardon, actually i was misusing this for private messaging, yes. sorry about that, andreas.

Sounds like you got into the scripting elements, that's good. Some commands are very straightforward like show and hide, others are a little bit more work (like creating and connecting objects). Show/hide I've found to be very handy for some things like this, if you can manage the placement and size concerns. As was said, a cellblock might be better in this case because you can constrain the size and let the scrollbars manage the space issues, plus each poly~ would be in one row/column.

For creating/show/hide a series of number boxes, or any other objects, I create the first one (say a number box) and name it number[1]. Then you alt-drag or option-drag to make the next, and it's already named number[2] (array notation). So say you've now got 10 of them, use sprintf to access them all at once:

the inlet is for the integer index number... send it the # output of uzi 10 1, and they'll all hide sequentially (though superfast).

Think of uzi as a "for loop" when you utilize the index # output instead of the bang output, which is much faster than [counter]. You can then do nested for loops whereby each index goes into the second inlet of a pack, then bangs the next uzi to fill the first inlet with all 10 or however many. Then the second # fires from the first uzi, again going into the pack and triggering the second uzi to fire all its numbers, etc....

sprintf script hide number[%ld]
the inlet is for the integer index number... send it the # output of uzi 10 1, and they'll all hide sequentially (though superfast). 

Hey CJ, i'm doing it in JS, and i am almost done. It's amazingly versatile. I can adapt the whole GUI dynamically to the number of looper instances used.

Will post something useful soon! Thank you very much for the new hints, will look at them tonite.

I got a whole big step further to my idea of a dynamically adapting GUI, now using JS extensively.

If you're interested in the problems as well as further results, please refer to this thread now:

https://cycling74.com/forums/index.php?t=msg&goto=158198&rid=8015

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