Hey Claude Yeah, it was a little bit of a brain dump, so not very clear. Sorry.
Thanks for the tip/reminder that [s~]/[r~]/[throw~]/[catch~] might be > useful in a livecoding session - I've always been frustrated by having > to connect things together, especially when needing to insert something > in the middle of a chain.
I'd forgotten about throw and catch, although they are mighty useful when you're duplicating voices.
Another "good practice"/"hacky workaround" > for Pd livecoding is inserting extra [*~ 1] all over the place so you > can break a stereo chain atomically later on.
I usually don't find issues with breaking chains, with Pd audio inlets summing audio you can usually make a connection via what you want to insert in your chain, then remove the original wire. While this does sometimes change the overall sound a bit, that's just slightly more interesting. I do tend to avoid using my own abstractions in a live code, just to make the actual process a little more up-front and open to an audience. That being said, it does usually wind up, at least for a while, as some very basic synth sounds. Arithmetic on beat counts can be fun, especially if you're drawing from a central [metro], (incidentally another side-chain to the design I placed down at first, using the left outlet of [bpm] to make something at the same speed using control signals which you can then sync up) always worth doing some polymetrics (3 or 5 over four are nice, don't tend to go down to decimals).
The same kind of thing works for slower oscillators, to get rhythms from > waveshaping a [phasor~] (I think this might be what you were trying in > the ascii diagram, perhaps?).
I wasn't doing waveshaping, as such. The two expr~ objects are using conditional logic, which outputs a 1 or a 0, multiplying these together means that when both read true, that outputs a 1 which makes for a the audio signal being described. So, if I have [expr~ $v1 > 0.1125] and [expr~ $v1 < 0] multiplied together, then this will output a 1 when whichever [phasor~] I feed into it is in the first 8th of it's progress. So essentially it's a simple sequencing system.
Another trick is to use delay effects to amplify your mistakes and make > them seem intentional by repetition. Pitchshifts in a feedback delay > lines are fun too.
I must, must, MUST try this. I'm quite fond of delay lines, even quite simple ones. Tho have been looking for ways to vary them. :) Self-sabotage? Do you mean in the sense of intentionally getting things wrong or simply in removing blocks of code to vary your sound? Because I do try to flatten my patch occasionally, especially on those occasions when I'm coding with someone else so one can pick up the slack while the other starts a new setup.
Incidentally, I didn't mention the self-destruct ending to most of my live-codes. Two or three delays running at different speeds. Usually matching the initial speed, to this sounds pleasant with the running patch. Then I set the feedback on each to about 35% chain them together. Feed the last one into the first (by this point you've got a pretty muddy tone) and cut input to that. Then cut any direct output (except from the delay) and wait while this nasty tone gradually (very gradually) dies down.
Date: Mon, 13 Sep 2010 07:53:57 +0100 From: claudiusmaximus@goto10.org To: jbturgid@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] Any Live Coders?
On 12/09/10 23:35, Andrew Faraday wrote:
Either way, I was wondering if anyone feels like sharing some of their mental templates for a live code approach. Just to get the ball rolling, here's one of my favorites:
[mostly-incomprehensible ascii art snipped]
Thanks for the tip/reminder that [s~]/[r~]/[throw~]/[catch~] might be useful in a livecoding session - I've always been frustrated by having to connect things together, especially when needing to insert something in the middle of a chain. Another "good practice"/"hacky workaround" for Pd livecoding is inserting extra [*~ 1] all over the place so you can break a stereo chain atomically later on.
Otherwise, I usually prepare some small abstractions for drums ([kick~] [snare~] [clap~] [hihat~] etc), as coding a reasonable sounding drum synth is hard (in fact I think I mostly 'borrowed' from Andy Farnell's stuff).
And some simple effects that are boring to code too, like delay-based [pitchshift~] and audio-rate [compress~] (my own invention that sounds too extreme, but stops everything clipping and I don't have to worry about levels so much).
One of my tricks when live coding (and more generally) is using arithmetic on beat counts, like [*] [+] [div] [mod] in various combinations. Then using the resulting numbers as frequency multipliers (for harmonic series/scales). For a (composed) EP that uses this technique, see:
http://www.archive.org/details/ClaudiusMaximus_-_Clouds_Are_Made_Of_Water
in particular the third track.
The same kind of thing works for slower oscillators, to get rhythms from waveshaping a [phasor~] (I think this might be what you were trying in the ascii diagram, perhaps?).
Another trick is to use delay effects to amplify your mistakes and make them seem intentional by repetition. Pitchshifts in a feedback delay lines are fun too.
Anyway, I uploaded some older recordings this morning, four Pd livecoding sessions:
http://www.archive.org/details/ClaudiusMaximus_-_Livecoding_2008
Listening back to them with a critical ear, I think in places I forgot the value of "(self-)sabotage" for making more interesting improvised music - getting locked into a groove (even if it's funky) isn't good if it goes on for too long.
Claude