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

[Alexandre Torres Porres]

by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a
couple of years ago and he said he didnt have time for it

2016-02-27 16:16 GMT-03:00 Matt Barber <brbrofsvl at gmail.com>:

> No, I have one in the works. I had to take some months off to write a
> piano concerto, but once this is done I can get back to it and show you. It
> won't be quite as quick as [partconv~] (and even [partconv~] used naïvely
> isn't nearly as quick as [partconv~] used well).
>
> On Sat, Feb 27, 2016 at 2:10 PM, Alexandre Torres Porres <porres at gmail.com
> > wrote:
>
>> so, you could do it, but it's insane to do partitioned convolution as a
>> patch, right?
>>
>>
>> 2016-02-27 10:42 GMT-03:00 Matt Barber <brbrofsvl at gmail.com>:
>>
>>>
>>>>
>>>> > 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>
>>>> An: "Christof Ressi" <christof.ressi at gmx.at>
>>>> Cc: "Alexandre Torres Porres" <porres at gmail.com>, "i go bananas" <
>>>> hard.off at gmail.com>, "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>
>>>> 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]>
>>>> 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: [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]> 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]]>
>>>> An: "i go bananas" <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]]>
>>>> 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]]>: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]]
>>>> 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]]]
>>>>
>>>> _______________________________________________
>>>> 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]]
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160227/9f87a763/attachment-0001.html>