Blog post: Working with samples the Heavy Lifting way

https://tidalcycles.org/blog/tidal_profile_heavylifting

Lucy gives us a deep-dive into her from-scratch livecoding process - from choosing samples and editing, to experimentation, going through "the entire Tidal documentation" (wow!), and building sketches (Tidal code samples included). It is a wonderful view into live coding as a complete process - and along the way we get anecdotes, some history and a style that is funny, vulnerable, and full of conviction.

She also provides some nice sample files via Google drive - plunder away!

Are you a blank-screener? Are you a (not) from-scratch livecoder? Either way - you should read this and think about it. Check it out!

Add your comments - what are your thoughts on from-scratch coding?

10 Likes

Thanks for all your help with this @HighHarmonics !

I just remembered this video which shows a bit of my experimentation process: heavy lifting playing with samples - chatty live coding - YouTube

If anyone has any questions please give me a shout!

7 Likes

Thanks for sharing your experience and insight @heavy.lifting. I would characterize from-scratch as an specific practice in live coding (not a model of what live coding should be). But I would also agree that a from-scratch performance enhances or emphasizes liveness in live coding. There's also much more transparency with the audience, which resonates a radical approach to open sourcing (thoughts). I like that you're old school in this way. Also your plundering approach seems fair to me.

2 Likes

Really great thoughts thanks @heavy.lifting! I guess we're all making it up, in that all live coding is from scratch unless you're starting from someone else's code.. Just some choose to hide the first bit :wink:

It's true that there isn't anything about blank slate in the TOPLAP manifesto.. I was curious about this, and checking the TOPLAP mailing list archive there was a 'coding from scratch' discussion in July 2004, where the manifesto was mostly written Feb-May earlier that year.. Thinking back, I guess the idea of live coding was too strange and unfamiliar to start defining how it should be done.. It was all up in the air. It's worth noting also that back then live coding was slow. There was no 'jux rev' or mininotation. I was live coding in Perl, and to code from scratch, I'd have to first think of an idea, and then write code to implement it. If the idea was fiddly it could take some minutes to make a noise.. I'd still do it in collaboration with a percussionist, but it wasn't very practical as he'd always have to improvise solo for some time at the start. Still it was a good way to start thinking about what a better language for live coding could be like!

Now there seems to be 'algorave DJs' who don't really edit the code at all but still project it. That's all fine, it's good to show what you're doing, and I've always been keen to support a variety of practices in the events I organise. I do agree though that we should take some time and energy to focus on what makes from-scratch coding so cool and support it as a practice as well. For me it's just the best feeling having something fresh and new unfold live in front of you, and brings real meaning to live collaboration.

So I totally respect people who really want to tweak and engineer a track until it's ready for a live audience.. But from-scratch motivations are just from a very different place. e.g. from-scratch really works against the idea of a fixed 'track' and a repeatable performance of it, which lets face it are comparatively very recent concepts brought by capitalism's attempts to limit creativity via copyright. So I guess I just associate from-scratch as being a particularly wholesome way of making music.

