We’ve been discussing this at great length in the past and, while it’s important to keep things open in order for users to hack/misuse the software in the way they wish, I think it would be nice that we be able to cater with those kinds of situations (which are pretty common, actually) in a generic way, that would stay in line with ossia’s global namespace management philosophy (if I can say so)
In my understanding of this “ossia philosophy” and of this kind of OSC pattern,
while, in this case, OSC-wise,
/Carla/0/set_parameter_value is the address and
int float is the message.
Though, structurally, here the
int part of the message is actually more of the address part, in my understanding, and the
float part is the actual message (or value)
(well, I guess things are expressed this way because of some internal VST specs logics, or for some kind of legacy, or whatever…).
So, a possibility would be that we added a kind of alias/pattern system, which would allow to display those address/double values schemes as a set of parameters, that would be e.g. represented in ossia as:
/Carla/0/set_parameter_value.int float which is: the int part of the message being an instance number, it would be represented with ossia’s instance syntax (aka dots)
and this would be output to the OSC device as:
/Carla/0/set_parameter_value int float
Would that make sense ?
If that does, then I guess we would need to find some kind of pattern creation UI in the device editor or the device’s node’s editor.
that could be an extra field (to be activated with a checkbox, or something), with some simplified wildcard/pattern-matching syntax - in the given example, that could be (with
/Carla/0/ defined as the parent node hierarchy) done so in the
set_parameter_value node edition window:
instance management [x] pattern: [set_parameter_value.$i1] values: [$f2]
$i1 would mean that the first int from the messages part is expressed as an instance, and
$f2 that the second, float, element would be used a the value)
I guess we would then have to define a max number of parameter instances, so that those adresses be automatically created in score.
(eg. if this particular VST had 23 parameters, score would create:
/Carla/0/set_parameter_value.1 (single float parameter)
/Carla/0/set_parameter_value.2 (single float parameter)
/Carla/0/set_parameter_value.23 (single float parameter)
that could be managed individually in the score
and would be mapped on the OSC output to:
/Carla/0/set_parameter_value 1 (single float parameter value)
/Carla/0/set_parameter_value 2 (single float parameter value)
/Carla/0/set_parameter_value 23 (single float parameter value )
what do you think ?
would that make sense ?
was my description clear enough ?
If the answers are yes, we should do some kind of survey of OSC devices/softwares using this kind of syntax, so we can devise the most generic possible syntax.