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

Christof Ressi christof.ressi at gmx.at
Fri Feb 26 19:49:39 CET 2016


Thanks Matt for diggin in!

> In principle it wouldn't be too hard to let them be any block size so long as they're the same size, 
 
What puzzles me is that I *can* actually send audio from one subpatch and receive it indifferent subpatches for blocksizes greater (but not less) than 64, but only if all the blocksizes match and - this is really weird - there's no more than 1 [r~] per subpatch. I guess you'd call that an "unsupported feature" :-p. I don't use it, however, and I wouldn't recommend other people to use it. So let's keep it a secret. 

After all we have [tabsend~] and [tabreceive]. I was just curious about the technical details. 

Gesendet: Freitag, 26. Februar 2016 um 17:48 Uhr
Von: "Matt Barber" <brbrofsvl at gmail.com>
An: "Christof Ressi" <christof.ressi at gmx.at>
Cc: "Alexandre Torres Porres" <porres at gmail.com>, "i go bananas" <hard.off at gmail.com>, "pd-list at lists.iem.at" <pd-list at lists.iem.at>
Betreff: Re: [PD] s~ & r~ with block size other than 64?

Here's the short story:
 
[s~] and [r~] are pretty straightforward: [s~] fills a block buffer every sample, and any [r~] with the same name can find that buffer and read from it. In principle it wouldn't be too hard to let them be any block size so long as they're the same size, but there would be some tricky things with overlap and resampling. [catch~] reads from a one-block buffer and zeroes it out as it goes, and [throw~] sums into its catcher's buffer. [delwrite~]/[delread~] work with any block size because the buffer size isn't related to any block size.
 
On Fri, Feb 26, 2016 at 11:23 AM, Christof Ressi <christof.ressi at gmx.at> wrote:I think he rather meant that [s~] and [r~] doesn't need to check the vector size for each DSP cycle. The error message you're talking about is only thrown after creating [s~] or [r~] objects in a subpatch with blocksize != 64 AND everytime you set a "forbidden" blocksize dynamically with a message to [block~], so it *could* be that the check is only performed for such events and not for each DSP cycle. Although getting an error message for dynamically changing the blocksize rather implies a check for each DSP cycle... But I'm only making assumptions. Apart from possible performance optimations I can't see any reason for this restriction either!

BTW: It's not like a pair of [s~] and [r~] won't generally work for blocksizes other than 64. It basically works as expected when used as "wireless audio connections" (at least in the situations I tried) but things get screwed up once you try feedback or if the blocksizes don't match. Again, it would be really cool if someone could clarify what's really going on under the hood (e.g. how [s~] and [r~] differ from [delwrite] and [delread~]) or point to an already existing thread in the mailing list archive.
 
 

Gesendet: Freitag, 26. Februar 2016 um 07:08 Uhr
Von: "Alexandre Torres Porres" <porres at gmail.com[porres at gmail.com]>
An: "i go bananas" <hard.off at gmail.com[hard.off at gmail.com]>
Cc: "pd-list at lists.iem.at[pd-list at lists.iem.at]" <pd-list at lists.iem.at[pd-list at lists.iem.at]>
Betreff: Re: [PD] s~ & r~ with block size other than 64?

really? can't see how much more relevantly efficient it'd be, and it kinda does check it already, hence the errors
 
cheers
 
2016-02-26 3:07 GMT-03:00 i go bananas <hard.off at gmail.com[hard.off at gmail.com]>:I would assume it's also slightly more efficient that pd doesn't have to check the vector size when processing the s~ / r~ functions.  _______________________________________________ Pd-list at lists.iem.at[Pd-list at lists.iem.at] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]]

_______________________________________________
Pd-list at lists.iem.at[Pd-list at lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list]



More information about the Pd-list mailing list