Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

On Sat, 2019-01-12 at 22:56 -0200, Alexandre Torres Porres wrote:
> Em sex, 11 de jan de 2019 às 19:25, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
> > So it seems this delay scheme needs to be revised, and maybe that's
> > why the minimum window size of 64 gives us some weird artifacts!
> > 
> 
> Actually, based on another thread I opened here on the list, it seems
> the minimum hop size for an overlap needs to be 64, so [block~ 64 2]
> wouldn't really work... this means that starting with a window of 64
> samples could raise issues, hence it might be the actual culprit! 

I haven't fully grasped your patch illustrating the issue yet, but you
seem to have identified the problem. Well done! I'm already totally
happy with the partitioned convolutions presented here and with the
current minimum delay of 128 samples. I'm curious, though, whether it's
possible to maintain correct results with smaller delays by treating
smaller block sizes differently.

Roman 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

I've been investigating more throughly about how latency works in reblocked
audios. This is because I just took the example from Philipp and copied the
scheme, but I wasn't sure or convinced it was correct.

The idea is that we start with a minimum window size (say 64, which should
be the minimum size) and have pairs of the same size that increase by a
factor of two. So, we get something like: 64 / 64 / 128 /128 / 256 / 256
and so on... until we reach a maximum window size.

So, if the first window is a block of 64, then it has no latency
whatsoever. Now there's a second 64 window size with a delay of 32 samples,
why? I'd first expect it to be delayed by 64 samples. But, as it turns out,
it seems we can just have a window size of 128 next, cause that will in
fact already promote a latency of 64 samples! I thought the delay would
always be the block size, but it's actually the block size -64!!!

So it seems this delay scheme needs to be revised, and maybe that's why the
minimum window size of 64 gives us some weird artifacts!

Anyway, moving on, the third and fourth window size are then 128, but the
first one gets no delay and the second one is delayed 64 samples - the
delay is always half the block size and only for the latter window of a
same size pair... it just doesn't seem right.

cheers



Em sex, 11 de jan de 2019 às 14:16, Alexandre Torres Porres <
por...@gmail.com> escreveu:

