----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: Jonathan Wilkes jancsika@yahoo.com 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?
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