[PD] stop sample playback when phasor~ reset?

hardoff goes bananas hard.off at gmail.com
Wed Sep 21 03:45:55 CEST 2011


that sounds like a re-blocking delay, rather than anything to do with vline~



On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

>
>
>
>
> ----- Original Message -----
> > From: Roman Haefeli <reduzent at gmail.com>
> > To: Jonathan Wilkes <jancsika at yahoo.com>
> > Cc: pd-list <pd-list at iem.at>
> > Sent: Tuesday, September 20, 2011 6:05 PM
> > Subject: Re: [PD] stop sample playback when phasor~ reset?
> >
> > On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote:
> >>
> >>
> >>
> >>  ----- Original Message -----
> >>  > From: Roman Haefeli <reduzent at gmail.com>
> >>  > To: Jonathan Wilkes <jancsika at yahoo.com>
> >>  > Cc: tim vets <timvets at gmail.com>; Pierre Massat
> > <pimassat at gmail.com>; James Dunn <james at 4thharmonic.com>; pd-list
> > <pd-list at iem.at>
> >>  > Sent: Tuesday, September 20, 2011 3:35 AM
> >>  > Subject: Re: [PD] stop sample playback when phasor~ reset?
> >>  >
> >>  > 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.
> >>
> >>  That depends on how one uses [phasor~].  In the example above the
> initial
> >>  ramp must start on a block boundary-- whatever is triggering [del
> > <time>] must
> >>  also send the relevent frequency to [phasor~] for playing the sound
> stored
> > in the
> >>  array.  Those actions must happen with control objects, which means
> they
> > will
> >>  affect the signal objects at the beginning of the next block.
> >>
> >>  However, for the ramp at the end of playback [phasor~] as used above
> can
> >>  produce a ramp that begins/ends in the middle of a block ( [vline~]
> too),
> >>  whereas [line~] cannot.  Of course I'm just talking about situations
> > implied
> >>  by the example above, where the user is just triggering events
> sporadically
> >
> >>  using control objects.
> >
> > What do you mean by 'triggering events sporadically using control
> > objects'? Aren't [delay] and [metro] also control objects? If those are
> > generating the event, you have more precise timing than only block
> > boundaries. We actually don't know what would be triggering the [del] in
> > the above patch (or probably I missed it?).
> >
> > Either way, the above patch would convert the precise timing to only
> > block boundaries timing because the frequency inlet of [phasor~] only
> > evaluates control messages on block boundaries.
> >
> > Using [vline~ ], however, would actually use the precise timing of the
> > event.
> >
> >
> >>   Neither [line~] nor [vline~] will trigger a ramp in the
> >>  middle of the current block, so if you're rule is "IF sample
> > playback THEN
> >>  [vline~] > [line~]" there are probably times you're wasting
> > cpu.
> >
> > Sorry, if I am missing your point, but how do you know that [vline~ ]
> > wouldn't trigger a ramp in the middle of block in this case?
>
> I didn't write that [vline~] cannot trigger a ramp in the middle of a
> block-- it
> obviously can.  I wrote that neither object can start a ramp in the middle
> of
> the current block.  In fact, [line~] will almost always trigger sooner than
> [vline~], because [line~] starts the ramp immediately at the next block,
> and
> [vline~] at minimum will be delayed exactly one block.
>
> I have an example patch that shows this but for some reason I can't attach
> it in Yahoo mail.  But just make a simple amplitude envelop inside a
> subpatch with a large blocksize (greater than one second will do), then
> try triggering your envelope using [vline~].
>
> -Jonathan
>
> >
> > Roman
> >
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110921/3ad842c3/attachment-0001.htm>


More information about the Pd-list mailing list