[PD] stop sample playback when phasor~ reset?
Jonathan Wilkes
jancsika at yahoo.com
Wed Sep 21 05:01:55 CEST 2011
>________________________________
>From: hardoff goes bananas <hard.off at gmail.com>
>To: Jonathan Wilkes <jancsika at yahoo.com>
>Cc: Roman Haefeli <reduzent at gmail.com>; pd-list <pd-list at iem.at>
>Sent: Tuesday, September 20, 2011 9:45 PM
>Subject: Re: [PD] stop sample playback when phasor~ reset?
>
>
>that sounds like a re-blocking delay, rather than anything to do with vline~
I'm not sure how to measure it without changing the blocksize to make
the response time obvious. If anyone has a better idea for an example,
please post it.
See:
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html#fig03.04
Notice that for all three examples of the conversion, the first time value for the
control event is 2, but the earliesttime this event is reflected in the
audio signal is at time value 4, which corresponds with signal index 0--
that's in part A, the "fast as possible" method. This corresponds to the way
[line~] works, and that's as fast as you can possibly go-- updating the value
at the very beginning of the next block.
Parts B and C describe the type of sample accuracy you can get with [vline~],
but notice that both examples actually start at time 6-- signal indexes 0 and 1
correspond to the values at time 0 and 1, and so signal index 2 coincides with
the value from the previous block at time 2. That's why the 1st method is
called "fast as possible".
That's why if you build a simple attack/release envelope in a subpatch with a
large blocksize (greater than 1 sec), if you use [line~] you'll notice that the
envelope starts/stops at various intervals after you trigger it (depending on
how close the triggering is to the end of the current block being heard). With
[vline~], you get a constant time interval between triggering and hearing the
event. As in the table above, that constant time interval corresponds exactly
to however long it takes to output one block of audio.
Hopefully that's how it really works, I get kind of confused when dealing with
this aspect of Pd. :)
-Jonathan
>
>
>
>
>On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>
>>
>>
>>
>>----- Original Message -----
>>> From: Roman Haefeli <reduzent at gmail.com>
>>> To: Jonathan Wilkes <jancsika at yahoo.com>
>>
>>> Cc: pd-list <pd-list at 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 at gmail.com>
>>>> > To: Jonathan Wilkes <jancsika at yahoo.com>
>>>> > Cc: tim vets <timvets at gmail.com>; Pierre Massat
>>> <pimassat at gmail.com>; James Dunn <james at 4thharmonic.com>; pd-list
>>> <pd-list at 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 at gmail.com>
>>>> >> >To: Pierre Massat <pimassat at gmail.com>; James Dunn
>>>> > <james at 4thharmonic.com>; pd-list <pd-list at 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 at iem.at mailing list
>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
More information about the Pd-list
mailing list