Hi there..

I made an envelope but I can't figure out what I did wrong. Please see the .pd file for more information.

Thanks!

http://www.pdpatchrepo.info/hurleur/Envelope.pd

How weird. At a guess I'd say it has something to do with [line~]'s incapability to interpolate between samples but really I don't know what I'm talking about.

Use [vline~] instead, and all your worries will be gone

I changed the delay to 2 ms and it worked. Not sure what that means though

Thank you both for your quick replies! I know about the 2 ms delay. But still.. see the graph.. it still changes slightly at some points, while it should be the same all the time. (1 ms delay.. -> beep beep no-beep no-beep. 2 ms delay.. -> beep-short beep-short beep-long beep-long -relatively of course.)

And I know about vline~ too, but in the end I want to be able to connect sliders to the envelope. That is why I chose the pack object, so I can connect sliders to those inputs. Or is there a way to deal with sliders and vline~?

And in the end I think this setup should work theoretically..?

[vline~] accepts controller values (sliders e.t.c.) as input and turns them into audio-rate values, no problem there..

Is this as simple as connecting the target-value-slider to the 1st inlet, the time-to-get-there-slider to the 2nd inlet and the delay-to-execute-slider to the 3rd inlet?

1ms is too fast for a standard [line~]. It gets updated every block boundary (64 samples) by default, so 1ms in samples is 44.1, therefore [line~] wont be able to keep up.

Use [vline~] instead, or change the ramp up/ delay to >2ms going into [line~]. I use 5ms. Its still riduclously short!

So you use 5 ms as an attack value and 5 ms as a delay? But how should this be for percussive elements like a kick drum. I use 1 ms attack to avoid a click, but this does not seem to work. 5 ms works, but is less percussive.

And how about the changing graph? Even when I choose 5 ms?

I don't know about the extra inlets, But you can pack your messages into [pack] which sends it to a message box connected to vline~ like this [$1 $2, $3 $4( e.t.c. following the required syntax that vline~ accepts.

Do you understand? or shall I patch it up for you?

Arif.. that would be nice. I think I understand the concept, but not how to connect it properly.

yes 5ms is probably too much. [vline] is best for percussion

so construct a message to vline that says
goto 0 in 1ms (from whatever level)
goto 1 in 1ms after a delay of 1ms
goto 0 in 80ms after a delay of 2ms

[0 1, 1 1 1, 0 80 2(
|
[vline~]

arif's patch will show you how to make variable messages to send to vline

So, now we know how to send messages to vline~ we simply substitute [0 1, 1 1 1, 0 80 2( for variables packed together in a pack object.

Making the static message, now a variable, based on what you feed it... Like so:

http://www.pdpatchrepo.info/hurleur/variable_envelope.pd

Thank you both boonier and arif for your great help so far. Now I understand how I can send 'packed messages' to vline~ I'm still wondering why..

a) the first step of going to 0 in 1 ms (from whatever level) is necessary. (?)

the graph still changes, while it should generate the same sound and/or graph all the time. (?)

a) you have to tell vline~ where to start (but you can always make that 0 a variable too)

the graph changes because of of timing differences between the banging of the metro and your manual banging of the play button. In the [t b b b] object, add another b (bang) and hook it up to the tabwrite~ object. Disconnect the metro from it and now whenever you hit the play button the tabwrite will begin writing at the same time every time, thus, the same graph occurs every time.

Thanks again arif, great help! Still some questions for the purpose of understanding it all, I hope you don't mind.

Concerning..

a) isn't vline~ starting at 0 by default? And because it changes back to 0 (in the decay stage) is it necessary to add this step?

I know about the timing difference between the play and metro button. Actually I was talking about the difference of the graph when you connect the bang of the envelope AND the bang of the tabwrite~ to the metro. The figure of the curve is the same all the time, but the position of the curve on the x-axis changes in small steps if you look closely. That's what I still don't understand.

I don't mind answering your questions at all, it is only from asking others that I know what I do anyway!

a) the current message tells vline~ to transition back to 0 at the end, yes, but vline~ doesn't know that that will be the only message it will receive in it's lifetime it may receive a different message that doesn't want it to go to 0 and then when it comes to providing your percussive attack, it'll be lost on the fact that you didn't tell it to start at zero.

vline~, line~ and line isn't intended solely for amplitude modulation (or envelope generation) it simply ramps numbers, for whatever purpose, however large or small your numbers. That's why it accepts the rather counter intuitive message format. - for functionality. If you want a percussive envelope generator, you would do well to stick to [ead~]

yeah, i still think that has to do with tiny timing differences, you see, metro is sending a bang to tabwrite at the same time as sending 3 sequenced messages to the vline~ object. the change in the x-axis dissapears when you modify the [t b b b] object to properly sequence everything.

>>but the position of the curve on the x-axis changes in small steps if you look closely. That's what I still don't understand.<<

adding the [vline~] to your patch has made the envelope timing sample accurate now, instead of only being triggered on block boundaries.

[tabwrite~] however, will still be triggered on the block boundary. thus a discrepancy of 0-64 samples (about 0-1.5ms) which you see as jitter in the display.

Aaah.. I see, now I can finally go to sleep . Thank you all for your great help!