Oh, I understand better now. I was mostly picking up
on the "interchange" idea, but what you really want is
a way to load and save the flow diagrams themselves.
I see no reason that XML shouldn't work for this. What
I think is very hard is loading an arbitrary Csound or
SAOL instrument and turning it into a flow diagram
or XML equivalent--there are many things that you can
do in each that you can't really represent in a
flow diagram (in SAOL, the 'while' statement is a
good example).
But as long as you're restricting the entities in
the XML schema to the kinds of *visual* manipulations
you want to allow, you're working within a smaller
subset of the overall synth functionality.
To put it another way, XML->SAOL and XML->Csound,
given a particular XML schema for synth diagrams, should
be easy. But SAOL->XML and Csound->XML are not.
Now that I think about it, this is actually quite an
elegant solution, because it lets you separate the
visual interface (which produces XML with a GUI) from
the translation into SAOL. You could make new languages,
or better translators, available as plugins.
My only remaining suggestion is that "FlowML"
or something like that is a clearer name--you're really
representing the flow diagram, not the synthesis
algorithm (which is more abstract than the flow
diagram) itself.
Best,
-- Eric
+-----------------+
| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7|
|eds@media.mit.edu| < http://sound.media.mit.edu/~eds >
| 617 253 1750 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
+-----------------+
-----Original Message-----
From: Bert Schiettecatte <bschiett@vub.ac.be>
To: Eric Scheirer <eds@media.mit.edu>
Cc: saol-dev@media.mit.edu <saol-dev@media.mit.edu>
Date: Wednesday, January 19, 2000 1:13 PM
Subject: Re: SML (Synthesis Modeling Language)
>Dear,
>
>On Wed, 19 Jan 2000, Eric Scheirer wrote:
>
>> >I believe such a standard is essential: it would allow to interchange
>> >instruments between CSound, SAOL, and several realtime popular software
>> >synthesizers.
>>
>> is much more difficult than you think. This was our
>> initial idea of what MPEG-4 SA should be---some kind of
>> interchange format that would allow the use of any
>> software synth to play back content.
>>
>> But it rapidly became clear that this idea is untenable.
>> The different software synthesizers---Csound, SAOL,
>> SuperCollider, Nyquist, and the commerical graphical
>> ones---all have different underlying conceptions of
>> events, signals, opcodes, and functions that makes it
>> impossible to have a single format that captures
>> anything but the very simplest aspects of behavior.
>>
>> So now the MPEG-4 SA argument is that SAOL itself *is*
>> the exchange format, and that other softsynths will,
>> in time, come to support SAOL. From this point of
>> view, your present work on QOrchestra is likely to
>> be much more valuable and important in the long term
>> IMHO than trying to solve the short-term incompatibility
>> problems today.
>
>Indeed. I didn't say I was going to drop QOrchestra :-)
>
>I don't know if you read the design on my homepage, but I wanted
>QOrchestra to be as general as possible: I want to implement the SAOL
>generator as a plugin, which traverses the synthesis circuits as used in
>many tools. However, I don't want to mix SAOL itself with the conceptual
>idea of buses, instruments, graphs of primitive structures and primitive
>structures.
>
>My idea is to provide a set of primitives (synthesis blocks you drag on
>a workspace and connect with other blocks) as close as possible to
>languages like SAOL or CSound, to make the generation process as easy as
>possible. The implementor of the code generator then provides statements
>in the code generator's target language for each of the primitive blocks.
>
>Ofcourse I don't have a guarantee this is the right way to go, but I
>thought this way of working seperates synthesis languages of what
>synthesis diagrams really represent.
>
>What has all this to do with this standard? I need to store the libraries
>of primitive building blocks and graphs of primitive building blocks, and
>I don't want to do this in my own binary format. Storing these building
>blocks as SAOL statements will make generation/translation to other
>languages more difficult.
>
>This is why I wanted a standard which _only_ defines how to store a graph
>on disk, if you forget everything about synthesis for a minute. I need a
>way to store the blocks and their relations on disk anyway.
>
>IMHO, this is totally different from specifying a language for signal
>processing. I'm just specifying relations between synthesis concepts, in
>such a way that I can load them from disk when the application starts.
>
>I don't know if I explained all this clear and correctly. I would greatly
>appreciate any comments on the software design of QOrchestra, which can be
>found on my homepage: http://wendy.vub.ac.be/~bschiett/saol/
>
>Thanks in advance,
>
>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