Dear,
On Wed, 19 Jan 2000, Eric Scheirer wrote:
> 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.
Indeed.
> 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).
Yes, I thought of that also.
> 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.
This is something I am aware of, but I don't think this is a real issue.
Experts can still edit the 'skeleton code' to optimize or add supports
which won't be generated by the application.
I now see QOrchestra as the Rational Rose (www.rational.com) for synthesis
design.
> 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.
Indeed.
> 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.
Yes, this has been the idea behind the XML-story. It would allow me to
make a command line XML->SAOL compiler, and make a GUI for authoring the
XML code (this is QOrchestra).
This has a big advantage I think: commercial realtime software synthesizer
applications could support the SML standard, and this allows instrument
exchange (this is what I originally meant).
> 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.
Okay :) It will be called FlowML.
The issue I'm stuck with now, is this:
Shouldn't the FlowML standard propose a set of primitive structures?
After all, to do the XML->SAOL translation, the implementor of this tool
must supply a set of SAOL statements for a primitive entities (structures)
used in the XML document? How can the translation be done otherwise?
A typical FlowML document has a tree-like structure, and I suppose you
need to define SAOL statements for the leafs in this tree, otherwise you
can't generate SAOL code for the whole tree?
Do you think this standard should become a real standard?
Thanks for your comments!
Bert.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:50 EST