Some corrections to avoid future confusion, sorry to be
nit-picky. These are subtle things:
>I've been using Csound for years, and have adapted it extensively, and
>contributed to it a little bit. SAOL appeals to me precisely because of the
>idea of an international standard. The GNU public license and complete
>intellectual freedom (no nagging questions about the MIT copyright on
>Csound) also is important to me.
The GNU public license only applies to a particular implementation
(sfront), not the SAOL language or specification. Both of these are in
the public domain. The MIT 'saolc' implementation is also in the public
domain. The differences between GPL and public domain are important
for future developers, and for people who would organize software into
larger packages. (I don't mean that one model is preferred over the
other; they both have their place in the software world, as does closed
source IMHO.)
>I think, however, that it would be a better way of doing a standard to
allow
>for "extensions" instead of trying to fix the standard for once and for
all.
>This is what Sun has done with Java and what the Linux community has done,
>in practice, with Linux. It also is what happened with C++: the standard
>grew over time and is still slowly accreting.
The Java standard is slowly fragmenting into incompatible directions
and many observers feel that it is unlikely to succeed as a useful
language in the long run. C++ standard with a single, fixed base
that had many good points, and allowed this base to remain relatively
stable for quite a long time. The standard is now fixed: it is not
"slowly accreting," but has proceeded in several discrete steps
through various standards bodies. With the STL now complete,
AFAIK there are no further plans to increase or extend the standard
any more. C is still the only usable standard language for writing
truly portable code IMHO exactly because C++ has been changing.
Now that C++ is complete and fixed, I think it is likely that it will
replace ANSI C as the portable standard over the next 3-5 years.
This is all a long way of saying that I disagree with you. To be a viable
standard IMHO a language *must* provide guaranteed stability to
implementors and users. Of course this crowds out the
possibility of incremental improvement to some extent, but it
is a necessary tradeoff IMHO. Compatibility is more important
than small improvements to a feature set, I think, and so if we
are looking to gain the advantages of a real software-synthesis
standard, we must be willing to accept the disadvantages as well.
>I also believe, and this is a bottom line, that the musical instrument must
>be made absolutely as good as possible. If double precision computations
>make better music, then double precision computations it must be.
I'm surprised, then, that you don't demand the IEEE 80-bit floating point
standard, which is very strongly specified and provides even better
quality than double precision! There are necessary tradeoffs to be
made between precision and implementability. To specify double-
precision in the standard would essentially make it impossible to
implement the SAOL language up to spec on this or the next
generation of DSP accelerators. Since bringing this sort of
acceleration into broad use in the software-synthesis world was
one of the most important goals of the MPEG-4 SA project, this
tradeoff was essential to me.
There will always be musicians who feel that they must demand
more precision than the popular platforms can provide, and this is
their choice. But I don't believe that 32-bit floating point is musically
limiting in any important way, especially if the composers and
instrument designers are cognizant of the issues surrounding
quantization, SNR, and the like. Of course it's possible to create
instruments that behave very differently under 64-bit than 32-bit
arithmetic; the question is whether these behaviors are (a)
musically essential, and (b) cannot be worked around in a 32-
bit framework. I believe the answer is no; if you have examples
to the contrary I would welcome them.
Thanks for your thoughts, Michael, these are important issues.
Best,
-- Eric
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:34 EST