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: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka   04 1999 - 22:47:26 EDT


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

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

On a broader front, I feel that its the purpose of the article is a
little mixed. 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.

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.

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.

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.

--regards,
--p


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