Hello,
The attached patcher functions as expected with the factory FFT settings (1024 -1 -1) for the fluid.bufpitch~ object which is in the “p analysis” subpatcher . It also functions correctly with window set to 512 samples (512 -1 -1). However, with a setting of 2048 (2048 -1 -1) or 4096 (4096 -1 -1), the patcher crashes as soon as the analysis is triggered (which happens automatically when a sound folder is chosen).
Tested with FluCoMa 1.0.5 under Max 8.5.2 under Windows 10(64bit).
Bug 2022-12-30_1.zip (12.5 KB)
Argh, I thought we’d finally quashed all the nasties to do with this.
To avoid the crash, explicitly supply your maximum possible fft size in the box when you make the object as a 4th entry to the fftsettings: e.g.
@fftsettings 1024 -1 -1 8192
will ensure that you have the resources needed to go up to a window / fft size of 8192. It will still crash (at the moment) if you go over that (and note that there’s a global maximum fft size of 65536 – the enforcement might also be flaky for this). We’ll fix the crash in an update.
You would need to do this in any case, except that what’s supposed to happen is that the window / fft size are clipped to a maximum inferred at object creation time. What’s actually happening is that resources are allocated on the basis of this inferred maximum but the clipping isn’t happening, so it then tries to process into memory it shouldn’t. The default value for the maximum is -1 which means (as with the fftsize) ‘use the window size’ – that is, the default settings 1024 -1 -1 -1 mean that the object should be limited to a upper limit of 1024 for the window / fft size after creation.
Why do it this way, given the inconvenience of having to state up front that you’ll want to use a bigger fft size?
The trade off is between how resource-hungry some processes are in terms of memory needs in relation to the maximum possible values of certain attributes versus how often, in practice, people actually want to increase the fft size after an object is created. The latter seemed to be pretty rare, whilst complaints about the memory demands of some objects (pitch among them) based on rarely-used maximum sizes weren’t rare.
In a less imperfect world, it would be possible to treat the buf* versions of real-time objects more leniently in this regard (by remaking the internals with a new maximum if the old limit is busted after the object is made), but things aren’t that clever yet.
2 Likes
oh I need to add some buf* window tests in the release testing dance… in SC they get pulled from the call, so we never had that combination before sorry I let that slipped!
1 Like
I’ve pushed a fix for this, so it should no longer be an issue in the next release
2 Likes