[PD] stop sample playback when phasor~ reset?

Jonathan Wilkes jancsika at yahoo.com
Wed Sep 21 01:42:03 CEST 2011





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



More information about the Pd-list mailing list