What does Tides' Range switch do in Clocked/PLL mode?

Once in clocked/PLL mode, tapping the Range (B) switch, changes the corresponding LED from green to amber to red. Couldn’t find any mention of what that is changing pertaining to PLL mode in the manual.

From what I can tell, green and amber are the same? Once the LED is red, changing the frequency ratio takes longer to lock in, or something like that. I’m a bit confused. Anybody have any insight on what this is doing?

I had the same question a while back… since then, I read the code and got the answer :slight_smile:

It does the same as in non-PLL mode: switch between rendering the wave at low, mid or high frequency. Tides has different routines to render control-rate waves, which are rendered at 6kHz with no anti-aliasing measure, and audio-rate waves, rendered at 96kHz (IIRC) with anti-aliasing. Incidentally, the code for PLL in each of these two routines is slightly different: it takes longer for the frequency to lock at audio-rate. I don’t know why Olivier made this choice.

The mode obviously also affects the range of the frequency knob and V/oct input, which means that the frequency attainable will be adapted to the routine chosen.

But in PLL mode, there is no restriction on the frequency attainable. So if you’re locked at, say, 1kHz, switching range will change the routine called. Especially, when using the control-rate routine (LED green or unlit), you’ll be able to hear some aliasing, which shouldn’t be possible otherwise.

Does this answer your question? Olivier, did I get this right?

Yes it does, thank you! My guess was pretty much what you just laid out, but the difference in locking made me unsure of what was going on.

The biggest difference is the algorithm used for following the frequency of the signal present on the “clock” input.

  • At low and medium ranges, it uses a pattern prediction algorithm, to allow the clock to be locked onto rhythmic patterns with shuffle or even with missing pulses.
  • At the highest range, it uses an algorithm optimized for audio.

> I don’t know why Olivier made this choice.

You will see aliasing on the clock input. For example, if your input signal has a frequency of 95.9 Hz, your period readings (at 48kHz) will be 500, 501, 500, 501, so you cannot directly “trust” a reading, but have to average several of them over time - hence the slower tracking time.

Note to myself (for future designs): a sync or clock input really benefits from being a proper audio ADC input, so that you can interpolate the zero-crossing position and directly get a fractional value of the period.

> You will see aliasing on the clock input.

But of course! Thanks Olivier for the clarification.