[PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)

[Charles Henry]

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 at 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