# Tides V2 Clocked: Range behavior modification

Hello all,

When clocked, Tides V2 doesn’t seem to change LFO speed when the range is changed.

Would it be possible to change Tides V2 so that when clocked && range 1/8 is selected, the LFO runs 8x slower to the clock? Meaning Frequency at 12 o’clock would be 1 cycle to 8 clock pulses, and at the slowest it would be 1 cycle for 16 x 8 pulses.

Is there a simple-ish place in the code where I could throw in a factor to multiply the ratio of the knob so that it’s 8x longer when 1/8 range is selected? I tried finding such a place myself, but I have to admit that Tides code seems very complex compared to some of the other MI modules. I see a lot of frequency multiplication stuff in tides.cc, but I don’t know if that applies when clocked or not.

Thank you–I apologize if my question is confusing or I am missing something obvious.

It is rather easy.

1. Change the size of the `kRatios` array to `[3][20]`. Create a list of 20 ratios for the low, medium, and high range.

Change `kRatios` to `kRatios[state.range]`

Ratios are stored in the array in the form `{ ratio, denominator }`. For example, `1/16` is ` { 0.0625f, 16 }`.

1 Like

I can’t wait to try this out, very clear explanation, thank you!

So, I did as you said, and it all worked perfect.

For reference, in case anyone else wants to try this, these are the ratios I used (at the bottom).

Range 1/8 is for slow clocks, and in fact I am thinking of making them even slower. I like very fast arpeggios running through very slow filter sweeps, though honestly when they’re that slow you can’t tell if they’re synced or not anyway.

Range 2 is only for powers of 2 of the clock with very wide notches (for quickly hitting the mult/div required rather than dialing it in.)

Range C3 is the original range for clocked LFOs.

Thanks again for the correct procedure! This has been very fun to do.

``` //bgFMI static Ratio kRatios[3][20] = { {//RANGE 1/8 = slow { 0.00390625f, 256 }, { 0.0052083f, 192 }, { 0.0078125f, 128 }, { 0.0104166f, 96 }, { 0.015625f, 64 }, { 0.0208333f, 48 }, { 0.03125f, 32 }, { 0.0416666f, 24 }, { 0.0625f, 16 }, { 0.125f, 8 }, { 0.125f, 8 }, { 0.1666666f, 6 }, { 0.25f, 4 }, { 0.3333333f, 3 }, { 0.5f, 2 }, { 0.6666666f, 3 }, { 0.75f, 4 }, { 0.8f, 5 }, { 1, 1 }, { 2.0f, 1 }, }, {//RANGE 2 = powers of 2 only with wider ‘notches’ { 0.03125f, 32 }, { 0.0625f, 16 }, { 0.0625f, 16 }, { 0.125f, 8 }, { 0.125f, 8 }, { 0.25f, 4 }, { 0.25f, 4 }, { 0.5f, 2 }, { 0.5f, 2 }, { 1, 1 }, { 1, 1 }, { 2.0f, 1 }, { 2.0f, 1 }, { 4.0f, 1 }, { 4.0f, 1 }, { 8.0f, 1 }, { 8.0f, 1 }, { 16.0f, 1 }, { 16.0f, 1 }, { 32.0f, 1 }, }, ```

```{//RANGE C3 = normal { 0.0625f, 16 }, { 0.125f, 8 }, { 0.1666666f, 6 }, { 0.25f, 4 }, { 0.3333333f, 3 }, { 0.5f, 2 }, { 0.6666666f, 3 }, { 0.75f, 4 }, { 0.8f, 5 }, { 1, 1 }, { 1, 1 }, { 1.25f, 4 }, { 1.3333333f, 3 }, { 1.5f, 2 }, { 2.0f, 1 }, { 3.0f, 1 }, { 4.0f, 1 }, { 6.0f, 1 }, { 8.0f, 1 }, { 16.0f, 1 }, }, }; ```

You might consider that the button was already altering the behavior of the module:

• In the 1/8 and 2 position, the clock tracking algorithm is sensitive to phase (and will thus cause jitter on audio-rate signals).
• In the C3 position, the clock tracking algorithm is optimized for smooth tracking of audio signals (it effectively discards the phase of the input signal, only considering its frequency, and uses that extra freedom to generate a signal with a steady pitch).

So effectively, with your modification, you can no longer multiply by 3 the frequency of an external slow clock (only an audio tone, since the original list of dividers is now available only with audio-rate tracking).

1 Like