[PD] Audio delay by samples (for comb filter)

Ingo ingo at miamiwave.com
Mon Jan 27 14:11:28 CET 2020


Thanks Hans and IOhannes!

I'll take a look at this as well but so far [zexy/z~] looks best to me.

Ingo


>> I also needed a delay in samples and so I made an abstraction in Pd 
>> vanilla, delaying a signal with x number of  samples; for example a one
>> sample delay is [delaysam 1]
>> I think this is the correct way of doing this without needing externals...
>> Hans


> -----Original Message-----
> From: Pd-list [mailto:pd-list-bounces at lists.iem.at] On Behalf Of IOhannes m
> zmoelnig
> Sent: Monday, January 27, 2020 2:02 PM
> To: pd-list at lists.iem.at
> Subject: Re: [PD] Audio delay by samples (for comb filter)
>
> On 27.01.20 11:29, info at hansroels.be wrote:
> >
> > I also needed a delay in samples and so I made an abstraction in Pd
> > vanilla, delaying a signal with x number of  samples; for example a
> > one sample delay is [delaysam 1] I think this is the correct way of
> > doing this without needing externals...
>
> kind of.
>
> - using [$1] can give you all kinds of nasty surprises, as you can e.g.
> use [delaysam samplerate~]. i'd rather go for [float $1] instead.
> - debugging printout (and a fan-out!) should be removed
> - why do you use [vd~]? do you need fractional sample-delay (the answer
> might well be "yes")? if not, than [vd~] is just taking more CPU-power...
> - why do you ramp to the target-delay with [line~]? since you cannot change
> the delay after the instantiation, i would rather have it jump to the target
> delay immediately.
>
> gfasdrm,
> IOhannes








More information about the Pd-list mailing list