Discussion on the semantic of ports, addresses & bindings

score
#1

Hi,

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 :

a
a831×359 15.9 KB

#2

In terms of data model, a goal is to remove the handling of min / max / domain which is part of each process implementation (for instance it’s the automation implementation which handles the min / max) and put it as part of the port handling, so that every process automatically benefits from it (while right now every process has to implement it manually - and as such it is done pretty much nowhere).

#3

Another question is, do we want to have any kind of non-linear mapping function in cables / in the address -> port & port -> address mapping ?

#4

I would imagine that at this level, it would be best to have a option when right clicking on a cable that places an actual mapper process on the cable. basically split the cable, shove a mapper in the middle, and make sure everything is reconnected.

I think all of it should happen on the receiving address slot with a similar interface as with extended types. On the receiving side, only one min and max should be necessary if the input range is deduced (it should always be set with some sensible defaults if the user did not provide a range). min and max could be separated, and default to the input range when not set (ie. not setting the min for incoming values starting at 0 would default to zero, that way, mapping a [0; 1] incoming range on a [0; 255] parameter range only requires setting the receivers max to 255).

This would also require for the address slot to be able to hold several addresses, each with a min, a max, extended types and a tween option. it would imagine a little “+” on the left of the slot to add another one, much like we have for conditions.

Also At this point it would be vital to be able to represent incoming cables in the address slot, to differentiate between different incoming streams, and set all these parameters accordingly.

hope this is clear, but I doubt it.
I’ll try to come up with illustrations.

Going full Nodal