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