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!
Strange envelope..
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!
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!
boonier
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?
Dual 1.8 IBM G5: Mac OSX 10.4.11 -- Asus eeePC 701: Pure:Dyne / eeeXubuntu GNU/Linux -- myspace.com/thearifd
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
boonier
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:
Dual 1.8 IBM G5: Mac OSX 10.4.11 -- Asus eeePC 701: Pure:Dyne / eeeXubuntu GNU/Linux -- myspace.com/thearifd
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.
Dual 1.8 IBM G5: Mac OSX 10.4.11 -- Asus eeePC 701: Pure:Dyne / eeeXubuntu GNU/Linux -- myspace.com/thearifd
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.
Dual 1.8 IBM G5: Mac OSX 10.4.11 -- Asus eeePC 701: Pure:Dyne / eeeXubuntu GNU/Linux -- myspace.com/thearifd
>>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!
Oops! Looks like something went wrong!