Forums > MaxMSP

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


jayrope
Nov 16 2008 | 2:33 pm

hello again,

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.

any help very much appreciated!

jrp


Leafcutter John
Nov 16 2008 | 2:58 pm

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

What exactly do you want to do?

J.


jayrope
Nov 16 2008 | 4:08 pm

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…


seejayjames
Nov 16 2008 | 7:37 pm

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


jayrope
Nov 16 2008 | 11:22 pm

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


Leafcutter John
Nov 16 2008 | 11:55 pm

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.


seejayjames
Nov 17 2008 | 1:03 am

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

— Pasted Max Patch, click to expand. —

jayrope
Nov 17 2008 | 3:06 pm

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


jayrope
Nov 17 2008 | 3:17 pm

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


jayrope
Nov 17 2008 | 3:29 pm

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


Luke Hall
Nov 17 2008 | 3:34 pm

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.

lh


Wetterberg
Nov 17 2008 | 3:35 pm

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

Andreas.

jayrope skrev:


jayrope
Nov 17 2008 | 3:39 pm

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.

jrp


jayrope
Nov 17 2008 | 3:56 pm

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

jrp


seejayjames
Nov 17 2008 | 8:45 pm

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:

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

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

Hope that helps,

CJ


jayrope
Nov 17 2008 | 9:36 pm

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.

jrp


jayrope
Nov 18 2008 | 9:56 pm

Just reporting:

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:

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

Thank you much!

jrp

Viewing 17 posts - 1 through 17 (of 17 total)
Forums > MaxMSP