22 comments

[ 3.0 ms ] story [ 60.1 ms ] thread
By the same author (David Griffiths), who is a creative genius and runs the FoAM Kernow studio with his partner Amber:

Pattern Matrix, tangible live coding interface w/ magnetic tokens and AR overlay: https://www.youtube.com/watch?v=pLpHBUmwGCk / https://penelope.hypotheses.org/2232

Viruscraft digital/tangible platform for exploring viruses: https://fo.am/activities/viruscraft/

Swarms of live coded robots doing maypole dancing (yes): https://penelope.hypotheses.org/1512

Scheme Bricks, 3D visual live coding in Scheme: http://davesblog.fo.am/?s=bricks / https://github.com/nebogeo/scheme-bricks

Al-Jazari: Minecraft meets Fluxus / Scheme Bricks https://www.youtube.com/watch?v=r8Mp6f65nWM / http://davesblog.fo.am/2013/02/al-jazari-2-minecraft-meets-f...

That project obviously has been dead for a long time, but its successor Extempore [0] seems to still be in somewhat active development. And btw. it runs on Linux, MacOS and Windows.

[0] https://extemporelang.github.io/

Impromptu was pretty nice as a scripting env for Core Graphics (I sued it as such at some point).

I also coordinated an effort to save it from being deleted from Wikipedia, along with Andrew Sorensen's "Study in Keith" video.

Andrew who's also the author of Impromptu and Extempore, had gifted the recording of a live coding performance to Wikipedia, under a CC license. Some editors wanted to have it removed because it was "personal research". Go figure... Sanity prevailed thankfully.

Edit: also, you should listen to "A study in Keith", it's a damn good piece. You can follow along as Andrew tweaks the grammar/Markov chains that make up the music, but it isn't necessary. The music starts at 1:56 (since the piece is written from scratch, there are a couple minutes of silent video while the author sets up the initial code).

https://upload.wikimedia.org/wikipedia/commons/c/c5/Study_in...

I didn't understand. Can anyone help me out? What is that?
Live coding is great for beginners to discover and enjoy that programming is writing that makes things happen.

I have had consistent success with design and communication students using LiveCodeLab [0] as the first step in our creative programming classes (ending with either Processing and Arduino or P5js/JavaScript)

First they get the magic of it, summoning a cube with just ‘box’, animating it, playing with colors, then they ask ‘can we use that for…’ and we can go to step 2

[0] https://livecodelab.net/

It mentions WebGL as one of its targets. Would it be possible to run Racket in the browser and have a fully browser-based live-coding environment?
It would have to be done carefully, but it doesn't strike me as strictly impossible.

The challenge for a live coding browser environment is proper partitioning of the environment running the editor from the environment running code under development. The JavaScript environment in the browser is not multithreaded, so if the code under development hangs forever (and thanks to the halting problem, you can't guarantee it won't), you'll have a bad time because you can't access your tools to stop the code or modify the behavior.

However, that doesn't mean it's impossible. There are multiple avenues I would suggest exploring that might ameliorate that problem (web workers, wasm, possibly iframes).

As for the question of running racket in the browser in general, there are options. https://cs.brown.edu/~sk/Publications/Papers/Published/yk-wh...

> The JavaScript environment in the browser is not multithreaded

Well, there's WebWorkers. They're a bit limited due to the whole message passing thing but still quite powerful.

Aside from that: could whomever downvoted the person above me explain what's misinformative about their comment?

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Cool! Take a look also at CEPL [0] an OpenGL environment for Common Lisp. Bit more low level, but you can have an OpenGL window open and make live changes in the code, just like anything else in Common Lisp. I can't imagine coding graphics any other way, and is a lot of fun that way too.

[0] https://github.com/cbaggers/cepl

So how does it work?

I imagine there are two concurrent threads: one receiving input from the programmer and another running the graphics and window event loop. How do these two communicate? I tried writing something similar as a teenager and the multithreading work quickly overwhelmed me. Perhaps there's a better approach?

I don't know about CEPL but when just using OpenGL you can simply redefine functions that are called in the main thread and they will execute there. You build up a lot of indirection to allow redefining things at run time.

It's also a good idea to write some macros to send the forms to the main thread when working with graphics libs.

This in clojure will eval the form once at the desired point in the program, it just queues up the forms and executes one every time it's called. The stuff below is racey but works.

  (def eval-points (atom {}))

  (defn eval-package
    [package]
    (binding [*ns* (:ns package)]
      (eval (:form package))))

  (defmacro eval-point
    [name]
    (swap! eval-points assoc name [])
    `(do (let [fs# (~name @eval-points)]
         (when (peek fs#)
           (eval-package (peek fs#))
           (swap! eval-points assoc ~name (pop fs#))))))

  (defmacro package-form
    [& form]
    `{:ns   ~*ns*
      :form '(do ~@form)})

  (defmacro eval-at
    [name & form]
    `(swap! eval-points
            assoc
            ~name
            (conj (~name @eval-points)
                  (package-form ~@form))))
So you would place (eval-point :foo) somewhere in the main loop so things like OpenGL calls are possible, then when evaling forms from the REPL you wrap them like:

(eval-at :foo (blah 0.3 0.3 0.3))

You can easily do the same in common lisp.

Sorry, don't know the internals or thread details (though you can browse the git of course), but it does work very well. Some key points:

1. As per CL error handling/continuations, if something goes wrong you are dropped into the debugger and can live fix the problem without losing the OpenGL context (usually, I've still found ways to break things of course, since you have some more manual memory management happening with the GPU). CEPL has a 'live continue' feature that handles this for OpenGL/threads.

2. Live changing of code as in usual CL REPL works well. If you want to change stuff on the GPU, like a texture or shader, you may need to repush it to the GPU depending how your main loop draws stuff. For instance, I'll just once set a shader, so if I want to change it I'll need to explicitly update it to the GPU.

Anyway, is all rather great, can't imagine doing this stuff manually like I used to back in the C days and before real GPU programming.

Trying to install this was the worst PITA since a very very long time.