> Yeah, I was suspecting the very very large FFTs were bad. I was
> considering maxing out to something quite smaller than 2ˆ20, I guess
> windows no bigger than 2ˆ15 should be allowed - I could try even something
> like 8192 (2ˆ13) as the maximum.
>
> Em sex, 11 de jan de 2019 às 13:30, Giulio Moro 
> escreveu:
>
>> (sent this to the list but didn't get through)
>> Non-uniform load in the audio callback, due to the larger FFTs happening
>> sporadically, I'd guess. This means that, while on average the CPU load is
>> low, in the worst-case (when a long FFT is performed) your audio callback
>> takes more time to execute than there is time available, thus causing
>> glitches. Increasing Pd's delay (internal buffering) should fix that.
>>
>> Giulio
>>
>>
>> On Friday, 11 January 2019, 15:27:40 GMT, Alexandre Torres Porres <
>> por...@gmail.com> wrote:
>>
>> 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 
>> 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ß
>> >> > >> > 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 > >> >:
>> >>
>> >>  > 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
>> >> mailto:reduz...@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
>> >>  >>
>> >>  >
>> >>
>> >>
>> >>
>> >> 

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

Yeah, I was suspecting the very very large FFTs were bad. I was considering
maxing out to something quite smaller than 2ˆ20, I guess windows no bigger
than 2ˆ15 should be allowed - I could try even something like 8192 (2ˆ13)
as the maximum.

Em sex, 11 de jan de 2019 às 13:30, Giulio Moro 
escreveu:

> (sent this to the list but didn't get through)
> Non-uniform load in the audio callback, due to the larger FFTs happening
> sporadically, I'd guess. This means that, while on average the CPU load is
> low, in the worst-case (when a long FFT is performed) your audio callback
> takes more time to execute than there is time available, thus causing
> glitches. Increasing Pd's delay (internal buffering) should fix that.
>
> Giulio
>
>
> On Friday, 11 January 2019, 15:27:40 GMT, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
> 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 
> 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ß
> >>  >> > 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  >> >:
> >>
> >>  > 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
> >> mailto:reduz...@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
> >>  >>
> >>  >
> >>
> >>
> >>
> >> ___
> >> 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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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ß
> >  > > 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  > >:
> >
> >  > 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
> > mailto:reduz...@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
> >  >>
> >  >
> >
> >
> >
> > ___
> > 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

Re: [PD] vanilla partitioned convolution abstraction

[Max]

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ß 
> 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 mailto:por...@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
mailto:reduz...@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
 >>
 >



___
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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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.schmalf...@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 :
>
> > 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 
> > 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
> >>
> >
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Philipp Schmalfuß]

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 :


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 
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









___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

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


#N canvas 585 289 400 393 10;
#X msg 191 294 \$1 10;
#X obj 192 314 line~;
#X obj 193 250 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -228856
-1 -1 10600 1;
#X obj 53 318 dac~;
#X msg 146 117 loadIR ./church.wav;
#X obj 65 161 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 14 272 *~;
#X obj 15 22 phasor~ 5;
#X obj 190 270 pow 4;
#X text 82 161 switch~;
#N canvas 193 363 450 300 conv64 0;
#X obj 43 71 inlet~;
#X obj 60 265 outlet~;
#X obj 237 71 inlet;
#X obj 316 84 inlet;
#X obj 316 155 switch~;
#X obj 63 148 pp.fft-partconv~ 64;
#X connect 0 0 5 0;
#X connect 2 0 5 2;
#X connect 3 0 4 0;
#X connect 5 0 1 0;
#X restore 14 234 pd conv64;
#X obj 171 166 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X text 188 166 switch~;
#N canvas 193 363 450 300 conv128 0;
#X obj 43 71 inlet~;
#X obj 60 265 outlet~;
#X obj 237 71 inlet;
#X obj 316 84 inlet;
#X obj 316 155 switch~;
#X obj 63 148 pp.fft-partconv~ 128;
#X connect 0 0 5 0;
#X connect 2 0 5 2;
#X connect 3 0 4 0;
#X connect 5 0 1 0;
#X restore 114 234 pd conv128;
#X obj 114 269 *~;
#X obj 146 22 loadbang;
#X obj 146 45 t b b;
#X msg 173 70 dsp 1;
#X obj 173 93 s pd;
#X connect 0 0 1 0;
#X connect 1 0 6 1;
#X connect 1 0 14 1;
#X connect 2 0 8 0;
#X connect 4 0 10 1;
#X connect 4 0 13 1;
#X connect 5 0 10 2;
#X connect 6 0 3 0;
#X connect 7 0 10 0;
#X connect 7 0 13 0;
#X connect 8 0 0 0;
#X connect 10 0 6 0;
#X connect 11 0 13 2;
#X connect 13 0 14 0;
#X connect 14 0 3 1;
#X connect 15 0 16 0;
#X connect 16 0 4 0;
#X connect 16 1 17 0;
#X connect 17 0 18 0;


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

hmm, weird, I don't seem to find problems...

Em qua, 9 de jan de 2019 às 12:10, Roman Haefeli 
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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

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



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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.
> >
> > https://we.tl/t-HYsWQww10V
> >
> > cheers!
> >
> > Quoting Alexandre Torres Porres :
> >
> > > 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 <
> > > por...@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 <
> > > > por...@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 <
> > > > > por...@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 <
> > > > > > por...@gmail.com> escreveu:
> > > > > >
> > > > > > > Hi, quick updates and developments over my weekend
> > > > > > >
> > > > > > >
> > > > > > > > On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre
> > > > > > > > Torres Porres <
> > > > > > > > por...@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 

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

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 :
> 
> > 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 <
> > por...@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 <
> > > por...@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 <
> > > > por...@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 <
> > > > > por...@gmail.com> escreveu:
> > > > > 
> > > > > > Hi, quick updates and developments over my weekend
> > > > > > 
> > > > > > 
> > > > > > > On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre
> > > > > > > Torres Porres <
> > > > > > > por...@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 

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

Em ter, 8 de jan de 2019 às 19:54, Philipp Schmalfuß <
philipp.schmalf...@uni-weimar.de> escreveu:

> i think it could be improved a lot by precomputing the IR like in your
> patch.
>

you mean like precomputing the FFT, right? Totally! Yeah, let's try it :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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.schmalf...@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.
>
> https://we.tl/t-HYsWQww10V
>
> cheers!
>
> Quoting Alexandre Torres Porres :
>
> > 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 <
> por...@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 <
> >> por...@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 <
> >>> por...@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 <
>  por...@gmail.com> escreveu:
> 
> > Hi, quick updates and developments over my weekend
> >
> >
> >> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
> >> por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Philipp Schmalfuß]

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 :


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 
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 <
por...@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 <
por...@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 <
por...@gmail.com> escreveu:


