A few weeks ago I had the joy of presenting a short paper on Praxis LIVE at the International Conference on Live Coding at McMaster University in Hamilton, Canada. While acting as an introduction to Praxis LIVE, the paper covered a few of the new features in v3 (finally released last week!).
One of the highlights of the conference for me was Andrew Sorensen’s keynote on The Art and Science of Livecoding. Andrew’s Extempore programming environment and his thoughts on cyber-physical programming have partly influenced recent developments in Praxis LIVE (I say “partly” because this was already the direction of flow! 🙂 ) As someone long interested in the interactions between arts, science and technology, it was great to see examples of these ideas in use in fields like physics and astronomy as well as audio and video.
The Extempore website describes cyber-physical programming as –
.. the notion of a human programmer operating as an active agent in a real-time distributed network of environmentally aware systems. The programmer interacts with the distributed real-time system procedurally by modifying code on-the-fly.
OK, but let’s break that down a bit! In a typical programming scenario there is a distinction between the development phase of the code and its execution. The developer might be able to make limited interactive changes to the software as it is developed, eg. through a REPL or debugger, but there is a stage where the code is “completed” and left to run. On the other hand, in a cyber-physical environment, this interaction with the code, the ability to evolve it as it runs, is supported and encouraged throughout its lifecycle.
I usually describe Praxis LIVE as a hybrid visual IDE for live creative coding, however in practice it is really an IDE and runtime – a runtime that ties into this concept of cyber-physical programming. Praxis LIVE’s runtime is based around a forest of actors, as described in a much earlier post – multiple dataflow / reactive graphs of actors running across multiple processes or machines. An embedded Java compiler means that the code, behaviour and configuration of those actors can be redefined at any point, on-the-fly, within a running system.
Another important aspect (in my mind) for a cyber-physical system is strong computational performance. What differentiates Praxis LIVE from other visual patchers with scripting language support, is what I call user code as a first class citizen (or sometimes Turtles all the way down), where the same language stack is used for both system and user code. In this way the user can work as high or low level as they want, even dropping down to livecoding per-sample digital audio (this is why Java has lambdas, yes?)
The JVM can be a somewhat controversial decision for a real-time system. Extempore’s xtlang makes use of LLVM to live compile high-performance code, but in doing so foregoes the safety of managed memory and automatic garbage collection – the high risk, high reward strategy! Personally, I think that the benefits of managed memory outweigh the costs for most uses of cyber-physical coding (but then I would say that).
Andrew kindly asked how Praxis LIVE dealt with issues of garbage collection after my own presentation! 🙂 My somewhat flippant answer was “don’t create garbage” … OK, I did explain a bit more than that afterwards. Praxis LIVE’s actor model environment, as well as allowing for lock-free communication makes it transparent to separate graphs into different processes (JVMs). This allows for tailoring the memory profile and garbage collector characteristics of individual graphs, such as audio, and keeps them separated from code that creates large amounts of garbage – looking at you NetBeans code completion!
A major improvement in v3 has been to rewrite the compilation infrastructure, another source of garbage. The bulk of the overhead of modifying code can now be handled outside of the process that the code will be used in, further improving real-time performance. In my experience of working with real-time code on the JVM for over 10 years, the garbage collector is not the only (or even biggest) concern however, with JIT compilation being another. Work is ongoing to further improve the compilation infrastructure, to automatically optimise bytecode before it hits the real-time graph.
More than media??
Most people reading this probably know Praxis LIVE as a tool for working with audio & video, as a tool for live-coding with Processing, maybe as a tool for live-coding your home automation with TinkerForge, or perhaps just as that weird IDE built on top of the NetBeans platform. But underneath all that is a fairly generic runtime for cyber-physical coding. Some work in v3 has been aimed at improving that generic nature, including the addition of a generic data graph type – so yes, if you’ve always wondered what it would be like to code a server in Praxis LIVE, or just want something more than Java 9’s REPL, then go have fun! 🙂
But more seriously, this generic side of cyber-physical coding is something that will feature more in Praxis LIVE’s development in the near future. The runtime can already be entirely separated and interacted with away from the NetBeans-based IDE. But the influence of that NetBeans-based module system remains in the decoupled and highly customizable nature of that underlying runtime.
So, if you think the natural home of cyber-physical coding is the JVM after all, come get involved and let’s make this happen!
If you’re interested you can read the paper presented at ICLC here!