[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 <giuliomoro at yahoo.it>
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 <
> porres at 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 <abonnements at 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 at uni-weimar.de
> >> <mailto:philipp.schmalfuss at 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 at gmail.com
> >>     <mailto:porres at 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 at gmail.com <mailto:reduzent at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> >>      >> UNSUBSCRIBE and account-management ->
> >>      >> https://lists.puredata.info/listinfo/pd-list
> >>      >>
> >>      >
> >>
> >>
> >>
> >> _______________________________________________
> >> Pd-list at lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >>
> >
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190111/96f7758f/attachment-0001.html>