RE: Software design for QOrchestra/FlowML

From: Bert Schiettecatte (bschiett@vub.ac.be)
Date: Sat Jan 22 2000 - 04:41:14 EST


Dear,

On Friday, January 21, 2000 6:11 AM, Michel Jullian [SMTP:exbang@wanadoo.fr] wrote:
> > Some generators will not have a simple statement for such a primitive
> > synthesis block, while other generators might have such a simple
> > statement. The set of blocks I'll introduce will be close to what SAOL
> > offers as primitive constructs, because that way, I will have less trouble
> > building the SAOL generator.
>
> Then imho it will end up as an SAOL library and editor, period :-) Pity to
> have this single library thing hampering your design, I fear this attempt at a

The point is, I need to define a way to store the diagrams for re-use. If I do it
binary and only for my own application, I will end up with severe debugging issues.
If I introduce a standard in XML, the design of my project is simplified since I can
divide it better in several small parts, since the XML technology is there and works.

> universal synthesis circuit language (that's what it is whatever you say to
> the contrary) might precisely defeat the universality of the tool. On the
> contrary having one library per code generator would allow using it for truly
> any language, even future ones you don't know anything about yet.

Yes, but this will eliminate one of the most important features: being able to re-use
instruments in several synthesis languages (SAOL, CSound, ...). Creating a strong
coupling between a library and a code generator will make the application a
universal editor like PatchWork.

> > If the set of primitives is too small afterwards, additions could be made
> > to the standard which introduce new primitives, much like HTML started
> > with 1.0 and became 4.01 today.
>
> But you will never get a module in one language to behave the same as a
> "similar" module in another language (apart from "*" and such, admittedly :-)
> : different number of inputs, different inputs labels and ranges, same for
> outputs, different manual pages etc...

I don't see why at this time: the format would give a definition of these
primitive structures (number of inputs, outputs, ranges, labels), and the
designers of code generators would have to generate code in the target language
which simulates the primitive structures defined in the standardized format.

All suggestions & comments greatly appreciated.

Thanks in advance,

Bert.



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:51 EST