And to make things clearer, not all IRCAM oscillators are that CPU intensive. The ones that are (IRCAM Stretch and Scrub) are based on IRCAM's enhanced PhaseVocoder called SuperVP. Usually time-stretch / pitch-shift of that quality can't run in real-time but they've heavily optimised it to the point that we can afford to make it real-time. It definitely won't allow a very big polyphony, but that would be a pity not to provide it just because the available polyphony isn't as high as usual.TrekStar wrote:-may we hope for an optimized CPU behaviour or do you persist on your Argument "good Sound Quality Needs CPU power"...which does not really help. do you intend to work further on that Point?
On top of that, it requires FFT analysis / synthesis which means that the CPU cost isn't uniformly distributed in time (similarly to what happens in an FFT-based convolution reverb) so if you experience dropouts especially at low blockSize, it's usually not because the CPU can't handle it on average, but because the peak CPU costs is bigger than the time available for this particular block.
Finally usually FFT processing also means there's a latency because data has to be buffered before computing the FFT. But because we use it in a MIDI triggered context, latency is not an option, so on the first note trigger we have to process for example 2048 samples even if the current blockSize is only 128, it makes the non-uniform CPU cost more salient.
I hope having such technical details will help people using it wisely, and be a little more indulgent with CPU cost. It's best to know when and how to use it. In many cases using IRCAM granular or the regular Stretch OSC could do the job, but if you need higher quality pitch-shift/time-strech, then there's always a price to pay.
After all we don't expect a convolution reverb to be runned per-voice.

