19 Jan
2003
19 Jan
'03
11:19 p.m.
I realized a few more things about ramping when messing with
Audiality's voice mixers:
1) The STOP event *is* rather handy, as it has no value
argument to be calculated or processed. If you're doing
internal ramping (or coefficients) instead of using the
ramped value directly, STOP just means you stop ramping
your internal controls. SET (which is what you must use
if you don't have STOP) is supposed to *set* a new value,
obviously, and would normally result in the coefficients
being recalculated, regardless of current stat.
2) RAMP events with a <target_value, duration> aim point
do not guarantee *anything* but the value hitting the
aim point. Plugins are not required to perform truly
linear ramping; only something that "sounds similar".
If you would SET halfway to the aim point, you would
get a click, unless the receiver is doing *truly*
linear ramping internally!
3) Ramping with aim points means you don't have to know
where you are, to set up an accurate ramp to a desired
value. You don't even have to know if the current value
is above or below the target value.
Now, a STOP event before the aim point of a ramp in
progress would not always give you *exactly* what you
want, but close enough. (Provided the receiver "fakes"
linear ramping well enough - which it basically *must*
do anyway, for ramping to be usable.) Remember that if
you set up a new ramp, it will take you to the new aim
point regardless of the current value. So, as long as
you don't *SET* before (or after) the aim point, you're
safe.
4) Normally, you'd probably re-aim with RAMP, but in some
cases, you really just want to hold where you are
indefinitely. That's when you would use STOP - or fake
it with a "long" ramp to what should be the current
value. Both should work, but STOP is easier and faster.
5) A more serious issue is that if control events are not
allowed while ramping, except at the time of the aim
point, there is no way to avoid sending one RAMP event
for each block while ramping. You can't aim further
ahead than the first frame of the next block, or you
might have to break in and adjust the aim before you
hit the aim point.
This could potentially be a serious performance issue
with low latency hosts, since it means 1000+ RAMP events
(and the related transformation overhead) per ramping
control.
As a real life example of the alternative, the RT
envelope generator in Audiality uses one event per node.
(DAHDSR currently, which means 7 nodes.) Extra events
will have to be inserted to handle real time modulation
of the envelope (volume and pan controls, at the very
least), but there's never a need for more than one
extra event per linear section added.
Questions:
A) Is it necessary to require that aim points are
within the current block, to avoid "re-aiming"?
B) Is STOP useful enough to be in XAP?
Anyway, I think I have answered my own questions by explaining all
this (A: Yes, or complex effects won't mix with low latency, and B:
no, you'll probably end up using RAMP all the time anyway) - but I'm
still interested in comments. This might not be all there is to it.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
20 Jan
20 Jan
11:22 a.m.
On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
5) A more serious issue is that if control events are
not
allowed while ramping, except at the time of the aim
point, there is no way to avoid sending one RAMP event
for each block while ramping. You can't aim further
ahead than the first frame of the next block, or you
might have to break in and adjust the aim before you
hit the aim point.
I dont see why there is a restriction on aiming further ahead than the
current block, this seems like a mistake. It forces the plugins to be
closed to linear than is desirable.
Questions:
A) Is it necessary to require that aim points are
within the current block, to avoid "re-aiming"?
I dont see why, the obvoius inner loop for ramp aiming should deal with
this perfectly well, it will just replace the delta_control number.
B) Is STOP useful enough to be in XAP?
I'd argue for it not be be there. Its hard to see when it would be
useful ,ad its one more thing to handle.
SET /could/ be done with a ramp with target time of 0, not optimally efficeint,
but the cases I can think of it wont hurt:
notched switches: will always jump to the target value anyway, so wont
have to do any interpolation.
continuous controls: SET operations will be quite unusual, and the
overhead is not that big.
- Steve, minimalist ;)
1:15 p.m.
On Monday 20 January 2003 16.15, Steve Harris wrote:
Exactly.
Agreed.
At the time, it happens to be a shortcut in Audiality, but as soon as
I implement modulation of the envelope generators, that shortcut will
be essentially useless, since the hold and sustain sections will no
longer be guaranteed flat. (The EG will basically be multiplying the
envelope with one or more streams of control events.)
On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson
wrote:
I totally agree on this. The reason why I'm bringing it up is that it
was originally suggested that a RAMP event refers to a specific range
in time; basically a "macro event" that describes two actions; one
now and one at the end of the ramp. (Physically, the latter action
would be "stop ramping", although that has been ruled out as tricky
to implement while not useful.)
5) A more serious issue is that if control
events are not
allowed while ramping, except at the time of the aim
point, there is no way to avoid sending one RAMP event
for each block while ramping. You can't aim further
ahead than the first frame of the next block, or you
might have to break in and adjust the aim before you
hit the aim point.
I dont see why there is a restriction on aiming further ahead than
the current block, this seems like a mistake. It forces the plugins
to be closed to linear than is desirable. Questions:
A) Is it necessary to require that aim points are
within the current block, to avoid "re-aiming"?
I dont see why, the obvoius inner loop for ramp aiming should deal
with this perfectly well, it will just replace the delta_control
number. B) Is STOP
useful enough to be in XAP?
I'd argue for it not be be there. Its hard to see when it would be
useful ,ad its one more thing to handle. SET /could/ be done with a ramp with target time of 0,
not
optimally efficeint,
OTOH, this test must be done somewhere anyway. (Audiality does it on
the sender side, as it has SET + RAMP.) It could be argued that with
pre-recorded event streams, it's better to use SET, as that
eliminates the run-time conditional altogether, but I'm not sure it's
worth it. (It's just one very simple test...) For control streams
generated on the fly, it doesn't matter much where you do it.
but the cases I can think of it wont hurt:
notched switches: will always jump to the target value anyway, so
wont have to do any interpolation.
RAMP is always interpreted as SET? Not the best way to fake ramping,
but then, if you say you do not ramp, you shouldn't be expected to
even fake it. Makes sense.
continuous controls: SET operations will be quite
unusual, and the
overhead is not that big.
So, alternative 1; RAMP events only:
case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
else
{
value = ev->value;
dvalue = 0.0;
}
break;
- Adds a receiver side conditional for decoding, even if
the input is prerecorded.
- Contrary to the normal logic, duration == 0 implies
that ramping is *stopped* by the RAMP event.
+ Senders don't have to check for 0 duration.
+ duration == 0 becomes a valid and logical case.
+ Won't blow up if a 0 duration is "accidentally" sent.
+ More streamlined API; only one event per control type.
Alternative 2; RAMP and SET:
case XAP_A_SET:
value = ev->value;
dvalue = 0.0;
break;
case XAP_A_RAMP:
dvalue = (ev->value - value) / ev->duration;
break;
- More events in the API.
- Senders must replace 0 duration RAMPs with SET.
- Sending 0 for RAMP duration may have plugins blowing up.
- Turns "ramping with dv == 0" into a special state.
+ No extra conditional for duration; switch() is full decode.
+ No 0 duration testing at all when playing prerecorded events.
Using only RAMP events definitely looks like a great idea to me. I'm
going to try it in Audiality right away! :-)
BTW, using INFINITY for duration (MAXINT for fixed point, provided
MAXINT is not a valid control value) has the same effect as a STOP
event... Should this be allowed? We've already concluded that the
STOP action - whether it's an event of it's own or not - isn't very
useful, so maybe we should just leave this in the "undefined
behavior" domain.
And yes, duration would be of the same type as the control value, I
think. There's no point in making it an integer for float controls,
since plugins will only use it for a aim point -> dv transformation
anyway.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
2:06 p.m.
On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
Well, youd have to extrapolate the ramp to the pint where the next notch
is reached and reshedule a 0 duration event for there if the timing was
critical.
but the cases
I can think of it wont hurt:
notched switches: will always jump to the target value anyway, so
wont have to do any interpolation.
RAMP is always interpreted as SET? Not the best way to fake ramping,
but then, if you say you do not ramp, you shouldn't be expected to
even fake it. Makes sense. So, alternative 1; RAMP events only:
case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
I think you'll find that that should be
dvalue = (ev->value - value) / (ev->duration + 1.0f);
Otherwise you end up with unwanted shelves or delays in the ramp shape.
No branch is needed, cos the next delta of the control value will set it to
the correct value, but it may well just be easier to set it and not have
to cancel the delta next sample.
Using only RAMP events definitely looks like a great
idea to me. I'm
going to try it in Audiality right away! :-)
Yup, I like it too.
BTW, using INFINITY for duration (MAXINT for fixed
point, provided
MAXINT is not a valid control value) has the same effect as a STOP
event... Should this be allowed? We've already concluded that the
No, getting Infs into float code can cause problems down the line.
And yes, duration would be of the same type as the
control value, I
think. There's no point in making it an integer for float controls,
since plugins will only use it for a aim point -> dv transformation
anyway.
Yes, though there is the problem of what happens when the host specifies a
non integer duration, events cant arrive at non integer timestamps, so you
will end up with overshoot or undershoot. It may be safer to make them
ints. int -> float cast is not expensive.
- Steve
7:48 p.m.
On Monday 20 January 2003 18.59, Steve Harris wrote:
Yes, you're right. My confusion is because Audiality (for some
reason) applies dv *after* using v for each sample.
Yeah, you're probably right - and again, the usefullness of the STOP
feature is an illusion. Old habit or something; I tend to like the
idea of stable states.
That would be illegal... Which is a good reason to prevent it, to
eliminate the possibility, as well as any doubts about what
'duration' really is.
On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson
wrote:
Well, youd have to extrapolate the ramp to the pint where the next
notch is reached and reshedule a 0 duration event for there if the
timing was critical.
Yeah - but then you really have a continous control with some
internal processing. I think a control is either continous or not,
from the API POV. If it's continous, it should implement or "fake"
ramping in the way expected. If it's not continous, it shouldn't have
to worry about ramping.
Anyway, inserting an event a bit later in your own queue doesn't
sound all that hard, but there's a "hidden" problem: If the event
lands beyond the end of the block, event ordering will be screwed up.
Senders just add events at the end of queues, assuming that there are
no events for the current block when they start sending.
One solution would be to always insert/sort, but I don't see many
situations where this overhead and complexity *really* adds anything.
Also, such a design would be in conflict with the idea that controls
are driven by structured data; an efficient alternative to audio rate
controls, rather than a "sequencer database interface".
but the
cases I can think of it wont hurt:
notched switches: will always jump to the target value anyway,
so wont have to do any interpolation.
RAMP is always interpreted as SET? Not the best way to fake
ramping, but then, if you say you do not ramp, you shouldn't be
expected to even fake it. Makes sense. So,
alternative 1; RAMP events only:
case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
I think you'll find that that should be
dvalue = (ev->value - value) / (ev->duration + 1.0f);
Otherwise you end up with unwanted shelves or delays in the ramp
shape. No branch is needed,
Excellent! :-)
cos the next delta of the control value will
set it to the correct value, but it may well just be easier to set
it and not have to cancel the delta next sample.
That sounds like the case where you're looking for a STOP event - and
I don't think there's a real need for that.
If you say "aim at (y, t)", you mean exactly that - and what the
receiver does when passing t is really *undefined*. It might try to
continue ramping, but you should *never* allow it to, because the
plugin might blow up if the ramping isn't as linear as you think it
is!
Just always tell the receiver what to do at or before the current aim
point, and you're safe. Ramped controls are driven by a chain of RAMP
events.
It may feel a bit scary that you can't reliably stop ramping, but
it's not very different from audio streaming. You don't have a
definitive stable/dead/stopped state until you kill the stream - and
that means disconnecting the input, or taking the receiver out of the
net. Untill you do that, you have to do *something* to keep the
receiver happy.
Using only
RAMP events definitely looks like a great idea to me.
I'm going to try it in Audiality right away! :-)
Yup, I like it too.
BTW, using INFINITY for duration (MAXINT for
fixed point,
provided MAXINT is not a valid control value) has the same effect
as a STOP event... Should this be allowed? We've already
concluded that the
No, getting Infs into float code can cause problems down the line. And yes,
duration would be of the same type as the control value,
I think. There's no point in making it an integer for float
controls, since plugins will only use it for a aim point -> dv
transformation anyway.
Yes, though there is the problem of what happens when the host
specifies a non integer duration, events cant arrive at non integer
timestamps, so you will end up with overshoot or undershoot.
Yes...
It may
be safer to make them ints. int -> float cast is not expensive.
Right, and the cast has to be done *somewhere* anyway, I think.
(Except when playing back prerecorded events, but that's not really
something to optimize for.)
At least, the Audiality EG calculates 'duration' as the # of frames
to the next node or other event, so it's all integer math in that end
of the connection anyway. Well, the node timing is derived from fixed
point values, but that's *before* we start talking about event
timestamps. Any other way could potentially have 'duration' disagree
with event timing due to rounding errors. *heh*
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
21 Jan
21 Jan
12:16 a.m.
On Tuesday 21 January 2003 00.41, David Olofson wrote:
[...]
I just realized something that might be worth pointing out.
If you send multiple RAMP events for the same control at the same
timestamp, only the last one will have any effect. This is because
RAMP events change only the delta, and it takes sample frame loops to
actually change the value.
The problem is that if you send multiple RAMP events that are so
close together they end up getting the same timestamp, results won't
be what you want.
For example, setting the initial level of an envelope and then
setting up the delay or attack phase won't work, unless you wait for
one frame before sending the RAMP event for the delay or attack
phase. Similarly, an attack duration of 0 would result in the decay
starting at the current value, instead of the attack peak level.
Note that waiting for one frame after saying "ramp to y over 0
frames" is actually illegal by the definition! You're one frame past
the aim point when the next event arrives, so results are undefined.
So, it seems like we'll need that 0 test anyway. It should obviously
apply the target value instantly, so that later events will work even
if they land at the same timestamp. It doesn't have to set the delta
at all, as sending a 0 duration means you *have* to send another
event with the same timestamp anyway.
Resulting Audiality code (how unusual! ;-):
if(ev->arg2)
{
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2 + 1;
}
else
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
> > So, alternative 1; RAMP events only:
[...]
No branch is
needed,
Excellent! :-)
1:24 a.m.
On Tuesday 21 January 2003 05.09, David Olofson wrote:
So, it seems like we'll need that 0 test anyway.
It should
obviously apply the target value instantly, so that later events
will work even if they land at the same timestamp. It doesn't have
to set the delta at all, as sending a 0 duration means you *have*
to send another event with the same timestamp anyway.
Another idea:
Since we need that (duration == 0) test anyway, why not have it
explicitly stop ramping as well, so we can connect non-ramped outputs
to ramped inputs and vice versa?
This doesn't interfere with normal operation, and it seems rude and
pointless to enforce ramping on all FP ins and outs, just to
guarantee punishment if you break the rules while ramping. :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
5:26 a.m.
On Tue, Jan 21, 2003 at 06:17:40 +0100, David Olofson wrote:
On Tuesday 21 January 2003 05.09, David Olofson
wrote:
I'd say that has different semantics, and so should be a seperate event.
Say... SET ;)
So, it seems like we'll need that 0 test
anyway. It should
obviously apply the target value instantly, so that later events
will work even if they land at the same timestamp. It doesn't have
to set the delta at all, as sending a 0 duration means you *have*
to send another event with the same timestamp anyway.
Another idea:
Since we need that (duration == 0) test anyway, why not have it
explicitly stop ramping as well, so we can connect non-ramped outputs
to ramped inputs and vice versa? This doesn't interfere with normal operation, and
it seems rude and
pointless to enforce ramping on all FP ins and outs, just to
guarantee punishment if you break the rules while ramping. :-)
Sure.
- Steve
12:27 p.m.
On Tuesday 21 January 2003 10.19, Steve Harris wrote:
[...]
Well, yeah. Back at square 1! :-)
Though, the 0 test is still really a fix for a logical glitch that
appears in the borderland between continous and sampled time.
So, if the test is needed anyway, is it all that bad to "abuse" it a
little, to make it usable as a SET event as well? I don't really like
it, but I don't like a special SET event any more...
Then again:
case RAMP:
if(ev->arg2)
{
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2 + 1;
break;
}
case SET:
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv = 0;
break;
Note that while this fixes the broken 0 duration case, it also has
the side effect that RAMP(value, 0) becomes equivalent to SET(value).
So, you don't really need to use the SET event explicitly at all.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Another idea:
Since we need that (duration == 0) test anyway, why not have it
explicitly stop ramping as well, so we can connect non-ramped
outputs to ramped inputs and vice versa?
I'd say that has different semantics, and so should be a seperate
event. Say... SET ;)
1:06 p.m.
On Tue, Jan 21, 2003 at 05:20:56 +0100, David Olofson wrote:
Note that while this fixes the broken 0 duration case,
it also has
the side effect that RAMP(value, 0) becomes equivalent to SET(value).
So, you don't really need to use the SET event explicitly at all.
Not quite, RAMP(new_val, 0) says that delta_val = val - new_val,
whereas SET(new_val) says that delta_val = 0, val = new_val. Not really
the same.
It also gives the possibility of controls that dont accept RAMPs, though
that may or may not be a good idea.
- Steve
1:28 p.m.
On Tuesday 21 January 2003 17.59, Steve Harris wrote:
On Tue, Jan 21, 2003 at 05:20:56 +0100, David Olofson
wrote:
Right; that's the minimal implementation. I was commenting on the
fall-through case variant I posted.
Note that while this fixes the broken 0 duration
case, it also
has the side effect that RAMP(value, 0) becomes equivalent to
SET(value). So, you don't really need to use the SET event
explicitly at all.
Not quite, RAMP(new_val, 0) says that delta_val = val - new_val,
whereas SET(new_val) says that delta_val = 0, val = new_val. Not
really the same. It also gives the possibility of controls that dont
accept RAMPs,
though that may or may not be a good idea.
Well, having totally incompatible semantics for ramped and non-ramped
controls means they have to be entirely different control types. You
wouldn't be able to connect a ramped float32 output to a non-ramped
float32 input or vice versa, without a converter in between.
It seems to me that if requiring that there is a SET event, or that
RAMP(value, 0) performs the SET action, is all we need, that's a much
smoother solution. We don't have to *deliberately* make hosting hard,
even if it "only" impacts host authors.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
5:25 a.m.
On Tue, Jan 21, 2003 at 05:09:34 +0100, David Olofson wrote:
For example, setting the initial level of an envelope
and then
setting up the delay or attack phase won't work, unless you wait for
one frame before sending the RAMP event for the delay or attack
phase. Similarly, an attack duration of 0 would result in the decay
starting at the current value, instead of the attack peak level.
Yes, you're right. Damn.
OTOH If we define that RAMP events arring in the same timestamp for the
same control override each other then it becomes the hosts job to
normalise them (not a hard task).
Envelope sections with 0 duration are often not provided anyway.
- Steve
12:16 p.m.
On Tuesday 21 January 2003 10.18, Steve Harris wrote:
On Tue, Jan 21, 2003 at 05:09:34 +0100, David Olofson
wrote:
It's not hard, but I didn't like the way it looked in Audiality's EG,
and I don't like the logical glitch that is a broken duration 0.
With only RAMP events and RAMP(value, 0) as a special case on the
receiver end, the EG code is nice and simple, and the receiver end
if() is trivial.
I could just test for 0 duration in the EG, but the only really
straightforward solution would be to delay for an extra frame, which
would effectively make a 0 duration stage take one frame too many ==>
timing error build-up. Then I would need to shorten the next section
by 1 - but what happens if the next section is 0 or 1 frames...?
I don't feel like I need that when I'm adding multiplication with
ramped input - and this is still pretty basic event processing! :-)
For example, setting the initial level of an
envelope and then
setting up the delay or attack phase won't work, unless you wait
for one frame before sending the RAMP event for the delay or
attack phase. Similarly, an attack duration of 0 would result in
the decay starting at the current value, instead of the attack
peak level.
Yes, you're right. Damn.
OTOH If we define that RAMP events arring in the same timestamp for
the same control override each other then it becomes the hosts job
to normalise them (not a hard task). Envelope sections with 0 duration are often not
provided anyway.
They definitely generate nasty clicks, but setting the initial level
of an envelope higher than 0 generally doesn't, unless the waveform
starts with a click. Anyway, this isn't as much of an issue as the
special-casing needed in senders, I think.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
12:27 p.m.
some guys from ohm force mentioned at the unified plugin api meeting
on sunday that they and a number of other people on the music-dsp (or
perhaps some other list) have written a 60 page document on proposals
for a plugin API. they left the meeting before i could get a url (they
had a copy with them - this is not vaporware).
it seems like it would be worth reading before going to far further
with XAP.
--p
1:17 p.m.
On Tue, Jan 21, 2003 at 11:24:20 -0500, Paul Davis wrote:
some guys from ohm force mentioned at the unified
plugin api meeting
on sunday that they and a number of other people on the music-dsp (or
perhaps some other list) have written a 60 page document on proposals
for a plugin API. they left the meeting before i could get a url (they
had a copy with them - this is not vaporware).
it seems like it would be worth reading before going to far further
with XAP.
Yes. Do you have anything to report back from the meeting?
- Steve
1:44 p.m.
On Tue, Jan 21, 2003 at 11:24:20 -0500, Paul Davis
wrote:
well, it was interesting. as one could have predicted, nothing much
happened in terms of movement other than the 40 or so people there
signing up to a mailing list. it was proposed that there would be a 4
stage process:
requirement gathering
design
review
publication
it was not clear whether any of these steps would be accomplished. ron
noted that expected the whole thing to take several (1-3) years.
however, it was very significant to have every involved company except
digidesign there (MS is represented, in essence, by Cakewalk who wrote
DXi). i'm not sure that it has ever happened before. the most
suprising thing for many people was steinberg's response: they seemed
really quite hurt, in the full psychological sense of that term, that
this was even happening. they considered VST to be "the standard" and
that it was MOTU and Cakewalk who spoiled things by not adopting
it. the politics of the session were quite delicate. a rep from apple
indicated a real reluctance on their part to putting much effort into
it because of their recent effort on AU, but they promised to track
what comes of it (if anything). there was a certain level of
skepticism that even if a new API was developed that anyone would use
it as any more than the "5th format" (after VST, MAS, AU, TDM etc.)
ron kuper from cakewalk who initiated the whole thing was quite clear
that one possible outcome from the process could be a decision to
recommend an existing API, but that the goal of the process is
definitely to have an industry group and/or standards body manage
whatever was selected. several folks raised the central problem of
(even benign) proprietary control of an API, and the shadow of the
OMS/Opcode/Gibson debacle hung long over any claims that a particular
company could safeguard "a standard". it was inevitably the plugin
writers who were most enthusiastic, and several people talked about
their desire for new features (or even just fully implemented
features). joe bryan of universal audio, always one of the most lucid
contributors to the vst-plugin list and a really really deeply
technical guy was very clear about some of the things they want to see
- they have particular issues because they are running plugins on
dedicated hardware, not the host CPU.
the biggest issue right now is just what happens next. the MMA is
going to sponsor a mailing list. the initial requirements gathering
phase of the process will be open to the public, but the current
thinking is that the design phase after that will be restricted to MMA
members. if that happens, i propose that LAD organizes to raise the
$450 or so that it would take to register a corporate membership of
some kind. the review phase (if it ever gets there) will be public,
and then the release phase will be private. the result will end up
being much like the MIDI spec - publically accessible, though the full
specs might cost non-MMA members (unlikely in an online era). note
that many plugin companies are not MMA members either - this is not
just an issue for folks in the linux world.
there was a slight air of "this is never going to work" that hung in
the room, but at the same time, there was also a sense of "its time we
did this". the absence of digi was very notable - if they are really
the 800lb gorilla that everybody thinks they are, its a bit of a
problem.
the last thing i would mention are the concerns i heard about copy
protection. apparently one of the reasons why some plugin writers only
write for TDM is that it provides excellent (hardware based) copy
protection. waves would be the obvious example here, though they
support some other formats too. it seems that those companies who
stake their existence on plugins would be very scared of supporting
any platform that allowed copying in the way that windows/macos and
linux do. on the other hand, i talked with angus hewlett of fxpansion
(another brit). angus knows that his warez/demo-to-sales ratio is on
the order of "hundreds to 1", but he doesn't seem to care too much. he
makes a living with/for 2 other employees, and things look ok to him.
the biggest thing that struck me (and this was echoed by comments from
angus) was how **tiny** the whole music/audio software industry
is. angus said that after 2-3 years of doing this, he knows more or
less everyone in the industry. you really had the sense that, barring
digidesign, we had the whole group in that room. i used to have
friends who could have bought most of the companies represented there
out of their own personal accounts :)) people planning on getting rich
in this field are out of their minds.
--p
some guys from ohm force mentioned at the unified
plugin api meeting
on sunday that they and a number of other people on the music-dsp (or
perhaps some other list) have written a 60 page document on proposals
for a plugin API. they left the meeting before i could get a url (they
had a copy with them - this is not vaporware).
it seems like it would be worth reading before going to far further
with XAP.
Yes. Do you have anything to report back from the meeting?
5:06 p.m.
On Tuesday 21 January 2003 18.41, Paul Davis wrote:
[...]
it was not clear whether any of these steps would be
accomplished.
ron noted that expected the whole thing to take several (1-3)
years.
Ouch. Well, as we all know, this kind of stuff takes time - and
having all that people in the discussion won't make it go faster.
Maybe the result could be better, though, if it's managed properly,
and enough people *really* care.
[...]
the
most suprising thing for many people was steinberg's response: they
seemed really quite hurt, in the full psychological sense of that
term, that this was even happening. they considered VST to be "the
standard" and that it was MOTU and Cakewalk who spoiled things by
not adopting it.
Frankly, I'm not very surprized at all. Despite the apparent
"openness", I've aways had this "it's ok as long as we're in
control"
feeling about them.
In real life, if Steinberg doesn't support a platform, it's not
supported by VST, period. This is the main reason why the OpenBeOS
guys are working on their own API, AFAIK. Steinberg are not
interested, and won't support VST 3.0 on OpenBeOS, so VST is a dead
end there.
It is by all means *expected* that other companies stay away from
VST, so I really don't think Steinberg has the right to blame other
companies for not adopting VST.
the politics of the session were quite delicate. a
rep from apple indicated a real reluctance on their part to putting
much effort into it because of their recent effort on AU, but they
promised to track what comes of it (if anything).
Kind of expected. But at least, they're not whining about others not
adopting their "standard"...
As to AU, I think the use of Objective C is a serious obstacle. I
also dislike the way they handle scheduling, and the general lack of
consideration for API overhead... But that's another topic!
there was a
certain level of skepticism that even if a new API was developed
that anyone would use it as any more than the "5th format" (after
VST, MAS, AU, TDM etc.)
VST, MAS, AU, TDM etc all have issues that make them unsuitable as
standards, and unlikely to ever be accepted as such. I think people
are forgetting the *real* reason why there still isn't a real
standard, and thus, what could make the new alternative different. It
must be Free and controlled by "everyone", or companies won't adopt
it, fearing that the API owners will abuse their powers.
As to XAP, if might become Yet Another Format - but it's also
different from the others; it's totally Free and Open in all
respects. OTOH, I'm afraid corporate people still have a problem
understanding that a standard doesn't *have* to come from one or more
megacorporations. Things are changing, though...
ron kuper from cakewalk who initiated the
whole thing was quite clear that one possible outcome from the
process could be a decision to recommend an existing API, but that
the goal of the process is definitely to have an industry group
and/or standards body manage whatever was selected.
That sounds mutually exclusive to me. The owner of the recommended
standard would have to give up control to a group or standards body,
and well, if the rest of them are anything like Steinberg, it just
won't happen. (Though, people actually change their minds *before*
all is lost, occasionally.)
several folks
raised the central problem of (even benign) proprietary control of
an API, and the shadow of the OMS/Opcode/Gibson debacle hung long
over any claims that a particular company could safeguard "a
standard".
BTW, what if people think of LAD as a company in this regard?
I think it's important to point out that we really don't *control*
LADSPA or XAP. If you're developing software using a GPL/LGPL API,
you can fork and go your own way if you really can't agree with the
maintainers of the original project. It would certainly not be a nice
thing to do, so it's in everybodys interest to avoid it, but the
possibility should be sufficient to ensure people we don't want or
have the power to screw anyone using our APIs.
On a similar note, what if someone *wants* to destroy XAP and LADSPA,
and deploys an embrace and extend attack on them? I think we'd better
state that forked projects must not use the original prefixes, or
something... Though, we can't prevent people from reimplementing
LADSPA or XAP, thus bypassing that requirement.
Frankly, the methods of companies like MS, Steinbergs reaction to
others not adopting their API and things like that make me nervous. I
almost *expect* any significantly successful standard to be attacked
by evil companies in one way or another.
it was inevitably the plugin writers who were most
enthusiastic, and several people talked about their desire for new
features (or even just fully implemented features).
Any details? :-)
joe bryan of
universal audio, always one of the most lucid contributors to the
vst-plugin list and a really really deeply technical guy was very
clear about some of the things they want to see - they have
particular issues because they are running plugins on dedicated
hardware, not the host CPU.
Well, this is currently beyond the scope of XAP, but I'd still be
very interested in more info on this stuff. (I know how VST deals
with it, but I don't know if that's sufficient or optimal.)
the biggest issue right now is just what happens next.
the MMA is
going to sponsor a mailing list. the initial requirements gathering
phase of the process will be open to the public, but the current
thinking is that the design phase after that will be restricted to
MMA members. if that happens, i propose that LAD organizes to raise
the $450 or so that it would take to register a corporate
membership of some kind.
Well, I have slightly mixed feelings, but an MMA membership probably
wouldn't hurt, even if this particular project fails. If nothing
else, it might make us look slightly better in the eyes of those that
still think "it can't be serious if it's free", or whatever.
Anyway, I guess I'm in, although if it's just me and Paul, I'm not
totally happy about the $225. :-)
the review phase (if it ever gets there)
will be public, and then the release phase will be private.
BTW, does "private" mean "top secret", NDA style, or just that
non-members will effectively be ignored?
the
result will end up being much like the MIDI spec - publically
accessible, though the full specs might cost non-MMA members
(unlikely in an online era). note that many plugin companies are
not MMA members either - this is not just an issue for folks in the
linux world.
Right. Do you know if any companies using Linux for audio hardware
are MMA members, and/or will take part in this? Basically asking if
LAD would be the only entity to represent Linux in this context.
there was a slight air of "this is never going to
work" that hung
in the room, but at the same time, there was also a sense of "its
time we did this".
Well, both views are motivated. In some ways, a totally generic,
portable "do it all" plugin API seems doable, but OTOH, looking at
the number of features that everyone wants in it, one can't help
being worried that the size of the SDK will be on par with that of
XFree86. ;-)
the absence of digi was very notable - if they
are really the 800lb gorilla that everybody thinks they are, its a
bit of a problem.
I think they'd just have to see an open standard run on dedicated
hardware. Other than that, they probably hope that native processing
will die a painful death. The way things look, they might be worried
about going that way themselves unless they play a M$ trick...
the last thing i would mention are the concerns i
heard about copy
protection. apparently one of the reasons why some plugin writers
only write for TDM is that it provides excellent (hardware based)
copy protection.
Well, if that's what they want, I'm afraid they'll have to stick with
TDM, or switch to another closed, proprietary and h/w specific
standard.
Either way, we can't make Digi or the TDM fans happy without
threatening their excistence at the same time. I think that's why
they won't hear of this project; as simple as that.
waves would be the obvious example here, though
they support some other formats too. it seems that those companies
who stake their existence on plugins would be very scared of
supporting any platform that allowed copying in the way that
windows/macos and linux do. on the other hand, i talked with angus
hewlett of fxpansion (another brit). angus knows that his
warez/demo-to-sales ratio is on the order of "hundreds to 1", but
he doesn't seem to care too much. he makes a living with/for 2
other employees, and things look ok to him.
Just a thought: If you write some great plugin that "everyone" wants
to use, what would be most profitable:
1) Making it for TDM and selling it at a price $199, or
2) Making it for VST and selling it at $49?
Either way, people have a serious attitude problem when it comes to
software and stealing. Most people don't even think of it as a crime
in any way! So, perhaps it doesn't matter what the price is, as long
as the plugin can be pirated.
Which is why I won't bother selling closed source software. I'd much
rather have a few people sending patches, than a bunch of paying
customers complaining about the effects my software has on their
dogs, and whatnot. ;-)
the biggest thing that struck me (and this was echoed
by comments
from angus) was how **tiny** the whole music/audio software
industry is. angus said that after 2-3 years of doing this, he
knows more or less everyone in the industry. you really had the
sense that, barring digidesign, we had the whole group in that
room. i used to have friends who could have bought most of the
companies represented there out of their own personal accounts :))
BTW, that's rather interesting, put in relation to the number of
Linux audio hackers as well. How many and how long does it *really*
take to create a complete Linux based studio solution?
people planning on getting rich in this field are out
of their
minds.
Right. My plan is getting rich creating music on Linux instead. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
5:45 p.m.
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
Well, I have slightly mixed feelings, but an MMA
membership probably
wouldn't hurt, even if this particular project fails. If nothing
else, it might make us look slightly better in the eyes of those that
still think "it can't be serious if it's free", or whatever.
agreed.
Anyway, I guess I'm in, although if it's just
me and Paul, I'm not
totally happy about the $225. :-)
Make that $150.
Do I hear $112.5? ;)
Next question is who would take the initiative
to spearhead this. Don't look at me. :-)
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's SCIENTIFIC HAPPY BITER!
(courtesy of isometric.spaceninja.com)
11:34 p.m.
Next question is who would take the initiative
to spearhead this. Don't look at me. :-)
i'll be happy to organize it if and when the time comes. its not time
yet. i am sure there will be some technicalities to address. tom white
at the mma seemed like a reasonable guy, however.
--p
22 Jan
22 Jan
5:42 a.m.
On Tue, Jan 21, 2003 at 10:31:56 -0500, Paul Davis wrote:
Is there a good reason for not joining ahead of time, or it it not yet
certain to go ahead?
- Steve
Next question
is who would take the initiative
to spearhead this. Don't look at me. :-)
i'll be happy to organize it if and when the time comes. its not time
yet. i am sure there will be some technicalities to address. tom white
at the mma seemed like a reasonable guy, however.
9:57 a.m.
Next question is who would take the initiative
to spearhead this. Don't look at me. :-)
i'll be happy to organize it if and when the time comes. its not time
yet. i am sure there will be some technicalities to address. tom white
at the mma seemed like a reasonable guy, however.
21 Jan
21 Jan
6:04 p.m.
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
As to AU, I think the use of Objective C is a serious
obstacle. I
also dislike the way they handle scheduling, and the general lack of
consideration for API overhead... But that's another topic!
I dont know that much about AU. I like objective C, but it has some
performace issues. In some ways it would make sense for linux to support
it, it would make porting plugins between MacOS X and Linux easier,
especially if you can make X11 guis for it.
Is it possible to read teh specs without becoming tainted?
That sounds mutually exclusive to me. The owner of the
recommended
standard would have to give up control to a group or standards body,
and well, if the rest of them are anything like Steinberg, it just
won't happen. (Though, people actually change their minds *before*
all is lost, occasionally.)
This has happened with Apple in the past, and I belive that AU is the most
"modern" of the plugin APIs.
On a similar note, what if someone *wants* to destroy
XAP and LADSPA,
and deploys an embrace and extend attack on them? I think we'd better
state that forked projects must not use the original prefixes, or
something... Though, we can't prevent people from reimplementing
LADSPA or XAP, thus bypassing that requirement.
I'm not sure you could do that while retaining the GPL.
Well, both views are motivated. In some ways, a
totally generic,
portable "do it all" plugin API seems doable, but OTOH, looking at
the number of features that everyone wants in it, one can't help
being worried that the size of the SDK will be on par with that of
XFree86. ;-)
Yep, a big, bloaty API is my biggest fear.
Which is why I won't bother selling closed source
software. I'd much
rather have a few people sending patches, than a bunch of paying
customers complaining about the effects my software has on their
dogs, and whatnot. ;-)
Hell yeah, if I released closed source I'd have to do my own beta
testing ;)
BTW, that's rather interesting, put in relation to
the number of
Linux audio hackers as well. How many and how long does it *really*
take to create a complete Linux based studio solution?
Bizarrely, I think we actually spend more time reinventing the wheel than
the commercial guys. We have a lot of low level library reuse, but
everyone and his dog wants to write a WAV editor. Theres also a shortage
of maths, electronics and graphic design skills compared to commercial
developers (for plugins at least).
- Steve
6:11 p.m.
On Tue, Jan 21, 2003 at 09:57:59PM +0000, Steve Harris wrote:
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David
Olofson wrote:
AU does not use objective-C -- the API is C. CoreAudio and CoreMIDI are
somewhat accessible from ObjC, but all GUIs for AudioUnits are written in
Carbon, which is a C/C++ API.
best,
wb
--
Will Benton
willb(a)acm.org
As to AU, I think the use of Objective C is a
serious obstacle. I
also dislike the way they handle scheduling, and the general lack of
consideration for API overhead... But that's another topic!
I dont know that much about AU. I like objective C, but it has some
performace issues. In some ways it would make sense for linux to support
it, it would make porting plugins between MacOS X and Linux easier,
especially if you can make X11 guis for it.
7:58 p.m.
On Tuesday 21 January 2003 23.04, Will Benton wrote:
On Tue, Jan 21, 2003 at 09:57:59PM +0000, Steve Harris
wrote:
The very AU interfaces looked a *lot* like Objective C to me in the
docs, but maybe I wasn't reading carefully enough...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David
Olofson wrote:
AU does not use objective-C -- the API is C. CoreAudio and
CoreMIDI are somewhat accessible from ObjC, but all GUIs for
AudioUnits are written in Carbon, which is a C/C++ API. As to AU, I think the use of Objective C is a
serious obstacle.
I also dislike the way they handle scheduling, and the general
lack of consideration for API overhead... But that's another
topic!
I dont know that much about AU. I like objective C, but it has
some performace issues. In some ways it would make sense for
linux to support it, it would make porting plugins between MacOS
X and Linux easier, especially if you can make X11 guis for it. 
7:57 p.m.
On Tuesday 21 January 2003 22.57, Steve Harris wrote:
I don't think we can prevent someone from creating binary compatible
hosts or plugins using their own headers instead of ours. As long as
we can't prove they just copied our work, and then extended and/or
changed it, we can't do anything about it, I think.
[...]
It's not that strange, really. We just do what we like best most of
the time, and that generally means hacking away on various little
projects that we find interesting. Whether they're useful or Yet
Another <whatever> is secondary to most hackers. And of course, "I
can do it much better!" (although no one would admit ever thinking
that ;-), and running your own project is more fun.
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David
Olofson wrote:
Well, AU doesn't deal with GUIs at all, AFAIK. Porting it to Linux
should be doable, I guess, but I'm afraid the situation is rather
similar to that with VST; most plugins depend heavily on either
platform specific stuff, or proprietary technology for their GUIs.
As to AU, I think the use of Objective C is a
serious obstacle. I
also dislike the way they handle scheduling, and the general lack
of consideration for API overhead... But that's another topic!
I dont know that much about AU. I like objective C, but it has some
performace issues. In some ways it would make sense for linux to
support it, it would make porting plugins between MacOS X and Linux
easier, especially if you can make X11 guis for it. Is it possible to read teh specs without becoming
tainted?
Well, at least you don't have to sign an NDA to read it, but other
than that, it would be the usual copyright stuff, basically - but
IANAL.
[...]
On a similar
note, what if someone *wants* to destroy XAP and
LADSPA, and deploys an embrace and extend attack on them? I think
we'd better state that forked projects must not use the original
prefixes, or something... Though, we can't prevent people from
reimplementing LADSPA or XAP, thus bypassing that requirement.
I'm not sure you could do that while retaining the GPL. BTW,
that's rather interesting, put in relation to the number of
Linux audio hackers as well. How many and how long does it
*really* take to create a complete Linux based studio solution?
Bizarrely, I think we actually spend more time reinventing the
wheel than the commercial guys. We have a lot of low level library
reuse, but everyone and his dog wants to write a WAV editor. Theres
also a shortage of maths, electronics and graphic design skills
compared to commercial developers (for plugins at least).
Yeah... The ones that are truly interested do *only* DSP hacking, and
the rest generally don't deal with audio at all. Besides, even if you
have other skills than hacking, hacking just takes too much of your
time. GUI design and graphics aren't things hackers in general spend
much time on, be there artistic potential or not.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
11:33 p.m.
BTW,
that's rather interesting, put in relation to the number of
Linux audio hackers as well. How many and how long does it *really*
take to create a complete Linux based studio solution?
Bizarrely, I think we actually spend more time reinventing the wheel than
the commercial guys. We have a lot of low level library reuse, but
everyone and his dog wants to write a WAV editor. Theres also a shortage
of maths, electronics and graphic design skills compared to commercial
developers (for plugins at least). 
28 Jan
28 Jan
6:09 p.m.
New subject: [linux-audio-dev] XAP status
Hey all,
I was out of town last week, and no inet access. I'll catch up again this
week.
With all the elaborate discussions we've been having, I decided that BEFORE
I work on the header any more, I should spec all the details.
I've begun transforming the overview I posted a while back into a more
proper spec. It will have details of concepts, but not details of
implementation.
I'll post as soon as I have something worked out - like a good Table of
Contents.
Tim
21 Jan
21 Jan
5:48 p.m.
On Tue, Jan 21, 2003 at 12:41:21PM -0500, Paul Davis wrote:
the biggest issue right now is just what happens next.
the MMA is
going to sponsor a mailing list. the initial requirements gathering
phase of the process will be open to the public, but the current
thinking is that the design phase after that will be restricted to MMA
members. if that happens, i propose that LAD organizes to raise the
$450 or so that it would take to register a corporate membership of
some kind.
Agreed. I'l chip in my share. It may even be the thing that saves it from
totally excessive design-by-committee.
there was a slight air of "this is never going to
work" that hung in
the room, but at the same time, there was also a sense of "its time we
did this". the absence of digi was very notable - if they are really
the 800lb gorilla that everybody thinks they are, its a bit of a
problem.
I'm not convinced it will work myself, but we have to give it a try right?
digidesign, we had the whole group in that room. i
used to have
friends who could have bought most of the companies represented there
out of their own personal accounts :)) people planning on getting rich
in this field are out of their minds.
I'm just glad its not making me too poor ;)
- Steve
1:22 p.m.
On Tuesday 21 January 2003 17.24, Paul Davis wrote:
some guys from ohm force mentioned at the unified
plugin api
meeting on sunday that they and a number of other people on the
music-dsp (or perhaps some other list) have written a 60 page
document on proposals for a plugin API. they left the meeting
before i could get a url (they had a copy with them - this is not
vaporware).
it seems like it would be worth reading before going to far further
with XAP.
Yes, definitely. Couldn't find anything on the 'net, so I mailed them.
BTW, Google told me the OpenBeOS guys are/were up to something. From
the initial discussion, it seems like what they have in mind is
*very* entangled with OpenBeOS system services, but it would still be
interesting to see how they handle connections, control ramping,
instrument voice control and stuff.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
7999
days inactive
8008
days old
linux-audio-dev@lists.linuxaudio.org
29 comments
7 participants
participants (7)
-
David Gerard Matthews -
David Olofson -
Paul Davis -
Paul Winkler -
Steve Harris -
Tim Hockin -
Will Benton