Live-Coding

  • Live-Coding Issues
  • connections to VPL of course, but not necessarily
  • levels of "liveness" from Steven Tanimoto:
    1. informative (e.g. flowchart as ancillary description)
    2. informative and significant (e.g. executable flowchart)
    3. informative, significant and responsive (e.g. edit-triggered updates)
    4. infromative, significant, responsive, and live (e.g. stream-driven updates)
    5. tactically predictive (adds programming via selection from running predicted behaviors)
    6. strategically predictive (adds inference of gross functionality)

    — A Perspective on the Evolution of Live Programming

Q2 2022

Natto recently gained multiplayer cursors, and it's fun to imagine collaboratively live-coding parts of your application, and then including them in the main codebase as an asset file (these canvases are just JSON files that could be easily included in a git repo). You can also imagine having a DEBUG flag which swaps parts of your application to be live-Natto-modifiable.

Examples of Tools Shaping the Outcomes
  • Live-Coding music is very often loop-based, because the tools to create live-coded music favour loops
    • generally loops in solo electronic music are what is often used both to construct more complicated music with just two pairs of hands, but also because most live-performance tools are loop-based
Future Of Coding
Live-Coding Issues
  • live-coding is great, but somehow hard to apply to "production systems", why?
    • anecdotally when working on "production systems" I rarely play with constants live by changing single numbers or colors - maybe only when polishing some UI, but even then it often feels like working at the wrong abstraction level
    • most of the time, I try different code paths, which often means toggling multiple lines on/off across multiple files; "wiggling" the structure, not a single value
      • this sometimes feels close to trying to have multiple git branches visible and editable at the same time
Solving Things Visually

There is really no boundary between the code and the world, and this allows for some wonderful workflows. For example, there is no boundary between programming and debugging - if something is acting weird, you can simply pause time, open the logic, and probe widgets and wires to see what state they're in. Tweak the logic on the fly and resume again. It's blissfully iterative and doesn't require you to learn any additional tools, e.g. a time-travel debugger or a Whitebox.

— I did Advent of Code on a PlayStation

  • again, this is not about "VPL" which is node-and-wire interface, but about a VPL which:
    • shows its state to you - the values flowing through the system
    • is "live" (as in Live-Coding) and allows you to prod at the values to see what happens
Working with the Material

Everyone who has written interactive software has experienced the same interplay. The programmer writes some code, runs it, and sees how it behaves and feels. The results are partially expected, partially surprising, and they feed into the next cycle of design. The ability to shape and reshape software requires a capacity for rapid prototyping - for turning an unarticulated idea into a working prototype quickly enough to be able to change it, to listen to it, even to throw it out and to go on to another. In this activity, the nature of the programming language and environment can make a large difference - perhaps as large as the difference between modeling in clay and sculpting in stone.

— Bringing Design To Software - Terry Winograd

  • interestingly Winograd points out here that some languages/environments are better at "changing" and "listening" to the prototypes - my bet would be that Live-Coding makes it easier to have tighter feedback loops, but there's probably more to unpack here!
Live Coding Livebook

I collaborated with José on a set of research prototypes that show a direction towards expanding Livebook with additional live-coding concepts: probing, tracing, and live test feedback.

Liveboard

In 2019 I got a chance to teach a couple of live-coding workshops using Liveboard. Environments with immediate feedback make a great teaching tools, and we also managed to spend some of the time actually playing around and making music.

Learning Haskell part 2

October was all about exploring different creative-coding-related uses of Haskell: famous live-coding environment — Tidal, and (a bit less) famous graphics library — Diagrams.

Tidal is a live-coding environment for creating live music. It's mostly sample-based, using SuperDirt as a backend (which itself is SuperCollider addon).