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? Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list