Subject: Re: [linux-audio-dev] My Hopes for an Open Plugin Specification
From: David Olofson (audiality_AT_swipnet.se)
Date: pe elo 27 1999 - 18:24:14 EDT
On Fri, 27 Aug 1999, est_AT_hyperreal.org wrote:
> Hello, people,
>
> First of all, I hope more people will participate in the dialog. :)
So do I. The massive force of our collective skills and experience should make
it possible to get something pretty decent together. Worked for Linux... :-)
In this case, we're actually dealing with Open Design rather than Open
Source... Kind of interesting. Has this been done before in this form?
> My personal hopes for an open plugin specification are based on
> frustration with the current situation. There's a *lot* of existing
> code out there. Usually when I want to use a piece of code for my
> purposes, I have to hack it up a little. I'd much rather hack it up
> to a common specification so that everyone can use it. Similarly for
> the code I write (or that my programs write :) I suspect most coders
> here can empathize with this.
Yep. And I'd like to add that there's quite a few hackers from The Dark Side
who are thinking about Converting. But they can't, as long as there's no
plug-in API they can port their DirectX and VST plugs to... Ok, they'll
probably need to get some more understanding of The Source before they decide
to release theirs, but I wouldn't mind seeing shareware Linux binaries. Some of
those plug-ins are pretty decent, and $20 or so isn't much, especially if you
get the whole OS and engine to run them for free with source!
And yeah, I'd pay the full price for plugs from the Big Guys as well, if there
was a system that made them usable. This is currently not the case, except for
ProTools. (Which is a dedicated hardware system; an obsolete design, IMO.)
> This means I want a specification that can accomodate most of the code
> out there that I'll probably end up using and most of the code that
> I'll end up writing. I hope other people's needs will be accomodated
> as well. This means that the specification should accomodate styles
> and paradigms that I don't plan on using and may even find
> distasteful.
Agree. Performance first, though. No creeping featurism, because that would kill
our project before it even got stable. I'd rather use an API with a style I
don't agree with, but results in good performance, than one the looks
cool, but doesn't solve the problem due to inherent performance or engine
implementation problems.
Anyway, that's exactly why I decided to go public with Audiality in the design
phase, rather than just hacking away. (Well, "talk is cheap" and all that, so
it's not easy to become popular without cool code on the web...) If there was a
spec to follow, I'd have been better off just shutting up and hack. But as
there's no API to build the engine around yet, this way is probably better.
> There's an incredible variety of approaches and concerns with respect
> to audio software on this list. If someone really wants a feature in
> the plugin specification, I think it should go in unless the cost for
> those who don't use it is overwhelming. That's how we can build a
> consensus specification. Applications that want to require/exclude
> certain types of plugins should have the means to do so. Plugin
> authors that don't want to worry about setting all the
> parameters/predicates right should be provided with reasonable
> defaults.
Limiting the new API's usefulness will hardly make it successful. That's
why I'm still collecting ideas rather than hacking a serious API spec. If I
did, I'd probably have to do it all over again a few times to get the new stuff
in without wrecking the API. I'll let others do the mistakes, while I let the
final API evolve in my mind. ;-)
> Anyhow, I hope this helps explain where I'm coming from as I make my
> more technical comments. :)
>
> Now, lets move on to audio world domination!
Yep, time to show the Big Guys how to do it! :-)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST