Subject: Re: [linux-audio-dev] "pro" soundfile editors for linux
From: David Olofson (david_AT_gardena.net)
Date: ti helmi 08 2000 - 23:03:20 EST
On Tue, 08 Feb 2000, Kai Vehmanen wrote:
> Another problem is compile-time and inter-library compatibility
> problems. Most problem-reports I receive are either g++ or
> libstc++ related. And taking your Quasimodo as an example, I've
> never been able to compile it. Same goes with aRts. And believe me,
> I've tried both many, many times. I've have only a 14.4k modem
> connection to Internet, so I can't afford to continuously update
> my libraries.
(This is getting slightly off-topic, I think...)
This is perhaps the most important reason why I want to do MuCuS in
C, using as few external libraries as possible (preferably none -
MuCoS should do everything all the way down to the system level), and
no crap in the API that forces you to do M$ DirectX style upgrading
every few months to keep your system usable.
For example, do you need to upgrade the Linux virtual file system all
the time to run the latest applications? There are *years* between
any changes in the basic functionality, and most of the changes don't
break anything on the other side of the standard libc. Do you need
to update your SysV/POSIX ICP libs every time you compile some new
app that use them? I never had to, anyway... It happens all the time
with all the other cool toolkit libs and all that, though.
If VFS or ICP that is so heavily used, can be kept clean, compatible
and easy to use, I believe a real time communication/plugin API can
be done that way too. It's really pretty similar to an IPC API, after
all. The most obvious (if anyone actualy has managed to figure out
what I'm working on, that is ;-) difference between the average IPC
API (and most other APIs) and MuCoS is that the IPC is based on
function calls and a few structures, while the MuCoS API actually
*is* the structures (and some macros, in case you don't feel like
manipulating the structs "by hand".) The functions are just the
gateway to the outer world, and are used only when you have finished
an entire cycle of your job. A plugin won't even do function calls in
the normal case.
Still, it's basically just about passing data between plugin functions
and processes. No need to mix in stuff that you want to change ever
other week in the low level core functionality, as it can't be
handled without real code in some engine or plugin anyway.
Perhaps the really significant difference from other plugin APIs is
that I'm trying not to mix up the API with the host implementation,
as is done in all other APIs I've seen so far...? Why should the
*transport layer* know about details of data formats and all that,
when it never actually manipulates the data anyway?
Well, anyway, you'll see what I mean when I get that event system
into the softsynth code. Time to cut down on long posts and hack
more code again...
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST