Controller linking scale/multiplier

[DeRobyJ]

Right now, it's possible to link two different controllers: when one is changed, the other takes the same value. This value is not scaled, so if I link a 0-1 controller to a 0-5 one, the second one cannot go over 1, and if the first is at half of its range, the other is at 1/10 of its one.

It would be interesting to decide the scale or a multiplier for this. Let's say I want to connect:

• Note Stacking Range [1-9, integers]
• Volume [0-200, integers] But I need that when Range is higher, Volume is decreased.

So I link them, by ctrl-dragging Range to Volume, and then I would left click on one of them to set it's scale. I'll left click on Volume, find the right connection (right now no connection is shown, you can only remove all connections), and then click on "Scale controllers". This way, when one is max, the other is max too. When one is at half (Volume at 100%), Range will be at half too (4, wich is the floor of the actual value, since Range is a integer) Then I'll click on "Invert controllers", so that when one icreases, the other decreases.

Cherry on top: write a function.

I right-click on Volume and go to the link with Range. Instead of Scale them, I'll write a funcion: Volume = [user input] In the input, the user will be able to write an "x", wich stands for "Value of the other controller" For example: Volume = 200 - (30 + 10x)

This way, if Range is 9, Volume will be 80%. If Range is 5, Volume will be 120%. If Range is 1, Volume will be 160%.

Of course this will need a lot of bug testing for stability, but if this works right, well, LMMS would be able to do all sorts of interesting things. Maybe most of them would just be experimental, but who knows!

[Spekular]

I think scaling so that both knobs can reach 100% is definitely better, but as you said it should be optional since some people might expect/want the old behavior. Adding an option to invert would be useful as well, but it feels sort of like a slippery slope. Why not an option for exponents, square root, multiplying, dividing, adding, subtracting? Writing functions allows pretty much 100% flexibility, but it seems like it would be nightmarish to implement.

[DeRobyJ]

Yea we could have different pre-made options to avoid bugs and strange behaviours, but we have a different problem: For example you may want to link something to Volume, to Filter Cutoff or Resonance: you will never want a 0% Volume, and in most case you don't want a >120% either, and you can't work with a 1hz cutoff, or you would like to limit Resonance to a certain range. With those options you couldn't! Instead, with a Function editor you could add any number to define ranges, offsets, etc.

[Spekular]

Exactly. There's lots of problems with both premade functions and custom ones. Premade functions are inherently limiting, and adding more of them can only add so much flexibility, while creating problems of their own. A function editor is the way to go from a usability standpoint, I agree with you on that, but, implementing it :/ I think it might be good to start with premade functions, and maybe work towards a function editor later.

[diizy]

On 11/20/2014 09:00 PM, DeRobyJ wrote:

Instead, with a Function editor you could add any number to define ranges, offsets, etc.

A function editor would require some kind of parser or interpreter to interpret the functions. If this is done in realtime, it's a performance hit. So then we might have to write an actual mini-compiler or some kind of JIT mechanism that compiles the function at realtime, and that's a whole new level of complexity...

Not to mention, when the function does something stupid: best case scenario, outputs tons of inf/nan, worst case scenario, hangs the entire software... if we have to write safeguards to protect the function from doing anything stupid, that's even more complexity...

I don't think this is very practical. A nice idea but not practical.

[tresf]

Probably a more practical usage is a new controller which serves as an automation link multiplier/distributor. (mock up idea attached)

Implementation may be difficult, but the idea of linking controllers is not new, and the software should be able to do interpretation of a simple equation. To Vesa's point, the inefficiencies may kill the idea, but it really depends on how efficient the just-in-time interpretations are as well as the frequency of changes being distributed, math complexity, etc. :smiling_imp:

[diizy]

On 11/20/2014 11:25 PM, Tres Finocchiaro wrote:

Probably a more practical usage is a new controller which serves as an automation link multiplier/distributor. (mock up idea attached)

image https://cloud.githubusercontent.com/assets/6345473/5133253/a30cef1a-70d1-11e4-8777-0ca4ad5635f0.png

Implementation may be difficult, but the idea of linking controllers is not new, and the software should be able to do interpretation of a simple equation. To Vesa's point, the inefficiencies may kill the idea, but it really depends on how the just-in-time interpretations are. :smiling_imp:

I think if we forget the idea of typed equations and instead just use a graph widget to represent the function, that would be doable. After all, we know the range of both input and output values, so the function can easily be mapped into a 2-dimensional grid.

With your mockup, there's the problem that currently, with the way our controller rack works, we allow only one control output per controller, so this "add more outputs" thing can't work without redesigning that...

[DeRobyJ]

A graph would be really interesting! With buttons for "linear", "exponential", "square", etc and one for "invert"!

:+1: