[PD] stop sample playback when phasor~ reset?

Pierre Massat pimassat at gmail.com
Tue Sep 20 10:06:01 CEST 2011


Yeah, a threshold~ set to 1 is never triggered (or very rarely).
So there's no perfect answer to the question it seems...

Pierre

2011/9/20 Roman Haefeli <reduzent at gmail.com>

> On Tue, 2011-09-20 at 09:43 +0200, Pierre Massat wrote:
> > I m curious to know which object you would recommend instead of
> > threshold~ (the delay way is obviously not feasible as soon as you
> > need to change the speed of phasor~ during palyback).
>
> Yeah, [threshold~] seems feasible, but this approach suffers from a few
> issues. As I said before, the bang comes only on block boundaries and is
> at least one block late, so it's not very precise. Also, a [phasor~]
> probably never reaches exactly 1 (or 0) and it is less likely the higher
> the frequency is. So you would need values like 0.001 or 0.999 for the
> [threshold~] which again makes it a bit more imprecise.
>
> You can also use the [vline~] approach and change the speed in the
> middle of the playback, though it needs a bit of patching to accomplish
> that. You need a delay, that is triggered at the time of the speed
> change. The delay value can be used to calculate the current position of
> the play head. Then you can use that value as a start point for a new
> message to [vline~].
>
> Roman
>
>
> > 2011/9/20 Roman Haefeli <reduzent at gmail.com>
> >         On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote:
> >         >
> >         >
> >         >
> >         >
> >         > >________________________________
> >         > >From: tim vets <timvets at gmail.com>
> >         > >To: Pierre Massat <pimassat at gmail.com>; James Dunn
> >         <james at 4thharmonic.com>; pd-list <pd-list at iem.at>
> >         > >Sent: Monday, September 19, 2011 4:08 PM
> >         > >Subject: Re: [PD] stop sample playback when phasor~ reset?
> >         > >
> >         > >
> >         > >When you use phasor~, you normally already know how long it
> >         will take for the sound to be finished playing (because you
> >         set its frequency to play it back at the proper speed)
> >         > >Store the information about the sound loaded (or recorded)
> >         and use that to stop the playback after one play duration.
> >         > >
> >         > >
> >         > >[del <time>]
> >         > >|
> >         > >[t  b  b]
> >         > >|        |
> >         > >[0(     [0(
> >         > >[        |
> >         > >[phasor]
> >         >
> >         > What's the benefit of this over a line~ based approach?
> >         >
> >
> >         [line~] is inferior to [phasor~] in that it only starts a ramp
> >         on block
> >         boundaries. Using [vline~] seems to me most flexible in terms
> >         of sample
> >         playback as it can start a ramp even in-between samples.
> >
> >         Using [threshold~] or any other method to detect the reset of
> >         [phasor~]
> >         is not feasible, because of two reasons:
> >          * [threshold] (but also [snapshot~]) output the bang only at
> >         block
> >         bounaries, so the detection is not very precise
> >          * Whenever the the audio domain (a signal) causes an event in
> >         the
> >         message domain (that's what [threshold~] and [snapshot~] are
> >         for), the
> >         event is at least one block late.
> >
> >         There is still one advantage of [phasor~] over [vline~]: The
> >         speed of
> >         the [phasor~] can be changed at signal rate, so one can create
> >         continuous pitch changes when playing the sample. That's not
> >         possible
> >         with [vline~].
> >
> >         Roman
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110920/9c95c452/attachment.htm>


More information about the Pd-list mailing list