The most obvious points at which the parser could be replaced are two
functions that are called by otran(): rdorchfile() reads an orchestra
file into memory (with preprocessing), while getoptxt() is called in a
loop to fetch the next opcode until the end of the orchestra is reached.
The stream of opcodes returned by getoptxt() is in the simplest form,
with no macros, expressions, if/then/else, etc.; this can be thought of
some sort of "Csound assembly language". So, the purpose of a parser would
be to convert a high level language to a list of "assembly" opcodes.
Of course, a number of changes and code cleanup are needed, and there are
a few additional utility functions that are relevant here, but the main
idea is to keep most of otran.c, while making it possible to replace most
of rdorch.c with a plugin (possibly selectable like -+rtaudio).
An external parser is expected to set a few callback functions (most
importantly the replacements for rdorchfile() and getoptxt(), but there
may be more), while having access to the various helper functions through
the API.
Of course, this may very well be different from and incompatible with
John's ideas about replacing the parser (about which I have no
information), but this is probably the simplest way to replace/reimplement
the language at a high level, while keeping the internal low level
representation (and thus remaining compatible with existing opcodes).


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net