Hi Matt,In my day-long block example, the [metro 150] is "triggering" the [tgl]
to [vline~]. I am just usingday-long blocks to show that once a block has been
computed you can't use [vline~] to travel back in time and change it. You have
to wait till Tuesday-- the next block.
Of course you could have sent a bang to a [delay] object on Sunday that
triggers the [metro 150] tostart on noon, Monday. But the point is you have to
start somewhere-- whether it's GUI events orloading a patch.
This isn't a big deal for Pd users because-- again-- I can't think of a case
where this ends up gettingin their way. But when people start inspecting the
code, I think they have to understand this. It'sway too tantalizing to just
assume that sub-block accuracy means you have to be able to interrupta perform
routine in the middle of calculations. That isn't true, but a) it's not
obvious why it isn'ttrue, and b) externals that check for clock events in a
perform routine are almost certainly doingit wrong.
But again, check my logic because this stuff is difficult to understand and
harder to explain. :)
-Jonathan
On Saturday, September 26, 2015 12:51 PM, Matt Barber
<[email protected]> wrote:
It depends on what you mean by "trigger". Triggered by the mouse, I think
you're right. But see the attached patch. Since [del] (among other objects, but
I used [del] here for clarity) can schedule bangs between boundaries, you can
trigger [vline~] in the middle of blocks. Not so with [line~]: if a bang is
scheduled in that block, it starts the ramp at the beginning of that block and
ends it at the end of a future block such that the total ms of the ramp does
not exceed the requested ms.
On Sat, Sep 26, 2015 at 12:01 PM, Jonathan Wilkes <[email protected]> wrote:
What I mean is that both [line~] and [vline~] receive their messages on block
boundaries.But unlike [line~], [vline~] can start/end ramps and jump to the
values you give it without beinglimited by block boundaries.
Another example with my day-long block sizes:
At noon on Monday you send a bang to [metro 150]--[tgl]--[vline~]. You'll
haveto wait until noon Tuesday to hear the result, but you _will_ hear that
same pattern of ones andzeros spaced 150ms apart that you were sending on
Monday, even though the block size lasts aday. That's the strength of [vline~].
On the other hand, the [line~] object would just take the last [tgl] value it
received on Monday(before it begins computing Tuesday's block), and it would
just repeat that value the entire day of Tuesday. If you had sent it a ramp
time, you would get your ramp Tuesday, but it would necessarilystretch across
the entire day of Tuesday because that is the block size.
Essentially-- you can't send a message that would interrupt the [vline~]
object's perform routineand feed it new values. But because block sizes are
usually small, I can't think of asituation where you'd need to do that.
It occurs to me I could be wrong about any or all of this. If so I'm certain
Matt or Miller can setme straight.
-Jonathan
-Jonathan
On Saturday, September 26, 2015 10:24 AM, i go bananas
<[email protected]> wrote:
In that case, maybe an even simpler question:
What is the difference between sending a [1, 0 50( message to vline as opposed
to line ?
Why does line exhibit jitter, if both only trigger on block boundaries?
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
