Hi, happy new year.
Here's a vanilla partitioned convolution abstraction https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip%E2%80%A6 https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip?dl=0&fbclid=IwAR3Sj1Cx8it5Tt8ne5miujaQxhgqlr1S2AuoyhGQzjQwofvR7OpUzhh9EgE
It is based on this http://tre.ucsd.edu/wordpress/?p=772 http://tre.ucsd.edu/wordpress/?p=772&fbclid=IwAR0cFSK7dKpsYc1tq1gH5nebQ0aSPLFhTOB-ztlsz0Fx0tbz9_tYwKAN4NE
what you think, is it working? Both objects on the help file take about 40% of my CPU power, but I'm on a wild machine
I made some changes on the original work by Tom Erbe. It is supposed to be more efficient because the FFT on the input is only done once! 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. And, well, it is made as an abstraction and all you need to do is give it the window size and the IR sound file name...
cheers
interesting thanks. I am on Pd 0.49.1 on Mac (10.11.6) and when I open the conv~-help.pd file I often (but not always!) get the following error in the Pd console:
while executing
("uplevel" body line 1354)
invoked from within
"uplevel#0 $docmds"
and sometimes some more, possibly having Pd crash. Anyone else?
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres porres@gmail.com wrote:
Hi, happy new year. Here's a vanilla partitioned convolution abstraction https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip%E2%80%A6
It is based on this http://tre.ucsd.edu/wordpress/?p=772
what you think, is it working? Both objects on the help file take about 40% of my CPU power, but I'm on a wild machine
I made some changes on the original work by Tom Erbe. It is supposed to be more efficient because the FFT on the input is only done once! 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. And, well, it is made as an abstraction and all you need to do is give it the window size and the IR sound file name...
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
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@gmail.com escreveu:
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
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@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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
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@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@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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
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.
cheers!
Quoting Alexandre Torres Porres porres@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@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@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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < porres@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
That's amazing, I was just discussing with Matt Barber about how to do a patch following Gardner's approach :)
that was gonna be my next step, and I can see how much more efficient it gets! I'll definitely check it out and follow that approach
cheers
Em ter, 8 de jan de 2019 às 19:54, Philipp Schmalfuß < philipp.schmalfuss@uni-weimar.de> escreveu:
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.
cheers!
Quoting Alexandre Torres Porres porres@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@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@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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres < > porres@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
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.PDFwith 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.cheers!
Quoting Alexandre Torres Porres porres@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@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@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@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@gmail.com> escreveu:
Hi, quick updates and developments over my weekend
> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre > Torres Porres < > porres@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
yeah, I also get lots of glitches and artifacts with a 64 minimum window. I have to increase the delay up to 50ms so I get rid of them, which is kinda bad, even though it seems incredibly efficient.
Brent is not using gardner's approach I assume. And what this does is that it increases the window over and over in the following partitions, this is why it gets so much lighter on the CPU
cheers
Em qua, 9 de jan de 2019 às 07:47, Roman Haefeli reduzent@gmail.com escreveu:
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.
cheers!
Quoting Alexandre Torres Porres porres@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@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@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@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@gmail.com> escreveu:
> Hi, quick updates and developments over my weekend > > > > On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre > > Torres Porres < > > porres@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2019-01-09 at 11:27 -0200, Alexandre Torres Porres wrote:
yeah, I also get lots of glitches and artifacts with a 64 minimum window. I have to increase the delay up to 50ms so I get rid of them, which is kinda bad, even though it seems incredibly efficient.
Just to clear: I'm not experiencing Pd glitches at any configured audio setting whatsoever. What I mean is the abstractions produces 'wrong' results when configured to 64. I don't understand enough to give any hint why 128 is still fine and 64 sounds off.
Brent is not using gardner's approach I assume. And what this does is that it increases the window over and over in the following partitions, this is why it gets so much lighter on the CPU
Yeah. From what I gather without reading William Brent's [convolve~]'s source code, is that it uses n partitions with same size. At least the printed number seems to suggest that. Thus, using a smaller delay leads to a significantly increased CPU load. With Gardener's approach, the penalty of a short delay is almost not noticeable.
Roman
hmm, weird, I don't seem to find problems...
Em qua, 9 de jan de 2019 às 12:10, Roman Haefeli reduzent@gmail.com escreveu:
On Wed, 2019-01-09 at 11:27 -0200, Alexandre Torres Porres wrote:
yeah, I also get lots of glitches and artifacts with a 64 minimum window. I have to increase the delay up to 50ms so I get rid of them, which is kinda bad, even though it seems incredibly efficient.
Just to clear: I'm not experiencing Pd glitches at any configured audio setting whatsoever. What I mean is the abstractions produces 'wrong' results when configured to 64. I don't understand enough to give any hint why 128 is still fine and 64 sounds off.
Brent is not using gardner's approach I assume. And what this does is that it increases the window over and over in the following partitions, this is why it gets so much lighter on the CPU
Yeah. From what I gather without reading William Brent's [convolve~]'s source code, is that it uses n partitions with same size. At least the printed number seems to suggest that. Thus, using a smaller delay leads to a significantly increased CPU load. With Gardener's approach, the penalty of a short delay is almost not noticeable.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
hmm, weird, I don't seem to find problems...
Aha? Even with attached test3.pd patch saved along the original test.pd patch? You can compare 64 to 128 and I get a glitchy tone with a frequency of 690 Hz (which seems to come from 44100/64).
Have you tried other IRs than the church.wav and IR.wav?
Roman
well, I was actually coming here to tell you that, by listening closely to it, I was in fact finding weird artifacts :)
Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli reduzent@gmail.com escreveu:
On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
hmm, weird, I don't seem to find problems...
Aha? Even with attached test3.pd patch saved along the original test.pd patch? You can compare 64 to 128 and I get a glitchy tone with a frequency of 690 Hz (which seems to come from 44100/64).
Have you tried other IRs than the church.wav and IR.wav?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1] I find the issue you're bringing up gets much more evident
Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli reduzent@gmail.com escreveu:
On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
hmm, weird, I don't seem to find problems...
Aha? Even with attached test3.pd patch saved along the original test.pd patch? You can compare 64 to 128 and I get a glitchy tone with a frequency of 690 Hz (which seems to come from 44100/64).
Have you tried other IRs than the church.wav and IR.wav?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
yes, i get the same glitchy tone, even worse with smaller blocksizes. I wasn't aware of this, thanks for the hint! will try to fix this
Quoting Alexandre Torres Porres porres@gmail.com:
Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1] I find the issue you're bringing up gets much more evident
Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli reduzent@gmail.com escreveu:
On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
hmm, weird, I don't seem to find problems...
Aha? Even with attached test3.pd patch saved along the original test.pd patch? You can compare 64 to 128 and I get a glitchy tone with a frequency of 690 Hz (which seems to come from 44100/64).
Have you tried other IRs than the church.wav and IR.wav?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Philipp, so, I checked in depth and revised your patch. Here's my take on it in a similar design of my last object.
I changed a lot of things and rewrote basically everything, so there might be something funny still and things may not match, but the basic stuff seem to be equivalent and the basic parameters like block size and delay seem to match.
anyway, this is also fully vanilla and the prototype is called [conv2~].
I am precomputing the FFT, so check it out, and also check the rest as I've changed much of your computations for something that's simpler I think.
here's the link: https://www.dropbox.com/s/z8l85y7p1knjv2i/conv2~.zip?dl=0
cheers
Em qua, 9 de jan de 2019 às 20:46, Philipp Schmalfuß < philipp.schmalfuss@uni-weimar.de> escreveu:
yes, i get the same glitchy tone, even worse with smaller blocksizes. I wasn't aware of this, thanks for the hint! will try to fix this
Quoting Alexandre Torres Porres porres@gmail.com:
Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1] I find the issue you're bringing up gets much more evident
Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli reduzent@gmail.com escreveu:
On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
hmm, weird, I don't seem to find problems...
Aha? Even with attached test3.pd patch saved along the original test.pd patch? You can compare 64 to 128 and I get a glitchy tone with a frequency of 690 Hz (which seems to come from 44100/64).
Have you tried other IRs than the church.wav and IR.wav?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Interesting stuff! However, I have hickups in the sound (dropouts) even though the CPU load is around 20% only. What might cause them?
m.
On 11.01.19 04:14, Alexandre Torres Porres wrote:
Hi Philipp, so, I checked in depth and revised your patch. Here's my take on it in a similar design of my last object.
I changed a lot of things and rewrote basically everything, so there might be something funny still and things may not match, but the basic stuff seem to be equivalent and the basic parameters like block size and delay seem to match.
anyway, this is also fully vanilla and the prototype is called [conv2~].
I am precomputing the FFT, so check it out, and also check the rest as I've changed much of your computations for something that's simpler I think.
here's the link: https://www.dropbox.com/s/z8l85y7p1knjv2i/conv2~.zip?dl=0
cheers
Em qua, 9 de jan de 2019 às 20:46, Philipp Schmalfuß <philipp.schmalfuss@uni-weimar.de mailto:philipp.schmalfuss@uni-weimar.de> escreveu:
yes, i get the same glitchy tone, even worse with smaller blocksizes. I wasn't aware of this, thanks for the hint! will try to fix this Quoting Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>>: > Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1] I find > the issue you're bringing up gets much more evident > > Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli <reduzent@gmail.com <mailto:reduzent@gmail.com>> > escreveu: > >> On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote: >> > hmm, weird, I don't seem to find problems... >> >> Aha? Even with attached test3.pd patch saved along the original test.pd >> patch? You can compare 64 to 128 and I get a glitchy tone with a >> frequency of 690 Hz (which seems to come from 44100/64). >> >> Have you tried other IRs than the church.wav and IR.wav? >> >> Roman >> >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I'm investigating that as well, I get the same and my CPU is at about 10% only...
cheers
Em sex, 11 de jan de 2019 às 12:20, Max abonnements@revolwear.com escreveu:
Interesting stuff! However, I have hickups in the sound (dropouts) even though the CPU load is around 20% only. What might cause them?
m.
On 11.01.19 04:14, Alexandre Torres Porres wrote:
Hi Philipp, so, I checked in depth and revised your patch. Here's my take on it in a similar design of my last object.
I changed a lot of things and rewrote basically everything, so there might be something funny still and things may not match, but the basic stuff seem to be equivalent and the basic parameters like block size and delay seem to match.
anyway, this is also fully vanilla and the prototype is called [conv2~].
I am precomputing the FFT, so check it out, and also check the rest as I've changed much of your computations for something that's simpler I
think.
here's the link:
https://www.dropbox.com/s/z8l85y7p1knjv2i/conv2~.zip?dl=0
cheers
Em qua, 9 de jan de 2019 às 20:46, Philipp Schmalfuß <philipp.schmalfuss@uni-weimar.de mailto:philipp.schmalfuss@uni-weimar.de> escreveu:
yes, i get the same glitchy tone, even worse with smaller blocksizes. I wasn't aware of this, thanks for the hint! will try to fix this Quoting Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>>: > Hi, I tested your patch with the [phasor~ 5] and with [phasor~ 1] I find > the issue you're bringing up gets much more evident > > Em qua, 9 de jan de 2019 às 14:03, Roman Haefeli <reduzent@gmail.com <mailto:reduzent@gmail.com>> > escreveu: > >> On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote: >> > hmm, weird, I don't seem to find problems... >> >> Aha? Even with attached test3.pd patch saved along the original test.pd >> patch? You can compare 64 to 128 and I get a glitchy tone with a >> frequency of 690 Hz (which seems to come from 44100/64). >> >> Have you tried other IRs than the church.wav and IR.wav? >> >> Roman >> >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
It freezes my windows machine if opening on Pd-64bit.
On Pd-32bit I get the console spitting multiple:
pd: resizebytes() failed -- out of memory
:(
Are you sure [clone ./convpartition 688 church.wav 1007] is correct?
Mensaje telepatico asistido por maquinas.
On 1/8/2019 1:52 PM, Alexandre Torres Porres wrote: 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@gmail.commailto:porres@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@gmail.commailto:porres@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@gmail.commailto:porres@gmail.com> escreveu: Hi, quick updates and developments over my weekend
On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <porres@gmail.commailto:porres@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@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em ter, 8 de jan de 2019 às 15:40, Lucas Cordiviola lucarda27@hotmail.com escreveu:
Are you sure [clone ./convpartition 688 church.wav 1007] is correct?
yup, what do you mean?
Anyway, I'm using dynamic patching because the patch calculates how many partitions we need fro the IR size and window size. Then I create the [clone] object with the ./convpartition abstraction and make the connections. The number of instances of clone is the number of partitions "688" when loading church.wav as an IR with a window size of 512. The last number (1007) is actually "$0", which I use to send information to the instances of ./convpartition abstraction (inside the abstraction there's a [r $3-size] object.
So yeah, all looks nice...
Anyway, if [clone] allowed us to set the number of instances via a message, everything would be much simpler and no need for dynamic patching.
On Pd-32bit I get the console spitting multiple:
*pd: resizebytes() failed -- out of memory*
:(
that sucks :/ - I have no idea why, I've never seen the "*pd: resizebytes() failed -- out of memory*" message.
It freezes my windows machine if opening on Pd-64bit.
weird :/
-
Alexandre Torres Porres -
Giulio Moro -
Lucas Cordiviola -
Max -
Philipp Schmalfuß -
Roman Haefeli