[PD] [convolve~] version 0.11 testing

[Peter P.]

* William Brent <william.brent at gmail.com> [2018-03-19 14:09]:
> 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