speed is multiplicative, current implementation is messed up

[lerobynetcool]

Hi.

I recently used the [ and ] shortcuts with { and }, which created a mess : I had to use backspace to get to the regular x1 speed.

This is a design issue. Changing speed is a multiplicative process, thus it should be controlled in log scale.

In other words : currently, speed is controlled "directly", but instead we should control log_speed and have speed = exp(log_speed) (or speed = 2^log_speed would be a more intuitive choice I thing)

Here is why this is a much better choice :

1. stability : we are less exposed to floating point rounding errors
2. we never reach negative speed, nor a speed of 0 (we would need log_speed=-∞)
3. now the intuitive rate is to add steps to log_speed.

(note that the initial value of log_speed should be 0, as exp(0)=1 and 2^0=1)

Then I would expect input.conf to look like this

# small steps of 1/8 = 0.125
[ add log_speed -0.125
] add log_speed +0.125
# big steps of 1
{ add log_speed -1
} add log_speed +1

no need to compute 1/1.1 and such, much cleaner ! isn't it ?

Moreover, now we can actually mix [, ], { and } and never get stuck, unable to reach a speed of 1.

[lerobynetcool]

note that my current input.conf has

[ multiply speed 0.9170040432
] multiply speed 1.09050773267
{ multiply speed .5
} multiply speed 2

because they are 2^(1/8) and 2^(-1/8), this way we have the property I talked about before... except maybe floating point stability issues.

[NotMithical]

no need to compute 1/1.1 and such

Currently you can use

[ multiply speed 1/1.1
] multiply speed 1.1

instead of having to use an approximate decimal value like 0.9090909091. This is what I use in my conf and it always goes back to 1x speed without having to hit backspace.

[lerobynetcool]

true, can we compute 2^(1/8) (I also tried 2**(1/8) but it failed) ? This would make much better sens (this is 8 regular substeps of x2 scaling).

Moreover, I see that the zoom feature uses the proper logarithmic scale. I think playback speed should use that same approach.

[NotMithical]

The value for multiply has to be a floating point number or ratio. A lua script might work better for what you're suggesting.