Oh yeah, you can use the formula device exclusively to do what you’re looking for, but you only have 3 available input parameters. That init-patch that has the sine-wave lfo looks a lot scarier than it actually is. You can make an “instant lfo” in the formula box by simply entering:
y=sin(SAMPLECOUNTER/SRATE)
The words in all caps are environment variables I guess (I’m bad on terminology here), and you can see what they mean by clicking on the “Help” box in the formula. It looks scary but you can break it all down line by line.
In this case, SAMPLECOUNTER is a continuously ascending (probably starting from 0 at project load) integer value (1,2,3,4…) that “counts up” for each audio sample (I’m thinking you know sample rate concepts) whether the song is playing or not. So it’s a number that gets big pretty fast (+44100 per sec, for instance) and just keeps getting bigger.
If we divide that big, constantly increasing number by SRATE (the sample rate, which is whatever you have in your settings/preferences), then we get a number that is increasing just as “fast” (i.e. one incremental increase per second), but not by as much (specifically increasing by 1/SRATE, so 1/41000 perhaps, aka 0.000022675736961 in my calculator app). So now it’s a number that is getting bigger every 1/41000th of a second, by 1/41000th. So it still gets big at a rapid rate, just less big, less rapid. I hope that makes sense and that I’m not condescending.
So now we have talked about SAMPLECOUNTER/SRATE, which is just a fractionally increasing number ad infinitum.
If we “plug that into” the sin() function in lua (the scripting language used in the formula device, and in much of renoise though you don’t get access to that other stuff through the formula), it will look like this:
y=sin(SAMPLECOUNTER/SRATE)
and basically what that means is that the sin() function will operate on whatever we have in the parentheses. I unfortunately cannot tell you what it is actually doing in arithmetical terms other than “look at what happens”, and I can’t tell you cuz I never got that far in math and I’ve never bothered to learn, all I know is it has to do with fancy stuff that euclid and maybe descartes figured out about circles and triangles and lines and stuff.
So this does give you an LFO based on a sine wave, but as you can observe, it’s actually only one half of the wave, and the output value just stays at zero for the “lower half”
But we can deal with this with just a tiny bit more math and understanding the formula device.
The output-value of the formula device is always always between 0 and 1. If the value which our little equation that we put in the y= box yields is outside of that 0-1 range, it will be “clipped” just like audio hard clipping, and the waveform won’t “move” until it falls back within that range.
And so because of that, when do our little sin(count/rate) equation, we are actually generating a value between -1 and 1 (negative one and positive one), and so that’s why the entire bottom half of our sinewave is now “out of view”.
I think you could work this out for yourself if you really wanted (with basic arithmetic and the Help box, and I would encourage you to dink around and try to do this on your own, if the formula device interests you), but I will let you know what you need to do to get a proper sinewave output from here.
we need to both “lift up” the negative values of the sinewave so that they are no longer below zero. We can do this with
y=sin(SAMPLECOUNTER/SRATE)+1
but now we kind of have the same problem because the wave is between 0 and 2. So we deal with this by halving the sinewave, and you have to remember order of operations here or you won’t get the result we’re desiring.
y=(sin(SAMPLECOUNTER/SRATE)+1)/2
Plug that in and you will get a mature and healthy sinewave.
Anything beyond that, I wouldn’t be telling you anything that can’t be figured out by looking at the Help documentation and learning a little Lua and maybe some trig. But I will show you what you would need to do to accomplish the same thing as that device chain from here.
If you want to control speed (in general. You can do more specific math for your own purposes), you can multiply SRATE in the equation by the input value A (which you can rename in the formula but it will always be represented by “A” in any of the code). This value is also between 0-1, which is displayed for you. So, considering order of operations, we multiply SRATE by A with
y=(sin(SAMPLECOUNTER/(SRATE*A))+1)/2
This way, A will control your speed. If you actually play around with it, though, you will see that the output value jumps discontiguously. Such is life in the formula device, there is no way around this behavior to my knowledge, and so you would be better suited using the actual LFO if you want continuous rate modulation with contiguous output.
If the “rate range” that you get with the above code isn’t right, you can multiply by various integer or decimal values, i.e. (SRATE*A*4) or (SRATE*A*0.2)
Then, you can multiply that entire formula by PLAYING and get
y=((sin(SAMPLECOUNTER/(SRATE*A))+1)/2)*PLAYING (NB the parentheses)
And so this is close to the behavior we want, but I actually had to test this to realize it’s not right lol. We actually want the “sample count” to not be constantly running nonstop, so we will use the SAMPLES variable instead (which counts up from the song start, and does not accumulate value while the playhead is stopped). We still get to use SRATE as is because it’s just 2 ways of counting up at the same rate, and then we can do without the PLAYING variable because SAMPLES “stops counting” for us already.
y=((sin(SAMPLES/(SRATE*A))+1)/2)
and this will give you a very roughly equivalent situation as the previous device chain setup, though it doesn’t work as well lmao.
But I typed all this up because sounds like I caught you a fish and so you can refer to this post if you ever want to learn a little more about fishing. Mostly I’ll post this cuz I can see future formula-aspirants coming to this thread and this might be stuff they would like to know, but don’t find easy to figure out.
Which reminds me, probably the most important thing that can be said about the formula device (specifically the “formula box” aka the text box that we’ve been putting all of this in.
Sometimes you will get an error that reads: attempt to call a number value and I would describe this as a bug and it’s kind of hard to reproduce and it’s very confusing when it happens and your shit won’t run right 
But you will get this message for completely legitimate code sometimes, and the only way I have found to fix it is to go to the end of your formula-box code, and enter +0 (or another integer) at the very end of the formula. This will make the formula device happy and then you can actually remove the +0 and it will still be happy, even though it was the same code before and after.
So really I should go make a bug report instead of wasting all of your time hahaha.
But yeah, the formula device can be dope when you need a very specific thing that can be triggered using the available “musical variables” that are listed in the Help box. In tandem with the other meta devices, there is much unexplored territory out there! The meta-mixer seems especially slept-on to me, especially because the weights are exposed as controllable parameters. But as you will learn by experience or further forum-combing, the output of the formula device is limited to your project’s tick-rate, and cannot output values any faster. It can calculate functions and waveforms that are “faster” than that tick rate, but you will get the nyquist effect going on, such that you’re only seeing “frames” of that waveform in the output at the tick-rate of your song. For this reason, I generally find that it’s best to use the formula device for precisely what it can do that other devices can’t, and then outsource anything else to other meta devices like the hydra or an LFO. Particularly, everyone should know about the Input Inertia preset that is available for the formula device. I use that hoe all the time.
In any case, as that one guy always says, Happy Tracking!
