[Algorithms] BPM changes (accel. or rall.)

[beary605]

The best way to slow down (rall) or speed up (accel) is to do it with a constant rate of change, e.g. +9 BPM after 1 seconds, +18 BPM after 2 seconds, +27 BPM after 3 seconds...

You are stepping something and thought a slowdown would make a great effect; but Stepmania only allows you to change BPM every beat. (i am aware you can now; problem still stands though)

The problem is: To get from X -> Y BPM in T seconds, while minimizing the difference between each BPM and the expected BPM from the linear rate of change. BPM can only be changed on the beat.

more formally: We want a list (b1, b2, ...., bn) where

the time of the end of the last beat is exactly T: (60/b1 + 60/b2 + ... + 60/bn = T)

We want to minimize the sum of the differences between the linear BPM change and the actual BPM.

let N be where bn occurs (N = sum(60/bk, k = 1 -> n))

= the wanted BPM - the actual BPM
= (the starting BPM - the rate of change in BPM * seconds) - the actual BPM
= (X - (Y-X)/T * N) - bn

Is there a way of doing this, or a way that gets close but is not optimal?

[Wayward Vagabond]

Re: [Algorithms] BPM changes (accel. or rall.)

Ddream

[Xiz]

Re: [Algorithms] BPM changes (accel. or rall.)

Ddream

[beary605]

Re: [Algorithms] BPM changes (accel. or rall.)

[benguino]

Re: [Algorithms] BPM changes (accel. or rall.)

The thing I'm worried about is that it seems you're only considering how well the bpm matches up on the last beat. However, you also want to make sure the bpm is matching up as you go through the entire time period, i.e., you want to look at your partial sums too. Taking this approach, the first partial sum is trivial since you'd only have one variable, b1. Solve for b1. Then for the partial sum up to b2, you have the variables b1 and b2. But you already solved for b1. Thus you can solve for b2. Then continue this process until you reach bn.

At least that's what I got out of it just by taking a quick glance. I'll take a closer look tomorrow; what I said above is just kinda speculation, I work better with pencil/paper which I don't have at the moment :P

[igotrhythm]

Re: [Algorithms] BPM changes (accel. or rall.)

The best way to slow down (rall) or speed up (accel) is to do it with a constant rate of change, e.g. +9 BPM after 1 seconds, +18 BPM after 2 seconds, +27 BPM after 3 seconds...

You are stepping something and thought a slowdown would make a great effect; but Stepmania only allows you to change BPM every beat. (i am aware you can now; problem still stands though)

The problem is: To get from X -> Y BPM in T seconds, while minimizing the difference between each BPM and the expected BPM from the linear rate of change. BPM can only be changed on the beat.

more formally: We want a list (b1, b2, ...., bn) where

the time of the end of the last beat is exactly T: (60/b1 + 60/b2 + ... + 60/bn = T)

We want to minimize the sum of the differences between the linear BPM change and the actual BPM.

let N be where bn occurs (N = sum(60/bk, k = 1 -> n))

= the wanted BPM - the actual BPM
= (the starting BPM - the rate of change in BPM * seconds) - the actual BPM
= (X - (Y-X)/T * N) - bn

Is there a way of doing this, or a way that gets close but is not optimal?

Sounds like a job for least-squares regression. Only that's a way to fit a line to a set of data points, but it sounds like you want the other way around.

[21992]

Re: [Algorithms] BPM changes (accel. or rall.)

from my understanding (although I wouldn't know too much about this) is that ths could be interpreted like Riemann sums. The more times you alter the BPM accurately the better the transition. But I'm assuming SM doesn't accept non-integer beat values for BPM transitions.

[Fission]

Re: [Algorithms] BPM changes (accel. or rall.)

sure it does

[Wayward Vagabond]

Re: [Algorithms] BPM changes (accel. or rall.)

Definitely does