The vline ~makes absolutely no sense to me
I understand the concept just fine but when putting multiple stages in a message it's just behaves not as expected
Concept is simple , target level , times it takes to reach that level and optional delay
SO
I created two packs the first left pack triggered by yellow toggle goes to level 1 in 500 ms and no delay time (console = print A)
The vline~ as expeced stays at that level , blue toggle will bring the Vline~down to level 0 in 600ms with no delay (console print B )
The console shows two separate messages .
The issue is when I want to bring these two messages into a single one , which uses a comma sign "," ' to separate the two series of arguments
So 1 500 0; 0 600 0 but the message doesn't work becasue of the zero delay time in the first part of the message ( attack stage )
Why is that ?
I put the two pack messages into a single message separated by a comma it should work no ?

@gentleclockdivider said:

becasue of the zero delay time in the first part of the message

That is why. How can it know when to start the next segment if you don't tell it? from the help file

Note that the middle and right inlet (that sets the time and delay) do not remember old values (unlike other inlets in Pd). Thus, if you send vline~ a float without priorly specifying a ramp time and delay and sent, it jumps immediately to the target value. In the same way, a list of two values will not have a delay time if no delay time was priorly set in the right inlet.

Message sent to objects act exactly the same as the inlets they correspond to.

The behavior you want is simply achieved in many ways and generally simpler overall than overriding the alternative, which tends to be the way vanilla objects work.

Edit: not sure what I was thinking with that example, oh well no time to fix and I always feel guilty about editing away my failures so it will stay for now.

@gentleclockdivider said:

The issue is when I want to bring these two messages into a single one , which uses a comma sign "," ' to separate the two series of arguments
So 1 500 0; 0 600 0 but the message doesn't work becasue of the zero delay time in the first part of the message ( attack stage )

The message box should be 1 500, 0 600 500.

You misinterpreted "delay time" as the delay after the previous segment. In fact, it's a delay time after the moment of receipt.

If you want the "0 600" segment to execute immediately after the 500 ms segment, this is 500 ms after the message arrives at the inlet -- so you have to restate the 500.

You could argue that this not the way you would like it to be done, but this is what's documented and it does work.

hjh

I think sometimes the distinction between 'messages' and 'the contents of a message box' isn't clear.

in message boxes, a comma separates multiple messages. The object that the comma-separated messages are sent to ([vline~]) has no way of knowing that both comma-separated messages come from 1 'thing' (in this case 1 message box).

Edit: I guess hypothetically for cumulative times there could be some kind of queue for messages in the order they're received (instead of time they're set for), and when the last plays the 'current time' resets to '0'. However this would create unintuitive behavior in other scenarios I think.

@ddw_music said:

@gentleclockdivider said:

The issue is when I want to bring these two messages into a single one , which uses a comma sign "," ' to separate the two series of arguments
So 1 500 0; 0 600 0 but the message doesn't work becasue of the zero delay time in the first part of the message ( attack stage )

The message box should be 1 500, 0 600 500.

You misinterpreted "delay time" as the delay after the previous segment. In fact, it's a delay time after the moment of receipt.

If you want the "0 600" segment to execute immediately after the 500 ms segment, this is 500 ms after the message arrives at the inlet -- so you have to restate the 500.

You could argue that this not the way you would like it to be done, but this is what's documented and it does work.

hjh

If I put the nr's 1 0 1000 into a pack f f f and bang it , the vline will be executed 1000 ms after it has received it's trigger .
Same as when put in a message 1 0 1000
So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )
Putting two messages into one message is afaik separated by a comma , this just does not work

If I put the nr's 1 0 1000 into a pack f f f and bang it , the vline will be executed 1000 ms after it has received it's trigger .
Same as when put in a message 1 0 1000
So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )
Putting two messages into one message is afaik separated by a comma , this just does not work

Not really an answer to your question, but in PlugData/ELSE there is also [envgen~], which can be combined with the [function] object. I find that to be a lot more intuitive for creating envelopes.

@timothyschoen
I am aware of that and I have used it before for making a drum synth , altough prefer the cyclone curve~object

Still I want to figure this vline~stuff out

