Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Wed Nov 22 2000 - 23:09:55 EET
Hi!
On Tue, Nov 21, 2000 at 02:12:59AM +0100, Benno Senoner wrote:
> On Mon, 20 Nov 2000, you wrote:
> >
> > Stefan is probably right that MCOP could be improved/extended to
> > handle such systems. But I suspect there is real work there, work that
> > is not guaranteed to result in a version of MCOP that can still be
> > considered universal in its utility. if stefan really believes that
> > the fixes for this are fairly trivial superficial details, i'm very
> > interested to know more. but i also know that to date, every time i
> > have looked at other linux audio software, i have found assumptions
> > and world-models that make them unsuitable for use in live, real-time,
> > low latency situations and/or situations working with hardware that is
> > anything other than a consumer soundcard and/or situations that make
> > it unsuitable for use with other pro-audio h/w.
> >
> (.....)
>
> Yesterday I had a chat with David Olofson about these issues:
>
> we came to the conclusion that although some object oriented model
> will be required, we need to keep it as simple as possible
> (keep it simple stupid).
>
> And for this C++ may not the right way to go.
> As we all know C++ is a difficult beast to handle and you need to
> know what you do when talking with abstract objects AND want
> RT-safe behaviour.
>
> Plus those that will want to use the "virtual studio" API out from a
> C app will not like it that much.
> (ever tried to write a Qt application in C ? no way .. (almost) ).
There are people who think that any piece of code that multiple apps depend
on should be written in C, in any case, object oriented or no, as a
untouchable design principle (Gnome development seems to follow this).
I don't think this is a good idea. Use what works. If you want object
oriented stuff, an object oriented language is a much better choice. I see
only advantages from the fact that MCOP is implemented in C++.
After all, you can do everything you could do in C in C++ as well, only
you can do more if you like to.
As for binding other languages, MCOP has an excellent meta object layer that
is based on the .idl definitions, and the MCOP component model (similar in
spirit to CORBA, but *much* simpler). So binding different languages should
be really easy. It should be like: write an MCOP <-> JavaScript bridge in
a minor coding effort, and use any MCOP component in JavaScript at once.
That's very unlike standard C++, I know, but it really works (it is needed
for the network transparency and RAD development with artsbuilder anyway).
> Plus this delegating the establishement/destroying of connections to
> a separate thread is not going to solve our problems.
> There may be cases where we want to make/modify connections in realtime
> without glitches and other sources of non-determinism and here we need
> to be VERY careful.
Right. I was talking about the network related non-deteminism here (i.e.
cross-server-connect). See my other mail. There is IMHO no way to rule with
out without extra thread, state machine, or similar.
Cu... Stefan
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Thu Nov 23 2000 - 00:20:23 EET