Re: [linux-audio-dev] Draft: Audiality article for MusicStation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Draft: Audiality article for MusicStation
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka   05 1999 - 15:43:45 EDT


On Tue, 05 Oct 1999, Paul Barton-Davis wrote:
> >The language of the API is C. C++ would add more complexity and hidden
> >overhead than it would simplify development, as a single plug-in is a very
> >simple, low level object.
>
> a small detail. I think the above is needlessly religious.

Yep. I actually had in mind leaving out the motivation altogether, or cutting
it down to "it works for The Kernel"...

> Instead of inviting language wars, you can write:
>
> As the Gimp ToolKit (GTK+) has shown very well, it tends to be
> easier to bind a variety of different languages to an API written
> for C. This decision makes it possible for users of, for example,
> C++, Java, and Python to use the API effectively while using the
> idioms of their chosen language.

Ok.

> And remember, I'm a C++ bigot :)

Well, I usually prefer C++ too, even for RT stuff :-), but I don't think it's
the right tool for this job.

> On a broader front, I feel that its the purpose of the article is a
> little mixed.

Yes. Should be three articles, or at least two...

> Although I think that Audiality is an interesting and
> worthwhile project, it holds no more significance for me than aRtS,
> Brahms or a variety of other excellent pieces of software. By
> contrast, the development of a well-defined plugin API for audio
> applications under Linux is of enormous significance. I may very well
> never use Audiality, but I might write or use a different
> server/engine that supported this standard API, and I might write
> or use plugins that could be used with it.

Yep... But what's the name of the API?

> Reading your article doesn't give me much of a handle on the
> distinction between these two, and makes it sound as if, in order to
> support the development of a standard API, I need to be thinking about
> Audiality. If this is true, then the whole idea of a standard API will
> have failed before we even get started.

That's the strange thing here... Currently, I'm not really working on the
Audiality engine, but on the plug-in API. I have no name for the *interesting*
part of what I'm doing, and besides, I was asked to write about the "proposed
API", referred to as Audiality... Need to make a decision here.

> So I think that you should decide whether the article is really a call
> for a standard API or for participation in Audiality. I am very happy
> to contribute my energy, stupidity and some time to the former, but
> I'm not terribly interested in the latter.

The former is what it's all about. Frankly, by now the Audiality _Engine_ is
little more than my starting point for getting a useful plug-in API together.
Except for the RTL implementation, it may well never be needed.

Audiality is just a name that happened to get mixed up with what I'm currently
trying to do... I didn't expect this much interest when I went public with the
project. I expected to gather a few useful ideas, and then get back to hacking,
not hearing much from anyone before I had yet another engine, living in a world
of it's own like most of the others. At that time, it would have made sense to
find a new name for the API, if anyone would care to use it in other projects.

Now, I have a project name that some people think is the name of the API...
Should have thought about that first! *hehe*

> As it happens, I've spent a lot of time thinking about your proposed
> event-based system, and I suspect that I could get Quasimodo to
> support it in a weekend or less, although there would be no plugins
> that could use it (yet) :) So for me, this distinction is critical.

I'd be happy to see any form of working implementation ASAP. There will most
certainly be details of the API that don't turn out as well in IRL as in the
headers, so I think the best way to get the API ready within the next few
centuries is to hack, and yell some at me as design flaws are encountered. I'll
hack some myself of course, but as I don't have a working engine of my own to
play with anyway, perhaps I'd better stay around the design department for now.

//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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST