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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
