howdy, is there any particularly good reason why [s~]/[r~] must run at only 64 block sizes?
if the issue is that they may have conflicting/different sizes between them, why not give the same error as you get now for blocks other than 64?
"receive~ x: vector size mismatch sigsend x: unexpected vector size"
It'd be really convenient for feedback loops
cheers
On 26/02/16 03:21, Alexandre Torres Porres wrote:
howdy, is there any particularly good reason why [s~]/[r~] must run at only 64 block sizes?
if the issue is that they may have conflicting/different sizes between them, why not give the same error as you get now for blocks other than 64?
"receive~ x: vector size mismatch sigsend x: unexpected vector size"
It'd be really convenient for feedback loops
if you want something that works right now, tabsend~ and tabreceive~ don't have any restriction about table size must be equal to block size must be equal to 64
see attached example of a single self-modulating fm oscillator with single sample feedback (block~ 1)
Claude
sure, I'm aware of how to do it, and I prefer delays. But I was just really wondering if there was a good reason for it, maybe hoping to a day that comes and allows it :)
cheers
2016-02-26 0:38 GMT-03:00 Claude Heiland-Allen claude@mathr.co.uk:
On 26/02/16 03:21, Alexandre Torres Porres wrote:
howdy, is there any particularly good reason why [s~]/[r~] must run at only 64 block sizes?
if the issue is that they may have conflicting/different sizes between them, why not give the same error as you get now for blocks other than 64?
"receive~ x: vector size mismatch sigsend x: unexpected vector size"
It'd be really convenient for feedback loops
if you want something that works right now, tabsend~ and tabreceive~ don't have any restriction about table size must be equal to block size must be equal to 64
see attached example of a single self-modulating fm oscillator with single sample feedback (block~ 1)
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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@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.
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@gmail.com An: "i go bananas" hard.off@gmail.com Cc: "pd-list@lists.iem.at" pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
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@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@gmail.com An: "i go bananas" hard.off@gmail.com Cc: "pd-list@lists.iem.at" pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[porres@gmail.com]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmail.com[hard.off@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@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
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@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[porres@gmail.com]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@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@gmail.com[ hard.off@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@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]
my guess for your last question:
no overlap: [tabsend~] is now at blocksize 128 and [tabrecieve~] at blocksize 64. Every other block, [tabsend~] is still busy filling the rest of the table while [tabreceive~] is reading the last 64 samples a second time (since the table couldn't been updated yet). so you always get a single 64 sample block tiwce while every other 64 sample block is lost.
with overlap 2: output is the original signal because now the update rate of [tabsend~] is twice as fast and therefore matches [tabreceive~].
Is there a prize? :-)
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?
Gesendet: Samstag, 27. Februar 2016 um 06:01 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@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@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[ pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmx.at[ christof.ressi@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@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
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@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, " pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@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@gmx.at[ christof.ressi@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@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
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@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@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, " pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@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@gmx.at[ christof.ressi@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@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
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@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@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@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, " pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@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@gmx.at [christof.ressi@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@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]
On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote:
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
what's that bug? has it been reported in some public place? why not?
gfmards IOhannes
2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote:
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
what's that bug? has it been reported in some public place? why not?
I contacted ben saylor in private in 2014, thing is that it needs to receive a set message, otherwise it wont work with the specified array given as first argument.
here's the response cheers
---------- Forwarded message ---------- From: Ben Saylor bensaylor@fastmail.fm Date: 2014-09-26 22:20 GMT-03:00 Subject: Re: patconv~ bug To: Alexandre Torres Porres porres@gmail.com, Hans-Christoph Steiner < hans@at.or.at>
Hi Alexandre,
I'm aware of the issue but don't have time to fix it myself, unfortunately. Here's an explanation I wrote to someone else, and a workaround.
I think the reason the seemingly redundant "set" is required is that
the table is empty when the patch is loaded, and so when partconv~ is created it initializes with an empty array. Because of the computation involved in preparing the impulse response, it only does it on creation and when sent a "set" message. The workaround is to populate the table with a loadbang - then, if the table doesn't change, you don't need a set message.
One of these days, I will have to make partconv~ handle these kinds of things better and not crash.
All the best, Ben
Just to confirm, this bug is only on patch load, right? Does it only happen when it's loading a table stored in a patch, or does it do the same if the table is loaded via soundfiler it generated algorithmically?
Is this fixable in partconv~ or is it a consequence of the design of the patch load sequence? On Feb 28, 2016 4:57 PM, "Alexandre Torres Porres" porres@gmail.com wrote:
2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote:
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
what's that bug? has it been reported in some public place? why not?
I contacted ben saylor in private in 2014, thing is that it needs to receive a set message, otherwise it wont work with the specified array given as first argument.
here's the response cheers
---------- Forwarded message ---------- From: Ben Saylor bensaylor@fastmail.fm Date: 2014-09-26 22:20 GMT-03:00 Subject: Re: patconv~ bug To: Alexandre Torres Porres porres@gmail.com, Hans-Christoph Steiner < hans@at.or.at>
Hi Alexandre,
I'm aware of the issue but don't have time to fix it myself, unfortunately. Here's an explanation I wrote to someone else, and a workaround.
I think the reason the seemingly redundant "set" is required is that
the table is empty when the patch is loaded, and so when partconv~ is created it initializes with an empty array. Because of the computation involved in preparing the impulse response, it only does it on creation and when sent a "set" message. The workaround is to populate the table with a loadbang - then, if the table doesn't change, you don't need a set message.
One of these days, I will have to make partconv~ handle these kinds of things better and not crash.
All the best, Ben
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/28/2016 11:03 PM, Matt Barber wrote:
Just to confirm, this bug is only on patch load, right? Does it only happen when it's loading a table stored in a patch, or does it do the same if the table is loaded via soundfiler it generated algorithmically?
Is this fixable in partconv~ or is it a consequence of the design of the patch load sequence?
well there is one thing designed into [partconv~] and that is: it does not continuously update the IR from the table, but does so only at explicit points. one of these points is whenever it receives a "set" message. another of these points is when the DSP is turned on for the first time after the object was created (and still no "set" message has occured).
it's because of the latter that i currently don't think that there is a bug.
gamsrd IOhannes
On 02/28/2016 10:54 PM, Alexandre Torres Porres wrote:
2016-02-28 16:08 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/27/2016 10:33 PM, Alexandre Torres Porres wrote:
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
what's that bug? has it been reported in some public place? why not?
I contacted ben saylor in private in 2014, thing is that it needs to receive a set message, otherwise it wont work with the specified array given as first argument.
i'm unable to reproduce the problem. see attached patch (which uses some randomly painted IR to get some coloured noise).
the initial colour of the noise (after starting the patch) is the same as when i click on the "set" messagebox. it is also different from the white noise.
looking at the source code, the problem you describe has been fixed since at least 2006-02-07 (rev.4566, which is the initial revision, where hans added partconv~ to the repository)
could you provide an example patch that triggers the problem?
gmdsar IOhannes
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@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@gmail.com[brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Torres Porres" porres@gmail.com, "i go bananas" < hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[ pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmx.at[ christof.ressi@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@gmail.com[brbrofsvl@gmail.com][ brbrofsvl@gmail.com[brbrofsvl@gmail.com]]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][ christof.ressi@gmx.at[christof.ressi@gmx.at]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]>, "i go bananas" <hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]>, " pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmx.at[ christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@lists.iem.at]]]" <pd-list@lists.iem.at[ pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][ pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@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@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][ hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][ Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][ Pd-list@lists.iem.at[Pd-list@lists.iem.at]]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Porres" porres@gmail.com, "hard off" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]][brbrofsvl@gmail.com[brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]]]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]][christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]][christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]
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@gmx.at An: "Matt Barber" brbrofsvl@gmail.com Cc: "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Porres" porres@gmail.com, "hard off" hard.off@gmail.com, "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]][brbrofsvl@gmail.com[brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]]]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]][christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]]>, "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]][christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][porres@gmail.com[porres@gmail.com]]]]> An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]]]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@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@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]]] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@gmx.at An: "Matt Barber" brbrofsvl@gmail.com Cc: "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Alexandre Porres" porres@gmail.com, "hard off" <
hard.off@gmail.com>, "pd-list@lists.iem.at" pd-list@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@gmail.com An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "i
go bananas" <hard.off@gmail.com[hard.off@gmail.com]>, " pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@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@gmail.com[brbrofsvl@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][
christof.ressi@gmx.at[christof.ressi@gmx.at]]>
Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][
porres@gmail.com[porres@gmail.com]]>, "i go bananas" <hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]>, " pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmx.at[
christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@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@gmail.com[brbrofsvl@gmail.com][
brbrofsvl@gmail.com[brbrofsvl@gmail.com]][brbrofsvl@gmail.com[ brbrofsvl@gmail.com][brbrofsvl@gmail.com[brbrofsvl@gmail.com]]]>
An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at][
christof.ressi@gmx.at[christof.ressi@gmx.at]][christof.ressi@gmx.at[ christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]]]>
Cc: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com][
porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]]>, "i go bananas" <hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][ hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[ hard.off@gmail.com]]]>, "pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[ pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]]" < pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmx.at[
christof.ressi@gmx.at][christof.ressi@gmx.at[christof.ressi@gmx.at]][ christof.ressi@gmx.at[christof.ressi@gmx.at][christof.ressi@gmx.at[ christof.ressi@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@gmail.com[porres@gmail.com][
porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]][porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]][porres@gmail.com[porres@gmail.com][ porres@gmail.com[porres@gmail.com]]]]>
An: "i go bananas" <hard.off@gmail.com[hard.off@gmail.com][
hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]]][ hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[ hard.off@gmail.com]][hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]]]]>
Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[
pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@lists.iem.at]]][pd-list@lists.iem.at[ pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]][ pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]]]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@lists.iem.at]][pd-list@lists.iem.at[ pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]][ pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[ pd-list@lists.iem.at]][pd-list@lists.iem.at[pd-list@lists.iem.at][ pd-list@lists.iem.at[pd-list@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@gmail.com[
hard.off@gmail.com][hard.off@gmail.com[hard.off@gmail.com]][ hard.off@gmail.com[hard.off@gmail.com][hard.off@gmail.com[ hard.off@gmail.com]]][hard.off@gmail.com[hard.off@gmail.com][ hard.off@gmail.com[hard.off@gmail.com]][hard.off@gmail.com[ hard.off@gmail.com][hard.off@gmail.com[hard.off@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@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][ Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][ Pd-list@lists.iem.at[Pd-list@lists.iem.at]][Pd-list@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]]] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[
Pd-list@lists.iem.at]][Pd-list@lists.iem.at[Pd-list@lists.iem.at][ Pd-list@lists.iem.at[Pd-list@lists.iem.at]]][Pd-list@lists.iem.at[ Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]][ Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[ Pd-list@lists.iem.at]]]] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list%5Bhttp://lists.puredata.info/lis...]]]]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
-
Alexandre Torres Porres -
Christof Ressi -
Claude Heiland-Allen -
i go bananas -
IOhannes m zmölnig -
Matt Barber