jack3l

I might be asking a crazy question but I thought I would ask the Max guru's on here to confirm or deny my idea.

Im using 16 dials as a sequencer, the sequencer is currently linked only to one parameter in my external synth (filter cutoff) and as the sequencer plays out it changes the value of the filter cutoff in my hardware per step.

My hardware has 500 or so such parameters that could be interesting to sequence - it would be a bit crazy for me to want to sequence every parameter but if I did try then it poses an interesting problem in Max that I am interested in solving.

The problem is "is it possible to use one set of UI dials to sequence multiple parameters on my synth".

My idea was that I could use a preset object - and each time I would click on a preset it would load different values into the dials and would connect to a different parameter on my external synth...the only problem would be how to keep sequenced values previously assigned to a different parameter on my external synth, since clicking a different preset would essentially disconnect the last parameter from the sequencer.

I know this must be possible - and somehow I have to find a way to store previous sequencer values and keep sending them to their assigned parameter.

re-use-of-ui-objects-to-control-multiple-different-values

It would need some work, but it is doable. My thoughts would go to JavaScript.

- Have a umenu/tab or something like that control where the dials are "connected" (instead of the preset you propose).

- Use a "two-dimensions" array to store the dial values. The array would have one dimension to be 16.

- The sequencer would trigger the values directly from the JS, "freeing" the actual dials from the control.

Just initialize the values of the array to not have null values.

I'm not sure I make much sense (in my head its clearer), I hope I do! I not, let me know to explain it better.

It would need some work, but it is doable. My thoughts would go to JavaScript.
This is what I would try:
- Have a umenu/tab or something like that control where the dials are "connected" (instead of the preset you propose).
- Use a "two-dimensions" array to store the dial values. The array would have one dimension to be 16.
- The sequencer would trigger the values directly from the JS, "freeing" the actual dials from the control.

Just initialize the values of the array to not have null values. 

it is indeed almost only difficult to reuse gui objects for other parameters because one want them to always show the right vaues.

the general strategy to find a good system is in my opinion to start this from stratch and not in conjunction with your already existing synthesizer.

in one of my projects i started like this:

all gui objects as well as all "real" parameters are always in the range of 0.-1., scaling happens elsewhere.

if i have (for example) 16 sliders for 64 parameters, i will [pak] them into a list (and upakc them later again) before they are sent to parameters 1-16.

if i now want to map the sliders to parameter 17-32, i only need to [gate 4] this one list and we re done.

since we are talking about mouse input, which is a single client task, such extra processes are absolutely no problem. (everything else like midi input, host automation or opening "presets" will be independet from the slider mapping, isnt it?)

part 4 of the problem is now only to fetch the current values of parameters 17-32 and "set" the GUI accordingly.

in my case, this was the first time ever where i used the often forgotten [grab] object - but there are many other options.

in some other of my software i am building things like that around the pluggo pp family of objects. it is kind of unrelated to your qustion but maybe you can make some use of 110.ppcontrol.help, it goes in a similar direction.

1.
all gui objects as well as all "real" parameters are always in the range of 0.-1., scaling happens elsewhere.

2.
 if i have (for example) 16 sliders for 64 parameters, i will [pak] them into a list (and upakc them later again) before they are sent to parameters 1-16.

3.
if i now want to map the sliders to parameter 17-32, i only need to [gate 4] this one list and we re done.

since we are talking about mouse input, which is a single client task,  such extra processes are absolutely no problem. (everything else like midi input, host automation or opening "presets" will be independet from the slider mapping, isnt it?)

4.
part 4 of the problem is now only to fetch the current values of parameters 17-32 and "set" the GUI accordingly.
in my case, this was the first time ever where i used the often forgotten [grab] object - but there are many other options.

Think of the usuall DAW automation of CC values, following the last programmed value at whatever point of the timeline.

So if You scroll to whatever position in the Song, last programmed automation value will be resent, to guarantee

that parameters reflect the last set value.

Now how to implement that in Your concept.

In fact the dials, visible in Your GUI can not reflect all the values being "current".

So the question is, for what do You want to use visible dials ?

Just to notify when at some point x Parameter with x Value got sent out ?

Or to lock them into step sequencer pattern in some point in the timeline to

You have to present the whole concept, otherwise it will just remain a theory,

which could be materialised in this or another way.

Think of the usuall DAW automation of CC values, following the last programmed value at whatever point of the timeline.
So if You scroll to whatever position in the Song, last programmed automation value will be resent, to guarantee
that parameters reflect the last set value.
Now how to implement that in Your concept.
In fact the dials, visible in Your GUI can not reflect all the values being "current".
So the question is, for what do You want to use visible dials ?
Just to notify when at some point x Parameter with x Value got sent out ?
Or to lock them into step sequencer pattern in some point in the timeline to
play with certain parameters ?
You have to present the whole concept, otherwise it will just remain a theory,
which could be materialised in this or another way.


Thanks so much for your posts it gave me some ideas and starting points and today I had some time to sit down and work on a test to see what I could come up with.

Its just a draft idea - nowhere near finished but I wanted to see what you all thought

***Before using the pasted patch you will have to double click on both table objects and modify the data chart that opens so that the dials will have values other than 0...sorry I thought these values would get saved into the patch

Here is just a bit optimised recall of table values.

I don't know the whole concept of storage and automation,

so I would rather make no suggestions about that.

And You can set @embed 1 argument to save table contents with patcher.

It does not harm to read help files of objects You are using, and reference too.

Here is just a bit optimised recall of table values.
I don't know the whole concept of storage and automation,
so I would rather make no suggestions about that.
And You can set @embed 1 argument to save table contents with patcher.
It does not harm to read help files of objects You are using, and reference too.


Still learning my way through the different objects and knew it must be possible to do better than my example.

Thanks for the quick reply also Source Audio, when I get time I will merge in the other parts I have built and paste into here so that you can see what I was aiming to achieve.

Thanks Source! I eventually hope to make such beautiful solutions soon myself once I know each object deeper

Oh wow!
Thats way more optimised! Impressive!

Thanks Source! I eventually  hope to make such beautiful solutions soon myself once I know each object deeper


It is really important to know about the objects, because that helps

Like cooking, if you know what is in the fridge...

You are welcome.
It is really important to know about the objects, because that helps
to get this ideas how to form something.
Like cooking, if you know what is in the fridge...


Yeah at least for now this is my disadvantage until I have more experience in Max.

There are some parallels to coding but the difference is you can't open a Max object and see how exactly it works...you are dependant on the docs and whilst the docs are pretty good some could be elaborated, have more examples, or have more in depth explanation.

I will get there though - I am really enjoying Max

Re-use of UI objects to control multiple different values