Hi, quick updates and developments over my weekend



On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

Em ter, 8 de jan de 2019 às 15:40, Lucas Cordiviola 
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 :/
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Lucas Cordiviola]

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 
mailto:por...@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 
mailto:por...@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 
mailto:por...@gmail.com>> escreveu:
Hi, quick updates and developments over my weekend

On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres 
mailto:por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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 <
> por...@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 <
>> por...@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 <
>>> por...@gmail.com> escreveu:
>>>
 Hi, quick updates and developments over my weekend


> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
> por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
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 <
> por...@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 <
>> por...@gmail.com> escreveu:
>>
>>> Hi, quick updates and developments over my weekend
>>>
>>>
 On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
 por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

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 
escreveu:

> Hi, quick updates and developments over my weekend
>
>
>> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
>> por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

Hi, quick updates and developments over my weekend


> On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres <
> por...@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

Re: [PD] vanilla partitioned convolution abstraction

[Giulio Moro via Pd-list]

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 
 wrote: 





Hi, happy new year.
Here's a vanilla partitioned convolution abstraction  
https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip…

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



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Maximiliano Estudies]

Dear Alexandre,

in my Mac I'm at 60% CPU!
Great work by the way, I was in the need for something like this.

Cheers,
Maxi

El jue., 3 ene. 2019 a las 12:01,  escribió:

> Send Pd-list mailing list submissions to
> pd-list@lists.iem.at
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.puredata.info/listinfo/pd-list
> or, via email, send a message with subject or body 'help' to
> pd-list-requ...@lists.iem.at
>
> You can reach the person managing the list at
> pd-list-ow...@lists.iem.at
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pd-list digest..."
>
>
> Today's Topics:
>
>1. vanilla partitioned convolution abstraction
>   (Alexandre Torres Porres)
>
>
> --
>
> Message: 1
> Date: Thu, 3 Jan 2019 02:18:43 -0200
> From: Alexandre Torres Porres 
> To: Pd-List 
> Subject: [PD] vanilla partitioned convolution abstraction
> Message-ID:
>  ymjvfhtqjcb95uwxufw4dvw6xfcqcbz-...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi, happy new year.
>
> Here's a vanilla partitioned convolution abstraction
> https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip…
> <
> https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip?dl=0=IwAR3Sj1Cx8it5Tt8ne5miujaQxhgqlr1S2AuoyhGQzjQwofvR7OpUzhh9EgE
> >
>
>
> It is based on this http://tre.ucsd.edu/wordpress/?p=772
> <
> http://tre.ucsd.edu/wordpress/?p=772=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
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.puredata.info/pipermail/pd-list/attachments/20190103/7d73b4eb/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Pd-list mailing list
> Pd-list@lists.iem.at
> to manage your subscription (including un-subscription) see
> https://lists.puredata.info/listinfo/pd-list
>
>
> --
>
> End of Pd-list Digest, Vol 166, Issue 5
> ***
>


-- 
Maximiliano Estudies
+49 176 36784771
maxiestudies.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] vanilla partitioned convolution abstraction

[Alexandre Torres Porres]

Hi, happy new year.

Here's a vanilla partitioned convolution abstraction
https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip…



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