Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Mar 31 2000 - 20:41:37 EEST
>> Connecting them together: now, how does a standard, daemon-style host
>> connect them together ? You'd have to have a (G)UI that allowed the user
>> to specify the routing, then relay this information to the
>> daemon. What you're describing now sounds more like a replacement for
>> esd.
>
>Please don't !!!!
>
>The daemon (or whatever) should offer an API for making the connections;
>the API can be a library communicating with the daemon with some IPC technique
>
>The daemon should not be linked with any code making direct user interaction;
>(think for a moment to a embedded Linux kernel running on a real synth :->).
What do think I was suggesting ? I wasn't even hinting at a solution
where the daemon GUI app was "directly" connected to the daemon
itself. It would *obviously* (I hope) use some API to control the
daemon, probably via shared memory, though a pipe/socket would
probably work for this as well.
>IMHO, plugin that have a direct UI (i.e. a UI running on the same
>process of t he daemon) are not a good idea on a Linux based
>architecture; think of having a plugin ma de with a Kde interface
>running on a GNOME system ...
Well, I never imagine plugins with GUI's running in the same
thread. But plugins with GUI's have to describe them at some point,
and either they are going to use a cross-platform simplified GUI
toolkit (e.g. vstGUI, WxWindows) or they are going to use a full blown
toolkit (GTK+, Qt). Anyone who writes KDE or GNOME applications that
can't run on a GNOME or KDE system is crazy, IMHO. Anyway, a plugin
with a GUI is going to have to get that GUI executed somehow. If the
GUI is specified in abstract terms (e.g. Quasimodo's XML interface
description), then perhaps some already running program can create the
GUI. If its specified more concretely (either with source code, object
code or something like glade), then its more difficult for an already
running program to create it, and in all likelihood, a new
process/thread will be needed to implement it (which may not be a bad
idea anyway).
>Leave the DSP code and the UI interface code separate, otherwise the whole
>thing will need to be redone tens and tens of time ...
Of course. I wasn't suggesting anything else. I don't write
application any other way (see Quasimodo, for an example).
--p
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 21:27:01 EEST