Quote:
Originally Posted by schwa
Regarding the OSC touch messages, we did give this some thought. The simplest implementation adds a new message for enabling/disabling touch for each parameter, as we have done. A more complex implementation could use a sort of meta-message, such as
PARAMETER_TOUCH_ON s/touch/on
PARAMETER_TOUCH_OFF s/touch/off
and the device would send volume automation like this (using the default pattern mappings):
/touch/on /track/volume
/track/volume 0.50
/track/volume 0.51
/track/volume 0.52
/touch/off /track/volume
However, this could be impossible to implement in some host devices, whereas the simple version can always be implemented.
|
Fair enough. But couldn't we have both? If our devices *can* support it, we should be able to use a smarter, perhaps more complex scheme. If they don't, bad luck, then we have to settle for using a dumb/simple 'lowest common denominator' scheme. But what are those cases anyway? With so few hardware devices shipping with hardcoded native OSC support, for most practical purposes it seems simply a matter of getting the appropriate software updated with some marginal improvements anyway.
For another possibility, have you perhaps also considered using something like keywords (e.g. "touch-begin" and "touch-end") in places where pre-existing OSC message patterns normally expects floats or ints, so type-checks can be used to filter/route messages as needed? E.g.
Code:
/track/volume touch-begin
/track/volume 0.50
/track/volume 0.51
/track/volume 0.52
/track/volume touch-end