Handling lot of parameters (presetting, recall, control, dynamic changing exports)?

Beginners
1

Hello,

I’m almost ok with my first network.
Almost, meaning I accept it won’t be finished ever ( :sweat_smile: ), as usual. But it works.

I got a bunch of parameters. I chose the most significant (about 20)
I have a couple of questions for working easily with them

Some will be controlled by audio/midi flows, some will be just statically assigned but I’d like to store/recall this values depending on my song.
It means I have, somewhere in the network, a BUNCH of nodes parsing midi, selecting channels etc.

First question here: maybe, scripting this somewhere (I mean having my parsing which means acquiring data, selecting, scaling) could be better than having my MIDI In + bunch of select and “explicit & visible” wires. I just mean, that could be more convenient to have a “script” somewhere where I can copy paste things and do my scaling, assignation etc. How would I do that ?

And it could maybe also help to answer my second question: which is:
I often use a dynamic routing for my parameters.
I mean: for the song 1, THIS sound features controls THAT parameter on that way (scaling) but for the song 2, THIS same sound features controls THAT OTHER parameter.

Using scripting, I could dynamically switch from an assignation to another one.
But if I don’t use scripting, how would you do that ?
Actually, it adresses the idea of exporting/controlling a parameter using a channel and dynamically make a parameter controlled by THIS channel, then by THAT channel…
I guess we can do that dynamically using scripting.
In Max, this part is often hard as we have to deal with race conditions and we have to stop flows to go there or there. Here I feel it like more constrained by design which is, for me, and here: BETTER.

And last questions on the topic is about getting all parameters in one place where I could also store static values and recall them.

The idea of visually having all my parameters chosen in one place is very important for me as it would save time while setting up my context for each song.

I know the node Parameter, but it is “only” for UI purpose.
I mean, I can’t use it for store/recall control, changing the parameters export etc.

I’m sure a lot of you already have their framework for this, their ways and visions.
I’m VERY interested by this.

2

Try my TauCeti preset engine:

It helps with storing, setting and interpolating with parameters. It also stores expressions so you can also fade between different selections (as long as you use python-syripts, no suport for binding/exports)

For mapping you can also take a look at galileo-mappers, but I have not implemented a nice way of switching between mappings, so there is that.
Also, it seems the experimental has problems with TauCeti, so no guarantie for this atm (no time to upgrade) but should all work in 25380!

1 Like
3

Hello,
Personnaly, I use table DAT for all my settings, different parmetters in different rows, different settings in columns.
If you edit it with excel (but any spreadsheet can works), you can record it as text (.text) and then link the table DAT to the file.
You check “Load On Start” and “Write on Toe Save” to have a sync between the table and your external file. Use select DAT to choose any colomn and ink it to the parameter you need it.
You can even have different external .txt for different events.
You change your different settings using a Select DAT.

settings
settings897×530 27.7 KB

settings.zip (7.7 KB)

1 Like
4

thanks a lot @alphamoonbase & @jacqueshoepffner

Ok for the Tau Ceti project it seems huge.
I’ll probably go more to the Jacques’ way because I’m still more confident with explicit ways.

Storing all parameters like this could be hard (I mean, there is no automatism with that, which brings more explicit stuff… of course).

I’m thinking about a DAT storing node name + parameter I want to keep, and that could at some point snapshot and store the whole thing somewhere.
That one would be a column, in the example you mention.

and I could eventually, if I want to modify it, change my parameters somewhere (I’d still need a kind of global parent console that ould show me all sliders in one place. I worked with panel, perform etc but I’m still confused)

I still don’t know how I could use it if I wanted to dynamically change the export conditions. I mean THAT parameter is controlling (exporting to) THIS parameter now, but later THAT parameter is controlling (exporting to) ANOTHER parameter.
I guess it is easier by programming.
Some other stragey would be to have multiple copy of my system, switched on/off depending of the context, each one with static exporting setup, instead what I have in mind which a big systems with dynamic exporting to setup.

5

Julien,
I just showed the basic and easy to understand setup.
In my propoer projects, I use blend between columns and I use scripting to record the parameters into the table when I change it. But the main advantage its it is readable and you can edit it externally.
Alphamoonbase project is awesome but, as some other proposition, I found it not usable for me because they are made for particular needs and not easy to maintain.

1 Like
6

The scripting is in fact not to hard, now that we can acces the parameter by name from a dictionary.
Lets just say that we have every preset as its own table, we can then simply iterate over all the values in the table:

grafik
grafik1182×797 66.7 KB

For storing we can simply iterate over all the parameter and write them into our table:

grafik
grafik1116×762 73.1 KB

Hope that helps you to go in the right direction:
Some notes:
This is barebones and error prone!
For the recall, you might also want to check if the parameter even exists. Also, boolean values will always be true, you will have to check if the target parameter is a toggle to set the value accordingly.
For storing, this stores ALL parameters! Not ideal. But you can simply iterate over customPars if you have them all in place.

Regarding TauCeti: The base setup is pretty streight forward and easy to use and litle bit more advanced but def. a good idea to get the basics down!

@jacqueshoepffner Regarding your special needs ( ;D ) feel free to comment the project and I can see if I find the time to implement what you are looking for if time allows or maybe is already implemented. Always happy about feedback .

1 Like
7

I agree with @jacqueshoepffner – store all control information in DAT tables. That way you have one part of your setup that sets or modifies the tables, i.e. your control inputs, and then the rest of your setup looks up the directions in the DAT tables. At any time, you can see what the intent of your setup should be, regardless of whether or not it’s actually doing what you want. If the DAT table isn’t being updated correctly, then your control portions need fixing; if the control and DAT is doing the right thing but the output is not what was intended, then you know the issue is downstream from the DATs.

1 Like
8

I don’t know which practices would be better between
changing “export to” dynamically VS having a null exporting always to THIS parameter and switch before the null