Hi Matt,
In my day-long block example, the [metro 150] is "triggering" the [tgl] to [vline~]. I am just using
day-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] to
start on noon, Monday. But the point is you have to start somewhere-- whether it's GUI events or
loading a patch.
This isn't a big deal for Pd users because-- again-- I can't think of a case where this ends up getting
in their way. But when people start inspecting the code, I think they have to understand this. It's
way too tantalizing to just assume that sub-block accuracy means you have to be able to interrupt
a perform routine in the middle of calculations. That isn't true, but a) it's not obvious why it isn't
true, and b) externals that check for clock events in a perform routine are almost certainly doing
it 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 <brbrofsvl@gmail.com> 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.