[EMAIL PROTECTED] wrote:
Quoting Steffen Juul [EMAIL PROTECTED]:
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
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
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
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[...]]
Hi, some years ago I made an abstraction that is only
a line~ type envelope but you can send it an infinite
message. Perhaps it is usefull for someone else.
Diego
Never miss a thing. Make Yahoo your
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
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
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
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
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
Quoting Steffen Juul [EMAIL PROTECTED]:
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
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]
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
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
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
[0, 1 1000, 0 500 2000, 7000 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 7000 in 6ms, 59000ms after inital bang
nothing gets 'cut off'..the 3rd digit just schedules a delay from initial
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
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
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
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,
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
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
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
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 [EMAIL PROTECTED] 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,
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:
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
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
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.
28 matches
Mail list logo
