i just had a try at it,
wouldn't say it sounded particularly amazing, but i managed to build
enough up in a few minutes to make it kind of interesting. will try
again later and see if practice makes things better.
best idea i came up with in the first run:
[key]
|
[t b]
|
[random 10]
|
[sel 0
i'm doing a talk in delhi next month on pure data for live
performance, so i will definitely incorporate some live coding in
there,
any tips and tricks people have found useful would be much appreciated.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and
hard off a écrit :
i'm doing a talk in delhi next month on pure data for live
performance, so i will definitely incorporate some live coding in
there,
any tips and tricks people have found useful would be much appreciated.
you could record into a buffer what is thrown to dac~ and rediffuse
hard off a écrit :
i just had a try at it,
wouldn't say it sounded particularly amazing, but i managed to build
enough up in a few minutes to make it kind of interesting. will try
again later and see if practice makes things better.
best idea i came up with in the first run:
[key]
|
Hi Tim,
I havent seen many examples yet around here though.
Are many people doing this with pd ?
The pd-graz group has done a variant of live-coding in its 'blind date'
performances. There we take a teamwork approach, letting multiple
players edit the same patch at the same time on stage
1) Think in a live situation, you want to close a sub patch but you
accidentally close the main patch.. DISASTROUS! :-)
Do you actually _have_ to handle closing and opening patcher windows
while
doing a live performance ?
I think your setup and/or patch should make that unnecessary (or
hi,
livecoding is one of my favorite use of PureData, it's the way I've
had the best fun with it at least,( sigmund~ is quite cool in this
context,) and once the piece is over, it won't be saved, like a mandala.
___
PD-list@iem.at mailing list
