I have a vline going into a cos~ and into a tabwrite~ plottercos ( range -1 +1 ) for plotting . tabwrite~ ramp has a range 0 +1
Upon a few bangs , the cosine is completely out of phase
I tried tbb first into vline , then into tabwrite ~ and vice versa but the issue still remains
You can clearly see in the second window ( vline~ without cos) that vline has a value 0 < upon it's start phase
Weird

@gentleclockdivider I will guess that it's because [vline~] can start and end between block boundaries, and [tabwrite~] cannot.
Unless you are hitting the bang again within 1 second, in which case try banging a zero into [vline~] first....... i.e. [0, 1 500, 0 500 500(
But I will defer to somebody that actually knows.
David.

@whale-av said:

But I will defer to somebody that actually knows.

Not implying that that someone is me, but I'm wondering if the OP might get the behavior they expect if they used [line~] instead? I think [vline~] has fancy features I don't know about and have never needed (but don't quote me).

@jameslo Yes, I thought the same..
.... and it is recently documented that timing in [vline~] is inaccurate if re-blocked in a sub-patch....!
David.

Oh wait, I can reproduce that behavior if I click a second time before the first click has completed. Maybe that's what's wrong? To address the issue I think you need to add a zero to the beginning of that vline~ message, i.e. [0, 1 500 0, 0 500 500(. That makes sure the first ramp always starts from 0.

The vline~ was mostdef. not in subpatch
Will investigate further
Else envgen~is really accurate

@jameslo Yes, I thought it might have been banged again before it had finished (see my post above) because the slope to the midpoint is different in the second graph.
David.

@whale-av OMG I was so fixated on the part I quoted that I didn't see that you had already offered that theory. COMPLETE BLINDNESS

As an aside, in situations where you need to plot [line~] or [vline~] it is often more efficient to just duplicate the logic in the message domain with plain old [line]. Keeping as much of the GUI in the message domain can help avoid audio drop outs and if your patch gets to the point of hitting the limits of pd's single thread nature this will make it easier to separate UI from audio into their own threads/cores with [pd~] or [netsend]. Assuming you will hit the wall can save you major refactoring if/when you do hit the wall.