Lfo period zero and cycles

this has been like this since i know about vvvv

period = zero should stop adding/subtracting cycles,
instead it goes crazy and you have to reset it.

lfo zero.v4p (3.1 kB)

really? going crazy seems like natural behavior when trying to do anything in zero time. to stop adding/subtracting cycles, there is a nice sane ‘pause’ pin.

as i was seeing it, no time means no cycles

well, not in the mathematical sense. because then there would be a “jump” between a reallly small period, say 0.0001s (really fast!) and a zero period (frozen!)… not very consistent.
if a pause would be implemented, then it would have to be as a Infinitely large period…

isnt the jump cleared by the frame-based system we use ?

i completely agree with diki and bilderbuchi.

@ggml: the time in the period of the LFO is wall clock time and not quantized to the current frame rate. so the small differences do make sense.

i am not sure if the current implementation guarantees the numbers at the output pin are random enough for practical purposes when period=0, but principally they should be as random as possible, and it should be possible to use an LFO as a random generator.

in the same future implementation cycle should also output a random integer in each frame (under the assumption that vvvv tries to wrap numbers in as many places as possible so a counter counting with infinite speed should wrap the cycles pin also infinitely often each frame and so will be sampled at any position with equal probability)

when using an lfo to animate things by adding output + cycles, an accidental 0 to the period basically breaks the patch by sending cycles to minus buxtehude; one has to reset the node to continue working. is the logically correct behavior really the most desirable one in this peculiar case? is there any use case at all for a period zero lfo? or would it be feasible to just put cycles to 0 on a 0 period?

as you experienced, it creates chaos. thats exactly what it should do and i like it. and that could also be a use case, making chaos…

if you dont like that, its easy to handle patchwise.

yeargh, there’s always workarounds …

i’m just thinking that creating chaos is not the primary function of the lfo node, and that using it to get random numbers is a misuse (meaning: not the thing that the algo was built for & not at all the most performant way to do that). rather than encouraging that, it could be decided to implement it in a way that is more practical in 99% of the actual uses of that node.

coming from the other direction, i also wouldn’t use the randomspread as a sawtooth generator just because the implementation allows that. and i would not argue against removing that particular quirk, because that would bring the node closer to its original intention.

thanks to all

LFOs randomness

@diki (thx): you argued from both theoretical and practical viewpoints (with different conclusions), but i hope with the new implementation somehow both will be covered…

for all LFO periods with abs(period) > 0.000000001 it will behave like you would expect from an LFO. note that also negative period values are ok for reverse movement. with that you should be able to model everything upto the behaviour of quarks and their randomness.
for all accidental zero periods the LFO freezes (reflecting the fact that there is a world which we know nothing about ;)

Randomspreads LFOness

i changed the behaviour of the randomspread node, so that it feels more like random. note that all your current patches will work with the unchanged legacy node.

for beta>22

randomspread2.v4p (7.4 kB)