Subject: Re: [linux-audio-dev] XAP: Some thoughts on control ramping
From: David Olofson (david@olofson.net)
Date: Tue Jan 21 2003 - 23:00:13 EET
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 ---
This archive was generated by hypermail 2b28 : Tue Jan 21 2003 - 23:04:02 EET