[PD] Re: Question about upsampling methods

[Christof Ressi]

On 09.04.2025 22:00, Alex Harker wrote:


otherwise you could ALSO get all zeros, which is even worse


That's an excellent point! If you take a zero-padded input signal, 
forget to filter and then delay it by 1 sample, the downsampled output 
will be silent :-D


Christof


---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/EGI6VIECMO6U5P2D5ZY4HBHDAWRDCEAJ/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[Alex Harker]

This is a really interesting discussion to follow along.

On a quick look the ZOH approach will add a gradual rolloff to the signal (I 
iwould magine consistent with an FIR of equal values in the new sampling rate 
of N although wikipedia says - "a 3.9224 dB loss at the Nyquist frequency, 
corresponding to a gain of sinc(1/2) = 2/π” but constructing FIRs gives 
different results according to their length… 
(https://en.wikipedia.org/wiki/Zero-order_hold)

> On 9 Apr 2025, at 13:09, Miller Puckette via Pd-list  
> wrote:
> 
> after noticing that you get really strange results if you upsample a signal 
> with zero-padding and then try to use it as the frequency of an oscillator... 
> the oscillator's frequency drops by the upsampling factor.  Another wa to say 
> the same thing: the DC gain of a zero-padding upsampler is 1/N where N is the 
> sampling factor. 

I *think* but I am not 100% sure that this is one of these weird areas where 
gain stuff happens with DSP processes that get compensated by engineers but are 
not in the literature. In testing if I take some noise and zero out every other 
sample then not only do I mirror the spectrum but I also get a gain loss of 
-6dB (to my mind this is equivalent to zero-stuffing a signal of half the 
sample rate, so there seems to be a gain factor in this transformation). 
Therefore I think when you zero stuff you get a gain loss across the whole 
spectrum of 1/N and not just at DC.

> You could correct this by multiplying the zero-padded signal by N but then 
> what of someone tries to downsample it again...

It depends what happens in-between. If you are drop sampling and don’t filter 
then you will get the gain factor, but only if you are aligned for sampling 
(which if your counts start at the same time and always run together they will 
be, but this seems like a weak guarantee) - otherwise you could ALSO get all 
zeros, which is even worse. I think after filtering in the higher sample rate 
you’d get the right result, because the DC level in the higher sample rate is 
now correct, and the filtering would spread the energy so as to give the right 
number over the period. I’ve also done some rough tests on this that seem to 
confer (if I zero every second sample on a DC signal and then filter the output 
stabilises at a number half of the original)

I could be off on some of this stuff, because I am very practically oriented on 
these matters, and I don’t have a direct mathematical explanation to hand, but 
I think the testing I’ve done makes sense - happy to be corrected…

Alex

> it then gets multiplied by N unless the downsampler averages all the N 
> samples... and then we're back to something that resembles the ZOH filtering 
> effect on the way back down.
> 
> If I weren't able to specify a choice of upsampling methods, an alternative 
> would be to make a special ugen that filters its input but only looks at 1/N 
> samples.
> 
> cheers
> Miller
> 
> 
> 
> On 4/9/25 1:07 PM, Christof Ressi wrote:
>> 
>> Hi,
>> 
>> I have made a PoC for adding upsampling and reblocking support to 
>> SuperCollider: https://github.com/supercollider/supercollider/pull/6702
>> 
>> One thing I have been thinking about is the default upsampling method. 
>> Currently, I'm using zero-order-hold (ZOH), aka "sample and hold", which is 
>> also the default for Pd's [inlet~]. The other practical alternative would be 
>> zero-padding. Letting the users choose the method is not a real option, so I 
>> need to settle on a good default.
>> 
>> Generally, upsampling is done by zero-padding + low pass filtering.
>> 
>> ZOH is basically a low-quality low-pass filter. It's like a FIR filter that 
>> consists of a series of 1s and the frequency response is that of a Sinc 
>> function. AFAICT, it introduces high frequency noise, but I'm wondering how 
>> relevant that is when the output runs through an antialiasing filter anyway.
>> 
>> Zero-padding without low pass filtering results in repetitions of the 
>> original spectrum above the original Nyquist frequency. (It's like 
>> multiplying the signal with an impulse train, which results in the spectrum 
>> being convolved by an impulse train, resulting in a regular repetition.) I 
>> think that an *unfiltered*//zero-padded signal can lead to strange result. 
>> For example, a slowly moving ramp would almost look like an impulse train.
>> 
>> In my understanding, a zero-padded signal *must* be filtered, while an 
>> unfiltered ZOH signal may be acceptable for many use cases. Is this correct? 
>> @Miller: Is this maybe also the reason why Pd 0.44 has switched from "pad" 
>> to "hold" as the default upsample method in [inlet~]?
>> 
>> Zero-padding has the advantage that low pass filtering can fully restore the 
>> original signal, which apparently is not the case for a ZOH signal. On the 
>> other hand, it's always possible to zero-pad the input signal after the fact.
>> 
>> At the moment I'm tending to keep ZOH as the default upsampling method,

[PD] Re: Question about upsampling methods

[Christof Ressi]

On 09.04.2025 20:32, IOhannes m zmölnig wrote:


On 09/04/2025 16:54, Christof Ressi wrote:

On 09.04.2025 16:25, IOhannes m zmölnig wrote:

but here's my reasoning why I picked zero-padding in the original 
implementation:

>
Do you mean that you actually implemented the different upsampling 
methods? Or the upsampling mechnism itself? 


both.
i implemented upsampling, and obviously this required an upsampling 
method. i couldn't decide on one, so i implemented both trivial ones 
and the linear implementation.


Hats off!

I had no idea that [block~] initially only supported reblocking and 
overlap, but no upsampling/downsampling!





When was this?


indeed it precludes the git history.
i checked, and it even precludes the svn history :-)

according to the original file, this was done on 2001-09-25:
Wow, that is quite some time ago :) It's fascinating to browse the Pd 
sources from 25 years ago.


 





