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 <m...@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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
