[PD-dev] query: upsampled block~ objects and inlet~

IOhannes m zmoelnig zmoelnig at iem.at
Mon Jul 18 09:14:24 CEST 2005


Miller Puckette wrote:
> Hi all,
> 
> I just started playing with up-sampled sub-patches (thanks Iohannes), and
> found out that the inlet~ object upsamples its input by interspersing
> zeros with the samples coming in.  So for instance, if you're upsampling
> by four and put in 1, 1, 1, ... you get out 1, 0, 0, 0, 1, 0, 0, 0, 1, ...

hmm, my intention was to generate output that obviously sounds weird 
without filtering. so people would know that they are doing something to 
their signal. but this was probably thought too technically.
(read on below)


> This seems to be scaled wrong, since if you low-pass it you should
> get out approximately 1/4, 1/4, 1/4, ... ; I noticed the problem trying
> to run an audio signal into the frequency input of a phasor~ and getting
> 1/4 the right frequency.

since this is just linear scaling i didn't do anything about it.
i thought it like overlapping: if you do overlapping by a factor of 2, 
then your signal will double at the output.
if you are doing iFFTs ,then your signal will even get multiplied by the 
blocksize.
so i thought, that people playing with [block~] are just used to adjust 
their gains.

> 
> It seems to me the best default behavior would be to have a, b, c, ...
> turn into a, a, a, a, b, b, b, b, c, c, c, c, ... so that you would
> get at least "reasonable" behavior (and anyway, it's no more expensive
> than the current setup.)  Would this break people's patches that use
> upsampling?  I assume people use some kind of filter after the inlet~
> object, and am hoping that, whatever the most popular filters are, they
> only look at every nth (4th, for instance) sample of the input, so
> nothing should be broken by doing this...

my intention was always to force people chose a specific upsampling 
method (with args to the iolet).
so if people wanted zero-padding they would type [inlet~ zeropadding], 
if they prefer (like you) a sample'n'hold behaviour, they would use 
[inlet~ sample'n'hold].
if they don't care for CPU-cycles, they would probably chose [inlet~ 
linear].
and the very lazy who don't want to do any filtering themselves would 
just do [inlet~ 5th-order-interpolation] (well this is not yet 
implemented ;-)
optionally one could implement a "best" and "fastest" keywords, which 
would choose one of the available algorithms (good if someone finally 
extends the implementations of up/downsampling)

otoh, i now understand that you don't really like the "arguments to the 
iolet" stuff i introduced then.




mfg.ad.sr
IOhannes




More information about the Pd-dev mailing list