Add time variable to control transformation formulas

See https://forum.cockos.com/showpost.php?p=2565767&postcount=2277.

Could be used for time-controlled parameter modulation or transitions. Especially for the latter it would be good if the time starts from 0 on each invocation (e.g. button press).

reminds me of #355

To respond to your forum post by adding to this FR and combining it with a few others:

I think it would be powerful and intuitive if the value sequences could be expanded to cover curves and the time domain. In theory it could allow for comprehensive transformations without a need for a fancy GUI for the curves. I'm just spitballing syntax, but what if you used ( ) to define the section of the curve that the following values are in, and [ ] to define time variables until the next [ ].

So a value sequence of:

(0-0.33), 1, 2, 3, (0.33-66), [0.3], 7-11, (0.66-1), [1], 6-4

Would go between values 1, 2, 3 within the first third of the curve as normal. The second third of the curve would go between 7 and 11, but take .3 seconds for the value to "catch up" to the position of the source. The final third of the curve would decrease the value from 6 to 4 with a full second of catch up time.

Now I'm straying into deep water here, but what if you could synchronize the time parameter to the BPM? You could make a button that slowly raises a filter over 3.75 bars and then quickly drops it back down with:

[BPM3.75], 2000, [BPM.25], 0

Or with some curves:

[BPM3.75], (0-0.46875), 0-1500, (0.46875-0.9375), 1500-2000, [BPM.25], (0.9375-0.9675), 200, (0.9675-1), 0

For smoothing a track peak, maybe just a value sequence of [.2] would work, in that it takes .2 seconds to catch up to the current value from the last value.

I have no idea if this is possible or if there are complications I'm not considering but if something like this would work I think it would cover all possible control transformations we could want.

This sounds interesting but should go into a new FR. I'm actually working on this one already and it only covers providing a rel_time variable in transformation formulas. I think it's a quick win with a huge benefit already.

Great! Excited to test it out. I'll make a new post for this idea then

A work-in-progress collection of practical formulas that I use for testing:

• Linear transition to control value: y = abs(x - y) < 0.05 ? stop : x * min(rel_time / 500, 1) (1 second transition time, works nicely with velocity-sensitive buttons)
• Temporary chaos: y = rel_time < 2000 ? rand(1) : stop (2 seconds)
• Smooth transition from current value to control value: rel_time; y = abs(x - y) < 0.05 ? stop : y + 0.1 * (x - y)
• Sinus LFO: y = (sin(rel_time / 500) + 1) / 2

... and you could combine this with the "performance control" feature (y_last)

Note to self: Still need to add the following possibilities:

1. Possibility to return a special stop value
   • This stops repeated invocation of the formula until the mapping is triggered again.
   • Good for building transitions with a defined end.
   • Stopping the invocation at some point is also important if the same parameter shall be controlled by other mappings as well. If multiple mappings continuously change the target parameter, only the last one wins.
2. Possibility to return a special none value
   • Usually, each repeated invocation always results in a target invocation (unless the target is not retriggerable and already has the desired value).
   • Sometimes this is not desired. In this case, one can return none, in which case the target will not be touched.
   • Good for transitions that are not continuous, especially if other mappings want to control the parameter as well from time to time.

Update: Added

... and you could combine this with the "performance control" feature (y_last)

Any particular use case in mind?

Any particular use case in mind?

Now that I think more about it, no. Just the general advantage of y_last over absolute values.

Doesn't the "Smooth transition from current value to control value" example above require y_last?

Doesn't the "Smooth transition from current value to control value" example above require y_last?

No. The way it works is that it looks at the current target value y on each invocation and adds little increments/decrements until it gets close enough to the desired value x. A sort of relative-style smoothening.

A rel_count variable which always counts the number of invocations since last mapping control would probably also make sense. Good for stepped transitions, e.g. change things at every 10-th invocation with rel_count % 10. This is difficult with rel_time because it contains the amount of milliseconds since the time of last mapping control and we are not called once per millisecond, but rather arbitrarily.

Okay, enough progress on this one for upcoming 2.13.0-pre.5. I'll leave it open though because it still might need some polishing or changes here and there.

Oops, referenced the wrong issue with many of the upper commits. Belongs to #589.

I think this has natured enough to be closed. The new control transformation editor even visualizes the transformation and some thought has been put into making rel_time better.