> 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" <[email protected]> > An: "Matt Barber" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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" <[email protected]> > An: "Christof Ressi" <[email protected]> > Cc: "Alexandre Porres" <[email protected]>, "hard off" <[email protected]>, > "[email protected]" <[email protected]> > 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" <[email protected]> > An: "Christof Ressi" <[email protected][[email protected]]> > Cc: "Alexandre Torres Porres" <[email protected][[email protected]]>, "i go > bananas" <[email protected][[email protected]]>, > "[email protected][[email protected]]" > <[email protected][[email protected]]> > 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" <[email protected][[email protected]]> > An: "Christof Ressi" > <[email protected][[email protected]][[email protected][[email protected]]]> > Cc: "Alexandre Torres Porres" > <[email protected][[email protected]][[email protected][[email protected]]]>, "i > go bananas" > <[email protected][[email protected]][[email protected][[email protected]]]>, > > "[email protected][[email protected]][[email protected][[email protected]]]" > > <[email protected][[email protected]][[email protected][[email protected]]]> > 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 > <[email protected][[email protected]][[email protected][[email protected]]]> > 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" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]> > An: "Christof Ressi" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]> > Cc: "Alexandre Torres Porres" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]>, > "i go bananas" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]>, > > "[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]" > > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]> > 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 > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]> > 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" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]]> > An: "i go bananas" > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]]> > Cc: > "[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]]" > > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]]> > 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 > <[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]]>: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. > _______________________________________________ > [email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]] > 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]]]]] > > _______________________________________________ > [email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]][[email protected][[email protected]][[email protected][[email protected]]][[email protected][[email protected]][[email protected][[email protected]]]]] > 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]]]] > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
