From alsa-devel-owner@alsa.jcu.cz  Tue Jan 12 18:48:17 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA07750
	for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 18:46:58 +0100
Received: from someip.ppp.op.net (d-bm2-17.ppp.op.net [209.152.194.55]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA07316 for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 11:27:29 -0500 (EST)
Message-Id: <199901121627.LAA07316@renoir.op.net>
To: alsa-devel@alsa.jcu.cz
Subject: Re: Linux scheduler issues. 
In-reply-to: Your message of "Tue, 12 Jan 1999 15:49:16 +0100."
             <01ee01be3e3a$ba7c82e0$47010180@pcbg> 
Date: Tue, 12 Jan 1999 11:28:06 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

In message <01ee01be3e3a$ba7c82e0$47010180@pcbg>you write:
>:Good point. Depends what you want to do though. If you just want a
>:sequencer/sampler with simple playlists fine. Maybe I am a lot more
>:ambitious than that. I'll try and explain what I have in mind, but
>:I'll keep it general. I'll write this seperately as it does have some
>:bearing on the language issue alluded to above.

I should perhaps mention the Quasimodo project here. 

  http://www.op.net/~pbd/quasimodo/

The page is a bit out of date right now. You can think of it as
essentially a reimplementation of Csound, and if you don't know enough
about what Csound actually is, as opposed to what people do with it,
here's a brief summary.

Csound is essentially a simulator for a very flexible and powerful
DSP.  It has opcodes written and compiled for the "real" processor
that Csound runs on. Csound itself takes a "program" written in its
own twisted language (which is vaguely like an assembler for audio,
midi and music work), and compiles/interprets it down to "thread
code": that is, a linked list of calls via function pointers. The end
result is an extremely flexible, very powerful, and, given the range
of opcodes available, incredibly-close-to-what-you'd-get-writing-it-all-in-C.

And I really mean that. Once Csound starts running an "instrument" in
real time, the only overhead compared to implementing the instrument
directly as C program is one function call per Csound opcode. That
really is *it*. Thats an incredibly low price to pay for complete
flexibility. How flexible ? The Pulsar runs Csound on its 4 SHARC
DSP's. Thats how flexible.

Unfortunately, the actual source code for Csound is a tangled mess,
and cannot reasonable be adapted for parallel processing (Analog
Devices discovered this when they ported Csound to the SHARC). Since
Quasimodo's overall goal is to implement something very much like
Creamware's Pulsar, but without any special hardware (although
benefitting greatly from a dual/MP system), I am basically rewriting
Csound from the ground up and a multithreaded, real-time DSP simulator
that runs all the existing Csound opcodes. Along the way, I'm fixing a
number of problems in Csound related to timing as well.

The end result is intended to be a complete environment for real-time
(or not, if the synthesis is really that complex that even a dual
PII-450 can't do it) synthesis, MIDI and audio (FX, etc) environment,
where all the instruments, modules and so forth are written in an
interpreted langauge (Csound, or perhaps in the future, something else
as well), and run on this very fast and efficient engine. Already in
Csound there are implementations of mixers, just about every type of
FX processing you can imagine (and some that you can't) plus of course
a wider range of synthesis techniques than just about any current
hardware has implemented. All these will work as part of Quasimodo.

The current status: Quasimodo compiles and runs simple
"programs"/instruments/modules. It has full multiport MIDI handling
all ready. It has submicrosecond timing resolution, thanks to the
Pentium cycle counter. It works, and every day, I add some new chunk
of functionality. Today, goto's will be operational for example.

ObAlsa: Quasimodo requires only /dev/dsp support and a direct MIDI
interface (no sequencing done). As such, it will run using ALSA, OSS,
or just about anything else that calls itself a soundcard driver :)

--p

