this post is about the last big remaining issue that I’d like to get done for a proper 3.0 release (with presets), which is the semantic of cables, ports, bindings, etc… in order to allow to map easily things together and stop requiring small math expression mappers left and right.
Related github issues:
The gist is, how do we make it easy to
1/ map things both from nodes within the software (e.g. using a LFO to control some audio effect, say a chorus’s intensity) and from/to external devices by taking into account their respective domains.
2/ allow multiple inputs-outputs for nodes (both cables and addresses). For instance, using the same LFO to control two parameters, one with a range of [0; 1], the other with a range of [-10; 100].
What we want to do :
Use-case 1: sending an automation to an OSC address (yes this already works but we have to keep it in mind !
Use-case 2: map an OSC address to another through a filter of some kind (mapping process, etc)
Use-case 3: sending an automation to a control in the software
Use-case 4: using OSC messages to map a control in the software
Use-case 5: generalizing tweening for every automation-like process.
Use-case 6: allowing tweening to work for cables too, not only OSC addresses.
A big blocker right now when reviewing the code is tweening.
The problem is that the way automation nodes were implemented, when e.g. an automation is tweening, the “tweened-from” value is fixed in the curve object at the beginning.
Thus a single “curve” object right now can only be used to tween one single parameter (and we don’t want to waste resources by duplicating the curve object for every output address / port.)
A question is: what happens when an address does not have a domain that we can use, e.g. it’s just specified as int but we don’t know its min / max.
Another question is, what is supposed to happen when a control / parameter sends/receives data from multiple inputs / outputs.
What kind of UI should we provide to map a parameter only partly, e.g say we have osc:/foo/bar which goes from 0. to 1., say we have an audio effect with parameter “gain” which goes from 0 to 1, and we want to map the “0.” of the OSC address to 0.5 and the “1.” of the OSC address to 0.8
If you are wondering why have all these headaches for supporting multiple parameters at the same time, consider this case and the implications on what messages this port can receive :