That's not completely unusual for things in the dspcontext struct. Some of them (I think "dc_toplevel" is another one) get stored there but not used--because the value gets set and used in the very same function. Over the weekend, I went digging for calcsize but gave up (I also wanted to prove or disprove it gets used). I think it must be in "ugen_doit" where N gets set for the ugen being scheduled.
Chuck On Tue, Oct 23, 2012 at 1:02 PM, Miller Puckette <m...@ucsd.edu> wrote: > 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