mention negative delay time in vline~ messages

[sebshader]

vline~ accepts negative delay time in its messages, which immediately clears the queue and jumps to the given value. from the comment in the source:

        /* negative delay input means stop and jump immediately to new value */

We should mention this in the docs

[porres]

how does that work? can you give an example?

[sebshader]

here is a simple example

vline_negative_example.zip

if you use the '-1' message box, when the vline gets the delayed message it immediately sets the value, which has the same effect as a message setting a sig~ (it will have that value at the beginning of the audio block)

if you keep it as '0' it uses the logical time the message is received, per usual for vline~.

[porres]

Sorry, but I I think the text and everything is still confusing. As I see it, the [vline~] seems to 'go back in time' and simply take actions at the beginning of the block, ignoring the actual time it should do its thing.

In my test I was also able to see that a negative value will ignore the ramp time and jump immediately. This information was missing.

I honestly don't see the use case anyway. Specially because I don't see a way to use this with scheduled segments that we could use in a single message, split by commas (since it would just clear and ignore the previous messages).

Is there a use case in mind here?

[porres]

"If you set the time to '-1' or less, the [vline~] ignores the delayed time it received the message and jumps to the value at the beggining of the block, which has the same effect as a message setting a [sig~] object. Note that a negative schedule also ingores the ramp time and immediately jumps to the value."

This is what I would say. I can document it, but I'm still struggling to see the point of this feature. Cause I imagine people will use [vline~] for what it does, not to behave like [sig~]. I get though that the object can behave as it is designed and also as [sig~] in the same patch if needed, but no use case comes to mind.

[sebshader]

well the feature exists, and maybe once users are aware of it they will come up with use cases for it.
on the Pd forum (I think you saw the thread?) there was a case to sync the vline~ to some other objects that are triggered at block-boundaries. with careful application this feature could be relevant in certain cases like that I think (when you want the initial jump of the vline~ synced to other block-synced objects)

also a small note: it doesn't have to be -1 or less, it's any negative number (could be between -1 and zero as well)

[sebshader]

Sorry, but I think the text and everything is still confusing. As I see it, the [vline~] seems to 'go back in time' and simply take actions at the beginning of the block, ignoring the actual time it should so its thing.

it does the same that sig~ and line~ do..

In my test I was also able to see that a negative value will ignore the ramp time and jump immediately. This information was missing.

I thought it was clear in the initial comment..

I honestly don't see the use case anyway. Specially because I don't see a way to use this with scheduled segments that we could use in a single message, split by commas (since it would just clear and ignore the previous messages).

only the negative-delay message clears the queue, so [1 0 -1, 0 200 300( would clear the queue and jump to 1 at the beginning of the block, but then still ramp to 0 over 200 ms 300 ms after the message was received. You can still use scheduled segments after the block-boundary jump.

[porres]

I mentioned in the thread that one should just use [line~] instead :) why use [vline~] if you want it to behave like [line~] or [sig~]?

[porres]

So, [1 0 0, 0 200 300( also clears the queue, right? this is because a segment cancels all planned segments at any future time. When you say that, it seems this only happens if you use "-1", which is misleading.

[porres]

You can still use scheduled segments after the block-boundary jump.

I never questioned that

[ben-wes]

i can't contribute much here since i admittedly didn't understand the use cases yet completely. but i assume that there's some reasoning behind the code that @sebshader is referring to above:

https://github.com/pure-data/pure-data/blob/e043d87a85597f353be8ea2e3351f9d3b907cd01/src/d_ctl.c#L302-L308

not sure how to document this in an understandable way - but would be nice if it wasn't a hidden feature for sure. i was surprised to learn about this!

[porres]

First the feature needs to be clear and understood, but it is still unclear to me :)

[porres]

Ok, if you have this negative delay message and then subsequent lines, then things really get confusing. I just wanted to note that this. Let me show you some tests.

The array sizes are 128 samples (hence, 2 blocks). The delayed bang comes 96 samples later, in the middle of the 2nd block. Without a negative delay, we have a ramp of 0.5 ms to reach '1' and then we start another ramp down of the same size (this one ends in the beginning of the 3rd block). Here we go.

Now, with the negative delay, the ramp time gets ignored, which is quite weird I must say. I have to really question if this is a real feature or a bug (a bug for an unkown feature, but a bug nonetheless).

Now, my intuition would tell me that a line to reach '1' should start at the beginning of the block, for the very rare and edge cases of messages not coming right at the beginning of block (we must also make it clear that is is more an exception than a rule). So I also find it weird that a line towards 0 waits for the 0.5 in the first ramp plus another 0.5 ms on the second to happen. This would be the same as feeding it |1 0 -1, 0 0.5 1(

Again, no use cases for this feature comes to mind. Also, not quite sure how to make sense of this so I can explain it...

[porres]

and this is definitely not like [line~], as [line~] does create a line from start to the end of a block.

So it's more closely related to [sig~]? Or, I don't know if it is worth making comparisons to other objects, since you can still start another ramp from the middle of the block, one which will finish also anywhere within a block...

[porres]

This is my test patch with an attempt to describe what is going on

vline_negative_test.pd.zip

[sebshader]

Now, with the negative delay, the ramp time gets ignored, which is quite weird I must say. I have to really question if this is a real feature or a bug (a bug for an unkown feature, but a bug nonetheless).

judging by the comment in the code I would say that this is the intended behavior.

Maybe it was originally intended as just a way to 'unset everything' quickly. Nevertheless I think it may have some uses.

Maybe adding ramp capability to it could be a feature request. even so it seems like it should still schedule future segments from the time of the received message to be consistent. (in the case above for negative delay it would ramp to 1 over .5 ms, then wait until the same scheduled time as for the normal case to ramp down again)

then again from an implementation perspective that would be slightly more complex/involved as it would require storing segments in the 'past' (currently the negative delay just deletes all segments and sets the 'current value')