From alsa-devel-owner@alsa.jcu.cz  Wed Jan 13 14:46:39 1999
Received: from janus.ericsson.no (janus-ext.ericsson.no [193.215.242.105])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id OAA30052
	for <alsa-devel@alsa.jcu.cz>; Wed, 13 Jan 1999 14:46:31 +0100
Received: from tele1.eto.ericsson.se (tele1 [193.161.187.12])
	by janus.ericsson.no (8.9.0/8.9.0) with ESMTP id OAA02992
	for <alsa-devel@alsa.jcu.cz>; Wed, 13 Jan 1999 14:46:23 +0100 (MET)
Received: from tele2 (tele2 [193.161.187.13])
	by tele1.eto.ericsson.se (8.9.0/8.9.0) with SMTP id MAA01015
	for <alsa-devel@alsa.jcu.cz>; Wed, 13 Jan 1999 12:46:10 +0100 (MET)
Received: by tele2 (5.0/client-1.5 (tele))
	id AA22097; Wed, 13 Jan 1999 12:49:46 +0100
Date: Wed, 13 Jan 1999 12:49:46 +0100
Message-Id: <9901131149.AA22097@tele2>
From: Stephen Thornton <Stephen.John.Thornton@ericsson.no>
To: alsa-devel@alsa.jcu.cz
Subject: Re: Linux scheduler issues. 
In-Reply-To: <199901130508.AAA05505@renoir.op.net>
References: <369B389D.FB567AB5@ife.ee.ethz.ch>
	<199901130508.AAA05505@renoir.op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

OK, here's an attempt at explaining what I have in mind:-

First, language. C is an old friend. Most things nowadays are written
in C. Problem is that nowadays, there are a lot of programming
paradigms that are used again and again, and need to be coded up each
time. C++ tried to solve this by having reusable code and classes, but
this doesn't go far enough. These are some features that would be good to
have as part of a language for realtime:-

1. language support forlightweight concurrent processes
2. realtime garbage collection
3. language support for sending interprocess messages and signals
4. Ability to change code modules without stopping the system
5. language support for distributed processing
6. language support for more "intelligent" processing (lists etc.)
7. Robustness. Good run-time error detection and reporting

All the above are requirements of the language, not libraries for the
language. The C language provides none of these: admittedly there are
libraries providing this functionality, but they are not part of the
(say) ANSI C language standard.

Second: what do we actually want to do? Let's assume that we already
have drivers for any bit of audio hardware we want: sound cards, MIDI,
converters, DSPs etc. Also assume that we can do stuff like mixing,
simple sequencing and the like. Now what?

My Dedicated Advanced Music Node (DAMN) is like a musical instrument
(or meta-instrument). I want it to gradually evolve to work with my
music, do things my way, and help me produce the music I want. The
best mechanism for this, is to forget the conventional idea of OS and
application. The whole thing is the OS (or the application). I would
like to be able to have the machine playing my audio/MIDI work, and be
able to change any code/parameter/configuration that I want to, while
the system is playing, whether this is part of the particular piece of
music I'm working on, or part of the general "operating system". I
want the file system to be an OO database. I want the ability to be
able to connect (say ethernet) to another DAMN belonging to my friend,
and have a fully integrated, distributed system that we can both use,
in real time. I want to play a riff, and say to the machine "out of
all the drum patterns we've made, which would fit this? get it and
play it", and if my friends machine is connected, check his database
too.

Every object in the database(file system) has one or more visual
representations bound to it. This is what the GUI displays, along with
relations and operations between objects. Objects can be edited with
the system running, and the object actually in use at the time.

Does this sound like fun?

Apart from sound drivers (hence interest in ALSA), I can do all of the
above.

Any questions?

rgds.

Steve

