From alsa-devel-owner@alsa.jcu.cz  Thu Feb 11 00:59:00 1999
Received: from math.mit.edu (MATH.MIT.EDU [18.87.0.8])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id AAA17244
	for <alsa-devel@alsa.jcu.cz>; Thu, 11 Feb 1999 00:58:31 +0100
Received: from severi (SEVERI.MIT.EDU [18.87.0.68])
	by math.mit.edu (8.8.7/8.8.7) with ESMTP id SAA22336
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 18:58:17 -0500 (EST)
Date: Wed, 10 Feb 1999 18:58:17 -0500 (EST)
From: Christopher Jeris <cjeris@math.mit.edu>
To: alsa-devel@alsa.jcu.cz
Subject: real-timing a la Golinvaux, Ashton
Message-ID: <Pine.SUN.4.03.9902101834030.17464-100000@severi.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


hi folks,

I am a little bit hesitant to speak up because my project is so far from
seeing the light of day (you know, never announce anything until you have
code) ... I just want to go on record with Benjamin and Michael as
interested in _real-time_ music applications on Linux.  I am building what
you might (if into buzzwords) call a "comprehensive next-generation music
composition and modification framework".  (Ick.  Remind me never to call
it that again.)  Basically I intend it to be analogous to Emacs, but for
MIDI and digital audio data instead of text files; and the implementation
and extension language is not Emacs Lisp, but Objective Caml (see
http://caml.inria.fr/).  I looked at KeyKit but the KeyKit language
doesn't have some "real programming language" features that I think are
important, and also the support for synth patch editing is not very good.

So I need to handle at various levels the problem of latency.  It is even
worse because I have a garbage collector to worry about, and haven't
started to thrash _those_ issues out at all.  In fact I'm starting with a
"universal patch editor builder" rather than sequencing or recording, so
timing is not an immediate issue, but I need to think ahead to it.  I
guess I want to ask people who are wrestling with ALSA timing issues to
continue posting their thoughts to alsa-devel or linux-audio-dev, and I
will too when I get some.

I used to run BeOS but I never got into programming on it because I _hate_
C++ with an unholy passion.  (No offense to C++ partisans.  It's just that
you can stand it and I can't.  If you can write good C++, it's great
because it reduces the ratio of bad C++ to good C++.  *grin*)  Therefore
(since this has also come up recently) I humbly request that no part of
the _core_ ALSA API be C++ centric at the expense of simple accessibility
from C (hence from other languages whose foreign-binding mechanisms are C
based).  It wasn't quite clear from my quick reading how "core" the
Patchables mechanism was intended to be, though; if it is philosophically
an extension, then your code is of course more important than my
preference.  :)

Ok, this is `devel', not `advocacy', so I will shut up now ...

thanks & peace,

Chris Jeris	cjeris@math.mit.edu	MIT Math!



