I'm becoming concerned... I really want QOrchestra, and I'm afraid you may
get bogged down!
What I suggest is a sort of compromise based on the work Russell Pinkston
did with PatchWork. He didn't have a standard metalanguage for synth
opcodes, but he DID have a standard for representing any particular synth
opcode in a template specifying its ins, outs, and types. Therefore, you
could add SAOL opcodes to PatchWork and use it to graphically wire together
SAOL orchestras.
It wouldn't allow you to define patches in a universal format and translate
them equally well to Csound, SAOL, Reaktor, or whatever. I agree with Eric -
I think this is too much. But it WOULD allow QOrchestra to be used to
graphically wire together patches in other synthesis languages.
Best of luck, whatever!
-----Original Message-----
From: Bert Schiettecatte [mailto:bschiett@vub.ac.be]
Sent: Wednesday, January 19, 2000 1:13 PM
To: Eric Scheirer
Cc: saol-dev@media.mit.edu
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