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

[Miller Puckette]

I think the most nearly correct thing to do would be to change the signal
structure to add an ?allocated-size" field, and put what is now calcsize
in the s_n field of the signal.

I'm not 100% sure I can change the size of the signal structure without
breaking binary compatibility with older objects.  However, there's other
stuff I want to add (to support objects being able to detect when there's
no signal connected to an input).  I think when I make that change I can
try making the non-power-of-two thing work too.  But I'm not sure anyone
will ever use it - there are other ways to process images these days :)

M

On Tue, Oct 23, 2012 at 06:56:31PM -0500, Charles Henry wrote:
> On Tue, Oct 23, 2012 at 1:02 PM, Miller Puckette <msp at ucsd.edu> wrote:
> > all the 'ugens' actually look at the allocated
> > size of input/output signals to determine the number of points to calculate.
> 
> Okay--I see where this goes now.  You just pass the signal data
> structure to the "dsp" method and the "dsp" method is responsible for
> putting the perform routine on the chain with s_vecsize
> 
> The code in the block_set() function is pretty much the same as what
> happens in signal_new() when you feed it a non-power-of-two vector
> size, except it doesn't get stored in the signal data structure:
> if (calcsize)
>   if ((vecsize = (1 << ilog2(calcsize))) != calcsize)
>     vecsize *= 2;
> 
> So, to make it work--you'd have to add s_calcsize to the signal data
> structure, and then, each compatible "dsp" routine would need to use
> s_calcsize in place of s_vecsize.
> 
> But it seems to be practically useless.  It's misleading to users to
> think they're getting a non-2^n blocksize.  The calcsize is after all
> set by the block~ and switch~ objects in the argument we think of as
> blocksize.
> 
> Chuck