Subject: Re: [linux-audio-dev] App intercomunication issues, some views. GSOUND ????
From: Paul Davis (pbd_AT_op.net)
Date: Thu Aug 01 2002 - 21:24:06 EEST
>To make sure the GSound API has the needed features, we are working also on
>diferent applications, who help us to desing, detect/fix bugs, and redesing
>the API if needed.
>
>NxsTools: Something like SoX.
>NxsAudio: A single audio editor (Similar to Soundforge)
>NxsrRAck: A rebirth 338 clone
>NxsrDJ: somthing like Tracktor DJ.
>
>And perhaps some day apps like Nuendo and Reason.
i don't believe that your approach will work. as the author of the
only vaguely nuendo-like program for linux, i don't believe that a
design based on stuff like:
----------------------------------------------------------------------
GsDev: low level access to any native/virtual audio/midi system.
(--Portaudio--/--PorMidi-)
GsData: a subset of tools to manage usual audio/midi data. (???)
GsCda: low level access to CD-RW/DVD hardware. (--CdParanoia--/--CdRecord--)
GsAmod: A "modular data flow graph filter" aproach. (???)
Gsff: A set of tools to make I/O from diferent File Formats (Libsndfile,
libaudiofile)
GsDsp: Common DSP operations. (Csound/Mustajuuri/MPEG4)
----------------------------------------------------------------------
can be turned into an efficient, easy to use system. Much of what is
necessary is in the GsData category, and if you take a look at Ardour,
you'll see that things get really hairy, really fast. there is a lot
of code in libardour to support extremely important functionality that
just doesn't show up in many other programs.
just today, i had to change a deep and fundamental aspect of how
things work internally to the disk buffering mechanism to support
ardour's scrubbing mechanism, because scrubbing (notably supporting
instant-reversal when you're scrubbing 16 tracks at one time)
radically changes the assumptions i had used about the relationships
between disk and audio I/O.
its not that i think that its impossible to write general purpose
libraries for some or even all of this stuff. its more that i think
you can't do it without first writing a really big and complex
application to fully understand all the performance and design
issues.
ardour may well end up as the codebase for a bunch of libraries, but i
don't think you could create ardour from a bunch of libraries.
--p
This archive was generated by hypermail 2b28 : Thu Aug 01 2002 - 21:28:04 EEST