Hi,
I am trying to understand oversampling to eliminate foldover from my patches. In the help file for block~ we read:
The block~ and switch~ objects set the block size, overlap, and
up/down-sampling ratio for the window. (The overlap and
resampling ratio are relative to the super-patch.)
This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact?
If not, do you have to include all of the audio rate objects at the same level in a patch without using sub-patches or abstractions?
Thanks for reading.
Cheers, David
Hi David,
try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct.
best, d.
David F. Place wrote:
This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact?
Thanks again, Derek. I couldn't find any documentation for samplerate~, but I guessed that the output would be a number and that I should probably bang the input to get it. It shows that the up-sampled rate from block is passed down to abstractions.
On Mon, 2008-10-20 at 14:57 +0200, Derek Holzer wrote:
Hi David,
try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct.
Putting [samplerate~] in the subpatch of Miller's upsampling help patch gives the correct upsampled rate. But I guess Miller's warning about the overlap could factor in here as well.
d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
Hi David,
try putting [samplerate~] in each subpatch or abstraction to see if the
afair, [samplerate~] will always output the _system_ samplerate (the one locked to the soundcard); it is not affected by up/downsampling.
fmgasd IOhannes
One small warning - the output of samplerate~ is confusing if there is overlap - samplerate~ output goes up by the overlap factor, which is arguably incorrect. It needs replacing by a more comprehensive solution.
Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it "correct' or just leave it wrong.
The throw~/catch~ 64-sample restriction is fixable. It would be a much bigger project to make them work across arbitrary changes of sample rate, block size, and overlap.
cheers Miller
On Mon, Oct 20, 2008 at 02:57:57PM +0200, Derek Holzer wrote:
Hi David,
try putting [samplerate~] in each subpatch or abstraction to see if the changes by [block~] are passed down. I don't know offhand if they are, but I *think* that is correct.
best, d.
David F. Place wrote:
This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 142: "Shut the door and listen from outside"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
One small warning - the output of samplerate~ is confusing if there is overlap - samplerate~ output goes up by the overlap factor, which is arguably incorrect. It needs replacing by a more comprehensive solution.
Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it "correct' or just leave it wrong.
personally i would just change it. if somebody relies on a certain upsampling algorithm, they should explicitely specify so in the creation arguments. (or even better, use a separate object that fills the gaps in the zero-padded signal with something more sophisticated)
fgmsdr IOhannes
On Mon, Oct 20, 2008 at 10:42 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Miller Puckette wrote:
Also the default upsampling algorithm is incorrect - if you upsaple by 2, for instance, incoming signals get interleaved with zeros, which does not result in a unity DC gain. I've been fretting over whether this should be changed (incompatibly!) to make it "correct' or just leave it wrong.
personally i would just change it. if somebody relies on a certain upsampling algorithm, they should explicitely specify so in the creation arguments. (or even better, use a separate object that fills the gaps in the zero-padded signal with something more sophisticated)
only tricky part about it, is that the method to perform interpolation/extrapolation on the zero-padded signal depends on the upsampling ratio. A separate object would have to be passed (or query for) the upsampling ratio.
There is a method by fft, that will perform extrapolation as well as interpolation during upsampling--it's limitation is that the points at the ends of the block may not have continuity between blocks (OTOH--this problem is always there). For an upsampling ratio of k and original size n: Take the fft of the signal at the original rate, multiply by k, pad the end with k*(n-1) zeros and take the ifft. O(kn*log(kn))
4-point interpolation is nearly trivial--there's still the problem of what to do at the end points. However, given that it has a fixed rate, coefficients for interpolation can be calculated beforehand. Then, it takes 4 multiplies and 3 adds per zero. Total: 4*n*(k-1) multiplies and 3*n*(k-1) adds.
Both methods could be optimally coded by omitting the zero-interleaving step. But it comes down to--what representation is most useful? Why go to all the trouble of interpolating, if what you really want is a zero-interleaved signal? Why zero-interleave first, and interpolate second?
So, I would favor an optional creation argument for specifying an interpolation method in place of the zero-interleaving step.
Chuck
Charles Henry wrote:
only tricky part about it, is that the method to perform interpolation/extrapolation on the zero-padded signal depends on the upsampling ratio. A separate object would have to be passed (or query for) the upsampling ratio.
yes, but this shouldn't be over-tricky.
So, I would favor an optional creation argument for specifying an interpolation method in place of the zero-interleaving step.
this is already there. you can specify via creation args to in/outlets which "interpolation" you want: currently only zero-interleaving and sample and hold are inplemented.
as far as i understand miller (in previous posts), he doesn't really like this approach, as all future resampling methods would have to go into Pd's core rather than being available as externals.
by now i can agree to this (despite my original idea that has made it into the code). as you say, the only thing needed would be a complete description of the signal-properties (resampling factor, overlap factor) made available for externals. then they could figure out themselves what they need. (well, this works if you have an upsampled subpatched; i guess it is a bit more clumsy if you have a downsampled subpatch (e.g. you do the upsampling outside). also an object to query these properties would be handy.
there has been a related feature request for ages: https://sourceforge.net/tracker/index.php?func=detail&aid=1228121&gr...
fgmadrs IOhannes
On Tue, Oct 21, 2008 at 2:17 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Charles Henry wrote:
So, I would favor an optional creation argument for specifying an interpolation method in place of the zero-interleaving step.
this is already there. you can specify via creation args to in/outlets which "interpolation" you want: currently only zero-interleaving and sample and hold are inplemented.
I see now. This might be the first time I've looked at the help page for inlet~. Also, linear interpolation is listed there.
as far as i understand miller (in previous posts), he doesn't really like this approach, as all future resampling methods would have to go into Pd's core rather than being available as externals.
by now i can agree to this (despite my original idea that has made it into the code). as you say, the only thing needed would be a complete description of the signal-properties (resampling factor, overlap factor) made available for externals. then they could figure out themselves what they need. (well, this works if you have an upsampled subpatched; i guess it is a bit more clumsy if you have a downsampled subpatch (e.g. you do the upsampling outside).
I see. Rather than a single variable to determine the interpolation, you need to know the ratio between sub-patches. It's probably better to leave the parameters up to the user.
I think linear upsampling is a bit more intuitive for users than a zero-interleaved upsampling as a default behavior. For most scenarios I can think of involving upsampling (filtering), there's only "incompatibility" by having a gain factor of the upsampling ratio (using default of linear interpolation instead of zero-interleaving).
Chuck
Charles Henry wrote:
On Tue, Oct 21, 2008 at 2:17 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I think linear upsampling is a bit more intuitive for users than a zero-interleaved upsampling as a default behavior. For most scenarios I can think of involving upsampling (filtering), there's only "incompatibility" by having a gain factor of the upsampling ratio (using default of linear interpolation instead of zero-interleaving).
my main argument when using zero-padding as default was to force users to think about what they are doing rather than providing non-optimal defaults. i think that the actual resampling/filtering algorithm is very specific to your application, so i wouldn't come up with clock-burning defaults that don't fit the needs of a user anyhow. and anything more sophisticated would have introduced additional delays, which i wanted to avoid at all cost: it's easy to do filtering, gain adjustment whatever - but it is still impossible to go back in time....
using a semi-good approach (like linear interpolation) might also give you acceptable results with cheap laptop speakers and then give you big surprise on a good PA. (note that the whole re-sampling thing made it into Pd in 2001)
maybe i had other thoughts as well
fgmar IOhannes
David F. Place wrote:
Hi,
I am trying to understand oversampling to eliminate foldover from my patches. In the help file for block~ we read:
The block~ and switch~ objects set the block size, overlap, and up/down-sampling ratio for the window. (The overlap and resampling ratio are relative to the super-patch.)This is confusing to me. If the overlap and resampling ratio are relative to the super-patch, then shouldn't block~ set the block size, overlap, and up/down-sampling ratio for the window and all its sub windows? (sub-patches and abstractions) Is that how it works, in fact?
yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course).
If not, do you have to include all of the audio rate objects at the same level in a patch without using sub-patches or abstractions?
no
mfgasdr IOhannes
On Mon, 2008-10-20 at 15:29 +0200, IOhannes m zmoelnig wrote:
yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course).
So, I added [block~ 4096 1 16] to my next to top level abstraction and now I get the following errors:
error: throw~ voiceSumLeft: vector size mismatch error: sigcatch voiceSumRight: unexpected vector size
All my abstractions are within the scope of one block~, shouldn't they have the same vector size?
I pass the final signal out through outlet~ objects to be downsampled before being passed to dac~.
David F. Place wrote:
On Mon, 2008-10-20 at 15:29 +0200, IOhannes m zmoelnig wrote:
yes, all subpatches share the same signal-properties with regard to the super-patch (unless further overriden of course).
So, I added [block~ 4096 1 16] to my next to top level abstraction and now I get the following errors:
error: throw~ voiceSumLeft: vector size mismatch error: sigcatch voiceSumRight: unexpected vector size
All my abstractions are within the scope of one block~, shouldn't they have the same vector size?
you are right.
the warning is misleading though: Pd simply refuses to [throw~]/[catch~] or [s~]/[r~] with anything other than the standard 64-sample, no-overlap, no-resampling signal.
gmasdr IOhannes
On Mon, 2008-10-20 at 15:50 +0200, IOhannes m zmoelnig wrote:
the warning is misleading though: Pd simply refuses to [throw~]/[catch~] or [s~]/[r~] with anything other than the standard 64-sample, no-overlap, no-resampling signal.
I see. I changed all of my throws and catches to direct connections and it now works, sort of. My patches are much uglier, though.
-
Charles Henry -
David F. Place -
Derek Holzer -
IOhannes m zmoelnig -
Miller Puckette