Explain that again, but slowly like I’m an idiot 
If you are doing a per sample call, you can’t vectorize your loop. But if you have fixed parameters (like delay), you can have the compiler generate SSE2/AVX instructions instead of the slow x87 ones.
If you do it per channel, each channel may have a different delay, so you can’t apply the same parameters. Besides you may have to load a cache line for each access instead of reusing the same one because of your data locality. So doing as much as possible on one channel brings more performance than doing one sample for each channel for each set of parameters.
(and I don’t agree on the idiot part )
Oh - i see. I was figuring with stereo processing it’d have two happy cache lines on the go one for each channel.
I think I’d be doing per-sample delay time changes anyway if I was allowing the user to modulate the delay time at any rate?
But I see where you are going here…
Though I’m thinking for my next project I@m going to go into using interleaved data so I can make better use of the SIMD instructions where I’m doing identical stereo processing (which is often).
Be aware that even interleaved may not bring you anything if you only have 2 channels (as SIMD instructions usually work with 4 or 8 samples at a time).
In the case of varying delays, you need to have the interpolation, and perhaps that in the case of the power of two buffer, you may be able to work something out indeed. Although I couldn’t find any reference to vectorized roundings, so it may be a lost cause for now.
For non-power of two, it’s too complicated to track the index in the circular buffer (IMHO).
This suggestion turned out to be essential as there were problems scaling up from mono to stereo.
Hi Daniel, I am writing a delay plugin that implements a method that looks basically exactly like what you suggest here…but I’m currently trying to debug the issue of artifacts coming from skipping delay times using a SmoothedValue (like in the rest of this threads posts.) Seems like the what solved Collin’s issues was using .getNextValue() at every sample rather than at every block. But with the addFrom and copyFrom methods used it doesn’t seem like there is a place to do that. Any thoughts on how to deal with smoothing if we’re not calculating the delay sample-by-sample?