[PD] How does vline~ work under the hood?
Matt Barber
brbrofsvl at gmail.com
Sun Sep 27 07:59:14 CEST 2015
The ramp segments themselves are pretty simple once they get going -- the
entire thing is calculated at once, and then it's just a matter of adding
the resulting constant increment until the target time has elapsed, or a
new event supersedes the current ramp. This is less than the interpolation
formula in [tabread4~], and not much more than what [line~] itself has to
do (although all the time stuff is done using doubles so there may be some
overhead there depending on architecture). But it does have to run one or
more nested conditionals every sample. Most of the time it's checking to
see if there's something in the linked list, so there isn't much to do, but
if you sent it a bunch of events at once, it's got a lot of things it has
to do. Here's the per-sample for-loop:
--------------------------------------------
for (i = 0; i < n; i++)
{
double timenext = timenow + msecpersamp;
checknext:
if (s)
{
/* has starttime elapsed? If so update value and increment */
if (s->s_starttime < timenext)
{
if (x->x_targettime <= timenext)
f = x->x_target, inc = 0;
/* if zero-length segment bash output value */
if (s->s_targettime <= s->s_starttime)
{
f = s->s_target;
inc = 0;
}
else
{
double incpermsec = (s->s_target - f)/
(s->s_targettime - s->s_starttime);
f = f + incpermsec * (timenext - s->s_starttime);
inc = incpermsec * msecpersamp;
}
x->x_inc = inc;
x->x_target = s->s_target;
x->x_targettime = s->s_targettime;
x->x_list = s->s_next;
t_freebytes(s, sizeof(*s));
s = x->x_list;
goto checknext;
}
}
if (x->x_targettime <= timenext)
f = x->x_target, inc = x->x_inc = 0, x->x_targettime = 1e20;
*out++ = f;
f = f + inc;
timenow = timenext;
}
-----------------------------------
That's a lot of conditionals. Luckily all of the clock function calls and
the can take place outside this loop because sample rate is constant, and
the knotty boolean algebra for structuring the event list is handled in the
vline_tilde_float method. The *goto checknext *here adds one extra pass if
there are two events scheduled for the same time (I think the
vline_tilde_float method ensures that the only way this can happen is in
the "leap, then ramp" scenario). Allocating new events (in the
vline_tilde_float method) and deallocating past events from the linked list
— t_freebytes(s, sizeof(*s)); here — also has some overhead not encountered
in [line~].
In general, [vline~] has more to do per event scheduled, and also more to
do per sample, than [line~].
On Sun, Sep 27, 2015 at 1:03 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> > And what vline does, is it reads that list, and then schedules itself to
> be hit after the correct amount of logical time has elapsed.
>
> I'm not exactly sure what "schedules itself" means here. So I'll just
> start explaining how it works until I understand it myself... :)
>
> The [vline~]
> object processes blocks of samples at a time (in vline_tilde_perform).
> But
> any of those clock events Frank mentioned that happen to be "ripe" for
> the upcoming block get sent to the "float" method of line
> (vline_tilde_float),
> which adds them to the linked list x_xlist.
>
> For example,
> suppose you have the following:
>
> [0 0.1, 1 0.2(
> |
> [pipe]
> |
> [vline~]
> |
> [print~]
>
> When you click the message box, [pipe] does the proper clock delay for
> each message: the "0" is scheduled for 0.1ms in the future, and the "1" is
> scheduled for 0.2ms. But these delay times take less time to fire than it
> takes to compute a block. So if [vline~] is calculating its output in
> blocks
> of 64 samples, when does it actually receive the output from [pipe~]?
>
> The answer is that Pd actually sends the "0" and "1" messages to [vline~]
> one after the other, before it calculates the next block. By "send" I
> mean it
> calls the function vline_tilde_float with the float argument "0", and then
> it calls
> vline_tilde_float with the float argument "1". But before each of those
> calls, it updates the "sys_time" to be the time when that clock was set to
> go off. So if the "0" was set to go off at "now + 0.1", Pd sets "now+0.1"
> to be the new system time, then it sends the "0" message to
> vline_tilde_float. And before it sends "1",
> it sets the sys_time to "now + 0.2".
>
> Let's go back to vline_tilde_float-- notice in the first line we're
> fetching the
> sys_time. And what is it going to be for our "0" message? As stated
> above, we
> set it to "now + 0.1". Great! And when we process "1" message, we get
> "now + 0.2". Thus, [vline~] adds those messages and their associated
> timings to the linked list.
>
> Finally, we do [vline~] perform routine. It starts with the time equal to
> what it
> was at the beginning of the block. Then it loops through our block's
> samples
> until it reaches a sample that corresponds to the time that an event in our
> linked list needs to be triggered. When we reach that sample, we jump to
> the new value.
>
> It's the same process for ramps, except that vline~ calculates an increment
> value for the ramp.
>
> After looking, I'm kind of curious what is most responsible for [vline~]
> overhead. I'd guess it's the math needed to set each ramp segment, but
> I'm not
> certain.
>
> -Jonathan
>
>
> On Saturday, September 26, 2015 10:55 PM, i go bananas <hard.off at gmail.com>
> wrote:
>
>
> I actually think Frank might have the my answer here.
>
> What i'm noticing, is not an inconsistency in the length of the ramps.
> It's an inconsisency in when they are first triggered. This is for stuff
> like the initial click of a bassdrum, so you can even hear the difference
> quite clearly. The line object jumps around, as it is being triggered on
> block boundaries, but the vline object is faithfully consistent in starting
> at the exact TIME i ask it to - regardless of blocksize, etc.
>
> The only logical answer i can see here, is the one Frank has given. I'm
> scheduling drums using a clock controlled by metro.
>
> So what i'm guessing that Frank is suggesting here, is that the scheduler
> is keeping a list of all the metro and delay bangs that should arrive in
> the upcoming block, and sceduling them to be hit while the block plays.
> And what vline does, is it reads that list, and then schedules itself to be
> hit after the correct amount of logical time has elapsed.
>
> And i would guess that the normal line object is not capable of that. It
> just waits until block boundaries and starts its simple incrementation.
>
> So, going back to Jonathan's day-long block example, i can see now how
> that works. the line can only be triggered once, at the start of the block
> (i still have doubts that it would actually stretch to the length of the
> block though. I reckon a 50ms line is still gonna take 50ms. )
> But the vline has that linked list inbuilt, and it reads from the
> scheduler to see when it should be triggered. So if you had the day-long
> block, then vline's linked list is gonna end up with a full day's worth of
> messages in it!
>
> Anyway, i'll go back to the source code tomorrow and have another look.
> But pretty sure that i now see how it is the ability to look ahead at metro
> scheduled events that gives vline the accuracy i need.
>
> Thanks Matt for suggesting i look at the clock, and scheduler code, thanks
> Jonothan for the great example of the day long block - taking things to
> extremes like that is a good way to see how they work. And thanks Frank
> for finally turning on that lightbulb and suggesting the role that metro
> was playing here.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150927/582df1b6/attachment.html>
More information about the Pd-list
mailing list