LFO device never stops running - should it?

As soon as you add an LFO device it starts running, even if the song is not playing, and it doesn’t stop when the song is stopped. This is problematic when using LFO->Instr. Midi Control and editing patches on hardware as 1) it can interfere with editing and sending patch data due to clogging up midi processing/bandwidth 2) is changing the values you wanted to edit constantly until you disable the LFO or midi device.

Steps to reproduce look like this:

  1. Launch Renoise
  2. Make a new song
  3. Add an LFO to one track (note that it is already running when the track is stopped here)
  4. press play
  5. press stop
  6. press stop again

Expected results:
an LFO doesn’t start when added if the song is not playing, and stops when song is stopped

Actual results:
LFO starts when added and never stops

This is not a bug but an unfortunate behavior. The modulation devices are not sophisticated enough to allow editing of modulated parameters.

This is more of feature request, and one that should be at the top of the list.

1 Like

LFO has a Reset button to which you can send a trig signal when needed, to always keep everything in sync the same way. If then there is the desire to completely stop the LFO and restart it, I imagine that you can also send a trig signal to the on/off… and the problem is solved, you have total control over when it starts, when stops and when it resets.


This is normal behavior and mirrors the way hardware (low frequency) oscillators work. In hardware form oscillators are always running.

You can automate the Active/Bypassed status of the LFO (or any device) in the track automation editor. Top is active, bottom is by passed.

Regarding syncing. In Renoise you can right click on the reset button and it will automatically add a reset-trigger on your current line & track. You can also type that manually. This also allows you to do cool things with the LFO’s phase. That reset trigger works for any of Renoise’s devices that has a reset option (e.g phasers, flangers, etc).

See the manual’s MetaDevices → LFO section for more details:


To add to this, the same right click parameter locking can turn the LFO (or any device) on and off also. Just in case the automation method isn’t to your liking.


I add, as an alternative experimental solution, instead of an automation on the on/off switch, you could create an automation on the frequency that slows down the oscillation a lot but without stopping it, and at the right moment brings it back to the desired frequency. It might be even more interesting than turning off the LFO completely.

1 Like

LFO shape preset banks should be automateable, so one of the presets could be drawn just as the middle straight line… (to do „nothing”). For now you can automate the LFO tool with FX command: 1100 (off) 1101 (on) (if it is just the 1st in effects chain), or 3100 (off) 3101 (on) (if it is the 3rd effect in the chain) etc. Remember also about the reset command (1800 etc.).

1 Like

formula_lfo.xrnt (3.3 KB)

There are lots of ways that you could use the formula to approach this issue, though I’m not sure what OP’s precise desired behavior is.

The device chain above contains a formula and LFO, where the “A” slider in the formula will determine the amplitude level of the LFO while playing. This value is “multiplied” in the formula box by the PLAYING variable, which is binary, so it will either be 0 output if not playing (0 amplitude = 0 movement) or the value set by A.

You could set the LFO destination to whatever parameter, find your “center” setting with the offset parameter while playhead is stopped, and then determine the desired amplitude while the song is playing. This method also leaves everything else in the LFO open and ready to use, so you can automate the reset of the lfo at the beginning of the song if you want to have exact play-through behavior like you normally could.


Actually duh I should have read people’s posts more clearly.

I just reassigned the formula to the LFO frequency here and now this behaves as @Dr4am describes, which is kind of more intuitive to work with.

formula_lfo2.xrnt (3.3 KB)

The other thing @boffin is I’m not sure what your experience with using renoise with hardware is, but if you want an LFO within renoise to modulate a parameter on your hardware device that you can fiddle with on the hardware device itself (via a pot or slider or whatever), you will no longer be able to edit the patch with that input method, you will have to edit within renoise.

The only way around this is to setup midi I/O for that parameter’s CC, but then you might have some kind of feedback situation?

You may already know this so apologies if that’s just wind in your ear.

1 Like

Thanks for your responses folks!
Ultimately my expectation was that if the entire song and everything in Renoise is stopped, that the LFOs should also be stopped. Plus stopping twice stops and resets everything and the tooltip says “Stop playing the song or pattern (to completely stop & reset all DSPs and MIDI devices, click the stop button while the song is already stopped, or press the right mouse button)” which I took to mean stopping EVERYTHING and resetting MIDI, but obviously LFOs must be one of the things which is a reset not a stop then!

This is all just so I can more easily move from renoise to synth and back for editing on hardware while working on a song which has any LFO->Instr. MIDI devices sending values in it. It seems preferable to me to not add “utility” automation to a song where it’s only there for creating it and not needed for playing it as intended so adding automation is less good in that regard, but @uncle_c this formula-LFO chain seems like it should do the job, cheers! I was considering using formula to replace LFO but disregarded it when the example one ran continuously as well, I had no idea you could do something as simple as PLAYING*whatever

1 Like

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:


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:


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


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.


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


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.


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 :frowning:

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!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.