Looking through the Fundamental modules for examples of dsp::ClockDivider usage as pertaining to module lights, I’ve noticed that different modules use a different division. Some are as low as 16 (VCO, Viz) and others as high as 512 (Merge, Split).
What’s best practice here for determining the division setting?
It seems to me that anything resulting in a higher rate than Rack’s frame rate is unnecessary, so the ideal division would be something like setDivision(x) where x = SampleRate/FrameRate. Even at 44.1kHz with Rack’s maximum frame rate of 60hz, that yields x = 735 which is higher than the largest division seen in Fundamental.
But maybe that’s all beside the point, and the better question to ask is: why update the lights on the DSP thread at all, rather than using the UI thread?
That’s the dsp thread telling the ui thread what to draw, it’s not the dsp thread actually drawing. People pick different rates for different reasons. I usually decrease the rate until it’s not affecting my cpu utilization any more. If that’s 4 or 16 I use that. Even if it is higher than necessary. Also, people often use one divider for both lights and looking at knobs so the knobs may want the 4. It’s just “whatever works”. Al least that’s what I do.
Is there any advantage to updating the lights’ brightness (the value, not the actual drawing) more often than SampleRate / (SampleRate / FrameRate)? Maybe the CPU savings would just be so small that it’s not worth thinking about.
In Rack v2, the lowest engine rate will be 11.025 kHz, so with that setting, if I understand the mechanics correctly, modules with a light divider ~256 or higher won’t update their lights at 60fps even if the Rack frame rate is set to 60hz.
my opinion - and it is only that - is that in most cases it just doesn’t matter. But the real answer is that you must measure this stuff and see in YOUR plugin what the effect is. For more on that, this paper has been pretty popular: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/efficient-plugins.md
If you update the light value less often than a frame, the light would look laggy.
If the value updates very fast (as with VCO-1 and Viz), using Light::setSmoothBrightness() often will compute a good approximation of the signal’s RMS.
For 16 frames, signals up to 44100 Hz / 16 = 2700 Hz will have a nice consistent brightness.
If the RMS isn’t important (as with Merge/Split), updating it every 512 frames is fine, since it’s the largest power of 2 less than 44100 Hz / 60 Hz = 735.