[PD] stop sample playback when phasor~ reset?

[Roman Haefeli]

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?

Roman