[PD] Scope of [block~] and [switch~]
czhenry at gmail.com
Wed Oct 22 00:12:32 CEST 2008
On Tue, Oct 21, 2008 at 2:17 AM, IOhannes m zmoelnig <zmoelnig at 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
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).
More information about the Pd-list