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