The canonical way to get cyclic "oscillator" behavior is, for every sample number (n), take a step of a certain size (increment) at a certain rate of speed (samplerate) wrapping around to stay within a specific range (length) such that you complete a certain number of cycles (frequency). What you'll get is an index (x) that you can use to look up values in a table, or as input to an equation, to get a result (y).
What should the step size (the increment) be? It's determined by the formula
increment = n*frequency*length/samplerate.
[I learned the above from Elements of Computer Music by F. Richard Moore.]
In this example patch, the counter object produces the sample number (n), triggered by metro producing the desired number of bangs per second (the sample rate). I arbitrarily chose a "length" of 1000 because it gives a reasonable degree of precision and makes the math simple.
Set an LFO rate you want (e.g., 0.25 for a cycle every four seconds) and a sample rate you want (e.g. 20 samples per second).
The expr calculates a sine, but you could use any formula. If you want a lookup table of floats, you can use buffer~ and peek~, as shown in the far right part of the patch. (In this example, I fill it with one cycle of a sine wave on load, then use it as a 1000-element lookup table.)
If this seems useful to you, you could encapsulate the core part of it and use it as an abstraction.
i have this idea of a non-signal phasor with a lenth independent playbackrate - so when changing the length the frequency of the playback doesnt change. is this somehow possible without recalculation the frequency
everytime i change the durration/length to be played?
of course i checked christophers example patch wich is very interessting.
maybe iam blind, but could it be that the phasor part doent work correct?
when setting the lfo speed to 0 it should stay at the actual position but instead it always jumps back to 0. and there are also some modulations in
position when changing the lfo speed.