Subject: Re: [linux-audio-dev] App intercomunication issues, some views. GSOUND ????
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Fri Aug 02 2002 - 12:25:55 EEST
On Fri, 2 Aug 2002, Toni Moreno Giménez wrote:
> I'm working on 3 libs and 4 apps + doc, as you can understand current
> features are now really poor. After 2 years of study I'm sure this
> architecture can help to make one, or three ardours, if lad people can work
> together. I 'm workign on a easy design for me, and for future users.... for
> make easy a complete redesign if needed ( this is beacouse of I'm coding over
> all documented and justified, I'm not a guru, I need for other people to fix
> my errors, and bad design goals).
I agree that partitioning your application suite to reusable libraries is
a good design decision, but it's not a silver-bullet for easy creation of
audio apps. Making reusable software components is just really difficult.
Technical issues are just one side of the problem.
As an example, for the last 5 years I've been working on libecasound,
which is essentially a mix of an application framework and a traditional
software library (you can extend it by both inserting custom code to
selected configuration points and by controlling the top-level control
flows).
I've built four applications on top of libecasound myself; ecasound
(multitrack recorder/mixer), ecamegapedal (realtime fx-processing),
ecawave (graphical audio file editor) and qtecasound (graphical frontend
to ecasound, not in development anymore). But that's it, although the
library has been available (and stable!) for a long time, very few apps
have been written on top of it. Most of the apps written by other people
than me (see <http://eca.cx/eca_links.html>) are using and extending
ecasound, not libecasound.
For me, maintaining a central library is mostly a question about
minimizing maintenance work. And in this respect libecasound has been a
huge success. But for developing more complex (= interesting!)
applications, I wouldn't recommend using libecasound or any other
high-level framework. For most application development, it's usually just
easier to write all the higher level code yourself than to rely on big
libraries and frameworks. Reusing well-defined components like audiofile
libs (libaudiofile, libsndfile) and plugin standards (LADSPA) is much more
beneficial (you lose only a little flexibility, but save a lot of
implementation&design work).
But anyways, welcome to the group! Even though sharing code is sometimes
difficult, sharing ideas is easier and this list is the perfect place for
doing that! ;)
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Fri Aug 02 2002 - 12:49:31 EEST