That's something I actually did for this round and then abandoned. I had it taking an array name as the 2nd argument (so it wouldn't break backward compatibility), and then automatically running the IR analysis routine at the end of object creation. The problem I couldn't come up with a good solution for was that the IR array won't necessarily be loaded with samples before [convolve~] creates. So in a scenario where you have a patch that loadbangs an IR .wav file into an array as the patch starts up, [convolve~] tries to analyze the IR array given as a creation argument before the .wav is loaded, and ends up analyzing an array full of zeros.
I started on a strategy where I set a clock to wait a certain amount of time before running the analyze routine at the end of object creation, but that seemed like bad design. Anyone have any suggestions for this problem?
Hm, what about letting users load a frequency domain IR into two arrays (real and imaginary) themselves? This can be done weill in advance, possibly with the help of an abstraction that calculates the spectrum in a reblocked subpatch, and would hence circumnavigate the race condition.
Just my two cents (one real, one imaginary), P