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: claudiusmaxi...@goto10.org > To: jbtur...@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
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list