I understand you now. I still think this is a very difficult job. There are
at least two approaches: (a) you define only very low level opcodes, in
which case you end up with a universal programming language, or (b) you make
the standard opcode set extensible. I recommend the latter.
You might want to check out the Ptolemy project. It is a huge resource for
advanced DSP work. They recently have created a Java version of the system.
The URL is http://ptolemy.eecs.berkeley.edu/ptolemyII/main.htm.
I mention this because Ptolemy has tools for designing synchronous dataflow
graphs, which are what Csound and SAOL orchestras are.
But maybe you already checked this out?
-----Original Message-----
From: Bert Schiettecatte [mailto:bschiett@vub.ac.be]
Sent: Wednesday, January 19, 2000 10:07 AM
To: Michael Gogins
Cc: saol-dev@media.mit.edu
Subject: RE: SML (Synthesis Modeling Language)
Dear,
On Wed, 19 Jan 2000, Michael Gogins wrote:
> If you're going to allow interchangeability of patch definitions between
> different synthesis programs, you'll need a way to specify the number and
> type of each input and output of an opcode for each language, plus perhaps
a
> way of transforming a block for one synthesis program to a block for
another
> synthesis program. I.e. "LFO" might have 5 inputs in Csound and 8 inputs
in
> Zsound (made up example). The specification for the opcode specifications
> would go into the Document Type Definition for SML, and the opcode
> specifications proper would go into subsidiary DTDs, one for each
supported
> synthesis language.
My idea was to come up with a standard which has a number of primitive
structures. An SML-to-CSound compiler (for example) would then need to
implement these primitive structures. New versions of the standard could
introduce new primitive structures.
What I mean is, I don't want to associate the standard with a language in
any way. I'd like to come up with a way to describe these synthesis
circuits, and then build a compiler which compiles these circuits to SAOL
(in my case).
I think this is still different from defining opcodes in the standard?
> Perhaps you should take on a less ambitious goal in order to have time for
> the rest of your project. Just put in an element specifying the target
> synthesis language for now.
If I put a tag in the document like <language name='saol'> for declaring
that this is a SAOL document, then the SML standard would be strongly
coupled with a certain signal processing language. I think this is a bad
idea.
> In any event, for SAOL you need a way to include the code for user-defined
> opcodes.
Mmmm... you are right. I'll continue to work on the standard (I need to
store instruments on disk anyway) and keep you all posted.
Thanks for the advice!
Bert.
____________________________________________________
Bert Schiettecatte (1e lic. Inf)
Vrije Universiteit Brussel
E-Mail: bschiett@vub.ac.be
WWW: http://wendy.vub.ac.be/~bschiett/
-- To be a popular composer, what is it you must do?
Perhaps to learn enough tricks that cause people to
have pleasant sensations without too much stress.
What are the tricks for making that catches on in
a listener's mind, and keeps repeating long after
the performance? -- M. Minsky
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:50 EST