And what was the initial upsampling method?


it was always zero-padding.
 




fdmdas
IOhannes

---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YZGCP6NHWBKUQQ3ZL2RXJOCGTZYXO2FB/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/


---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DDTI2VUVD5MI2MFQZOZXRSVLZQND3IPN/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[IOhannes m zmölnig]

On 09/04/2025 16:54, Christof Ressi wrote:

On 09.04.2025 16:25, IOhannes m zmölnig wrote:

but here's my reasoning why I picked zero-padding in the original 
implementation:

>
Do you mean that you actually implemented the different upsampling 
methods? Or the upsampling mechnism itself? 


both.
i implemented upsampling, and obviously this required an upsampling 
method. i couldn't decide on one, so i implemented both trivial ones and 
the linear implementation.



When was this?


indeed it precludes the git history.
i checked, and it even precludes the svn history :-)

according to the original file, this was done on 2001-09-25:





And what was the initial upsampling method?


it was always zero-padding.



fdmdas
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YZGCP6NHWBKUQQ3ZL2RXJOCGTZYXO2FB/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[Christof Ressi]

On 09.04.2025 16:25, IOhannes m zmölnig wrote:


Am 9. April 2025 13:07:35 MESZ schrieb Christof Ressi:

In my understanding, a zero-padded signal *must* be filtered, while an unfiltered ZOH signal may be 
acceptable for many use cases. Is this correct? @Miller: Is this maybe also the reason why Pd 0.44 
has switched from "pad" to "hold" as the default upsample method in [inlet~]?

miller already answered why the default method has changed.

but here's my reasoning why I picked zero-padding in the original 
implementation:
Do you mean that you actually implemented the different upsampling 
methods? Or the upsampling mechnism itself? When was this? And what was 
the initial upsampling method?

I wanted the user to be aware that the signal *will* need filtering in most 
cases.
if ZOH is acceptable, it should be a conscious decision, rather than a 
default, that results in everybody complaining that the Pd's appalling is "somewhat shitty".
I see. But then again, ZOH is apparently good enough for many (most?) 
use cases and most people don't even think about it. I can totally see 
both points.

(so it's one of my dubious pedagogical devices)

:)



mfg.sfg.jfd
IOhannes
---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/IIMH434XKDIARLWHLBSKD56AEH7GYTZL/

To unsubscribe send an email topd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->https://lists.iem.at/---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/MRIMAE6ZXGQP2GSYN5MPFRUU36H6PUKE/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[IOhannes m zmölnig]

Am 9. April 2025 13:07:35 MESZ schrieb Christof Ressi :
>
>In my understanding, a zero-padded signal *must* be filtered, while an 
>unfiltered ZOH signal may be acceptable for many use cases. Is this correct? 
>@Miller: Is this maybe also the reason why Pd 0.44 has switched from "pad" to 
>"hold" as the default upsample method in [inlet~]?

miller already answered why the default method has changed. 

but here's my reasoning why I picked zero-padding in the original 
implementation: I wanted the user to be aware that the signal *will* need 
filtering in most cases. if ZOH is acceptable, it should be a conscious 
decision, rather than a default,
that results in everybody complaining that the Pd's appalling is "somewhat 
shitty".

(so it's one of my dubious pedagogical devices)


mfg.sfg.jfd
IOhannes
---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/IIMH434XKDIARLWHLBSKD56AEH7GYTZL/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[Christof Ressi]

Hi Miller,

On 09.04.2025 14:09, Miller Puckette wrote:
I ended up doing 'ZOH' after noticing that you get really strange 
results if you upsample a signal with zero-padding and then try to use 
it as the frequency of an oscillator... 

Yeah, that's exactly one of the cases I thought about...
the oscillator's frequency drops by the upsampling factor.  Another wa 
to say the same thing: the DC gain of a zero-padding upsampler is 1/N 
where N is the sampling factor.  You could correct this by multiplying 
the zero-padded signal by N but then what of someone tries to 
downsample it again... it then gets multiplied by N unless the 
downsampler averages all the N samples... and then we're back to 
something that resembles the ZOH filtering effect on the way back down.


If I weren't able to specify a choice of upsampling methods, an 
alternative would be to make a special ugen that filters its input but 
only looks at 1/N samples.


Yes, that's what I figured. Actually, you can do that by multiplying the 
signal with an impulse train at the original frequency 
(Impulse.ar(s.sampleRate)) and then applying a lowpass filter, but a 
dedicated UGen could be nice.


So I guess I will stick with ZOH unless somebody convinces me of the 
opposite :)




