[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