(BTW @heavy.lifting and I are performing together as 'epiploke' in ICLC (and in Sheffield the week before), exploring a from-scratch approach to improvisation informed by (@heavy.lifting's interests in) the Ancient Greek approach to metrical structure and living memory.. )

6 Likes

At first, thank you very much for your thoughts, @heavy.lifting. Your blog post is very helpful for me.

I feel somewhat addressed by your thoughts @yaxu, which are very interesting to me too. I probably belong more or less to the "algorave DJs", even if my music has little to do with club music. But at the moment I prepare my code 90 - 95% of the time.

On the one hand, I understand better and better also through your explanations what the special challenge is for many in the practice of from scratch. I also find from scratch very appealing and have already tried it once in public. It was a lot of fun, but the result did not (or not yet) meet my musical requirements. I just have a completely different background, a different socialisation. And my background is (pop) music and not coding. That's why I will probably always think of livecoding practice from the end, from the musical result.

On the other hand, what I dream of:
Thinking musically, too, it would be very desirable for me to create something symbiotic from both worlds. I would also like to get away from the practice of finished musical pieces. I would like to pre-programme a basis of code, basis of style and complexity. Preferably no more than 40-50 lines.

At best, this would then be the basis of 50% for a 60-minute performance in which this sparse code is improvised. At best, the results should no longer be individual pieces, but an improvised, unique sound event that permutates over the duration of the performance.

2 Likes

Yes I agree! from-scratch is just one approach, but for me and my practice it feels almost essential. For me that 'liveness' as you describe it is the element that hooked me into live coding as opposed to more traditional means of making music. I actually maybe should have talked about this in the blog but it becomes even more of a thrill when collaborating with others - I think the from-scratch approach helps encourage freedom, trust and exploration in collaboration.

I'm certainly not an expert on open source, but the 'Give us access to the performer's mind, to the whole human instrument.' element of the manifesto really does resonate with me. But I also wonder if screen sharing alone gives enough insight to the audience... In the video of me playing with samples in the blog post, one of the things I wanted to achieve was even more openness about what I was doing (actually maybe with this blog post too). I think even with the outwardly stated intention of openness, there is still a lot of mystique around what we do.

But regardless, I think that radical openness can be achieved with pre-written code too, arguably more so since you have much more scope for organising things well and annotating when you pre-prepare, and you can share scripts online etc etc - it feels less ephemeral, less 'blink-and-you-miss-it'. I'm always happy to share code, but it's rarely representative of what I've done since I edit and delete so heavily during my set - it's more of an accidental artefact. I'm going to ICLC and I'm excited for Dan Gorelick's workshop on the craft of algorave documentation, since I'm interested in thinking about if/how we preserve a performance designed to be experienced in the moment :thinking:

Thanks anyway for reading and sharing your thoughts - I appreciate it :slight_smile:

3 Likes

Yes I very much agree with your point about collaboration and wish I had said something about this in the blog now (...although it is already very long)! But I think enjoying that level of unpredictability is a bit of a personal choice/quirk :stuck_out_tongue:

Thanks for sharing your thoughts @ganz - I think I very much understand where you're coming from and it sounds like we have different drivers in what we are trying to achieve with a performance. For me my 'musical requirements' are almost non-existant in advance, they evolve as the performance does - so it seems to me like we approach from very different directions! (I'm also not from a coding background though - but your comment has made me interested in understanding if there are certain 'types' of people who prefer to perform from-scratch)

I think your idea sounds incredible - almost like you have some sketches which you fill in with colour during the performance. I can imagine achieving a very authentic style with this approach. In a way it's only a step or two beyond the process of preparation I outlined in the blog post - maybe 'from-scratch' is a spectrum... certainly I'm not writing my own software on stage, or recording and editing samples on stage...

At any rate, I want to emphasise I don't think there is anything wrong with pre-prepared code!! I think it is more the norm these days, and some of my favourite performers/performances work this way. It's interesting to me that there has been a bit of a cultural shift round this in the scene, but in a way I'm happy because I think it opens up more opportunities for people who don't want to code from-scratch. I know that has definitely been a barrier to people in the past. However, I hope that my blog post might help people gain confidence in from-scratch performance if it is something they want to do.

Another thing I should add - my from-scratch performances are almost always 30 mins or less. I can do longer but these definitely require more dedicated preparation as I outline in the blog, I need more 'ideas' and will often have a few snippets of code in reserve in case I panic - again, working to a different point on the spectrum.

2 Likes

I think from-scratch is super cool, but I prefer preparing my code for two reasons:

  1. I don't want to force the audience to listen to the same pattern on a loop for the fifteen minutes it takes for me to program a sequence of transitions lol part of me feels like the only haptic part of improvising with code is how fast you can type but my own insecurities play into that too. I don't have all the syntax for all the effects and pattern manipulation memorized and even the stuff I do have memorized I can easily forget when I'm on stage and have 10 or more channels to keep track of. I saw somewhere, it was some algorave website, a manifesto about live code being about completely on-the-fly blah blah blah and it felt like they were making live code into a pissing match between from-scratch versus prepared code. I think either way is cool. I like to have a general structure or skeleton prepared. There's some stuff you can do with a turntable at the touch of a button, like making one quarter of a bar repeat with each button press to make a break section, that would take at least eleven lines of code for a 10 channel mix (as I understand it, maybe there's a better way) in live code or building up to drop and then starting all 10+ channels on a new section and those things are fun to do with a performance but they aren't very realistic to do in real-time. Even if it's copying and pasting code into the right structures for that I still feel like it's silly to make a big deal out of doing stuff like that live from scratch. It doesn't matter so much to me. When it comes to creating a groove though, that's really cool when that happens from scratch. So for me it's about certain structures (drops, breaks, interludes) that I prefer to just have prepared in advance. When you have those prepared it frees up time to have fun changing patterns and stuff to build up to those big structural changes and then even incorporate those pattern changes into the structures you have prepared. If I had a full 2 hour headliner set to myself I'd totally be more open to doing a from-scratch piece but usually I get like a 20 minute slot and 20 minutes is like one piece if I'm doing it from scratch lol

  2. The oscillators in SC sound bad. I tried making my own synth patches in SC with synthdefs and they just don't sound anywhere near as good as what I'm able to produce in the DAW with commercial VST's. I saw someone mention on one of my SC forum posts that the oscillators in SC actually downsample in lower frequencies and so you get these muddy, weak sounds out of them. I'd love to build from scratch if I could create high-fidelity sounds and patches with SC to use in Tidal Cycles but it's not really possible right now. It does sound cool sometimes when you take a tiny snipppet of a good synth patch, like 1/4 beat of a note from a patch, and then use sampling techniques to pitch the sample up or down and create sort of a pseudo-synth patch but you need two different samples for longer vs shorter notes to make somewhat smooth transitions and it just becomes too convoluted for me. If I could make a fat wob wob or a clean growly bass patch in SC and use that with Tidal I'd be way more down for just improvising on-the-fly. So for now I write everything in the DAW, then sample that all out and plug it into Tidal and use that to perform and change and restructure things etc

The distortion plugins in SC are also kind of weak sauce when you compare them to commercial VSTs. I'd love a good multiband distortion Ugen or something with different saturation models to choose from so I can trash a single frequency band on a synth patch with maybe a Screaming Rock Amp saturation algorithm and then toss an aggressive limiter on it and crush the whole thing it into a mean little bass monster. Maybe that's just my lacking in code sklills though, I just can't make the fat wob wobs and growly growls in live code :frowning:

I like the tone of this post though. I think either approach is awesome and valid as creative practices. I hope my tone wasn't offensive. I really love live coding and using Tidal and I love SC, but I'm just being frank about my own limitations, insecurities, and thoughts about it all.

1 Like

All I wanted to say is that I absolutely love this series, and that the blank screen from-scratch concept is so theatrically appealing. Thanks!!

2 Likes

Thanks for sharing your thoughts - I don't think your tone is offensive at all.

With your first point I totally agree - there are a lot of things that are difficult to achieve in a from-scratch performance - in my post I talk about how I only use a really limited subset of the Tidal syntax, and that is at least partially because I just can't remember much else or confidently execute it on-the-fly. My code is usually super simple and while that works for what I'm trying to do, it doesn't work for everything. I also agree that transitions are really difficult in from-scratch performance, I have a few strategies for that but I don't really tend to incorporate dramatic drops or structural changes, and wouldn't really have a good way of doing that if I wanted to.

Like you, I also don't like this idea that from-scratch and pre-prepared code are in opposition to each other or in competition with each other. They are different practices and as you point out both are totally valid. Live coding isn't just one thing or one way of doing things, and there are as many different approaches as there are performers. My intention with this post wasn't to say one way is better than another, but really just to share my own approach in the hope that it would be interesting, and might encourage some blank-screen experimentation. I meant this wholeheartedly since I find it so fun personally, but of course each performer has their own ideas and preferences (and it would be very boring if we all did the same thing). You talk about feeling like you have limitations and insecurities - I do too and I guess we all probably do - my hope with this post was to show that a lot of preparation goes into from-scratch performances and that they aren't some magical dark art that requires god-like confidence and skill to pull off.

For your second point - it made me wonder have you tried controlling your synths in the DAW directly from Tidal (e.g. via MIDI) rather than re-sampling? And if you have tried that then why do you prefer to re-sample? The fidelity of the sound isn't super-central to my technique, and sound design isn't really my strong suit anyway, but I'm interested in your thoughts on this since it seems like something very important to you, and it's something I don't know a lot about. I don't tend to use VSTs but I do use a lot of hardware controlled by MIDI from Tidal, which I enjoy a lot (particularly controlling parameters via Tidal also, it opens up a lot of possibilities for synchronising the sounds). I'm always interested to hear more about people's approaches to sound design since I think sometimes we focus too much on code and not on the sound (...which is really what it's all about!)

YES! I also like the drama of the blank screen :stuck_out_tongue:

My sets are the same, I mostly stick to the sampling stuff and limited syntax, I really love using the splice command the most! Chopping a sample and then reorganizing it on the fly is something you can't do on a turntable, and chopping samples is a painstaking process even in the DAW and Tidal just does it so instantaneously with results that typically blow me away every time.

I think I could pull off a dramatic change in structure on the fly, like leading from an A section to a B section, in a reasonable amount of time now that I have a solid understanding of how to use "Do" blocks and the Clutch function (or command? idk what you call it) with a piece I've performed before but writing a piece from scratch in front of an audience and trying to do that would take me forever.

I really appreciate the tone of your post though, in terms of the opposition to the two approaches. I think they're both totally valid. I think of it like any other form of music really, and improvisation is something really vital to a performance. No one expects other musicians to write entirely new pieces from scratch in front of an audience and it seems like a lot of pressure to put on yourself imo. Although, now that I say that maybe there needs to be a distinction between writing on-the-fly and composing/producing on-the-fly?

I did look into controlling them from Tidal or SC. I use Serum for pretty much everything. Sometimes I work with FM8 and I like to generate wavetable samples from VCV Rack to plug into Serum. I know it's possible but I wonder how stable that is in a live context, especially with an intense instrument like Serum? Serum is very well optimized but I worry about loading up like 10 or more instances of it live. I could be wrong though.

What I really want is a Serum-like instrument in SC that can be controlled by Tidal. I imagine setting up lines of code like

d1 $ note $ "c2 d2@ as1" # s "TidalSerum" # WTPosA 4-8 # OSCAVoice 6 # OSCBVoice 3 # WTPOSB 22-42 

And maybe with additional commands at the end to control how fast the WaveTable Position on an oscillator transitions between wavetables. It might be tricky if you try to add in custom envelopes or LFO's to shape the way the wavetable position changes in SC but you could definitely do something similar without as many bells and whistles to start off with. I was working on a synthdef that would do all of that. I think it would be fun to design a patch on-the-fly or just modulate one you already made in that kind of format. I also think that it would be wicked fun to compose from Tidal with an instrument like that. I'm not a big fan of the instruments that are out there right now.

The biggest issue I ran into was the OSC Ugen in SuperCollider. I was building this wavetable synth in SC to use in Tidal, and got help on the SC forums. I had managed to load a wav file onto the server and convert it into a wavetable and loaded that into an oscillator and even got the whole thing to perform via Tidal. My biggest issue was setting up the envelopes correctly and then dealing with clipping issues from the oscillator. They were all simple fixes and the community there even helped me make the code really efficient. At some point one of the devs there, or at least someone who had some developer knowledge about SC explained to me that the OSC Ugen doesn't oversample like Serum's oscillators do. So you won't get as hi-fidelity of a sound from your wavetables. I ended up doing research into it and figured out that you could make an Oscillator Ugen with a similar or maybe even better algorithm than Serum if you could use embedded Assembly instructions in a custom OSC Ugen. Serum's oscillator algorithm is derived from a formula that was actually published in some mathematical academic papers out of Europe over a decade ago. That formula was made more efficient for Serum's oscillators by a mathematician that wrote or co-wrote one of those papers. I need to hunt down the papers, I'm sure they exist in an academic journal on math somewhere. Even with the original, less efficient formula that was published long ago I'm sure you could improve upon it and build something amazing. That's all public knowledge too btw. The developer of Serum talked about it in an interview years ago that you can still find on YouTube. An oscillator like that would be something amazing to offer up to the live code community. I want to work on it, developing for SC is something I'm working on atm but it's slow going. I'm a novice when it comes to C++ and I'm having a hell of a time trying to set up a development environment to code and debug an SC plugin. There's a lot of moving parts involved and it's not super straightforward. I can set up a development environment easily for a VST3 framework inside Visual Studio and do the debugging right from Visual studio but setting up for SC is super confusing. People have pointed me towards the cookie cutter for SC plugins and stuff but for someone who likes using visual studio it's kind of confusing.

For me the oscillators are a big issue. I can hear the difference, even though I'm sure not everyone agrees. I also really like working with LFOs and it's a bit awkward setting those up on something like, let's say a low pass filter cutoff in SC. It can be done with the lin Ugen (I think that's what it's called) but it's tricky getting it dialed in the way you want. So if I had my wavetable synthdef and it's playing a low octave note for an entire bar I can set it to have a low pass filter that shifts the cutoff frequency over the course of a bar (roughly) using what is essentially an LFO but then to get the drive I want I'd have to probably add the compressor Ugen, a distortion Ugen, and another limiter Ugen and then use the distortion plugin in Tidal to get the wob wob sound I want. I mean, it's doable to some degree but I want to be able to just do all of that from within Tidal with a synth patch that has that all ready to be modulated, with default settings set to bypass or something.

Loading multiple wavetables into a single oscillator in SC is also doable but as far as a I know it is a bit cumbersome to do in a synthdef and to try and control the wavetable position from Tidal. But it's something I want to do. It's funny, discussing all of this and yeah, it would be simpler to just control the VST from Tidal, so why do it the way I'm describing? lol I don't have a solid answer for that right now lol

I also like multiband saturation. With the right algorithm you can make even a synth with a highly aliased and lifeless digital sound have the same "warmth" as an analog synth that costs thousands of dollars. I use fabfilter Saturn 2 for distortion but even on cleaner synth patches with just a subtle amount of warm tube distortion at varying levels across a few bands you can create what sounds like a super expensive moog machine. I think another project I;d like to work on some day is a multiband saturation/distortion plugin for SC that has multiple algorithms to emulate various forms of saturation and compression like tube amps, transformers, tape saturation etc that would work like an exciter as well. That would probably be a simpler project than the oscillator though.

Anyway I've dragged that out enough. And yeah I really appreciate what you had to say about preparing for a blank screen performance. I'll admit even with a prepared structure of code I still run through it a few times before a performance, modulating and changing things before resetting it back to how it was.

And I admit a lot of my own struggles with the code are probably due to my own limitations with it. I go to the forums a lot with questions and whenever I paste code examples there's always someone who suggests more efficient method. But yeah, thank you for your post and for the discussion. There's only one other person in my entire state that I know of who does live coding and I don't know how to get a hold of them lol so it's nice being able to discuss things with people!

3 Likes