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.
2015 has been a major year for Praxis LIVE development, even though this blog has been a little bit quiet recently. Somehow my level of writing always seems to be inversely proportional to the level of activity and features being added to the software. Well, that’s my excuse why a 9-month gap between posts is a good thing, anyway! 😉
So, here’s a little review of some of the big things that have happened in the world of Praxis LIVE this last year …
So, you’ve got a String property that’s a fragment of Java code, and you want to open and edit it within the NetBeans editor; you want access to code completion, hints, and all that NetBeans goodness; and, you want your String property to update every time you hit Save. Well, that was the challenge facing me in integrating the NetBeans editor into Praxis LIVE for version 2.
core:math:add component with code open for editing.
So, after months of development (and not much blogging!), Praxis LIVE v2 is finally released into the world. And after some radical changes in its underlying architecture, Praxis LIVE is now getting much closer to my original vision of a hybrid visual IDE for creative coding.
Want to run a project across multiple computers on a local network? Want to code on one computer and have it inserted into a running pipeline on another? Want to run pipelines across multiple local processes (VMs) for better performance? The latest alpha release of Praxis LIVE v2 finally makes distributed hubs a reality (an idea that’s been around since the architecture was originally designed).
Live coding Java (Processing) & GLSL code on one laptop while it runs on another.
If you’ve been following the Twitter feed recently you may have noticed that Praxis LIVE has gained an all new look. However, the recent changes are far more than skin deep, with a radical rethink of many aspects of the project.
Praxis LIVE development (and blog posts, I know!) took a back-seat over the first half of this year as various other commitments took over. But in many respects, that time off has been good for the project, and initiated a rethink of how to continue developing and supporting Praxis LIVE into the future. A major part of that will be concentrating on those key aspects of the project that make it unique (media-neutral – distributed – edit everything live), and better use of existing third-party code even if it requires compromises to be made.
New annotation driven live-compiled components and code completion
The JAudioLibs’ AudioServer API is a Java library loosely inspired by PortAudio. It was initially designed early in the development of Praxis LIVE in order to provide a common callback-based interface for working with low-latency audio. This API has since found its way into a variety of other projects, primarily by people wanting to use the JACK Audio Connection Kit from Java (JAudioLibs’ JNAJack was developed at the same time). Using the AudioServer API provides an application the ability to switch easily between JavaSound and JACK at runtime. It can also make working just with JavaSound a little easier.
Praxis LIVE & Hydrogen linked through JACK
For some time I have been considering how to extend the AudioServer API to improve runtime service discovery, provide better access to features of the underlying audio libraries, and make it easier for people to contribute new implementations. A recent email from Ollie Bown, developer of the excellent Beads audio library, prompted me to spend some time over the last week trying to finish this work (the development version of Beads has been using this API for some time).