Michael Gogins wrote:
>I think compiling to Java bytecode is a reasonable approach. So is
compiling
>to Java source code. In either case newer compilers would run somewhere
>between 0.6 and 1.2 times as fast as C. But I suspect that Csound would
>still be faster. In effect, Csound does compile to pcode and it has been
>highly tuned to do so.
I agree with both points. Compile-to-Java would be a great approach,
because it would allow a web browser to run the sounds. It is a very
short step from this to the sort of functionality that Beatnik enables.
I think an open Beatnik based on SAOL (or any other open framework,
for that matter) would be a great contribution and enable musicians
to play with lots of new ideas in distributed composition.
With regard to the second point, I think that on similar hardware, SAOL
implementations will never be as fast as hand-tuned custom languages
like Csound and SuperCollider. Fortunately, we are reaching a point
in the computer-music world where they don't have to be, for two
reasons:
1. Having a real language specification means that we can simply
move to other hardware options as they become available. All of
the proprietary SAOL projects right now are compile-to-DSP. There's
also several tentative compile-to-FPGA projects in the works. The
language specification was designed to make this possible; I think
the Extended Csound project has shown the difficulty of trying
to retrofit an informal language onto a new sort of hardware platform.
When SAOL-native sound cards become available, the question of
"how fast can I make this C++ implementation go" becomes largely
moot.
2. The benefits of having a stable platform with lots of robust addon
tools outweighs a 25% increase in speed for most musicians. To quote
from our forthcoming CMJ paper:
As computers and signal-processing units get ever faster,
eventually the need for high-quality, mutually-compatible development
tools for synthesis languages will be more pressing than the need
to squeeze every cycle out of existing processors. This is the world
that the design of SAOL targets, one in which musicians are willing
to accept 75% performance on state-of-the-art hardware in exchange
for inexpensive yet powerful implementations, sophisticated
interfaces,
cross-platform compatibility, and a broad and competitive marketplace
for tools, music, and hardware.
Working on the fastest possible custom implementation of a custom
language (this is, to some extent, the SC model, although there's
also great research in language concepts there) has the Hacker
Nature, without a doubt. But I disagree that for everyone to do
this has the greatest benefit to the greatest number of musicians.
To connect to the thread currently on the Csound list (Michael's "Proposal
for a new version of Csound"), I'd encourage careful benefit analysis of
the use of Csound in that context before undertaking a lot of development
effort. If the goal is to benefit the existing Csound community, then
obviously that's best done within the context of Csound. But if the goal
is to make the world of software-synthesis better, then the disadvantage
of SAOL's currently small user base should be weighed against the long-
term advantages of having a single standard accepted both by the
"academic" community and the multimedia industry.
Just to make it explicit, I don't feel competitive about encouraging SAOL
implementations at the cost of new work on Csound, SC, Quasimodo, and
other such projects -- I think that any work in this arena is a good thing
because all of the projects can feed off each other and help promote
flexible software-synthesis as an alternative to the common practices
in the PC industry today.
Best,
-- Eric
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:23 EDT