Ben Casey

Hey Guys, I'm looking at using Coll to save the state of a number of parameters and recall them at given times. Seems straight forward enough but there are a few challenges i'm hitting. It's easy enough to capture 4 parameter names and values as list. so that i have:

0, Param1 value1 Param2 value2 Param3 value3;

However what if i want to change just the value of Param2? It would seem like I could just use an nsub message however I don't necessary intend for every index point to have the same number of parameters stored.

Is there a way to reference and change index 0 Param2's value by name?

Is this a crazy way to implement this? should I be looking at Pattr instead?

Hey Guys, I'm looking at using Coll to save the state of a number of parameters and recall them at given times. Seems straight forward enough but there are a few challenges i'm hitting. It's easy enough to capture 4  parameter names and values as list. so that i have:
0, Param1 value1 Param2 value2 Param3 value3;

However what if i want to change just the value of Param2? It would seem like I could just use an nsub message however I don't necessary intend for every index point to have the same number of parameters stored.
Is there a way to reference and change index 0 Param2's value by name? 

Is this a crazy way to implement this? should I be looking at Pattr instead?


coll-question-2

Well, among other professions in my other live I am database developer. Let me talk a little about this fine little Max database called [coll] ...

[coll] is better than it looks. It's a flat text-based database, those belong to the fastes and maintenance-friendliest databases available. And it has a special character: it does not care about the type of index. This is unusual and might give you the opportunity to find your records and parameters easier than you think. The record index (the first "column") can be numbers or letters or words or mixed. The order of the lines is irrelevant unless you plan to retrieve them by a counter. Therefore, depending on your application, you could be able to "flag" your records in a meaningful way just by naming them properly.

Imagine two synthesizer modules: Osc1 and Lfo3. They have different parameters. If you are used to deal with strings, you don't need to keep abstract number tables. You know that oscillator has 3 param/value pairs and the LFO has 5. With a clever system you can precisely find the parameters by name or line. No need to use nsub or something like that.

Identify them by numbers (technically) and names (when you look at them), with multiple params per line:

Neither of the two methods leave much room for errors. You can save both colls as files, sort them, read them, understand and edit them. Even solution #2 above is almost failure proof. You may not need the first parameter and if you don't display it somewhere it is just for humans who want to see what's going on. And you certainly know the parameters of each sound module. Got another module with a parameter more? Take a text editor, find the lines containing "Lfo3" and there you go.

Of course I do not know if this fits to your application. I wanted to show you that [coll] isn't a magic box. It's a simple text file, a piece of paper that you can organize how you like. The simpler the better, because the number of lines does not count with today's computers. Complicated structures are the problem, they cost your programming and finally processing time and are candidates for endless debugging.

Only if you cannot organize your data in a simple way would be a good reason to look for another method. Picking data quickly out of a virtual x/y matrix is definitely not a job for [coll] but the little friend serves many purposes very well.

This was a completely non-academic approach, only based on experience with I-do-not-know-how-many crazy systems.

Imagine two synthesizer modules: Osc1 and Lfo3. They have different parameters. If you are used to deal with strings, you don't need to keep abstract number tables. You know that oscillator has 3 param/value pairs and the LFO has 5. With a clever system you can precisely find the parameters by name or line. No need to use nsub or something like that. 

Solution #1
Only pairs, identify them by name:

Osc1_freq, 1200;
Osc1_amp, .6;
Osc1_wave, rect;
Lfo3_freq, .2;
Lfo3_amp, .9;
Lfo3_wave, sin;
Lfo3_phase, -180;
Lfo3_sync, off;

Solution #2
Identify them by numbers (technically) and names (when you look at them), with multiple params per line:

1, Osc1 1200 .6 rect;
2, Lfo3 .2 .9 sin -180 off;

Very informative reply, thanks Peter. Sorry to hear about the endless experiences with the nightmarish database systems, hope you were paid well :)

Regards to the original topic, no reason you can't use multiple [colls] as well, maybe have each one dedicated to a certain type of parameter list (so they would have the same number of params throughout). This might make retrieval easier. Also it would let you recall whole "banks" of parameters, one set from each coll, from varying indices in each: just use (say) 8 number boxes, each one is an index to a specific [coll], then use [preset] on the number boxes... out comes a new combination of parameter lists.

[pattr] can certainly work for this too, there are pros and cons to each. Well worth a look regardless, it will be useful sometime I'm sure... mmmm... interpolation!

Very informative reply, thanks Peter. Sorry to hear about the endless experiences with the nightmarish database systems, hope you were paid well :) 

[pattr] can certainly work for this too, there are pros and cons to each. Well worth a look regardless, it will be useful sometime I'm sure... mmmm... interpolation!


Thanks so much for your reply Peter! The idea had bee to store the data more like Solution #2. However I'm wondering how i can easily change:

Or what if each index entry might have different number of value pairs for the same device?

Thanks so much for your reply Peter! The idea had bee to store the data more like Solution #2. However I'm wondering how i can easily change: 

1, Osc1 5000 .6 rect;
2, Lfo3 .2 .9 sin -180 off;

Or what if each index entry might have different number of value pairs for the same device? 

1, Osc1 1200 .6 rect;
2, Osc1 1200;
3, Osc1 1200 .9;
4, Osc1 1200 saw;


Ben, one parameter per line is good. Defined groups of parameters per module per line are good. Multiple colls to keep things apart, as seejayjames suggested, are very good.

Your last suggestion with the same sound module but different number of parameters is about the ONLY bad idea you can have in this context :-)

3rd param in line 2: nothing (this may be ok but rather not)

3rd param in line 4: waveform (boing, crash, feep ...)

Line 4 is a potential problem. You know its content now while developing, but finally the application will run on its own and it doesn't know what you know.

Identical constructed lines are always best because you can process them all the same way. If they are not identical, they should be marked by a meaningful index, a numbering or naming scheme.

Remember, [coll] does not care about the form of its index. You could say 88 is a synth, 23 is a LFO and 3 is the number of the LFO. So an index of 88231 or 88_23_1 would clearly identify the correct line. Or you take Synth1_Lfo_3 for example. In the first stage it's all a matter of concept, not so much a matter of "what can I do".

Ben, one parameter per line is good. Defined groups of parameters per module per line are good. Multiple colls to keep things apart, as seejayjames suggested, are very good. 

Let us retrieve the third parameter:
3rd param in line 1: amplitude
3rd param in line 2: nothing (this may be ok but rather not)
3rd param in line 3: amplitude
3rd param in line 4: waveform (boing, crash, feep ...)

Remember, [coll] does not care about the form of its index. You could say 88 is a synth, 23 is a LFO and 3 is the number of the LFO. So an index of 88231 or 88_23_1 would clearly identify the correct line. Or you take Synth1_Lfo_3 for example. In the first stage it's all a matter of concept, not so much a matter of "what can I do".


HA, thanks Peter, I was afraid of that. Ok time to reconsider building this with multiple colls. Is having 8 smaller colls much more resource intensive then one large one?

HA, thanks Peter, I was afraid of that.  Ok time to reconsider building this with multiple colls. Is having 8 smaller colls much more resource intensive then one large one?


I dare to say that it does not matter for the average Max project.

Coll Question