I love Chronoblob2. It’s my favorite delay module for Rack. But it does eat the CPUs. I wonder if there is any chance for optimization? Of if that’s just “the way it is” for such a device … ?
Is the source code available? If so, do you have a link to it?
Closed source, maybe. In which case, I guess it’s up to @AlrightDevices.
And I want to stress that I am not disparaging it in any way, except that I have a weak PC, and I need to be conscious of my cycles, lest I be poppin; and clickin’.
There are a lot of plugins that use WAY more CPU than they need to. For example, our Mixer-8 is a clone of the AS mixer, but uses 10X less CPU. For most simple mistakes, the tips we published are all you need to fix it. Without seeing the source to the delay in question I can’t say if it’s using too much CPU for what it does. Here’s a link to our old paper in this topic: https://github.com/squinkylabs/SquinkyVCV/blob/master/docs/efficient-plugins.md
I’m getting 7-10%, typically, but I guess I will live with it. I really like the way it works … and looks. And that aspect is very important to me, too.
Have you asked the developer if they can improve the performance? No reason to live with it if can be easily improved.
Currently the module operates on single samples, which creates a lot of processing overhead. So I tried changing it to operate on blocks of samples instead, which reduced the CPU usage by about half. The only drawback is latency of response to control signals, and latency in the dry signal. But that’s exactly how the hardware module works, so I’m thinking it’s a good idea to push this change.
Well, you’re the boss. Do whatever you think is best for the module.
My two cents: if we are talking about small latencies (1ms range), then I don’t see a problem with that. If anything, just report via some documentation how many samples or ms are needed to compensate for it at various sample rates. This way, people who go nuts about getting everything exactly lined up can manually compensate using other modules.
Perhaps another option: you could also try to build a right-click menu option to go from High CPU/Zero Latency Mode (current) to Low CPU Mode. It uses about 5% on my desktop, which isn’t absurd, but I definitely feel the CPU hit on my laptop.
But why does a “simple” delay need to use more than 1% in the first place? afaik it’s a single delay line without elaborate EQ, yes? Is it using a 128 point FIR interpolation filter? Is the CV lag calculation being done every sample? Just doesn’t seem like it should be that heavy, nice as it is.
@funkybot I’m using 16 sample blocks, so only 1/3 ms latency at 48k, and less at higher sample rates. I did consider having the option to switch on ‘low-latency’ mode but that would mean quite a bit of code refactoring work.
@Squinky It’s not really a “simple” delay. It’s got sample interpolation, an input compressor, a couple of PLLs for the time sync, and some pretty complex signal routing to allow seamless transition between the 4 delay modes.
@InductiveOne Totally agree. And thanks for the support!
16 samples? Yeah, just go for it. I doubt anyone would ever notice it and it’s easy enough to compensate for if absolute sample perfect timing is needed.
Agreed. Actually it already does latency compensation, just like the hardware module does.
Thanks for indulging this request, Tyler.
It’s also the only delay I know of that has 2 modes.
1 mode where you can hear the pitch change when the tempo is shifted.
And the other mode where the pitch is not affected when shifting tempo.
I haven’t pushed this update yet because I really need more people to test it. Does anyone want to volunteer? You would just use the plugin as normal for a week or so and make sure no weird bugs have been introduced by the update.
I will test it, just let me know how I get it.
Thanks! I’ll DM you.
Happy to test!