this update introduces a breaking change in the parameter syntax. why did we do this?
- previously parameter names could have spaces and non-alphanumeric characters
-
@artfwo is working on automatically creating OSC endpoints for all parameters, hence a param
filter would be OSC-controllable via the /param/filter OSC pattern
- hence we had to make parameter āidā fields safe for OSC strings
- this also generally makes code look nicer as well, allowing for verbose names but having sensible functions ie
params:set('cutoff',4000) but the param displays as Filter Cutoff (hence we donāt need to type params:set('Filter Cutoff',4000)
how to fix scripts that use the old syntax:
-
params:add_x() have an additional argument. previously it was:
params:add_x(name, ...)
now it is
params:add_x(id, name, ...)
where x is number, control, option, etc.
so if you previously had params:add_number("Favorite Number", 0, 100, 0) you need to change that line to: params:add_number("favorite_number", "Favorite Number", 0, 100, 0). and then anywhere you have a params function change the name to the index, ie: params:set("Favorite Number", 3) becomes params:set("favorite_number", 3). easy enough!
furthermore, weāve made a helper function to make parameter initialization much easier.
params:add_number("scale_mode", "scale mode", 1, 7, 3)
params:set_action("scale_mode", function(n) build_scale() end)
becomes:
params:add{type="number",id="scale_mode",name="scale mode",
min=1,max=7,default=3,
action=function(n) build_scale() end}
this initializer uses table initialization (notice the curly brackets).
- you can leave out the
name field, and name will be assigned the id
- attributes can be specified, making everything much more readable so you donāt need to memorize parameter order
-
action function can be specified in the same command
- you can still use the old way of course
this has the unfortunate side-effect of smashing existing presets. if you want to convert old presets to the new system you simply need to run a find-replace on the whole file for each parameter type. for example, in playfair i converted some old presets by running fine-replace on "1: filter cutoff", replacing it with "1_filter_cutoff". highly suggest some fancy macro-ing for this task.
i apologize for any trouble this causes. weāve been careful to design for future-forward-ness, but occasionally weāre going to discover moments like this where the architecture needs to be tuned.
huge thanks to @artfwo and @markeats and @jah for parameter design insights. we have a bunch of new features coming that are very exciting.