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).
There are a variety of reasons why this feature has been added now, and why you might want to make use of it. Obviously, running a project across a network offers some exciting possibilities, but one of the prime motivations for adding this now is actually to do with the new editor infrastructure derived from the NetBeans IDE. Live code editing in v2 offers a massive improvement over v1, with full code completion and error highlighting. However, this comes at a bit of a price – the NetBeans infrastructure does tend to play havoc with real-time performance (eg. low-latency audio), most likely due to the amount of garbage collection it causes. Running audio in a separate process mitigates this effect.
There are plenty of other reasons to consider using distributed hubs too – maybe you want to
- run multiple video pipelines projecting from different machines, but controllable from a central point
- maybe you want to test GLSL code across multiple machines with different graphics cards
- maybe you’re working with TinkerForge and embedded hardware (i want a RED brick! 😉 ) but want to live develop the project from a desktop machine?
- or … the possibilities are, well, not endless, but many.
There are some caveats to be aware of too.
- Distributed hubs do not mean that pipelines themselves are split across machines – eg. you cannot run a single video processing pipeline across multiple machines. It should be possible to share audio between pipelines using the JACK backend and NetJack. A solution for sharing video frames will probably come later.
- Files are not currently resolved across the network, which means that any images, sound files, etc. need to be at the same absolute file location on all machines. This is obviously not an issue for local distributed hubs, but is across a network, and an answer to this problem is in the works for the next alpha release.
- GUI’s will run in a different process, however you won’t be able to edit them within Praxis LIVE – unlike the other editors, the GUI editor depends on having direct access.
Above is the network options panel available at Tools / Options / Core / Network. To start using the distributed hub, first tick the box to Enable networked Hub. The default configuration (not as pictured!) is to run all audio in a local slave. Changes in this panel will only be registered when the Hub is restarted! Slaves on localhost can automatically be started using the launcher location shown, which should be automatically found – if the slave launcher location is empty, file a bug.
You can add more slaves or alter slave configuration as required. The default host is localhost, but can be changed to any network address – obviously, Autostart will only work if the slave is local though. The default port is 13178, but can be changed as required. The ID Pattern and Type Pattern parameters take glob-like parameters, using * as a wildcard and | to split options – eg. to run all audio & video pipelines on the same slave use audio|video for the Type Pattern.
It is better to run video and audio in separate slaves. To do this, click Add and then alter the configuration parameters, eg.
- Host: localhost
- Port: 13179 (make sure each slave on a host is different!)
- ID Pattern: *
- Type Pattern: video
- Autostart: true
.. and restart the hub! Or, to run multiple video pipelines on different slaves, use multiple lines with the ID Pattern set as necessary (eg. video, camera, video2, etc.)
An important thing to note is that the configuration data is part of Praxis LIVE and not of any individual project. There is no change to projects themselves from making use of this function – you can disable the distributed hub support, re-start a project and it will all be running locally again.
It’s not possible to auto start slaves on another computer. Instead, you’ll need to run the praxis (note, not praxis_live) launcher manually.
# run the Praxis command line player as a slave # running on the default port (13178) # not very useful as it's only connectable from localhost # but locking the default userdir! praxis --slave # allow connections from the local network 192.168.1.xxx # (see CIDR) praxis --slave --network 192.168.1.0/24 # listen on an alternative port praxis --slave --port 28282 --network 192.1681.0/24 # run multiple local slaves with different userdir # this is how the autostart function works praxis --slave --port 13178 --userdir /tmp/slave1 praxis --slave --port 13179 --userdir /tmp/slave2
To convert for use on Windows, substitute praxis.exe and a suitable userdir location. It’s perfectly possible to run a hub across machines using different OS – eg. run Praxis LIVE on Windows to develop a project using an embedded Linux device.
Get it while it’s Hot!
So, how do you have a play with this new functionality – it’s in the latest alpha release, v2.0a3, download-able from www.praxislive.org Please share, please play, please test. Any questions, please ask away!