[PD] stop sample playback when phasor~ reset?

[Jonathan Wilkes]

----- 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.  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.

The first paragraph of 
3.audio.examples/C04.control.to.signal.pd
spells it out pretty well.

-Jonathan

> 
> 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
>