I think he rather meant that [s~] and [r~] doesn't need to check the vector 
size for each DSP cycle. The error message you're talking about is only thrown 
after creating [s~] or [r~] objects in a subpatch with blocksize != 64 AND 
everytime you set a "forbidden" blocksize dynamically with a message to 
[block~], so it *could* be that the check is only performed for such events and 
not for each DSP cycle. Although getting an error message for dynamically 
changing the blocksize rather implies a check for each DSP cycle... But I'm 
only making assumptions. Apart from possible performance optimations I can't 
see any reason for this restriction either! 

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

Gesendet: Freitag, 26. Februar 2016 um 07:08 Uhr
Von: "Alexandre Torres Porres" <[email protected]>
An: "i go bananas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Betreff: Re: [PD] s~ & r~ with block size other than 64?

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

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

Reply via email to