cheers
Miller



On 4/9/25 1:07 PM, Christof Ressi wrote:


Hi,

I have made a PoC for adding upsampling and reblocking support to 
SuperCollider: https://github.com/supercollider/supercollider/pull/6702


One thing I have been thinking about is the default upsampling 
method. Currently, I'm using zero-order-hold (ZOH), aka "sample and 
hold", which is also the default for Pd's [inlet~]. The other 
practical alternative would be zero-padding. Letting the users choose 
the method is not a real option, so I need to settle on a good default.


Generally, upsampling is done by zero-padding + low pass filtering.

ZOH is basically a low-quality low-pass filter. It's like a FIR 
filter that consists of a series of 1s and the frequency response is 
that of a Sinc function. AFAICT, it introduces high frequency noise, 
but I'm wondering how relevant that is when the output runs through 
an antialiasing filter anyway.


Zero-padding without low pass filtering results in repetitions of the 
original spectrum above the original Nyquist frequency. (It's like 
multiplying the signal with an impulse train, which results in the 
spectrum being convolved by an impulse train, resulting in a regular 
repetition.) I think that an *unfiltered*//zero-padded signal can 
lead to strange result. For example, a slowly moving ramp would 
almost look like an impulse train.


In my understanding, a zero-padded signal *must* be filtered, while 
an unfiltered ZOH signal may be acceptable for many use cases. Is 
this correct? @Miller: Is this maybe also the reason why Pd 0.44 has 
switched from "pad" to "hold" as the default upsample method in 
[inlet~]?


Zero-padding has the advantage that low pass filtering can fully 
restore the original signal, which apparently is not the case for a 
ZOH signal. On the other hand, it's always possible to zero-pad the 
input signal after the fact.


At the moment I'm tending to keep ZOH as the default upsampling 
method, but I would be curious about other people's opinions.


Christof






---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/4FJQN73I6OCQ6QKTSCSTXDF4NDNYF3WT/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/

[PD] Re: Question about upsampling methods

[Miller Puckette via Pd-list]

I ended up doing 'ZOH' after noticing that you get really strange 
results if you upsample a signal with zero-padding and then try to use 
it as the frequency of an oscillator... the oscillator's frequency drops 
by the upsampling factor.  Another wa to say the same thing: the DC gain 
of a zero-padding upsampler is 1/N where N is the sampling factor.  You 
could correct this by multiplying the zero-padded signal by N but then 
what of someone tries to downsample it again... it then gets multiplied 
by N unless the downsampler averages all the N samples... and then we're 
back to something that resembles the ZOH filtering effect on the way 
back down.


If I weren't able to specify a choice of upsampling methods, an 
alternative would be to make a special ugen that filters its input but 
only looks at 1/N samples.


cheers
Miller



On 4/9/25 1:07 PM, Christof Ressi wrote:


Hi,

I have made a PoC for adding upsampling and reblocking support to 
SuperCollider: https://github.com/supercollider/supercollider/pull/6702


One thing I have been thinking about is the default upsampling method. 
Currently, I'm using zero-order-hold (ZOH), aka "sample and hold", 
which is also the default for Pd's [inlet~]. The other practical 
alternative would be zero-padding. Letting the users choose the method 
is not a real option, so I need to settle on a good default.


Generally, upsampling is done by zero-padding + low pass filtering.

ZOH is basically a low-quality low-pass filter. It's like a FIR filter 
that consists of a series of 1s and the frequency response is that of 
a Sinc function. AFAICT, it introduces high frequency noise, but I'm 
wondering how relevant that is when the output runs through an 
antialiasing filter anyway.


Zero-padding without low pass filtering results in repetitions of the 
original spectrum above the original Nyquist frequency. (It's like 
multiplying the signal with an impulse train, which results in the 
spectrum being convolved by an impulse train, resulting in a regular 
repetition.) I think that an *unfiltered*//zero-padded signal can lead 
to strange result. For example, a slowly moving ramp would almost look 
like an impulse train.


In my understanding, a zero-padded signal *must* be filtered, while an 
unfiltered ZOH signal may be acceptable for many use cases. Is this 
correct? @Miller: Is this maybe also the reason why Pd 0.44 has 
switched from "pad" to "hold" as the default upsample method in [inlet~]?


Zero-padding has the advantage that low pass filtering can fully 
restore the original signal, which apparently is not the case for a 
ZOH signal. On the other hand, it's always possible to zero-pad the 
input signal after the fact.


At the moment I'm tending to keep ZOH as the default upsampling 
method, but I would be curious about other people's opinions.


Christof





---
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/YTQLO35UO4XHQT7GVNTMY43S3CAL4S57/

To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/