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
> --
> http://claudiusmaximus.goto10.org