I'm afraid I have not read the FDIS in enough detail to be aware of the
Obviously, for me float output is more important than float precision. I
still would appreciate it, however, if there were an easy way to compile
sfront or sa.c so that double precision was used for processing.
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. What joy there would be if most music
hardware and software could work with SAOL. The gap between the commercial
music world and the academic computer music world, a private bete noire,
would be substantially bridged. Also, I deeply feel that music demands
practice and continual changes in the instruments get in the way of that. I
think that after 40 years of unit generator languages it is clear that the
idea works and what needs to be in it. I don't care who sets the standard as
long as it exists and anyone can use it. I view the development of a stable
standard for software synthesis as being at least on a par with
standardising the orchestra or the piano.
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.
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.
From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU]
Sent: Saturday, August 28, 1999 12:48 PM
Cc: email@example.com; firstname.lastname@example.org
Subject: Re: Things I would like to see
> More changes I would like to make to sfront:
The following in your list all seem quite doable:
> A float WAV soundfile output option.
> Drivers that are switchable at runtime.
However this one:
> Related to this, I repeat, default double precision processing.
Basically, if sfront had a mode that stored and processed all
variables as double precision, when it ran in that mode it would
be out of compliance with the 5.8.3. on p 29 of the FDIS:
"At any point in time, the value of a variable, sample in a
wavetable, or single element of an array value, shall be
represented by a 32-bit floating-point value.
Conformance to this subclause is in accordance with subclauses
5.7.4; that is, implementations are free to use any internal
representation for variable values, as long as the results are
identical to the results of the calculations using 32-bit
floating point values."
Maybe that's OK ... but its probably good to reflect on what
the future holds when we go down the path of "embrace and
extend" with MP4-SA. There's really nothing stopping anyone
from putting out an MP4-SA implementation that has dozens of
useful, non-compliant features, and making that version
ubiquitious -- content will use the features, and the control
of the standard leaves MPEG the organization and becomes
closer to how Microsoft and AOL jointly determine what the
"standard" subset of HTML is at any given time ...
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:34 EST