Speed in effects have no unit of measure

[ewowi]

In some effects in StarMod I replace ‘speed’ with BPM as I hope that speed does the same in different effects. Now it’s completely different in WLED .

I was thinking, should BPM be a general parameter which defines how often an effect frame is called ? So leave it out specific effect code?

And if so should the same bpm apply also to all effects if you have more than one effect or could each effect have a different BPM?

I propose bpm because it has a unit of measurement: beats per minute, but frames per second might also be possible, or whatever / time-unit

[ewowi]

SH007:

good point actually - "speed" is really used very inconsistently in wled effects - same about "intensity".

its not just about how often the effect function is called - but indeed some effects use the parameter to "skip" frames.

better use of speed (or BPM) is to control the "progress" of an effect. For example, in DJLight, speed should be used together with elapsed time to decide how many steps of "scrolling" are needed.

this is basicially the difference between "frame rate controlled" (evil) vs. "time based" (smooth) progress

EW:
So you are saying a frame something’s need to be called a few times before one step is done?

SH007:
maybe yes, if too much time has elapsed.

other effects (like animartix) move the content sideways, and for these, it's better to let the effect decide. for example, move 3 pixels left instead of 1.

TH:
There's also places where I would consider "speed" to be backwards - where it's used more like a delay.

Small delay (slider to the left) is faster.

007:
i think the critical parameter for effects is "millis since last call". maybe the value could already be "stretched" or "condensed" based on a global bpm.

so effects would just look at their "elapsed millis" timebase, but they do not need to have their own bpm-to-speed calc

for example:
effect framework does ⁠ elapsedTicks = ( (millis()-last_time) * userBPM) / speedBase; ⁠

effect does ⁠ if elapsedTicks < 10) return; ⁠
or ⁠ newX = oldX + elapsedTicks/5; ⁠

--> frameworks handles base speed
--> effects get simpler, but still flexible on how to handle "smooth motion"

speedBase ⁠ is just a calibration constant, to achieve something like "10 ticks per beat"

... or maybe 50 (100?) ticks per beat

... for my first patter "if elapsedTicks < 10" to really work, there must be a way for effects to tell the framework that progress has happened. like "return SKIPPED" -> don't update last_time. "return DONE" -> update last_time.

[ewowi]

the speed parameter should also have an option to run "max speed' (slider at max?) so the effect runs as fast as possible

[Flavourdynamics]

Generally, I think FPS is better, unless we are talking about sound reactivity, where BPM is more applicable. Speed is a bit vague. If speed is used, it should also describe what is speeding up: colour, movement parameter_x, etc.