Bugs with [limi~] lookahead
Hi folks,
I am on MacOS Big Sur 11.2.2, and there seem to be something seriously wrong with the [limi~] object and derivates [mc.limi~] and [mcs.limi~].
Changing the lookahead parameter is not causing any difference in the output.
It is impossible to get the output to be delayed more than one sample, and therefore no lookahead can be applied. It doesn't matter how big of a lookahead buffer you create when you instantiate the object. The only (undesirable) thing that the lookahead parameter does is to cause extreme spikes in the CPU usage. That's clearly visible in the Audio Status window.
The attached patch should reproduce the behavior.
Definitely not usable for me.
Can someone double check that?
Thanks
- Luigi
I can confirm the patch is showing the issue exists as you mentioned: increasing lookahead causes severe CPU spikes(doesn't seem to enact any actual lookahead).
I'd also like to add, i found a serious problem with limi~ as i was trying to use it many times last year where audio would suddenly click/pop loudly and then i could not get audio output unless i deleted and reinstantiated the limi~ object(turning audio on/off did not fix the problem...it's the same exact audio result that happens if you get a biquad~ to blow up, except limi~ has no 'clear' message), so it's proved unusable for me as well thus far.
Unfortunately, i could not figure out any reliable way to track my 'audio blow-up' issue, i was just creating improvised synthesis algorithms using many gen~ patchers in the patch among regular MSP objects...(my first guess was something to do with the dc blocking feature but trying it either way didn't seem to isolate the issue any better - i was not working with the 'lookahead' value at all, though... and i was trying limi~ as the final limiter before the output... although, there might have been a live.gain~ slider between the limi~ and the ezdac~).
Anyways, just confirming and providing some other information about weirdness of limi~, overall.