Hello list~
I'm kind of embarrassed, but I really want to learn how to use vline~ effectively. The help file isn't clear on my problem, and I haven't found any reference to it in my Pd folder.
If I want to send a message with multiple ramps in a single message, i.e. [1 1000, 0 0 1000, 1 1000 1000(, where we have corresponding actions ramp up, jump down, ramp up again, how does this all work?
I can't seem to figure out what the three digits are for. How would I for example make a vline~ message that said to start at 0, go to 1 in 1000 ms, go to .5 in 500 ms, and then back to zero in 750 ms?
Thanks,
~Kyle
first digit = value to ramp to
second digit = ramp time in ms
third digit = offset from the time when the message box was banged
in your example, [1 1000, 0 0 1000, 1 1000 1000(, it will ramp up to 1 in 1000ms, then down to 0 in 0ms, then back up to 1 in 1000ms.
How would I
for example make a vline~ message that said to start at 0, go to 1 in 1000 ms, go to .5 in 500 ms, and then back to zero in 750 ms?<<
[0, 1 1000, 0.5 500 1000, 0 750 1500(
all third digit offsets are from the initial bang, not from when the last ramp has ended. you have to do the maths yourself.
Ok thanks! I don't know why it's so hard for me to remember that...
~Kyle
On Dec 18, 2007 12:46 AM, hard off hard.off@gmail.com wrote:
How would I
for example make a vline~ message that said to start at 0, go to 1 in 1000 ms, go to .5 in 500 ms, and then back to zero in 750 ms?<<
[0, 1 1000, 0.5 500 1000, 0 750 1500(
all third digit offsets are from the initial bang, not from when the last ramp has ended. you have to do the maths yourself.
I have a hard time remembering that as well. It would be great to
have an improved help patch. If you submit one to the patch tracker,
I'll commit it to the pddp collection.
Here's the PDDP help template and an example help patch:
http://pure-data.cvs.sourceforge.net/pure-data/doc/pddp/templates/ template-help.pd http://pure-data.cvs.sourceforge.net/pure-data/doc/pddp/templates/ example-help.pd
.hc
On Dec 20, 2007, at 9:32 AM, Kyle Klipowicz wrote:
Ok thanks! I don't know why it's so hard for me to remember that...
~Kyle
On Dec 18, 2007 12:46 AM, hard off hard.off@gmail.com wrote:
How would I
for example make a vline~ message that said to start at 0, go to 1 in 1000 ms, go to .5 in 500 ms, and then back to zero in 750 ms?<<
[0, 1 1000, 0.5 500 1000, 0 750 1500(
all third digit offsets are from the initial bang, not from when the last ramp has ended. you have to do the maths yourself.
--
---- -----
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
I have a hard time remembering that as well. It would be great to
have an improved help patch.
how would you improve it? probably just add the line "The messages consist of a target value, a time interval (zero if not supplied), and an initial delay (also zero if not supplied.)"
mfgdrs. IOhannes
On Dec 21, 2007, at 6:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I have a hard time remembering that as well. It would be great
to have an improved help patch.how would you improve it? probably just add the line "The messages consist of a target value,
a time interval (zero if not supplied), and an initial delay (also
zero if not supplied.)"
Clear examples are always helpful. Ideally, there will be an example
that illustrates each parameter individually.
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Is there a reason for the third digit? The only possible advantage
for the third digit it that I can imagine right now would be the
ability to cut off previous messages prematurely w/o having to change
the value of previous messages (besides testing my math skills). Am I
missing something?
For example: 0 0, 1 1000 0, 0 0 1000 0 200 1200, 1 200 1400, 0 200 1600
vs
0 0, 1 1000 0, 0 0 900 <--- cuts the ramp off early 0 200 1200, 1 200 1400, 0 200 1600
On Dec 18, 2007, at 1:44 AM, hard off wrote:
first digit = value to ramp to
second digit = ramp time in ms
third digit = offset from the time when the message box was banged
in your example, [1 1000, 0 0 1000, 1 1000 1000(, it will ramp up to 1 in 1000ms, then down to 0 in 0ms, then back up to 1 in 1000ms.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[0, 1 1000, 0 500 2000, 70000000 6 59000( | [vline~]
=
start at zero,
ramp to 1 over a 1000ms period,
ramp down to zero in 500ms, 2000ms after initial bang,
ramp up to 70000000 in 6ms, 59000ms after inital bang
nothing gets 'cut off'..the 3rd digit just schedules a delay from initial bang.
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
Otherwise, I don't see why it wouldn't be better to just accept a list like [0, 1 1000, 0.5 1000, 0 2000( where it starts at 0, goes to 1 in 1000 seconds, then goes to .5 in 1000 seconds, then goes to 0 in 2000 seconds. Why even have the extra digit?
I am curious for the answer, so I CC'ed some gurus.
Confusedly,
~Kyle
On Jan 26, 2008 12:10 PM, hard off hard.off@gmail.com wrote:
[0, 1 1000, 0 500 2000, 70000000 6 59000( | [vline~]
=
start at zero,
ramp to 1 over a 1000ms period,
ramp down to zero in 500ms, 2000ms after initial bang,
ramp up to 70000000 in 6ms, 59000ms after inital bang
nothing gets 'cut off'..the 3rd digit just schedules a delay from initial bang.
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
You can think of the 3-element lists going into vline~ as a stack ordered by the last element, the delay. So if you send
1 1 0, 2 2 0, 3 3 0
only the last triple, "3 3 0" is played. It overwrites all others. To actually schedule more than one message, you need to give them different delays:
1 1 1, 2 2 2, 3 3 3
Ciao
Frank Barknecht _ ______footils.org__
Kyle Klipowicz wrote:
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
Otherwise, I don't see why it wouldn't be better to just accept a list like [0, 1 1000, 0.5 1000, 0 2000( where it starts at 0, goes to 1 in 1000 seconds, then goes to .5 in 1000 seconds, then goes to 0 in 2000 seconds. Why even have the extra digit?
i cannot follow you here at all. however, i would say that the 3rd digit is more or less useless (only there for convenience) because you can get the same behaviour with scheduled messages. e.g. [0, 1 1000 500( | [vline~]
is the same as
[t b b] | | [0( [del 500] | | | [1 1000( +-----+ | [vline~]
mfg,dr IOhannes
I thought about it again today and I agree, there's no fundamental need to have it. On the other hand, if you happen to be using lots of vline~s for scheduling breakpoint envelopes, there might be a big efficiency gain having the vline~ object manage the timeouts itself. (The vline~ object would still have to be dsingend to store multiple scheduled breakpoints in case more than one fell within a DSP block.)
cheers Miller
On Sun, Jan 27, 2008 at 02:58:30AM +0100, IOhannes m zmoelnig wrote:
Kyle Klipowicz wrote:
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
Otherwise, I don't see why it wouldn't be better to just accept a list like [0, 1 1000, 0.5 1000, 0 2000( where it starts at 0, goes to 1 in 1000 seconds, then goes to .5 in 1000 seconds, then goes to 0 in 2000 seconds. Why even have the extra digit?
i cannot follow you here at all. however, i would say that the 3rd digit is more or less useless (only there for convenience) because you can get the same behaviour with scheduled messages. e.g. [0, 1 1000 500( | [vline~]
is the same as
[t b b] | | [0( [del 500] | | | [1 1000( +-----+ | [vline~]
mfg,dr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
however, i would say that the 3rd digit is more or less useless (only there for convenience) because you can get the same behaviour with scheduled messages. e.g. [0, 1 1000 500( | [vline~]
is the same as
[t b b] | | [0( [del 500] | | | [1 1000( +-----+ | [vline~]
Note that the former version is *muchmuch* more convenient, especially when building line segments dynamically.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Note that the former version is *muchmuch* more convenient, especially when building line segments dynamically.
totally! i just wanted to demonstrate that there is indeed no mandatory reason to have the 3rd value - but not because of the shortcuts kyle mentioned (which seem to do more harm than good)
fgmadsr. IOhannes
I agree as well, prefer the existing vline message syntax. (I hope we
haven't started a movement against the third value!) Now that I get
it, it is much more intuitive than emulating an old 2 value breakpoint
envelope.
Has anyone made a vline-like external that only takes the first two
values?
Cheers, ~Brandon
On Jan 27, 2008, at 7:08 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Note that the former version is *muchmuch* more convenient,
especially when building line segments dynamically.totally! i just wanted to demonstrate that there is indeed no mandatory
reason to have the 3rd value - but not because of the shortcuts kyle mentioned (which seem to do more harm than good)fgmadsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, I still think it's confusing, especially for newbies (as well as myself!) but I can understand that it's sort of entrenched.
I wonder how hard it would be to code a detector that counts to see if there are three element bundles in the message vs. two, and can process each accordingly, so that the old way still works but also the 'new way.' Does that make sense?
Thanks to all who have participated in this discussion! I appreciate it.
~Kyle
On Jan 27, 2008 11:14 PM, bsoisoi bsoisoi@mac.com wrote:
I agree as well, prefer the existing vline message syntax. (I hope we haven't started a movement against the third value!) Now that I get it, it is much more intuitive than emulating an old 2 value breakpoint envelope.
Has anyone made a vline-like external that only takes the first two values?
Cheers, ~Brandon
On Jan 27, 2008, at 7:08 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Note that the former version is *muchmuch* more convenient, especially when building line segments dynamically.
totally! i just wanted to demonstrate that there is indeed no mandatory reason to have the 3rd value - but not because of the shortcuts kyle mentioned (which seem to do more harm than good)
fgmadsr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2008-01-28 at 14:01 -0600, Kyle Klipowicz wrote:
I wonder how hard it would be to code a detector that counts to see if there are three element bundles in the message vs. two,
it would be very easy by using [list length], but it's not necessary (see next paragraph).
and can process each accordingly, so that the old way still works but also the 'new way.' Does that make sense?
no, since there is actually no need to do that. you still can use [vline~] as [line~]. if the third argument is not used, 0 is assumed, which makes [vline~] behave as [line~] (it's still more accurate, though).
in other words: just forget about the third argument, if it confuses you, and it won't do you any harm and it'll work as expected.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 27/01/2008, at 2.58, IOhannes m zmoelnig wrote:
Kyle Klipowicz wrote:
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
Otherwise, I don't see why it wouldn't be better to just accept a
list like [0, 1 1000, 0.5 1000, 0 2000( where it starts at 0, goes to 1 in 1000 seconds, then goes to .5 in 1000 seconds, then goes to 0 in 2000 seconds. Why even have the extra digit?i cannot follow you here at all.
Kyle wants to, correct me if i'm wrong, translate
[0, 1 1000, 0.5 1000 1000, 0 2000 2000( | [vline~]
into
[0, 1 1000, 0.5 1000, 0 2000( | [nothirdVline~]
That is have the object do the delay bookkeeping.
Or maybe this would to instead:
[0, 1 1000, 0.5 1000, 0 2000( | [vlineBookkeeper] | [vline~]
On Mon, 2008-01-28 at 22:17 +0100, Steffen Juul wrote:
On 27/01/2008, at 2.58, IOhannes m zmoelnig wrote:
Kyle Klipowicz wrote:
I think the question is, why have that book keeping available for vline~? Are there any practical uses for it?
Otherwise, I don't see why it wouldn't be better to just accept a
list like [0, 1 1000, 0.5 1000, 0 2000( where it starts at 0, goes to 1 in 1000 seconds, then goes to .5 in 1000 seconds, then goes to 0 in 2000 seconds. Why even have the extra digit?i cannot follow you here at all.
Kyle wants to, correct me if i'm wrong, translate
[0, 1 1000, 0.5 1000 1000, 0 2000 2000( | [vline~]
into
[0, 1 1000, 0.5 1000, 0 2000( | [nothirdVline~]
That is have the object do the delay bookkeeping.
Or maybe this would to instead:
[0, 1 1000, 0.5 1000, 0 2000( | [vlineBookkeeper] | [vline~]
oops, it seems i misunderstood kyle as well.
a [vlineBookKeeper] should be pretty straight forward to realize with a handful of [list] objects. have a look at the help-file of [list] -> 'another sequencer' for a starting point.
in order to make it work exactly how you described, you would have to convert all messages (separated by commas) to one big message, while making sure, that each message consists of a pair of elements. i think it would make sense to convert a '300' message to '300 0' (assume 0, if second argument is not given).
[0, 1 1000, 0.5 1000, 0 2000(
convert to:
'0 0 1 1000 0.5 1000 0 2000'
serialize/delay by pair (using [list split 2] and [del] etc.)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:
Kyle wants to, correct me if i'm wrong, translate
[0, 1 1000, 0.5 1000 1000, 0 2000 2000( | [vline~]
into
[0, 1 1000, 0.5 1000, 0 2000( | [nothirdVline~]
That is have the object do the delay bookkeeping.
Which however would prohibit things like "sustain" in an adsr-like envelope:
[0, 1 10, 0.5 10 10, 0 300 200(
This goes to 1 in 10msec, to 0.5 in 10 msec after that, but to 0 over 300 msec *after* 200 msec (measured from the envelope's start).
With an auto-delay line object you'd need to write this:
[0, 1 10, 0.5 10, 0.5 190, 0 300(
One message more instead and not necessarily easier than the current version.
Or maybe this would to instead:
[0, 1 1000, 0.5 1000, 0 2000( | [vlineBookkeeper] | [vline~]
Yep, one could do a [vlineBookkeeper] like that which automatically adds up delay times, if needed.
Ciao
Frank Barknecht _ ______footils.org__
Quoting Steffen Juul stffn@dibidut.dk:
i cannot follow you here at all.
Kyle wants to, correct me if i'm wrong, translate
seems like i talked babylonian here.
i understood what kyle requested it, but i did not understand why he
wanted it.
(that is: he wanted it for simplicity, but i think it the "simplicity"
he proposed would make assumptions on the use of [vline~] which i
think are not valid)
mfga.dsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at wrote:
Quoting Steffen Juul stffn@dibidut.dk:
i cannot follow you here at all.
Kyle wants to, correct me if i'm wrong, translate
seems like i talked babylonian here. i understood what kyle requested it, but i did not understand why he
wanted it.
too early in the morning: i understood _what_ kyle requested, i did not understand _why_ he requested it.
fgmasdr. IOhannes
Haha this conversation is hilarious! Thanks for keeping it so lively everyone.
I may be suffering from Csound-itis. I want vline~ to basically act like the linseg Csound opcode:
kr linseg ia, idur1, ib[, idur2, ic[...]]
Where each segment is defined as points in time connected by a linear ramp. It seems easier to me mostly because it's the first programmable linear envelope generator that I was exposed to.
Perhaps just making a [linseg~] abstraction out of vline~ using the previous suggestions on this thread would suffice. I definitely do not want to limit the sustain possibilities of vline~ as a sort of ADSR envelope generator. I just want to do what Steffen said. After all this banter, it's probably easier for me to just remember what the third tuple is in the comma separated messages.
However, I don't think it's possible to make a playable ADSR generator with vline~ using only one message anyway. I think that it would still have to be somewhat hacked together using some triggers and delays etc like the ADSR example that Miller included with Pd. Am I wrong here?
Thanks again for participating in the thread!
~Kyle
On Jan 29, 2008 2:13 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
zmoelnig@iem.at wrote:
Quoting Steffen Juul stffn@dibidut.dk:
i cannot follow you here at all.
Kyle wants to, correct me if i'm wrong, translate
seems like i talked babylonian here. i understood what kyle requested it, but i did not understand why he wanted it.
too early in the morning: i understood _what_ kyle requested, i did not understand _why_ he requested it.
fgmasdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2008-01-29 at 14:55 -0600, Kyle Klipowicz wrote:
However, I don't think it's possible to make a playable ADSR generator with vline~ using only one message anyway. I think that it would still have to be somewhat hacked together using some triggers and delays etc like the ADSR example that Miller included with Pd. Am I wrong here?
hm.. depends on how strictly you define 'one message'. yeah, it is perfectly possible to make a [vline~] based ADSR generator without using [del] and [list split] trickery and by using only one message box, but you are right: in this message box you need several comma separated messages (so: it's not possible with literally 1 message). usually you don't know the length of the key pressure in advance, but for simplicity's and illustration's sake let's assume we know it (T=280ms) beforehand:
/\
/ _____________________
/
/
/ \
A=50ms S=0.6 R=30ms D=20ms
|<- T=280ms ->|
[0, 1 A, S D A, 0 R T(
which is:
[0, 1 50, 0.6 20 50, 0 30 280( <- one message box, four messsages | [vline~]
or you could replace the variables actually represented as letters by real pd variables (A->$1, D->$2) and you would get a real adjustable ADSR envelope generator with subsample accuracy ;-)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
Haha this conversation is hilarious! Thanks for keeping it so lively everyone.
I may be suffering from Csound-itis. I want vline~ to basically act like the linseg Csound opcode:
kr linseg ia, idur1, ib[, idur2, ic[...]]
Where each segment is defined as points in time connected by a linear ramp. It seems easier to me mostly because it's the first programmable linear envelope generator that I was exposed to.
Perhaps just making a [linseg~] abstraction out of vline~ using the previous suggestions on this thread would suffice.
Basically all you need to do is add up all previous segment lengths to get the delay for the next segment. Like attached (for a start). Note that while in Csound, the duration comes before the target, the attachement still has the duration after the target, in sync with line~ and vline~.
Ciao
Frank Barknecht _ ______footils.org__
Ahh, okay. RIght, but if you scheduled that last message at 1800
instead of 59000 it would interrupt the full motion of the previous
item. I was looking at these messages from the perspective of classic
envelope generators (for example, the 'time varying' envelopes on the
Roland XP-50/60/80 series for example, which are simply a set of
volume points with associated slide times). So I get it now.
The example below is a good one, hard off. If I were to make that
envelope on the XP-50, for example, I would need a point in between to
setup the long delay between 2000 and 59000, and would look something
like this:
[0, 1 1000, 0 500 2000, 0 57000 2000, 70000000 6 59000(
Thanks a bunch, ~brandon
On Jan 26, 2008, at 1:10 PM, hard off wrote:
[0, 1 1000, 0 500 2000, 70000000 6 59000( | [vline~]
=
start at zero,
ramp to 1 over a 1000ms period,
ramp down to zero in 500ms, 2000ms after initial bang,
ramp up to 70000000 in 6ms, 59000ms after inital bang
nothing gets 'cut off'..the 3rd digit just schedules a delay from
initial bang.
-
brandon zeeb -
bsoisoi
-
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Kyle Klipowicz -
Miller Puckette -
Roman Haefeli -
Steffen Juul -
zmoelnig＠iem.at