Re: PartConv with non-uniform block size?

Aha,  I will try to check that out, thanks!

The other idea, having several running at once, is also worth considering, but I have a hunch that doing all of that within the language would not only be a coding headache but possibly introduce more inefficiency in calculating the IR spectra.  One part of what I'm trying to do involves a continually updating IR.

Thanks for the ideas!

Best,

Patrick

________________________________
From: [email protected] <[email protected]> on behalf of [email protected] <[email protected]>
Sent: Thursday, March 11, 2021 7:17 PM
To: [email protected] <[email protected]>
Subject: Re: [sc-users] PartConv with non-uniform block size?

Stefan Kersten's VEPConvolution from the rendering engine for the virtual Varese project might be worth a look:
https://github.com/kaoskorobase/skUG
It is a low-latency convolution plug-in, but comes with little documentation.

Best
N

I couldn't find previous discussion in an online archive quickly, but from my own local copy:

21st October 2008 on sc-dev:

Hi Stefan,
 I was under the impression that your VEPConvolution wasn't being released (we had discussions about that before off list before). However, I just managed to find the source on your site; builds fine (well, except for missing CompareAndSawp in VEPRingBuffer.h, easy get around), works well! So I'd encourage you to release this officially soon!

I was aware of the non-uniform partitioning schemes, thought I'd start with uniform. I've read papers by Adriaensen and Torger/Farina, but not accessed the original Gardner ( no AES library subscription). I know that LakeDSP patent is overturned in EU, so no issues for those not in North America ;  )  The bruteFIR/SIMD vector processor tricks also seem worthwhile; I see from your project code how you've had to compiler directive to cover different processors/operating systems. I'm also very interested to see your use of custom UGen commands, the first real working example I've seen of that.

In terms of comparison, let me say up front that I'd be perfectly happy if a tidied version of your VEPConvolution went into the sc source (I'm not going to stand by PartConv obsessively either, happy to make way)! For longer IRs especially (2 seconds plus), it has a much lower average load. However, you're right that the Peak CPU is worse. Did you amortise the spectral multiplications over blocks?

One issue is that the plug-in cmd based initialisation (whilst cunning)  is a large CPU spike; this is why I made a new buffer command to prep the IR partition spectra. Maybe that could help tidy up your plug-in?

best
Nick


On 11 Mar 2021, at 18:43, [email protected]<mailto:[email protected]> wrote:

I’m shooting from the hip here, but couldn’t you use multiple copies of PartCov in the same synth, the first at 512 fft size with the first 512 samples of the impulse, the next at 1024 with the next 1024 samples of the impulse, and the last at 2048 with the rest of the impulse?

To be clear, I have not tried this, but it works in my mind.

Sam

On Mar 11, 2021, at 4:28 PM, [email protected]<mailto:[email protected]> wrote:

Just wondering if there is an already existing SC implementation of a partitioned convolution with non-uniform blocks (short at the beginning and long at the end of the impulse response, to split the difference between the low latency of short blocks and the efficiency of longer ones.)  PartConv uses uniform block sizes, so you are stuck with the latency (2048 samples if you use an fftsize of 2048, etc.)

For clarification, I mean what is described here:   http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF
Department of Computer Science and Engineering - HKUST<http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF>
Created Date: 10/29/2006 2:54:00 AM
www.cs.ust.hk<http://www.cs.ust.hk/>