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 - 22:44:54 EST
Eli writes:
>No, a disaster because it would be totally and utterly unreadable,
>unwritable, and undebuggable. It's hard even to think about. It
>would have to look like the C code (which is pretty damn scary itself)
>with all of the data structures smashed into some unstructured Csound
>representation, if that can even be done. Whereas in the sort of
>language I'm envisioning, FOF is under fifty lines of code, and clean.
and:
>Are you familiar with a particular one of the classes of
>`other languages' I mentioned? I'm wondering what range of languages
>the Q engine forms a reasonably natural processor for.
and
>Yeah, different goals. I want a composition tool, so I want the
>score as data within the real language, where I can manipulate it.
>My scores are mostly signals anyway.
I think that you and Bill Gribble should talk to each other. Bill
wanted to use Guile or something better as the basis for a new
Quasimodo language. I have no familiarity with the languages you're
talking about, but I can say this: if they can be compiled down to von
Neumann-like code, then they will run OK in the Q engine.
>Okay, when I was talking about Quasimodo as a language, I meant the
>set of languages that are only a lex/yacc away, since that's how I
>thought you meant to implement new languages. That set is, I believe,
>scalar static dataflow.
That's probably true.
>Quasimodo as an engine is a different matter. If this interface is
>documented and held stable, it may be an interesting target machine
>for compilation. It's probably about as much work overall as
>compiling to native code, but it's more flexible.
actually, its a little less work in some senses, because you're able
to work with "machine instructions" that approximate the useful items
of work you wish to accomplish, rather than resynthesizing them out of
basic store/load/arithmetic ops.
>Is the "DSP simulator" something like Csound's interpreter loop? I'm
>thinking about compiling Lucid into the latter, and it's feeling
>awkward.
Not really. But its also very much like any/most machine simulators.
Remember, its all written in C++, so its fundamentally all about the
interrelationships between a set of objects. You first compile your
definition-in-some-language down to a Module. This is essentially
equivalent to position-independent code that requires pointer
twizzling before it can be used. When the DSP is instructed to start a
DspProcess instantiating that Module, it makes a copy of the Module
code, allocates a chunk of memory to act function as a "stack" and to
hold the closures that will be passed into the opcode functions. Then
it fiddles with all the pointers so that they point to the right
places. Then it just inserts the resulting DspProcess into its run
queue (after data flow analysis to decide where in the queue it should
live). Last, it gets back to endlessly running over the run queue,
which means taking each DspProcess on the queue, and calling its
"execute" method, which in turns just iterates over the relevant
DspInstruction objects that make up the DspProcess, and calls the
appropriate opcode function on each one.
So, in the end, its just a simulation of a standard serial CPU with a
thin OS on top for process loading/unloading. What the DspInstructions
do is up to their authors ... But it attempts to use a high level of
objectification to embody a very low level engine that is restricted
to a von Neumann like model, but not tied to a particular idea of a
language above assembler level.
>fun (fof: float ivec)
Looks like python to me :)
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST