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 <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. On Sat, Sep 26, 2015 at 12:01 PM, Jonathan Wilkes jancsika@yahoo.com 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 <hard.off@gmail.com> 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?