Idea: Make it possible to tie LFO to delay-time with tickbox?

[esaruoho]

would it be possible to tie LFO to Delay/Echo clarification: LFO to Delay Time and Pan with tickboxes? would be real swell :)

[vsariola]

I think the panning works pretty close what you are thinking: when slide the panning slider all the way to the right, it does not mean that the sound comes from right channel. Instead, it means that the sound continuously (sinusoidally) alternate between left and right. You can use the panning frequency to control how fast it happens.

Regarding delay tied to LFO, how often you would use it? In principle, it could be added without breaking too much: fxLFO could include two bit flags on how the LFO behaves. That would be backward compatible solution too. But I checked the player-small.js; adding the feature would take something of the order of ~20 bytes and might make it slightly slower (LFO oscillator would be called always).

In particular, the solution would be something like:

o = oscLFO(lfoFreq * k) * lfoAmt + 0.5; // reused in two places
...
if (fxLFO & 1) { ... }
...
z = dlyAmt * (fxLFO & 2 ? o : 1);
lsample += chnBuf[k-dly+1] * z;
rsample += chnBuf[k-dly] * z;

Marcus?

[mbitsnbites]

I feel that every time I make a change like this (e.g. when I added the arpeggio effect) the player routine grows slightly, and all the small increases in size add up.

At some point it would be nice to have some automatic player routine generation based on song data analysis (e.g. if the arpeggio effect is not used, exclude the arpeggio generation code). So far I have manually edited the player routine myself to remove the parts that I do not use, and I think that as long as it easy to remove the unused parts (e.g. an effect is implemented as a single block of code that you can keep or remove), it's ok if a feature adds a few bytes to the player routine.

Regarding your solution, it looks fine. It won't change the song format, and it would be fairly easy to remove the code if you wish to trim a few bytes.

[vsariola]

Esa, one more clarification: did you mean tying the LFO to the delay time or the delay amount. Now that I think of it, tying it to delay time could potentially produce pretty funky sounds, but maybe Esa can comment what he was trying to achieve.

[esaruoho]

@vsariola LFO->delay time :)

edited issue title, and original posting to clarify it's definitely LFO -> Delay Time.

[mbitsnbites]

As @vsariola said, I suspect that the controlling the delay time with an LFO can produce undesired effects.

[esaruoho]

@mbitsnbites thing is, i think when @vsariola used the words "pretty funky", he meant "cool" as opposed to "crappy" ;)

[mbitsnbites]

I did a quick hack (modulated the delay time with the LFO), and it sounded like lo-fi frequency modulation (Doppler effect or similar). Cool effect, but useful?

[mbitsnbites]

@esaruoho If you'd like to try it out, I did a branch with delay time modulation (not sure if it's an optimal implementation in the player routine yet): https://github.com/mbitsnbites/soundbox/tree/feature/lfo_for_delay_time

[mbitsnbites]

Here's the diff: a3bcae4

[esaruoho]

@mbitsnbites Hi! How much of a size increase do you think this will cause for 4Kb intros, if used?

[mbitsnbites]

Looking at my patch, I'd say that the size increase would be minimal (i.e. only a few bytes, less than 100 bytes for sure).