<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Hey Claude<div><br></div><div>Yeah, it was a little bit of a brain dump, so not very clear. Sorry.</div><div><br></div><div><div><br></div><div>> Thanks for the tip/reminder that [s~]/[r~]/[throw~]/[catch~] might be <br style="text-indent: 0px !important; ">> useful in a livecoding session - I've always been frustrated by having <br style="text-indent: 0px !important; ">> to connect things together, especially when needing to insert something <br style="text-indent: 0px !important; ">> in the middle of a chain. </div><div><br></div><div>I'd forgotten about throw and catch, although they are mighty useful when you're duplicating voices. </div><div><br></div><div>>Another "good practice"/"hacky workaround" <br style="text-indent: 0px !important; ">> for Pd livecoding is inserting extra [*~ 1] all over the place so you <br style="text-indent: 0px !important; ">> can break a stereo chain atomically later on.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>> The same kind of thing works for slower oscillators, to get rhythms from <br style="text-indent: 0px !important; ">> waveshaping a [phasor~] (I think this might be what you were trying in <br style="text-indent: 0px !important; ">> the ascii diagram, perhaps?).</div><div><br></div><div>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. </div><div><br></div><div>> Another trick is to use delay effects to amplify your mistakes and make <br style="text-indent: 0px !important; ">> them seem intentional by repetition. Pitchshifts in a feedback delay <br style="text-indent: 0px !important; ">> lines are fun too.</div><div><br></div><div>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. :)</div><div><br></div><div>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. </div><div><br></div><div><br></div><div>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. </div><div><br></div><div> <br>> Date: Mon, 13 Sep 2010 07:53:57 +0100<br>> From: claudiusmaximus@goto10.org<br>> To: jbturgid@hotmail.com<br>> CC: pd-list@iem.at<br>> Subject: Re: [PD] Any Live Coders?<br>> <br>> On 12/09/10 23:35, Andrew Faraday wrote:<br>> > Either way, I was wondering if anyone feels like sharing some of their mental templates for a live code approach.<br>> > Just to get the ball rolling, here's one of my favorites:<br>> <br>> [mostly-incomprehensible ascii art snipped]<br>> <br>> Thanks for the tip/reminder that [s~]/[r~]/[throw~]/[catch~] might be <br>> useful in a livecoding session - I've always been frustrated by having <br>> to connect things together, especially when needing to insert something <br>> in the middle of a chain. Another "good practice"/"hacky workaround" <br>> for Pd livecoding is inserting extra [*~ 1] all over the place so you <br>> can break a stereo chain atomically later on.<br>> <br>> Otherwise, I usually prepare some small abstractions for drums ([kick~] <br>> [snare~] [clap~] [hihat~] etc), as coding a reasonable sounding drum <br>> synth is hard (in fact I think I mostly 'borrowed' from Andy Farnell's <br>> stuff).<br>> <br>> And some simple effects that are boring to code too, like delay-based <br>> [pitchshift~] and audio-rate [compress~] (my own invention that sounds <br>> too extreme, but stops everything clipping and I don't have to worry <br>> about levels so much).<br>> <br>> One of my tricks when live coding (and more generally) is using <br>> arithmetic on beat counts, like [*] [+] [div] [mod] in various <br>> combinations. Then using the resulting numbers as frequency multipliers <br>> (for harmonic series/scales). For a (composed) EP that uses this <br>> technique, see:<br>> <br>> http://www.archive.org/details/ClaudiusMaximus_-_Clouds_Are_Made_Of_Water<br>> <br>> in particular the third track.<br>> <br>> The same kind of thing works for slower oscillators, to get rhythms from <br>> waveshaping a [phasor~] (I think this might be what you were trying in <br>> the ascii diagram, perhaps?).<br>> <br>> Another trick is to use delay effects to amplify your mistakes and make <br>> them seem intentional by repetition. Pitchshifts in a feedback delay <br>> lines are fun too.<br>> <br>> Anyway, I uploaded some older recordings this morning, four Pd <br>> livecoding sessions:<br>> <br>> http://www.archive.org/details/ClaudiusMaximus_-_Livecoding_2008<br>> <br>> Listening back to them with a critical ear, I think in places I forgot <br>> the value of "(self-)sabotage" for making more interesting improvised <br>> music - getting locked into a groove (even if it's funky) isn't good if <br>> it goes on for too long.<br>> <br>> <br>> Claude<br>> -- <br>> http://claudiusmaximus.goto10.org<br></div></div> </body>
</html>