>> Also, since convolution is much more efficient around block sizes of >> 256 or 512, perhaps I should default to one of these, buffer a little, >> and have a "runatpdblocksize" message or somesuch? > > I still have not understood if/how the user can set the duration of the > first partition of you partitioned convolution, and how these partitions are > structured in their (possibly increasing) sizes. Since this first paramter > will define the latency-vs-CPU tradeoff it should not be preset by the > developers.
I guess this is what I was asking. I support a few "block pattern" partitioning schemes (they're pluggable, its very easy to add a new one), I could export the choice of these to the end-user, including the option of what block size to start with - the minimuum block size of course being Pd's current block size. My guess is, in the wild, most "pd users" are using Pd-extended, and ships with a 20msec default delay (dunno if this is inherited from vanilla, or overridden by the distro, but either way, same effect: most pd installs probably run at 20msec). I'm all for allowing configuration of these important parameters, but I want the external to do something sane out of the box. My guess is 64 sample blocks (~20msec) is more abusive CPU-wise than most people expect out-of-the-box, so I'm probably going to default to a partitioning that looks like: 256, 512, 1024, 2048, 4096, 4096, ..., 4096 And allow people to set a different partitioning scheme, including reducing the initial partition size, if they want. That make good sense? -Seth > > P. > > PS: Pd and Pd-extended use the same core, audio engine. You might want to > consider Pd-extended as vanilla Pd with a folder full of precompiled > externals. > >> >> On Mon, Apr 4, 2011 at 7:48 PM, Seth Nickell <[email protected]> wrote: >>>>> >>>>> 2) Anyone have requests for features/api? Its currently simplistic: >>>>> - takes a "read FILENAME" message, loads the file, does a test >>>>> convolution against pink noise to normalize the gain to something sane >>>> >>>> Is this done within the main Pd audio thread? >>> >>> The convolution engine has support for doing it either on the calling >>> thread, or a background thread. I'm thinking of default to a >>> background thread. That seem like the right move? >>> >>>>> - caches the last N impulse responses, as the test convolution >>>>> takes a little time >>>>> - allows setting the cache size with a "cachesize N" message >>>> >>>> To make sure I understood this: cachesize is not the size of the first >>>> partition of the partitioned convolution, but the cache that tries to >>>> avoid >>>> audio dropouts when performing the test convolution? >>> >>> The convolution engine can swap-in a pre-loaded ('cached') IR in >>> realtime without glitching... but it means keeping 2x the Impulse >>> Response data in RAM. To keep the default API simple but useful, I'm >>> defaulting to caching only the last 5 impulse responses in RAM. >>> "cachesize N" lets you increase that number.... lets say in a >>> performance you wanted to use 30 different impulse responses and you >>> have 2GB of ram... should be nbd. >>> >>>>> - disable normalization with "normalize 0" or "normalize 1" >>>> >>>> Yes, disabling this could be a good idea! You could also add a "gain >>>> 0-1" >>>> message for manual control. >>> >>> Its worth noting that impulse responses are usually whack without gain >>> normalization.... like factors of hundreds to millions off a usable >>> signal. >>> >>>>> Features I'm considering (let me know if they sound useful): >>>>> - load from an array instead of from disk (no gain normalization?) >>>> >>>> Very good. >>>>> >>>>> - It wouldn't be hard to enable MxN convolution if that floats >>>>> somebody's boat. >>>> >>>> I am sure if you come up with a convolution as efficient and flexible as >>>> jconv by Fons within Pd, then soon a multichannel use and hence request >>>> will >>>> come up fast. >>> >>> I'd be interested in what flexibility means in this context, it might >>> give me some good ideas for features to add. Efficiency-wise, last >>> time I benchmarked its more efficient than jconv, but the difference >>> is offset by less graceful degradation under CPU load (I convolve in >>> background threads to preserve realtime in the main thread while >>> avoiding an irritating patent that's going to expire soon...). >>> >>> WRT to Pd's audio scheduling... are Pd signal externals held to >>> realtime or can my dsp call vary the number of cycles it takes by 100% >>> from call to call? VST seems to do ok with this, but AudioUnits get >>> scheduled to run at the very last instant they possibly could. If Pd >>> can have some variance, I can drop the threads and improve the >>> external's degradation under high CPU load. >>> >>> thanks for the feedback (also, is the best list for this kind of >>> feedback?), >>> >>> -Seth >>> > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
