Hi Tony,
yes, that's a common concept for some of the languages I mentioned. E.g.
jMAX has a Java GUI to create patches that link basic modules together. The
sound processing code that goes with these modules runs on a server called
fts (which incidentally stands for 'faster than sound'). The server can be
on the same machine, of course, however in my case it would run on the
performance platform. The patch is then sent in some form to the server who
interprets it and sets up DSP chains and all that.
This isn't a bad approach at all, and maybe I should just go for it and not
demand too much flexibility. However, it'd be nice if people could write
plugins to extend the functionality according to their needs. E.g. for Macs
and Wintels you can write VST plugins, on Linux there's LADSPA and MAIA.
Also, while I don't have to worry about porting the GUI/client part,
there's still the server code base to maintain which changes when new
modules become canonical.
I'm aware that too much flexibility can also hurt as stability becomes a
problem. But one has to find a sufficient user base, and musicians tend to
be quite diverse.
I'm currently working with a Trimedia processor and it competes quite well
against both PPC and x86. The design you suggested certainly makes sense
and is quite conceivable for this system.
I think I'm just a little concerned about the support, maintenance and
upgrading from a long-term perspective.
Sukandar
sukandar kartadinata - www.glui.de - technology for musicians & artists
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
