Hi!
On Thu, Dec 07, 2000 at 08:02:42PM +0100, Matthias Nagorni wrote:
> There already exists the powerful Midi Operating System "MidiShare" by
> GRAME (www.grame.fr). It took them 6 years of Research to complete this.
> The ALSA Midi Sequencer was inspired by this project and, as Takashi told
> me, the Linux Version of Midi Share is based on the ALSA Sequencer concept
> in turn. So, do you really want to reimplement all this or is there
> perhaps a way to make use of the already-existing powerful
> Midi-infrastructure of ALSA ? With ALSA you already can connect many
> different Midi-Clients simultaneously, even over the network. So what
> about implementing a small Midi Interface Module to ALSA ? All the
> event-streaming could then be done by the ALSA sequencer and the
> Arts-Clients could still communicate via ALSA. If you don't like this
> idea, then what about taking this as an intermediate solution ?
There are a few things to say about this. One is, that I today committed
a big part of the code that needs to be done to make the aRts midi stuff
work. It is already usable. Most of the IDL interfaces are implemented now.
It clearly seperates "devices" from "applications", which act both as clients
to one central midi manager. Mostly this means that you can easily write a
module for various backends, like ALSA, OSS, MidiShare, ... - the current
(non-timed) OSS backend has less than 300 lines of code.
So I want to encourage you, please consider writing an ALSA backend and/or
a MidiShare backend. And I mean that. I would really love to see something
like this.
But on the other hand, I really like the current approach much better than
an ALSA-only approach for instance. KDE will run on Solaris. Is there ALSA
on Solaris? KDE will run on linux distributions without ALSA support. KDE
will be able to talk over network to other unix boxes - the MCOP protocol
layer makes the current aRts-midi support network transparent _already_,
without additional stuff.
It is also language independant, given somebody writes bindings to MCOP for
a non-C++ language. All in all, I am pretty confident that the code that is
now in the CVS is a solid base for the future.
Cu... Stefan
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
