[PD] How does vline~ work under the hood?

[Matt Barber]

As always, it's good to include a demo patch when you have a question like
this. I wasn't sure what you meant by "jitter" initially, but now I
understand it because [line~] isn't translating your [metro] faithfully.
You can see that jitter in the patch I attached above. It's important to
see how [line~] starts its ramps *before* the logical time of the
clock-delayed triggers -- those have to be scheduled before the target
block starts executing, and [line~] quantizes them to the beginning of the
target block.

On Sat, Sep 26, 2015 at 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/65907ed4/attachment-0001.html>