[PD] vanilla partitioned convolution abstraction

Wed Jan 9 10:37:22 CET 2019

Hi

It performs even better than William Brent's [convolve~] external, even
with small delays. When both set to 256, I get 9% load vs. 26%.

However, I get artefacts with a setting of 64 samples. When loading the
various IRs, the result sometimes sounds glitchy. Setting of 128 or
higher are always fine, regardless of IR.

Also with the church.wav and a setting of 64 you can hear the glitches
by feeding it a [phasor~ 5].

BTW: I can load many instances just fine (Pd 0.49 on Linux amd64)

Thanks for sharing!

Roman

On Tue, 2019-01-08 at 22:54 +0100, Philipp Schmalfuß wrote:
> Hi Alexandre,
> 
> i made a pd-vanilla abstraction for real time convolution a while
> ago.  
> it is part of a collection of pd abstractions that i am planning to  
> share with the community, soon...
> it loosely follows gardner's approach  
> http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF
> 
> with this, i get about 8-10% cpu-load with the church-IR and 64  
> samples min. fft-blocksize on an old lenovo t430 running linux.  
> however, i get the ugly clicks when i have more than one instance
> of  
> the abstraction running and on windows it causes pd-crashes, so i'm  
> not perfectly happy.
> i think it could be improved a lot by precomputing the IR like in
> your patch.
> 
> https://we.tl/t-HYsWQww10V
> 
> cheers!
> 
> Quoting Alexandre Torres Porres <porres at gmail.com>:
> 
> > Bug, for some reason, you may need to recreate the object so the
> > sound
> > comes out. I have no idea yet why...
> > 
> > Em ter, 8 de jan de 2019 às 14:52, Alexandre Torres Porres <
> > porres at gmail.com>
> > escreveu:
> > 
> > > oops, I hads uploaded the wrong file, here's the hopefully
> > > correct and
> > > last word on it
> > > 
> > > https://www.dropbox.com/s/05xl7ml171noyjq/convolution~.zip?dl=0
> > > 
> > > and my CPU load is actually at about 57%, not 50%
> > > 
> > > The last file I uploaded was using a compiled object to perform
> > > the
> > > complex multiplication and that helped a little with the
> > > efficiency. I'm
> > > gonna use it for my non vanilla abstraction that I'm bringing
> > > into my ELSE
> > > library.
> > > 
> > > cheers
> > > 
> > > 
> > > 
> > > Em ter, 8 de jan de 2019 às 14:13, Alexandre Torres Porres <
> > > porres at gmail.com> escreveu:
> > > 
> > > > Ok, here's the new deal...
> > > > 
> > > > https://www.dropbox.com/s/l69gzv98g3th5d1/conv.rev~.zip?dl=0
> > > > 
> > > > there are two subpatches for testing, one is light with a
> > > > relative big
> > > > window partition (1024) and a short Impulse Response (2 secs).
> > > > 
> > > > The other is quite heavy, it's an 8 sec long IR with a window
> > > > size of
> > > > 512! This one takes just a bit over 50% of my CPU power, and
> > > > I'm on a last
> > > > generation macbook pro (2.6Ghz processor)... but I need to
> > > > increase the
> > > > Delay (msec) from 5 to 10 in the audio settings, otherwise I
> > > > get terrible
> > > > clicks!
> > > > 
> > > > William Brent's convolve is ridiculously much more efficient,
> > > > the same
> > > > parameters take about 14% of my CPU power and I can use a delay
> > > > of 5 ms in
> > > > the audio settings.
> > > > 
> > > > But anyway, this is useful for teaching and apps that implement
> > > > a light
> > > > convolution reverb (short IR/not too short window) need pure
> > > > vanilla
> > > > (libpd/camomille and stuff)
> > > > 
> > > > Cheers!
> > > > 
> > > > Em dom, 6 de jan de 2019 às 14:25, Alexandre Torres Porres <
> > > > porres at gmail.com> escreveu:
> > > > 
> > > > > Meanwhile, I deleted the original file so people can't get it
> > > > > anymore :)
> > > > > 
> > > > > Em dom, 6 de jan de 2019 às 14:16, Alexandre Torres Porres <
> > > > > porres at gmail.com> escreveu:
> > > > > 
> > > > > > Hi, quick updates and developments over my weekend
> > > > > > 
> > > > > > 
> > > > > > > On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre
> > > > > > > Torres Porres <
> > > > > > > porres at gmail.com> wrote:
> > > > > > > 
> > > > > > > what you think, is it working?
> > > > > > 
> > > > > > 
> > > > > > So, the patch/algorithm was wrong and I've fixed
> > > > > > 
> > > > > > 
> > > > > > > Both objects on the help file take about 40% of my CPU
> > > > > > > power, but I'm
> > > > > > > on a wild machine
> > > > > > > 
> > > > > > 
> > > > > > I was able to do a few more things and make it much more
> > > > > > efficient
> > > > > > 
> > > > > > 
> > > > > > > I tried the idea of having each partition work with FFT
> > > > > > > saved on
> > > > > > > tables, so we wouldn't need to perform FFTs in different
> > > > > > > instances of
> > > > > > > clone, but that doesn't seem to be possible.
> > > > > > 
> > > > > > 
> > > > > > This is because things were wrong, like I said, now that
> > > > > > I've fixed it,
> > > > > > that was possible.
> > > > > > 
> > > > > > But my current version is not vanilla anymore, as I'm
> > > > > > developing this
> > > > > > object to include it in my "ELSE" library. Once I'm done
> > > > > > I'll try to make
> > > > > > another vanilla compatible abstraction and re share it!
> > > > > > 
> > > > > > Cheers
> > > > > > 
> 
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190109/48d12a99/attachment.sig>