Sure enough... a quick search for dc_calcsize verifies that it's not used anywhere although set - all the 'ugens' actually look at the allocated size of input/output signals to determine the number of points to calculate.
I'm not sure how to fix this - and anyway I don't have any real patches that use this 'feature' that would permit me to test it :)
M
On Tue, Oct 23, 2012 at 07:41:08PM +0200, IOhannes m zmölnig wrote:
On 10/23/2012 06:30 PM, Miller Puckette wrote:
Hi all -
block sizes in subpatches are restricted to being a power of two multiple or submultiple of the containing patch. So the only context in which a non-power-of-two blocksize is allowerd is if it's specified in the top-level patch.
Then, of course, dac~ and adc~ will no longer work as they need block size of 64.
yes, i'm aware of that. i only wanted to say that in real live, i haven't been able to construct a patch that would do non-power-of-two processing, even if it was in a top-level patch without any fancy input/output. e.g. claude's example patch doesn't do non-power-of-two block-processing but instead falls back to the next greater 2^n blocksize.
so if somebody (miller?) could post a simplistic patch that really does block-processing with an odd number of samples, that would be great.
fgmadsr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev