Lfo speed

i have a question to pichenette

i would to know if it’s possible to have very very low lfo ,now the minimum it’s near 1hz when it’s at minimum

do you think it’s possible to put lower than 0.1hz .

it’s for make long evolving drone .

thank you for reply

the only risk i have if i change the code it’s bug on starting

i can’t burn the Atmega ?

No, you can’t damage a chip with bad code.

It’s easier to program with an AVR ISP programmer, since it takes only seconds to load the code into the chip. But it’s not necessary, you could very well build a .syx file and send it to your Shruthi to test your code.

how to program ,i need interface ,sorry i’m the noob of the noob :slight_smile:

thanks a lot for the clarification. i am beginning to understand what is going on in your code. (i am not a total c/c++ noob, but i am quite rusty and out of practice with that)
this also answered my question where the lfo render method is called from.

Actually what sets the control rate is kAudioBlockSize - the LFOs are recomputed once for each block of 40 samples. A side-effect of changing that size is that it will increase the size of audio buffers, and thus the latency.

A more correct way is to increment a counter in ProcessBlock(), and to call lfo_[i]. Render() only when this counter is a multiple of 2 (or 4, or 8, or 16…)

maybe try to change the controlrate for slower lfo? (everything als happening at controlrate will get slower this way obviously)

it is set in line 74 in shruthi.h
static const uint8_t kControlRate = 40;

higher value means slower, because the audio rate gets divided by that number. 80 would be half the speed for example.

no idea if it works that easy, but worth a try.

i am no expert at this at all. i was just browsing through the code, trying to understand what goes on and learning about how to calculate an lfo. the lfo values are rendered in lfo.h (render method of the lfo gets called from somewhere else though. i didn`t find out where until now, but it must be happening at the controlrate)

modify the code yes i need two years for unerstanding the first line :)))

slow slow slow ,for meditation ,shruti tanpura

do you think it’s possible to hack with a ltc1799

Why don’t you modify the code instead? You could refresh the LFOs at a 10x slower rate. It will no longer be possible to make them run as fast; but doesn’t seem to be a problem in your case.

a damnnnnn

hahahah i need my modular

Just put a slower crystal on the control board :smiley: (joking, doubtful it would work?).

I remember reading how someone lowered the pitch of a gameboy by fitting a slower crystal.

No, it’s not possible without modifying the code. Minimum LFO time is currently close to 0.1 Hz.

Would it be possible to achieve this using the operators?


apologies for necromancing this thread, but did anyone suss out the firmware changes needed to slow down the LFOs? I’d fancy a build with slower LFOs as well. Kinda wish there was an LFO speed multiplier setting (0.1 / 0.25 / 0.5 / 1 / 2) available in the system settings menu, but I guess ther’s no room in the code for something like that?

Use a synced X16 LFO to an external slow BPM clock. You will need an external sequencer that sends it’s clock over MIDI for this. Then set the Shruthi clock from internal to external.

Interesting. I would like to do the opposite. Does this mean I would simply refresh the LFOs at a faster rate?
Also it seems like the knobs are exponential (the LFOs start getting much faster toward the end of the knob rotation)…is there a way to change this to what sounds more linear?

You can change the minimum and maximum frequency, along with the control law here

wow…thats easy, even for a dummy like me