Be aware that JS has no block scope!The "i" you are declaring is always the same "i", be sure you want that.
Code: Select all
var i = "test"; // assign "test" to "i"
var i; // "i" still contains "test"...
You could have one for loop and have both declarations for macro and knob values in it.
As for the value scaling: I think the problem is, if your faders are close to top or bottom there actually is hardly anything to interpolate and you get jumps again.
That's where the concept falls flat on it's face (and why the guy in the video puts his slider conveniently in the middle
).But it's still much better than not having it.
Alternatively you could build a kind of limited/damped acceleration into it, where a value can never change faster than a certain amount per call until the actual fader value is reached, after which it would "connect" and go with whatever speed you move...
I'll have to try that idea out actually, could be a very nice way of bridging the gap for non-motorized faders etc.
As for the "automagical" part, yeah, that's what the observers do
But in a non-hard-linked way which prevents dropouts in the main engine since it has fully control over when it updates the values. Observers fill in the values once on init and then only if something changes. Same with the "set", it decides when to update the internal value, but other than a "get", it can do so on it's own convenience where a "get" would need to be served right away, which could lead to problems if for some reason used excessively.
Cheers,
Tom
