No, it’s not possible without modifying the code. Minimum LFO time is currently close to 0.1 Hz.
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.
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)
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…)
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.
No, you can’t damage a chip with bad code.
It looks like you're new here. If you want to get involved, click one of these buttons!