Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti helmi 01 2000 - 19:48:58 EST
>Impossibility. :-) I can't even imagine writing FOF in Csound.
>It may be theoretically possible, I'd have to think about that, but
>surely it would be a disaster.
If it would be a disaster for performance reasons, I suspect that this
would be true of any interpreted language that wasn't written
explicitly to support FOF. Thats why there is a "fof" opcode :)
>> However, there were other issues too,
>> and in the end, I don't consider Quasimodo to be that connected to
>> Csound in any conceptual sense at all anymore.
>
>They're both unit-generator languages (scalar static dataflow), with a
>score/orchestra division, so for my purposes they're in the same
>family. Different from Lucid (lazy dataflow) or Sisal (first-order
>functional with streams) or Fran (higher-order functional with type
>constructors), for example.
None of this is fundamentally true. Quasimodo has no particular
connection to any unit-generator language, because at its core is not
an intepreter, but a DSP simulator. The interpreter/compiler layer,
which can be replaced, takes a given language and translates it into a
series of DSP instructions.
It just so happens that the DSP instructions correspond to the opcodes
in Csound, making the compilation of Csound down the DSP code very
easy. But they could be any opcodes at all - every instruction is just
a dynamically loaded C++ function (loaded at
language-compile/interpret time). The only limitation is that they
need to understand the "function call convention", which in this case
is a single pointer to a suitable closure.
So you could connect up any language to it as long as you could
compile/interpret the language down to a serial DSP program with DSP
instructions written in C/C++ and understanding the call convention.
If the language can't be handled that way, I don't know how it run
efficiently on any real hardware, since it means it doesn't really
follow the von Neumann model :)
As for the score/orc division, well, yes, to a certain extent. But
scores in Quasimodo are reduced in importance, because its primary
purpose is as a real-time device, not a playback engine. In the end,
scores are just another source of user-interaction events that happen
to be derived from a file. They have no particular centrality in its
operation, because once again, they are simply converted into a series
of commands to the DSP to start/stop a particular DspProcess
etc. There are other ways of doing this without a score (MIDI,
on-screen buttons etc.), and there will, I hope, be ways of using
different file formats as the score too. So I consider them quite
peripheral to the whole engine.
>Yeah, in Aura we had to distinguish between "ugen" and "instrument".
>An instrument consists of one or more ugens, connected statically.
Quasimodo makes this distinction. In fact, since many ugens are much
too low level to actually be useful, they are mostly not wrapped
singly into instruments. Instead, I (or Stephane) have written very
small modules to combine them together into things more closely
approximating a usable "unit generator".
>Each ugen is wrapped up singly as an instrument, so you have them all
>available for dynamic connection.
Right, but the question is: can the instruments patch themselves ? I
did not like the feeling of Robin's zak patches for Csound, and he
himself noted that it was kind of a hack. But at a deeper level,
Quasimodo has the notion deep within it that a patch happens without
the patchees knowing anything about it. This is not useful for process
music, in which an "instrument" needs to be able to dynamically create
and destroy patches between itself and other similar or dissimilar
instruments. I think this represents a different kind of patching, on
some level, but i have severe mental dissonance just thinking about
it, so I've stopped for now.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST