[PD] s~ & r~ with block size other than 64?

Sun Feb 28 16:48:07 CET 2016

Definitely no windowing for the kind of time-domain convolution done by
[partconv~].

On Sun, Feb 28, 2016 at 4:52 AM, Christof Ressi <christof.ressi at gmx.at>
wrote:

> > one of them are plain linear convolution
>
> of course meant: "none of them".
>
> > Gesendet: Sonntag, 28. Februar 2016 um 10:49 Uhr
> > Von: "Christof Ressi" <christof.ressi at gmx.at>
> > An: "Matt Barber" <brbrofsvl at gmail.com>
> > Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> > Betreff: Re: [PD] s~ & r~ with block size other than 64?
> >
> > All the FFT example patches work with squared hann-window and overlap 4
> and the FFT examples I've seen in books do as well.
> > On the other hand, when I think of it, one of them are plain linear
> convolution of two audio signals, at least one of the two spectra is always
> somewhat arbitray (e.g. ignoring the imaginary part or manipulated in some
> other way).
> > So for true linear convolution you'd definitely go for zero-padding,
> right? With windowing or without?
> >
> >
> >
> > Gesendet: Sonntag, 28. Februar 2016 um 01:52 Uhr
> > Von: "Matt Barber" <brbrofsvl at gmail.com>
> > An: "Christof Ressi" <christof.ressi at gmx.at>
> > Cc: "Alexandre Porres" <porres at gmail.com>, "hard off" <
> hard.off at gmail.com>, "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> > Betreff: Re: Re: Re: Re: [PD] s~ & r~ with block size other than 64?
> > Can you point to an example of this? I don't think it would work for
> partitioned convolutions, e.g. for reverb, where we need the linear
> convolution.
> >
> > I was always asking myself why FFT convolution in Pd is usally done
> without zero-padding and with a sqared hann-window. theoretically, ommiting
> zero-padding leads to circular convolution, but the squared hann-window
> seems to prevent audible artifacts. However, having less delay using your
> [tabsend~] trick could be reason to prefer 'classical' overlap-add. What's
> your point on this, which method do you actually prefer? And would there a
> point in using a hann-window after zero-padding? Theoretically it shouldn't
> be necessary.
> >
> >
> > Gesendet: Samstag, 27. Februar 2016 um 14:42 Uhr
> > Von: "Matt Barber" <brbrofsvl at gmail.com>
> > An: "Christof Ressi" <christof.ressi at gmx.at[christof.ressi at gmx.at]>
> > Cc: "Alexandre Torres Porres" <porres at gmail.com[porres at gmail.com]>, "i
> go bananas" <hard.off at gmail.com[hard.off at gmail.com]>, "
> pd-list at lists.iem.at[pd-list at lists.iem.at]" <pd-list at lists.iem.at[
> pd-list at lists.iem.at]>
> > Betreff: Re: Re: Re: [PD] s~ & r~ with block size other than 64?
> >
> > > It would allow you to do things like partitioned convolution without
> any delay, since the convolution of two 64-sample windows fills a
> 128-sample window.
> >
> > sounds more like the classic overlap-add-method. can you explain more?
> >
> >
> >
> >
> > OK, forget partitioning and imagine that your impulse response is 50
> samples. You want to convolve it with whatever is coming in from [adc~],
> which is blocked at 64. The problem is that the convolution of a 64-sample
> input and a 50-sample IR is 64+50-1=113 samples long; it has to be done
> with a 128-pt FFT with zero-padded inputs. This means you'll also need an
> overlap of 2, since you'll need a 128-pt FFT for every 64 samples of input.
> Using [inlet~] makes the zero-padding tricky, and you'll also get a block
> delay. Using [tabsend~] and [tabreceive~] zero-pads for you, and also lets
> you do it with no block delay. The logic for partitioned convolution is the
> same; it just requires more windows and extra delay, and some tricks for
> efficiency: pre-calculate the IR FFTs, delay and sum in the frequency
> domain so you only need one IFFT, use differently sized windows to take
> advantage of FFT efficiency for larger windows, etc.
> >
> >
> >
> >
> > Gesendet: Samstag, 27. Februar 2016 um 06:01 Uhr
> > Von: "Matt Barber" <brbrofsvl at gmail.com[brbrofsvl at gmail.com]>
> > An: "Christof Ressi" <christof.ressi at gmx.at[christof.ressi at gmx.at][
> christof.ressi at gmx.at[christof.ressi at gmx.at]]>
> > Cc: "Alexandre Torres Porres" <porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]]>, "i go bananas" <hard.off at gmail.com[
> hard.off at gmail.com][hard.off at gmail.com[hard.off at gmail.com]]>, "
> pd-list at lists.iem.at[pd-list at lists.iem.at][pd-list at lists.iem.at[
> pd-list at lists.iem.at]]" <pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]]>
> > Betreff: Re: Re: [PD] s~ & r~ with block size other than 64?
> >
> > You have to be careful reblocking with [tabsend~] and [tabreceive~]
> though, because of what happens with blocking and block delay. Hopefully
> this isn't too obvious to explain.
> >
> > You know the regular situation: suppose you write into the [inlet~] of a
> subpatch that is blocked at 128 from a parent blocked at 64, and then back
> out an [outlet~] into the parent patch. When you start dsp, for the first
> parent block the first 64 samples go in, but nothing comes out because the
> subpatch needs to collect 128 samples before it sends anything out. On the
> second parent block, 64 more samples go in, the subpatch can do its
> calculations on its 128-sample vector(s), and start output immediately,
> beginning with the first block of input from the parent patch. So
> everything is delayed by one block in this case, or in general by N_s - N_p
> where N_s is the subpatch's block size and N_p is the parent's.
> >
> > Now, suppose instead you have an array of size 128 called "depot." From
> the block-64 parent you [tabsend~] a signal to depot, and you make sure
> your signal is calculated prior to anything in the subpatch using the
> [inlet~] trick. [tabsend~ depot] will write the first 64 samples of depot
> every block, leaving the last 64 untouched. Then inside the block-128
> subpatch you [tabreceive~ depot] and send it out to the parent through an
> [outlet~]. What will happen? When you start dsp, during the parent's first
> block [tabsend~ depot] writes the first block of samples to depot. Nothing
> happens in the subpatch because 128 samples haven't passed yet. Then on the
> parent's second block, [tabsend~ depot] writes the second block of samples
> to the first 64 samples of depot. 128 samples have passed, so the subpatch
> can do its thing. [tabreceive~ depot] receives the whole array, starting
> with the 64 samples just written in by the second parent block, so on
> output, those 64 samples come out with no block delay. However, since the
> first parent block's samples were overwritten in depot by the second
> block's samples, every other block from the parent will be lost in the
> subpatch. However, if you set the subpatch to overlap by 2 (or generally
> N_s/N_p), the [tabsend~]/[tabreceive~] pair actually allows you to reblock
> with no block delay and no lost samples, but with the CPU penalty and the
> general hassle of dealing with overlapping. It would allow you to do things
> like partitioned convolution without any delay, since the convolution of
> two 64-sample windows fills a 128-sample window.
> >
> > So, knowing this, what do you think would happen if you put the
> [tabsend~] in the subpatch and the [tabreceive~] in the parent and don't
> overlap in the subpatch? What if you do overlap in the subpatch?
> >
> > NB - overlapping does not affect the block delay of normal
> [input~]/[output~].
> >
> > I now realize I should have just built a patch to illustrate all this.
> Next time. :)
> >
> > Matt
> >
> > On Fri, Feb 26, 2016 at 1:49 PM, Christof Ressi <christof.ressi at gmx.at[
> christof.ressi at gmx.at][christof.ressi at gmx.at[christof.ressi at gmx.at]]>
> wrote:Thanks Matt for diggin in!
> >
> > > In principle it wouldn't be too hard to let them be any block size so
> long as they're the same size,
> >
> > What puzzles me is that I *can* actually send audio from one subpatch
> and receive it indifferent subpatches for blocksizes greater (but not less)
> than 64, but only if all the blocksizes match and - this is really weird -
> there's no more than 1 [r~] per subpatch. I guess you'd call that an
> "unsupported feature" :-p. I don't use it, however, and I wouldn't
> recommend other people to use it. So let's keep it a secret.
> >
> > After all we have [tabsend~] and [tabreceive]. I was just curious about
> the technical details.
> >
> > Gesendet: Freitag, 26. Februar 2016 um 17:48 Uhr
> > Von: "Matt Barber" <brbrofsvl at gmail.com[brbrofsvl at gmail.com][
> brbrofsvl at gmail.com[brbrofsvl at gmail.com]][brbrofsvl at gmail.com[
> brbrofsvl at gmail.com][brbrofsvl at gmail.com[brbrofsvl at gmail.com]]]>
> > An: "Christof Ressi" <christof.ressi at gmx.at[christof.ressi at gmx.at][
> christof.ressi at gmx.at[christof.ressi at gmx.at]][christof.ressi at gmx.at[
> christof.ressi at gmx.at][christof.ressi at gmx.at[christof.ressi at gmx.at]]]>
> > Cc: "Alexandre Torres Porres" <porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]][porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]]]>, "i go bananas" <hard.off at gmail.com[
> hard.off at gmail.com][hard.off at gmail.com[hard.off at gmail.com]][
> hard.off at gmail.com[hard.off at gmail.com][hard.off at gmail.com[
> hard.off at gmail.com]]]>, "pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]][pd-list at lists.iem.at[
> pd-list at lists.iem.at][pd-list at lists.iem.at[pd-list at lists.iem.at]]]" <
> pd-list at lists.iem.at[pd-list at lists.iem.at][pd-list at lists.iem.at[
> pd-list at lists.iem.at]][pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]]]>
> > Betreff: Re: [PD] s~ & r~ with block size other than 64?
> >
> > Here's the short story:
> >
> > [s~] and [r~] are pretty straightforward: [s~] fills a block buffer
> every sample, and any [r~] with the same name can find that buffer and read
> from it. In principle it wouldn't be too hard to let them be any block size
> so long as they're the same size, but there would be some tricky things
> with overlap and resampling. [catch~] reads from a one-block buffer and
> zeroes it out as it goes, and [throw~] sums into its catcher's buffer.
> [delwrite~]/[delread~] work with any block size because the buffer size
> isn't related to any block size.
> >
> > On Fri, Feb 26, 2016 at 11:23 AM, Christof Ressi <christof.ressi at gmx.at[
> christof.ressi at gmx.at][christof.ressi at gmx.at[christof.ressi at gmx.at]][
> christof.ressi at gmx.at[christof.ressi at gmx.at][christof.ressi at gmx.at[
> christof.ressi at gmx.at]]]> wrote:I think he rather meant that [s~] and
> [r~] doesn't need to check the vector size for each DSP cycle. The error
> message you're talking about is only thrown after creating [s~] or [r~]
> objects in a subpatch with blocksize != 64 AND everytime you set a
> "forbidden" blocksize dynamically with a message to [block~], so it *could*
> be that the check is only performed for such events and not for each DSP
> cycle. Although getting an error message for dynamically changing the
> blocksize rather implies a check for each DSP cycle... But I'm only making
> assumptions. Apart from possible performance optimations I can't see any
> reason for this restriction either!
> >
> > BTW: It's not like a pair of [s~] and [r~] won't generally work for
> blocksizes other than 64. It basically works as expected when used as
> "wireless audio connections" (at least in the situations I tried) but
> things get screwed up once you try feedback or if the blocksizes don't
> match. Again, it would be really cool if someone could clarify what's
> really going on under the hood (e.g. how [s~] and [r~] differ from
> [delwrite] and [delread~]) or point to an already existing thread in the
> mailing list archive.
> >
> >
> >
> > Gesendet: Freitag, 26. Februar 2016 um 07:08 Uhr
> > Von: "Alexandre Torres Porres" <porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]][porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]]][porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]][porres at gmail.com[porres at gmail.com][
> porres at gmail.com[porres at gmail.com]]]]>
> > An: "i go bananas" <hard.off at gmail.com[hard.off at gmail.com][
> hard.off at gmail.com[hard.off at gmail.com]][hard.off at gmail.com[
> hard.off at gmail.com][hard.off at gmail.com[hard.off at gmail.com]]][
> hard.off at gmail.com[hard.off at gmail.com][hard.off at gmail.com[
> hard.off at gmail.com]][hard.off at gmail.com[hard.off at gmail.com][
> hard.off at gmail.com[hard.off at gmail.com]]]]>
> > Cc: "pd-list at lists.iem.at[pd-list at lists.iem.at][pd-list at lists.iem.at[
> pd-list at lists.iem.at]][pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]]][pd-list at lists.iem.at[
> pd-list at lists.iem.at][pd-list at lists.iem.at[pd-list at lists.iem.at]][
> pd-list at lists.iem.at[pd-list at lists.iem.at][pd-list at lists.iem.at[
> pd-list at lists.iem.at]]]]" <pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]][pd-list at lists.iem.at[
> pd-list at lists.iem.at][pd-list at lists.iem.at[pd-list at lists.iem.at]]][
> pd-list at lists.iem.at[pd-list at lists.iem.at][pd-list at lists.iem.at[
> pd-list at lists.iem.at]][pd-list at lists.iem.at[pd-list at lists.iem.at][
> pd-list at lists.iem.at[pd-list at lists.iem.at]]]]>
> > Betreff: Re: [PD] s~ & r~ with block size other than 64?
> >
> > really? can't see how much more relevantly efficient it'd be, and it
> kinda does check it already, hence the errors
> >
> > cheers
> >
> > 2016-02-26 3:07 GMT-03:00 i go bananas <hard.off at gmail.com[
> hard.off at gmail.com][hard.off at gmail.com[hard.off at gmail.com]][
> hard.off at gmail.com[hard.off at gmail.com][hard.off at gmail.com[
> hard.off at gmail.com]]][hard.off at gmail.com[hard.off at gmail.com][
> hard.off at gmail.com[hard.off at gmail.com]][hard.off at gmail.com[
> hard.off at gmail.com][hard.off at gmail.com[hard.off at gmail.com]]]]>:I would
> assume it's also slightly more efficient that pd doesn't have to check the
> vector size when processing the s~ / r~ functions.
>  _______________________________________________ Pd-list at lists.iem.at[
> Pd-list at lists.iem.at][Pd-list at lists.iem.at[Pd-list at lists.iem.at]][
> Pd-list at lists.iem.at[Pd-list at lists.iem.at][Pd-list at lists.iem.at[
> Pd-list at lists.iem.at]]][Pd-list at lists.iem.at[Pd-list at lists.iem.at][
> Pd-list at lists.iem.at[Pd-list at lists.iem.at]][Pd-list at lists.iem.at[
> Pd-list at lists.iem.at][Pd-list at lists.iem.at[Pd-list at lists.iem.at]]]]
> mailing list UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]]]]
> >
> > _______________________________________________
> > Pd-list at lists.iem.at[Pd-list at lists.iem.at][Pd-list at lists.iem.at[
> Pd-list at lists.iem.at]][Pd-list at lists.iem.at[Pd-list at lists.iem.at][
> Pd-list at lists.iem.at[Pd-list at lists.iem.at]]][Pd-list at lists.iem.at[
> Pd-list at lists.iem.at][Pd-list at lists.iem.at[Pd-list at lists.iem.at]][
> Pd-list at lists.iem.at[Pd-list at lists.iem.at][Pd-list at lists.iem.at[
> Pd-list at lists.iem.at]]]] mailing list
> >
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]]]
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/ee9e22b3/attachment-0001.html>