Hi Andy,
On 25/02/2012 5:05 AM, Andy Farnell wrote:
The problem with "plug unit generators languages" for me is that they
privilege the process (network of unit generators) over the content
Some really interesting thoughts here Ross. At what level of
granularity does the trade-off of control, flexibility and
efficiency reach its sweet spot?
Part of my argument is that ther's a problem if your synthesis language
is not turing complete. C/C++ and MP4-SAOL are two options here. I'm not
sure Faust gives you that.
In some ways the unit generator or patchable code-block
model is to be considered a compromise between the overhead
of calling functions on single samples and being able
to process chunks. It comes bottom up, out of implementation needs
rather than being a top down shorthand. On the other hand,
because familiar structures like the filter, oscillator and so forth
make sense as basic units of design the VM + Ugen model makes
a lot of sense to practitioners coming from the studio.
Agreed.
As an aside: studio equipment (typically, not always) has this property
that all couplings are impedence matched, or buffered. What something is
plugged into doesn't affect what it does (to a first order
approximation). This is not how acoustic systems nor electronic circuits
work. So that's one problem with the abstraction. Indeed increasingly
audio software is incorporating iterative solvers for this kind of
thing, although we don't yet see computer music languages with full
solving capabilities like QUCS or SPICE.
Plenty of analogous structures in general computer science
have similar rationales, like pipelines, SIMD, with the
question being at what level of granularity can you lump a
bunch of stuff together and process it all without sacrificing
flexibility? Even apparently atomic instructions are, from the
microprocessors point of view, collections of more atomic
register operations that we never consider unless programming
in machine code.
Right. But unless you're programming in assembley language these
constraints (and benefits) don't usually impact the outcome. The
compiler provides a generalised model of computation and optimises to
these low level structures.
The problem in something like Music-N-with-control-rate derived
languages is that the optimisation surfaces as a strict constraint in
the structure of the high level language.
Faust is one example that gets away from this. Although I'm pretty sure
it is not usefully turing complete.
MP4-SAOL is the best thing I've seen so far that allows control-rate
semantics/optimisations but doesn't force them (you can write a single
sample delay and the compiler will recognise it as such).
Anything else is just plugging unit generators together, which is
limiting in many situations (one reason I abandoned these kind of
environments and started writing my algorithms in C++).
As linguists and writers note (Wittgenstein, Orwell, Ayer, Chomsky etc)
language defines the modes of thought and facilitates or limits what
we can do more or less easily. I guess plenty of studies have been
done of the "expressibility" of computer languages, since they are
strictly formal and amenable to analysis. Though we tend to invoke
"Turing completeness" and assume all roads lead to Rome, clearly some
languages are much better for certain things than others.
I don't think we have to resort to the Saphir-Whorph hypothesis here.
(there was a great thread on that on the POTAC list last year btw.)
I think you're right about turing completeness though: in my view, you
need something that is expressively turing complete that can operate on
individual samples within that language framework. C/C++ and MP4-SAOL
give you this. CSound doesn't, at least not easily, perhaps if ksamps=1
you can get close, neither do any of the split synthesis graph/control
language systems (SC3, LuaAV, pd, maxmsp).
Grist for the mill in computing philosophy, but as musicians or
sound designers it takes on a freshness. For example, the ease with
which polyphony can be conceived in Supercollider and Chuck is
amazing compared to Pure Data/Max, which makes it an awkward hack
at the best of times. Csound is somewhere between. And of course,
though Csound is clearly conceived as a _composers_ language where
large scale structures are easy to build, abstraction is very obtuse.
Well I would question whether CSound is a composers language. To me it's
an audio rendering language. Whenever I used CSound in my composition
workflow I would write Python scripts or C programs to generate scores,
so the composition didn't happen in CSound per-se.
I remember Gunter Geiger's thesis being a good comparative
treatment of different computer music languages, but that was
mainly from a computational rather than expressibility angle.
Maybe there's a good doctoral project for someone lurking in this
question.
Ah didn't realise he ever finished, I should look it up.
Programming in C++ makes the signal efficiently accessible.
Getting down to the metal with C/++ is more than just a departure from
the VM plus UGEN model, it allows, as you say, complete reconfiguration
of the signal processing structure on a sample by sample basis, and
departures from strictly causal models using look ahead computation
etcetera. But at the same time it lays the signal bare, it
seems to bury the larger process (unless you are an extremely methodical
hacker and already working with quite robust and well used libraries).
Nothing stopping you developing your own frameowork. Based on personal
experience I'd say it takes around 10 years to learn enough to get
started with that.
Is there is a fundamental trade off here that we just cannot get around?
I don't think so.
I don't see any fundamental reason why a synthesis language can't
incorporate efficient block-level optimisations and allow sample level
access in an easy to use turing complete environment. It's possible
extempore does this, although I havn't looked into it deeply enough to
comment. Michael's experiments with LuaJIT point in this direction too.
And MP4-SAOL does it, although it has some other limitations (it's
turing complete, but maybe not a very user friendly programming language).
Cheers,
Ross.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp