max 4.63 – [gate] – dynamically changing number of outlets
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!
you could do it with scripting – but you might be better served with forward and receive.
What exactly do you want to do?
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.
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, 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.
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,
–> 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.
----------begin_max5_patcher---------- 2238.3oc0b01biZCD9yoyz+Cp95G5M0mK5cQ+V+czoyMDPIgdXjG.2KW6z9a uRZAGbhsgbfL4xL2QLFKu7nUO6ytqH+y2+c2r5Vyi55UneE86nat4erm4F+4 bm4ltSbypsIOlVjT6uvUolsa0kMqV29lM5Ga7uQsViRJJP6LEe4+P+URwdcM JoAYJS0qOb4k62lWVna7CFt6r2YJaJS1p8CzuUkmTz+CX12z8Ih5Ncdl+ZM2 9me.GiOb06pz0VqKoI2T9wJcZCbyQYxMQqQTBycHp8+P+Q+u+57+1+8icWS2 vkzj9Pd488GJIq2PQh3aDw1ej1em5FR+m7e+9uyczdX8zA1zjRT5CIk2qQOn qznsIk6s.8WPMFygqtHuTmZ1W5+Hjfh1QCg1BkCZvLxH.a7FdLGqjW.wEw9g i5AbbD1C+SCq2tunIutHOSWMfm4w.xAfsV2z7kc5i.o5cIoVK+nOdp8dMKoI 4nS1GMUxU8FSqEXsS311CbXhrOzcF.mv8t2w7SC3vMPm896nUqVa+WuQ8kX9 QiHQ3+eBo+fZs15luT.yhyuSeRYFx9U3YTZ4R9bdyCV1DMp9yFyteHnTJJ9f TJTvQjGOcJEXLnbpGmY7MzH6OzvQo7tNVZSdpik1A1VaEYtC8S5jzGdOf4nS sN45wznXCMIHiU.YLcDSBjKNIDGA95JIPdoNLI3HdBwjfowRm24b6H42WamA 7mDlcxK+EKDUGVGc5vwNAuSoXFbz8gDjX.ooaTVDFqBmedh0AOCYMf8U016p fhjR0PHINRAZFlt2JNRBbEjtfhDm2J2M5gAJuqxrEkZpr2Z6LkYVyYgYGjxg vaBF.mn4QGB1u.PBpQruP3Pbwj0hbVDW+Xx1cE1vcVyvd.Xj+ocIkk1SrFsK 2ZgqQ5lzMuOrN1CFKjQ.40znoSQv7zvLPjMH1KTrCNxUqyKv1FVHbvHYLFD7 eDpIbqvujbYvOES6oZ1MrS.AK0e1da7R.LuDgmKb6jpikOEc5khXmvJYHFOb vpiK1sRlzwcdPgaxeoy9n0NretOlzzTke69FHc4adBotYk6s9XmSlyzWAuSK ROu9r4kWKWVxfgy7tVBwj8XgbMfE9yiC6Vcccx85WBe1qB8imwmkLS9rCVMh XdDnZMZr4q806pGCN4BOQpMAiNWcrZR.7dq249C2m4M5sskQBaSsbsM+RR6Q V6QU6Qrn8WncWgf8zc2ocjSppLe9tp1YjniN8Qm4BSbNzr0DO5qq2rI8jylQ mmAJ2s.8EYS6Lh6RR0uXs3goM0EWMn3vBAHDHGVNHCVDv1bMfaNTi4MkFOwf Zp4r1jIhmtlZPRcLHolI8Rpwjvk.3K.6tz9rXRP41Exgki.DF.uwjfUIFX6f zHsgz8Y84qtQfRUoIo5dcyZPwbXARwHkFyHQSGHYPcUghxoXajANkuZ6p7xL z6P40GbMyzO9qH+h+ZjOkPKgeQ9mNpTQnLit9zrEzfNaLXhJbAnJdT0KZDQW kvLhrkwFRcQDFoKtpg9ij.qdoGg6bpBgFCUq.TL9DCvDUgXuetcvJ3OZ7fbJ 7PNX3+aSb07ep4h.ExADFNw0ymKaMWvdbHoC6wF9U5f.s5w9BwatLxNGptKI 8SnHTTPWUxBYZvJ5FaPDd7F1Qf9riTEljL+hk.Vw.wEJXvTWnBs0LN5YbXAB sZdHudVyx+Tza7go2bGlBn0VtTf4m.ZVvSF0NaTRyNcIhEzD7EC1xDNU.Rdw gOA+1zEUcwODySB9mUTXgw7I215HurtIoLUidWXUXOXYn3sUSAZE3jJ9rDx1 lCEPEZVUnJ9rSNmumq2kWUa+UCpz3xB+Cl69vsV4xY0HcUkopFYRS2WAc+dg yFevJaI.GelbL5qubQAUPd3DH+ILWNCkE7B8C+DcBegA6nUeMcwtsr+O0WvY pK1WlvMvkTkGOHIPr2+feEKoJNxGZiC0IxES6Me1LX9v0SCnQYiduDc9rfdQ QPs2O4a2u87EFU7jusEY5tVJ4hSFd6UAkqB1BG79FrESp062Mssoz4DoUuSq yJx25ZxbXWAHWEFwCs6hQOcgR7rNgM+hZQ4n7v5gKBrh1NHqsk27MRd3Ty5C EEZx0AqZl.TuywwWA4rJnDHPg533CIL7M.4Ja3lU.xihYuYHWErg80wfbtfw tdV2+VQYgdAvv4yAU185r.fBJcUdWEAat5X64ojKPEgccAY0X2Ixu55uC8VB GSuBjwg1MDObujhfdIIBuanj0Vx99HafbA+YTfQ1A5g+TPIXGcJXWC+ORPQI 1f4FPgvALHW7.6+AqrIvlYKr9e0nFiqTqAsPVrAaULExgkIjyTyIgDTov1fs 0SMP9lPK2CbjZRX1MfcKhUc6TJQXi3VjW2b29xRcQH6DBAedvxYAyPTWYzy. ro5c8V4oxRF+Zdnr9Zd7pfsqDTjEJ33comupCmrcVhR91jDLZ0DIyZetGBKY lujlgURBNLLY.HA8BBx0bhbXWFinAEiHgojWQ7qJFEVQaAJhHnvaFwncICGt 616SMElpNhVFkShYNMPBLWnDteiqhnwtHy8YJGyS4VOssmXym.rv8dfpnQmp QSvWouGPO+gl2Opt23YfPsYeUZ2LR2FrB0y3yz0M4kdof8uJwwW0C4YY5xmU umrcFa1KG1TymetYzFm+oQdXqyEdbIrNd7XrNWPlEw5Dix5bUaZwLO7vlGeg LO43PukYggbTddNI2uNiiDqb68JJv2J.B2ieElOPOueEXLOLqtIs+IwfgmKK URGEKobg7UYixWU9pcGhgzBvvVen8UvtQIlH76ROwrAw3wsfSsLXr64tYLzU rEw7DixCPrLXmXTTohkA43i23vWejaTzN7Eh1YbV2hI+QMN9jkR633.Ol3Mc Hkkx0y0BuwfdpEz7FQvB7hXdjQFokrPf2HMukhWIZTRuWnrpXp2xzJj21jdj vDOSgYNox3HF7GaH0gWMOlcfBCKEhfZ13qj5A2IrG9ef3CLVp -----------end_max5_patcher-----------
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!
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.
i’ll will certainly post results here!
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
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. Then you alt-drag or option-drag to make the next, and it’s already named number (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,
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:
Thank you much!