Bert Schiettecatte wrote:
...
> > 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.
I don't see how multiple libraries would prevent using XML, you just need a
tag for target language. When you open a FlowML file, the program looks up the
target language tag and loads the corresponding library and code generator,
that's all. FlowML can still be a standard regardless, and its specification
be library-independant which would make it more powerful in fact, and wouldn't
require updating it frequently.
...
> Yes, but this will eliminate one of the most important features: being able to re-use
> instruments in several synthesis languages (SAOL, CSound, ...).
Yes but this is an impossible dream so why bother ? I agree with Eric that it
would be easier to implement translators between languages, which in itself is
extremely difficult, than a universal language translating into all languages.
Also and most importantly imo, a universal library would necessarily have to
adopt a common denominator attitude and eliminate modules which can be
implemented in one or several languages and simply cannot be implemented in _
just one_ other language. So you would miss many useful features of SAOL for
example, which would be a pity. Your library would be universal but poor.
> Creating a strong
> coupling between a library and a code generator will make the application a
> universal editor like PatchWork.
So what ? Your application will generate code, which PatchWork doesn't I
imagine (haven't looked it up). In any case it will be the first application
to generate SAOL code via visual wiring and that's what matters.
...
> > 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.
Which would make their task so arduous that no one would design code
generators for your application, QED.
-- Greetings, Michel ......................................................................... Michel Jullian Directeur General email exbang@wanadoo.fr Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 .........................................................................
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:51 EST