Re: [linux-audio-dev] SuperClonider

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] SuperClonider
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Sat Apr 20 2002 - 22:21:20 EEST


Hi everyone,

        Interesting posts here on the pros and cons of SAOL by
several folks ... what is being missed here is that the end
goal for SAOL is to embed a SAOL decoder everywhere you would
embed an MP3 decoder today -- PCs, stereos, cell-phones, etc.

        This was a language design constraint -- the core app
that got SAOL into the spec was a mixdown language for the
audio tracks of other decoders, and so it needed to be simple
enough to work in that environment. And in fact, with current
technology its still considered "too heavyweight" for that
application, so there are simpler tools in MPEG that can handle
mixdown too now.

        So given this, you can ask "so why should we, as content
creators, care about this client-driven language"? Well, in one
sense, you don't -- it's totally reasonable to imagine a
SuperCollider-to-SAOL compiler, just like the CNMAT folks did
a SDIF-to-SAOL compiler:

http://cnmat.cnmat.berkeley.edu/ICMC99/papers/saol+sdif/icmc99-saol+sdif.pdf

        But, for some folks, Structured Audio is a good match
to how they like to program natively, and for these folks using
SA instead of CSound or SuperCollider makes sense.

        However, this is LAD, not LAU -- the "we" here is in
theory "content toolmakers" as opposed to "content creators".
Why should the LAD "we" care about SAOL?

        Imagine SAOL exists on these consumer end-user-clients.
And, imagine you have authoring tools that can target a complete
performance to SAOL -- some combination of special-purpose
acoustic codecs written in SAOL for things like vocal tracks,
and SAOL instrs controlled by MIDI or SASL for synthetic tracks,
with more SAOL code for effects and mixdown info. It's not that
hard to imagine a ProTools plugin that does this, for example.
It's a much easier job to convert the "work materials" to SAOL
than it is to take the final audio tracks and do auditory scene
analysis to get the constituent sound streams back!

        If you choose your instrument models correctly (heavy
on CPU instead of memory), you can end up with something as
small as a MIDI file, which yields a truly normative audio
output on the user end -- sounds the same for every compliant
decoder, unlike (say) General MIDI.

        Realistically, this is only way we break through the
current 64-192 kbs range for quality psychoacoustic coders,
to get quality audio into low-bit-rate worlds.

        In addition to low-bit-rate coding, it also opens up
a way to code, in a standardized way, the 24-track work materials
of (say) the Eagle's Hotel California on a DVD-ROM, sold as
raw materials for DJ mixing -- if you went this route, you could
have special-purpose SAOL decoders for each track, one codec
that worked great just for bass drums, another that worked great
just for snare drums, etc. Not to mention the "Don Henley custom
voice codec" :-).

        So, to answer the question, the LAD "we" that thinks that
targeting end-consumer devices with an algorithmic programming
language is interesting should be most into SAOL. Of course, this
isn't a 2002 vision -- like GIF 89a, there's a time lag between
when a standard is ready for use and when a standard starts to
get used, and SAOL hasn't crossed the chasm yet. But I think the
odds are much higher for SAOL to be the algorithmic language that
crosses the chasm in this way, than it is for a proprietory language
like SuperCollider -- SAOL was designed for it, and its an ISO
standard.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 20 2002 - 22:08:31 EEST