[PD] Making a Realtime Convolution External

[Seth Nickell]

>> 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 <seth at meatscience.net> 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
>>>
>