@gentleclockdivider said:

So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )

Do you want the envelope segments to run at the same time?

No. You want one after the other.

Therefore the two times should not be the same.

Making them both 1000 means it will of course not work.

Putting two messages into one message is afaik separated by a comma , this just does not work

It absolutely does work. Here, there's one message box with two messages in it, and you clearly see two envelope segments being drawn.

hjh

@ddw_music said:

You misinterpreted "delay time" as the delay after the previous segment. In fact, it's a delay time after the moment of receipt.

NO I didn't
See part my first message
I created two packs the first left pack triggered by yellow toggle goes to level 1 in 500 ms and no delay time

@gentleclockdivider said:

NO I didn't
See part my first message
I created two packs the first left pack triggered by yellow toggle goes to level 1 in 500 ms and no delay time

Delay time, third value, is 0 in both cases.

If you want one after the other, why do you keep writing the same delay time for both messages?

See the screenshot above. It works if the multiple messages in the single message box have different delay times.

hjh

@ddw_music said:

@gentleclockdivider said:

So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )

Do you want the envelope segments to run at the same time?

No. You want one after the other.

Therefore the two times should not be the same.

Making them both 1000 means it will of course not work.

Putting two messages into one message is afaik separated by a comma , this just does not work

It absolutely does work. Here, there's one message box with two messages in it, and you clearly see two envelope segments being drawn.

hjh
Now change that delay time time for the attack stage to 1000 , it won't work anymore

@gentleclockdivider in order to have an attack time of 1000 ms, you need to do:
[1 1000 0(
meaning 'from the time this message was sent (no delay = 3rd arg), ramp to 1 over 1000 milliseconds'.
then, if you want to send a message for the decay and for the decay to be scheduled after that attack you would send this at the same time:
[0 500 1000(
meaning "from 1000 milliseconds after this message is sent (3rd arg, which will be when the attack stage ends), go to 0 in 500 ms"
putting those together (and sending them at the same time) would be:
[1 1000 0, 0 500 1000(

@gentleclockdivider said:

Now change that delay time time for the attack stage to 1000 , it won't work anymore

Why are you setting the attack's delay time to 1000?

hjh

@ddw_music
To wait before attack stage is excuted , iow delay time
Wait for 1000 ms when triggerd , then go to level 1 instantly (0ms°)

@seb-harmonik.ar said:

@gentleclockdivider in order to have an attack time of 1000 ms, you need to do:
[1 1000 0(
meaning 'from the time this message was sent (no delay = 3rd arg), ramp to 1 over 1000 milliseconds'.
then, if you want to send a message for the decay and for the decay to be scheduled after that attack you would send this at the same time:
[0 500 1000(
meaning "from 1000 milliseconds after this message is sent (3rd arg, which will be when the attack stage ends), go to 0 in 500 ms"
putting those together (and sending them at the same time) would be:
[1 1000 0, 0 500 1000(

You mean opening with an opening square bracket and closing with an opening bracket ?
Sorry but I hav never ever seen something that closes a message-list with an open bracket
I guess that must be some knd of typo since the console doesn't understand it , forgive me when wrong
Using [ ] doesn't work either

@gentleclockdivider said:

You mean opening with an opening square bracket and closing with an opening bracket ?

No.

There are a couple conventions for representing Pd objects in text:

• [object] -- square brackets for object boxes -- if you see [metro 100] in a post, it means you would do ctrl-1 and type metro 100 inside not including the brackets.
• [message( -- imitating the funny shape of message boxes -- if you see [tempo 120 permin( in a post, you would do ctrl-2 and type tempo 120 permin not including the delimiters.

However I'd also note -- there is a screenshot above showing you how to get the result you want. For some reason, this seems uninteresting for the moment... A large amount of energy is going into arguing with the people trying to help you, and much less energy is going toward the use of an available solution. From where I sit, this is a peculiar set of priorities.

hjh

I'd like to briefly apologize for the moments in this thread when I chose to escalate instead of de-escalate. I think this put @gentleclockdivider on the defensive and did not help to refocus the thread on the solution.

Will try to be less reactive next time.

hjh