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 …
Version 2 of Praxis LIVE brings in Processing as a core library, and adds a whole new OpenGL video pipeline with access to most of Processing’s features. Almost all of Praxis LIVE’s built-in components are now defined via the new live-code API, essentially as small sketches that can be defined and re-defined as your project is running. There are also a number of base components for creating completely custom components on-the-fly. Here we’ll explore how to use
video:gl:p3d to translate Processing’s TextureCylinder example into a Praxis LIVE component. You can see this in action in the Smoky 3D example.
Smoky 3D example running with cylinder code open for editing.
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).