that sounds like a re-blocking delay, rather than anything to do with vline~
On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote: > > > > > ----- Original Message ----- > > From: Roman Haefeli <reduz...@gmail.com> > > To: Jonathan Wilkes <jancs...@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 <reduz...@gmail.com> > >> > To: Jonathan Wilkes <jancs...@yahoo.com> > >> > Cc: tim vets <timv...@gmail.com>; Pierre Massat > > <pimas...@gmail.com>; James Dunn <ja...@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 <timv...@gmail.com> > >> >> >To: Pierre Massat <pimas...@gmail.com>; James Dunn > >> > <ja...@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 > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
