* William Brent <[email protected]> [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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
