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 msp@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