Hey Renato,
 

Cool!
 

I'll share some ideas that things that I found, these are just my opinions, others might think the exact opposite (in that case I'd like to hear why...).

First of all; set out to have fun. Clearly livecoding involves a display of skill but that -imho- shouldn't be more important than the fun that should be the core of musical performance. Music is, after all, a form of entertainment, not of competition or whatever.

That said; practice is quite important in any instrument and livecoding is far from a exception. If you practice for a hour each day even for just a month you'll see yourself progress by leaps and bounds. With practice you'll be more relaxed when there is a actual audience and that's good; under stress people get less creative (typically). Sometimes record your practices and always time how long it takes you to go from 0 to something interesting; it's fun to see that time go down.

Pick a good environment to work with. I like the MiniAudicle because you can use the hotkeys to control the VM from inside of the editor. IMHO that's far more convenient than reaching for a mouse. Sadly on Linux the hotkeys to switch between text buffers don't work and when creating a new buffer it won't get keyboard-focus without touching the mouse, Linux users may want to pick a different editor for livecoding and probably map some of their own hotkeys. Whatever you pick; stick with it while practicing.

As part of your practice regime; look for some strategies that create nice music/sounds for little code and practice variations of those. I wouldn't try try to memorise a multi-page program to enter that and have The Perfect Track play just as the audience has left. Instead look for something that will sound ok in its most basic form and get progressively more interesting as you flesh it out. As you build up a repertoire of these you'll be able to re-combine them in different ways. This keeps your practices more exciting and by doing things in different (slightly) ways each time you avoid the risk of a single accident throwing off your plans during a performance.

If you use samples keep them in a set directory with a set naming convention; you only need to set that up once and it'll save a lot of confusion and annoyances in the future.

Things like libraries for scales and clocks and things are nice, but I found that keeping everything as simple as possible often works at least as well and it's less effort :-).

Using random functions is easy but ultimately leads to pieces with little sense of progression. I tend to have a random value or two in the first version of the code that I write, then replace it with something more interesting as I flesh it out.

The STK instruments in ChucK are a nice place to start with for sound-generators that take little code to sound nice. Bonus points for finding new ways to use them that are unlike their intended purpose.

Hmmm, I think that's about it for the general tips. That's probably a good moment to repeat how important practice is; experience with writing larger ChucK pieces in a non-live setting is helpful but not the same as specific practice. Oh, and the bit about the "fun", that's important too.

Yours,
Kas.