that sounds like a re-blocking delay, rather than anything to do with vline~<br><br><br><br><div class="gmail_quote">On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>><br>
> To: Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
</div><div><div></div><div class="h5">> Cc: pd-list <<a href="mailto:pd-list@iem.at">pd-list@iem.at</a>><br>
> Sent: Tuesday, September 20, 2011 6:05 PM<br>
> Subject: Re: [PD] stop sample playback when phasor~ reset?<br>
><br>
> On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote:<br>
>><br>
>><br>
>><br>
>> ----- Original Message -----<br>
>> > From: Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>><br>
>> > To: Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
>> > Cc: tim vets <<a href="mailto:timvets@gmail.com">timvets@gmail.com</a>>; Pierre Massat<br>
> <<a href="mailto:pimassat@gmail.com">pimassat@gmail.com</a>>; James Dunn <<a href="mailto:james@4thharmonic.com">james@4thharmonic.com</a>>; pd-list<br>
> <<a href="mailto:pd-list@iem.at">pd-list@iem.at</a>><br>
>> > Sent: Tuesday, September 20, 2011 3:35 AM<br>
>> > Subject: Re: [PD] stop sample playback when phasor~ reset?<br>
>> ><br>
>> > On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> >________________________________<br>
>> >> >From: tim vets <<a href="mailto:timvets@gmail.com">timvets@gmail.com</a>><br>
>> >> >To: Pierre Massat <<a href="mailto:pimassat@gmail.com">pimassat@gmail.com</a>>; James Dunn<br>
>> > <<a href="mailto:james@4thharmonic.com">james@4thharmonic.com</a>>; pd-list <<a href="mailto:pd-list@iem.at">pd-list@iem.at</a>><br>
>> >> >Sent: Monday, September 19, 2011 4:08 PM<br>
>> >> >Subject: Re: [PD] stop sample playback when phasor~ reset?<br>
>> >> ><br>
>> >> ><br>
>> >> >When you use phasor~, you normally already know how long it<br>
> will take<br>
>> > for the sound to be finished playing (because you set its frequency to<br>
> play it<br>
>> > back at the proper speed)<br>
>> >> >Store the information about the sound loaded (or recorded)<br>
> and use that<br>
>> > to stop the playback after one play duration.<br>
>> >> ><br>
>> >> ><br>
>> >> >[del <time>]<br>
>> >> >|<br>
>> >> >[t b b]<br>
>> >> >| |<br>
>> >> >[0( [0(<br>
>> >> >[ |<br>
>> >> >[phasor]<br>
>> >><br>
>> >> What's the benefit of this over a line~ based approach?<br>
>> >><br>
>> ><br>
>> > [line~] is inferior to [phasor~] in that it only starts a ramp on<br>
> block<br>
>> > boundaries. Using [vline~] seems to me most flexible in terms of<br>
> sample<br>
>> > playback as it can start a ramp even in-between samples.<br>
>><br>
>> That depends on how one uses [phasor~]. In the example above the initial<br>
>> ramp must start on a block boundary-- whatever is triggering [del<br>
> <time>] must<br>
>> also send the relevent frequency to [phasor~] for playing the sound stored<br>
> in the<br>
>> array. Those actions must happen with control objects, which means they<br>
> will<br>
>> affect the signal objects at the beginning of the next block.<br>
>><br>
>> However, for the ramp at the end of playback [phasor~] as used above can<br>
>> produce a ramp that begins/ends in the middle of a block ( [vline~] too),<br>
>> whereas [line~] cannot. Of course I'm just talking about situations<br>
> implied<br>
>> by the example above, where the user is just triggering events sporadically<br>
><br>
>> using control objects.<br>
><br>
> What do you mean by 'triggering events sporadically using control<br>
> objects'? Aren't [delay] and [metro] also control objects? If those are<br>
> generating the event, you have more precise timing than only block<br>
> boundaries. We actually don't know what would be triggering the [del] in<br>
> the above patch (or probably I missed it?).<br>
><br>
> Either way, the above patch would convert the precise timing to only<br>
> block boundaries timing because the frequency inlet of [phasor~] only<br>
> evaluates control messages on block boundaries.<br>
><br>
> Using [vline~ ], however, would actually use the precise timing of the<br>
> event.<br>
><br>
><br>
>> Neither [line~] nor [vline~] will trigger a ramp in the<br>
>> middle of the current block, so if you're rule is "IF sample<br>
> playback THEN<br>
>> [vline~] > [line~]" there are probably times you're wasting<br>
> cpu.<br>
><br>
> Sorry, if I am missing your point, but how do you know that [vline~ ]<br>
> wouldn't trigger a ramp in the middle of block in this case?<br>
<br>
</div></div>I didn't write that [vline~] cannot trigger a ramp in the middle of a block-- it<br>
obviously can. I wrote that neither object can start a ramp in the middle of<br>
the current block. In fact, [line~] will almost always trigger sooner than<br>
[vline~], because [line~] starts the ramp immediately at the next block, and<br>
[vline~] at minimum will be delayed exactly one block.<br>
<br>
I have an example patch that shows this but for some reason I can't attach<br>
it in Yahoo mail. But just make a simple amplitude envelop inside a<br>
subpatch with a large blocksize (greater than one second will do), then<br>
try triggering your envelope using [vline~].<br>
<font color="#888888"><br>
-Jonathan<br>
</font><div><div></div><div class="h5"><br>
><br>
> Roman<br>
><br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br>