Saving and recalling 100 parameter values in Max
Hello everyone! I have built a fairly complex electronic instrument, and I would love for the user to be able to create and save their own presets. I’m dealing with a large number of parameter values — potentially as many as 50 or 100 different parameters, each with their own values.
Ideally, I would love the user to be able to select which parameters will even be affected by the preset (so that if they’re not “included” in the preset, then that preset wouldn’t change the parameter value at all). And it would also be great to be able to set individual ramp times for each parameter that *is* affected.
So, essentially I’m dealing with about 100 parameters, and for each, I need to be able to store whether it’s affected by the preset or not, and if it is, then I need to store its desired value and ramp time.
And of course, the dream is to allow these presets to be easily edit-able, copy-able, rename-able, etc...
I don’t want to limit the number of different presets you can create.
Has anyone dealt with something like this before? Would you recommend going the coll route, and just saving a giant list of values for each preset, or should I try out pattrstorage?
Thanks in advance 😁
Hi Ben
welcome in my modest but seems "shared" perplexity. I like much coll, so i must have a reflexion:
configuration or play parameters ? Can i group parameters, i.e. level-delay / eq / limiters etc.? Type of data : on/off, 0-127, float, symbol etc. ? Real need of particular ramps, or just a general smooth to groupped parameters ? Chronology: in a partial recall, the general state changes depending of where from you go. In my mind, playing in improvisation, a hierarchy appears: pertinent criter in 1 second, after 5 seconds, to never (too late ), etc.
For lists, zl nn, ( it was a limit of 256). For named parameters in a list, match nn nn. With multiple instances of a named coll, you can rename, delete etc. Clearly less sexy ui than pattrstorage and dict, and you need to make the visible patch.
MIDI, sound or image, every has nice objects with oher imperative needs. You can use a buffer to store notes, an image for an audio matrix, etc.
For me, 50-100 parameters are too much for my ten fingers, % my five neurons. But i need too to try 100 before to know the ten really usable first... Welcome !
hth
michel
Coll is my favorite for that since beginning.
100 params is no problem. more than 100 presets as well
And one can reach that many params in a complex patch.
Good strategy is to group params into lists,
and to have default values ready for reset to default etc.
Whatever You decide, coll vs pattr etc, the most difficult part
would be to disable a part of the whole thing from storing and recalling
into a preset.
I never did or would do that.
But if I had to, than a single item in the list for a group of params
could be a gate for recalling stored data in specific preset.
in my synths and sequencers i use coll.
it has at least two nice features, which are coming in one package:
- if you use one line per device, you can write the presets of many devices in one coll/file.
- if you use one line per device, this is also the perfect starting point how to easily have a copy&paste function in every device.
parameter parameter parameter parameter
/ / / /
[pak 0 0. hello 0.] ---> [coll] (save to disk)
/
[tosymbol]
/
[v foo] (copy and paste)
I would add the following :
if each of so many parameters needs beside it's value and maybe ramp time
also a switch to include it or not into a preset, that would mean a lot
of mousing arround.
Not including every single parameter into a preset
also means that recalling a preset leaves it in unknown state, because
depending on last preset in which a parameter was included for storage
it could be left at any value.
That is not acceptable in my opinion.
Although I dislike the idea for my needs, one would be better of
writing all in a text file, having fixed IDs for params.
Than one could just write something like :
OSC1 100 250 ( oscilator 1, value 100 Hz, 250 ms ramp time)
OSC2 88 400
and so on.
Even jit.cellblock with fixed headers for Parameter names
and few general functions, like to clear all, store, make new preset, copy or whatever would be thinkable.
If each preset was a file, there would be no limit on number of presets,
they would be scanned into umenu for exampe, or another cellblock.
Just few thoughts...
Have a look at one example of the software needing few parameters for storage.
It has 2 Amps, quite few effects, 2 live loopers, audio players,
5 pedals with 5 assignable destinations and range each ,
pedal with 12 buttons also assignable per preset,
and all is managed by a single coll, offering storage into named preset, and
saving into default (auto loaded) bank or any other bank.
Bank has a limit of 128 presets, but that is just because of midi compatibility.
Beside presets, ther is also stuff that is stored per Bank,
like output attenuators, Master Volume etc.
I use such system with less or more parameter demanding software
than the one on the screenshot.
But at the end it is not easy to make suggestions
without knowing exact structure and way that Instrument
You are making is going to be used.
Also, make sure you try [pattrstorage]. That might be of great interest over coll if you want to use the built-in enable on/off and interpolation features.
Would you recommend going the coll route, and just saving a giant list of values for each preset, or should I try out pattrstorage?
Try both options in focused example patches. You will learn both techniques and be able to see which solution best fits your needs.