> Cc: pd-list <
pd-list@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@gmail.com>
>> > To: Jonathan Wilkes <
jancsika@yahoo.com>
>> > Cc: tim vets <
timvets@gmail.com>; Pierre Massat
> <
pimassat@gmail.com>; James Dunn <
james@4thharmonic.com>; pd-list
> <
pd-list@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@gmail.com>
>> >> >To: Pierre Massat <
pimassat@gmail.com>; James Dunn
>> > <
james@4thharmonic.com>; pd-list <
pd-list@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?