Hi ..
heres my two pence..
I use PD for most of my coding audio, but I have also written quite a few
apps using, c++
and libs like portaudio and the vst interface sdks..
Basically there is a limit to how 'basic' your starting set can be, but all
systems will actually be quite similar
in terms of libraries available.. PD has a built in set of about 50
objects/commands, such as osc~
which is a sine generator (as is cycle~ in Max). Now this object is not that
much different from using a standard
math.h sine() command in C, Ok you can mess about with using wavetable
lookups instead of algo generated sines,
but were talkning about the same sort of function. In fact a langage like
c++ or PERL contain
much more inbuilt object/functions than an audio language/environment like
PD. Unless you want to start working in ASM,
(In which case you will probably take quite a while to get a sound out) then
most langs hold the same linguistic/syntactical
functions.
The key to the work I think is to do with the environment. PD/MAX/SC/ etc
are designed to allow realtime experimentation with code
The compilation process is constant and the interface is the most
significant aspect. Granted I could code everything inside Visual studio and
run parallel compilations using raw c code and portaudio lib, but what is
the point, I could spend the whole gig building the motherboard, or
mining the copper for my silicon bath;) Of course we all know this, but
sometimes we can get a bit too puritan.
If i was live coding from scratch I would work with what pre-existed in the
app and then the sticky point comes when I decide
what other objects/function to include in my initial pallette (whether
written by me or by others).
One thing I find hard not to include is reverb patches... I can write delays
on the fly and therefore all kinds of modulation stuff etc,
but a decentish reverb is half an hour of wiring up allpass n delays etc.
do you let the aestheic of the basic form disallow such processes,
or do you include certain pre-coded elements...Of course if you wrote the
initial system (such as some of alex's perl stuff i guess)
then who can say what is part of your base set?
PD is a very visual language and as such it is great at revealing the
thought processes and construction methods to people who cant follow
a three level pointer structure in text. Its also very easy to break/re-make
connections and play with flow, which is a great aid to
improvisation and experimentation. And of course all the patches are simply
text files which I guess you could write in an editor ;)
(I prefer PD to max because it is closer to the pure level of audio coding,
but I'm sure others would already think that
it is too 'dressed up' itself). I mean we could just pipe our kernels to
dev/dsp and be done with it, now thats live code ;)
Anyway, just my RAM on the loose again.
Tom
http://www.nullpointer.co.uk
http://www.r4nd.org
----- Original Message -----
From: "alex" <alex_at_slab.org>
To: <livecode_at_slab.org>
Sent: Wednesday, July 07, 2004 10:33 PM
Subject: [livecode] coding from scratch
>
> I've found live programming during a performance a problem. In recent
> experiments I've been preparing some scripts in advance, running them
> and then finding myself tweaking variables rather than working the code
> in any significant way.
>
> So while I have found live coding to be an inspiring and productive way
> of writing music at home and in my studio, the way I'm performing with
> these pre-prepared scripts seems a step back from how I was working
> before. I've thrown away the user interfaces to reveal the code below,
> but am then just editing numbers that are scattered around the screen.
>
> So what I'm aiming for now is to be able to start with a blank text
> editor and write code from scratch during the performance. Has anyone
> tried this approach yet? I seem to remember you saying something about
> pd wars Tom, where the artists compete against each other, starting with
> an empty patch and seeing how quickly they can make something good.
>
> I think it could work well. Many times I've spent hours on a problem,
> come up with an ugly solution, then re-written a better version later in
> a fraction of the time. There are some things, such as chat systems or
> website backends that I've made many times over with the same ideas, and
> yet they've ended up behaving quite differently for whatever reasons,
> each creation satisfying in its own right.
>
> I suppose it lends a certain structure to the performance, starting off
> with one very simple element, developing it a little, adding a little
> bit of structure until it becomes something like a melody, then starting
> up another editor, introducing another simple element, developing that
> into a simple rhythm, then coding in some interactions between the two
> processes perhaps, and going from there.
>
> Just because code exists on disk after a performance, it doesn't
> necessarily mean that it should be run again... It could be thought of
> as a kind of fossilised improvisation. Not even a record of a
> performance, but a frozen impression of the performance at the moment of
> its death.
>
> So I'm collaborating on a set with a drummer at a headphone festival in
> london next week (http://state51.org/placard/). Even though the set
> will only be twenty minutes it seems that I'm going to have to try this
> out.
>
> I'd better sleep now anyway, apologies for my late-night ramblings! No
> conclusions here, just stray thoughts...
>
> alex
>
> --
> alex <alex_at_slab.org>
> slab laboratories
>
>
>
>
Received on Thu Jul 08 2004 - 08:25:25 BST