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.
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 1 2 3 4 5 6 7 8 9]
that way, while i was coding, sounds were being changed and triggered by keystrokes.
personally i think if you're going to do live coding, you should do it from scratch without using abstractions.
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.
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 it randomly or following the rule you find at the moment you do it.
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] | [t b] | [random 10] | [sel 0 1 2 3 4 5 6 7 8 9]
that way, while i was coding, sounds were being changed and triggered by keystrokes.
personally i think if you're going to do live coding, you should do it from scratch without using abstractions.
Hello,
using abstraction would be cheating, :p. It would be bummer to not use useful list-abs, or some RTC, and obviously, the doc files, where the consultation almost always turns to livecoding.
-
hard off -
Patrice Colet