Hi,
On 18/10/12 08:39, SourceForge.net wrote:
Feature Requests item #3578019, was opened at 2012-10-18 00:39
It's already implemented...
Submitted By: Nobody/Anonymous (nobody) Summary: I'd like to...
Initial Comment: ..know if it is possible to use other than "2^n"-blocksizes?!
Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate).
You know, I've read about that, and now I wonder if the info or the implementation is bugged..
Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached. Note that dsp must be on globally, but switched off for the particular canvas, for this to make sense. Also bang->switch~ seems to compute a dsp block immediately, so remember to use trigger when applicable to initialise your signal objects in that patch. Perhaps it wouldn't hurt to have a small example somewhat along these lines in the help patch.
Claude
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-18 10:16, Claude Heiland-Allen wrote:
..know if it is possible to use other than "2^n"-blocksizes?!
Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate).
You know, I've read about that, and now I wonder if the info or the implementation is bugged..
Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached.
hmm, but it seems that the actually computed blocksize is rounded to the next power-of-2. in your example, the actual blocksize is not 12345 but 16384 samples (simple check: make your table big enough to hold 15000 samples, and use [tabsend~] instead of [tabwrite~] --> triggering DSP will fill the entire table with noise; resizing the table to e.g. 20000 shows that [tabsend~] only writes the first 16384 samples)
fgmasdr IOhannes
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.
The intention of non-power-of-2 block sizes is to allow using the ~ objects on non-audio objects like video rasters. It's experimental - I don't believe anyone has actually used this for anything, and I'm not sure it's useful at all. Since it's untested it might end up having to be changed incompatibly before it's frozen as a Pd feature.
cheers Miller
On Tue, Oct 23, 2012 at 06:23:17PM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-18 10:16, Claude Heiland-Allen wrote:
..know if it is possible to use other than "2^n"-blocksizes?!
Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate).
You know, I've read about that, and now I wonder if the info or the implementation is bugged..
Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached.
hmm, but it seems that the actually computed blocksize is rounded to the next power-of-2. in your example, the actual blocksize is not 12345 but 16384 samples (simple check: make your table big enough to hold 15000 samples, and use [tabsend~] instead of [tabwrite~] --> triggering DSP will fill the entire table with noise; resizing the table to e.g. 20000 shows that [tabsend~] only writes the first 16384 samples)
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlCGxHIACgkQkX2Xpv6ydvSZagCgipLpyjwFw/nS2mmmQLvUJPvy cW8An2gJ4Hlesc+6EyGpjhNFA6ML61xc =YkTd -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-24 02:56, Miller Puckette wrote:
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.
<m_pd.h> typedef struct _signal { int s_n; /* number of points in the array */ t_sample *s_vec; /* the array */ t_float s_sr; /* sample rate */ int s_refcount; /* number of times used */ int s_isborrowed; /* whether we're going to borrow our array */ struct _signal *s_borrowedfrom; /* signal to borrow it from */ struct _signal *s_nextfree; /* next in freelist */ struct _signal *s_nextused; /* next in used list */ int s_vecsize; /* allocated size of array in points */ } t_signal; </m_pd.h>
now i haven't recently checked the mechanics how all these variables are used internally, but according to the comments i would have guessed that, "s_vecsize" is the "allocated-size" field, and "s_n" is the actual (to-be-computed) vectorsize.
I'm not 100% sure I can change the size of the signal structure without breaking binary compatibility with older objects.
i think that "t_signal" is used by reference everywhere, which would grant binary compatibility, as long as you only add the end of the struct.
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
more important for me would be fields to separate overlap/resampling/samplerate. PLLLLLEAASE!
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 :)
there have been other ways to process images before... i still would love to see non-2^n blocksizes, ideally allowing reblocking to sub-patches if one blocksize is an integer multiple of the other.
mfgasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-24 09:24, IOhannes m zmoelnig wrote:
On 2012-10-24 02:56, Miller Puckette wrote:
I'm not 100% sure I can change the size of the signal structure without breaking binary compatibility with older objects.
i think that "t_signal" is used by reference everywhere, which would
a quick grep over the entire externals-svn for "signal_t" without a trailing '*' seems to confirm this assumption (note however, that my grep does not catch any dereferences, so the check might be incomplete)
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-24 02:56, Miller Puckette wrote:
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.
attached is my somewhat simplistic attempt to make non-2^n blocksizes work.
i have run some basic help-patches with it and it seems to work fine (though i expect problems with e.g. fft-objects in non-2^n mode).
fgmasdr IOhannes
-
Charles Henry -
Claude Heiland-Allen -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette