[eu-gene] Psst...Wanna Buy an Algorithm? (Working Title)

[alex]

On Sat, 2005-10-15 at 20:27 -0700, Andrei wrote:
> > If an algorithm runs without any external interaction, then it will 
> > produce the same output  every single time, unless the computer is 
> > broken.
> 
> I'm really surprised to hear you say that. With SuperCollider for
> example (and I'm sure also with Max, C Sound and other apps) you can
> create very simple patches which will produce very different output
> each time you run them.

Ok, I'm talking in theoretical terms and you're talking in real world
terms.

> The output might not constitute a piece of
> music, but the sound that'll be produced will vary each time. There are
> all sorts of things you can do: mess around with arrays of values, use
> if-then-else conditionals, use noise unit generators to control
> parameters, etc., etc.. 

Operations on arrays and other structures, and if-the-else conditionals
will produce the same results each time you run them with the same data.
Noise generators in SuperCollider don't really generate noise but
algorithmically synthesise an approximation, with a random seed taken
from an external input, probably the system clock.

A program will only produce different results with environmental input.
That could be getting a value from a system clock, relying on triggers
that other processes in the computer environment effect such as timing,
or explicitly taking input from a user.

But perhaps I'm being a little pedantic.  However, I do take issue with
that "very simple patches produce very different output each time you
run them."  I think that's not true, in the musical sense.  You may use
arbitrary values (such as noise generators) to make your patch appear to
produce novel output, but on closer inspection it's not doing so.  It's
just producing variations of the same thing.  If your patch doesn't
contain any more interesting structure, it will just produce noise,
which is structureless by definition.

This becomes clear when you play this patch many times.  The brain
recognises the patterns in the output and tunes out of the arbitrary
structureless parts.  The randomly generated aspects are therefore
perceived as silence around the real structure behind the music.

For this reason I think random numbers should be used carefully, in the
same way that silence is used carefully.

> "Generative" to me means a process which involves some element of
> "chance"/unpredictability/surprise/indeterminacy. I see "generative" as
> an overall category, under which things like stochastic and "aleatory"
> processes fall.

Ah, then we're using the term very differently then, it's described more
broadly than that on the generative.net site.

> It can get confusing. I haven't actually sat down and tried to sort it
> all out. Maybe the category under which a piece falls depends on which
> aspects of the piece are "generative." The structure could be
> indeterminate, timbres could vary, pitches could be indeterminate,
> interaction between different elements could be indeterminate, etc..

But then internally, a computer is not indeterminate.  And whatever
happens, the music itself is not indeterminate either.  As some result
of a process, a note gets played, and once that's happened, it's a
nonsense to say that it is a random note.  It's just a note, placed with
the notes before and after.

> I don't really lose my time thinking about terminology when it comes to
> creating music.

Sure, but it helps when talking about it :)

> I tend to think more like "I want this aspect or
> element of the piece to be indeterministic (indeterminate?) to some
> degree". I just want to be surprised a bit by what happens. So far in
> my efforts it's tended to be more about using some element of
> randomness to choose between different variations.

Same here - sometimes you just don't want to make a decision about what
happens, so you use an arbitrarily generated random number to decide for
you.

> I think it's
> actually quite difficult to compose something that's indeterminate to a
> great extent. It can get kind of self defeating in the end and you
> arrive at some philosophical conundrums. You're putting all this effort
> into creating something which you don't want control over. You're
> making all this effort trying to create something effortless. You might
> as well just let things be the way they are, or improvise, or
> something...

Well put.

I like the idea of making something that "stands despite all chance to
fall."  Writing code that produces stable musical structure, and then
writing code that attempts to destabilise it.  You then get the sense of
an underlying structure that is struggling to keep together.  You can
then increase the entropy until it falls over completely.  Cruel.


alex