JAudioLibs AudioServers – a PortAudio-esque Java API

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 & JACK

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).

Continue reading

Packaging as a .deb

If you’ve been following this blog or the Praxis code site for the last couple of months, you might be forgiven for thinking that not a lot had been happening. Actually that’s far from the case. I’ve been busy with a number of projects, one of which has seen some major additions to the Praxis code, and I’m now in the process of tidying that up for a new release. Some of the audio code has also been extracted and pushed to a separate repository (https://github.com/jaudiolibs/) of which more soon … but I digress. One thing that changed with the last Praxis LIVE release is that by default the Linux download is a .deb (Debian binary package) file, and I’ve been meaning to write up a how-to (for my benefit as much as yours!) since. So, here goes. Continue reading

Dabbling with the dark arts again

Well, the subject of dark themes seems to have come up again in the NetBeans world recently, with Geertjan blogging about Stan Aubrecht’s dark theme for Nimbus.  This looks great, though as you might have gathered from the look and feel of Praxis LIVE, I quite like dark look and feels! :-)

Unfortunately, the problem with Nimbus is it’s still not officially supported in NetBeans due to some EDT issues (though seems much more stable than the last time I tried it).  Also, to quote from Geertjan’s blog, “In Stan’s words, this is a “poor man’s” solution. There are some area that would need more tweaking, e.g., the top bar in the Options window. But it would mean changing code in NetBeans. This new module just adjust a few UIManager constants.”  Well, as I blogged about in the Dark arts of NetBeans hackery, it is possible with some devious hackery to alter things like the top bar of the Options window, and this is done in Praxis LIVE, so I thought I’d have a go at providing a plugin for this look and feel that could be used within the NetBeans IDE (or other platform application).

NetBeans IDE running with Praxis LIVE look & feel

NetBeans IDE running with Praxis LIVE look & feel

Continue reading

The Influence of the Actor Model (Praxis architecture 101)

No, not a post about my salacious exploits with a C-list Hollywood celebrity (that’s for a different blog :-) ), but a technical overview of a key aspect of the Praxis architecture. Absolutely essential to Praxis’ media neutral architecture, as well as the ability to edit everything live, is an asynchronous, shared-nothing, message-passing system. This is loosely inspired by the Actor Model and other solutions for concurrent / distributed programming (without following any particular concept to the letter). Continue reading

Praxis LIVE build:120123

A short note that a new build, and first full release, of Praxis LIVE is now available for download from http://code.google.com/p/praxis/

This is a slightly late post as I was concentrating on getting it finished and uploaded prior to flying to Toronto on Wednesday. There’s a wide range of new features, including a live GUI editor, a MIDI control editor, and component editors. The project system, save support and hub management have been revisited to make them much more robust. Many components have been refactored to ensure a more consistent naming and ordering of controls and ports. And the UI has had a bit of spit and polish, with a consistent icon style and colour scheme throughout – it’s looking sexy now! :-)

Read the full release notes.

The image above shows one of the major additions to this release, the GUI editor. Praxis uses MigLayout and the edit overlay allows you to drag components from the palette into a running control panel, and move them around using the arrow keys. Component properties are accessible by double-clicking to open the component editor dialogs (or in the properties window). Drag and drop of existing components, and a UI for other layout features is coming soon.  And I’ll blog a bit more about the implementation as it develops.

NB. Some of the architectural changes mean that projects from EA builds may not be fully compatible.  The examples have all been updated.  It is intended to keep backwards compatibility from this release onwards.

So, it’s a full release – is it beta?

No, though it’s better! :-D  Simply put, a couple of blog posts I’ve read over the last month or so have convinced me that the whole alpha, beta, whatever cycle is just not right for a project like Praxis / Praxis LIVE that is continually evolving.  Different features are at a different stage of evolution – some are what I’d consider release quality, some are beta, and some are quite definitely temperamental, anti-social, and marked as such!  The important thing is that it’s usable, the basic architecture is complete, and the framework (Praxis) and visual editor (Praxis LIVE) are now in sync and developing concurrently.  So, from now on there will be frequent incremental releases on a 4-6 week timetable.

So, what’s next?

Lot’s more components (some of which are already in testing), improved OpenGL support (which didn’t make this release, sorry), and much better documentation (I have a project where I have to teach 2 people to use Praxis LIVE this next month, so that will help!).

And some blogging about the details; the fun (and occasional hair pulling) of Java audio / video; and the joys of hacking on top of the NetBeans platform, without which none of this would have been possible.

JNA 3.4.0 on the NetBeans Platform

This is a little problem that’s been bugging me for a while – how to use a newer version of JNA (Java Native Access) with a NetBeans platform application.  The recently released JNA 3.4.0 brings some major performance improvements for callbacks, and as this improvement was requested by me (particularly for JNAJack) I’m damn well going to use it! :-)

UPDATE 21/6/12 – after reading this be sure to read JNA 3.4.x on the NetBeans Platform (revisited) which covers in more detail some of the questions in the comments here.

So, what’s the problem?


  • JNA is in the platform, but it’s an old version.
  • A number of platform modules require JNA.
  • JNA includes a native library, which precludes having multiple versions of JNA in the module system.
  • JNA in the platform only allows friend dependencies (don’t get me started on the annoyance of friend dependencies on modules that provide native libs!)

And, the solution -

  • Create a new library wrapper module for JNA 3.4.0. Give the wrapper module the same code name base as the core JNA module – org.netbeans.libs.jna
  • Give the new wrapper module the same major release version as the platform JNA (1), and a specification version higher than the platform JNA (I chose 3.4.0 as the logical choice)
  • Make sure JNA is enabled in the platform. This confused me for a while, but the excluded modules list has no sense of clusters, so if you exclude JNA from the platform, your new module will also be excluded!  (that would probably make a good RFE)
  • Make sure you’ve got a module in your application that has a dependency on the new JNA module (ie. depends on version 3.4.0).  Not sure how necessary this is, but it seems to ensure the right module is loaded, and you’ll need the dependency to rely on the new features anyway.

Run your application and look at the module list in the log.  You should see the new version of JNA being loaded.

So, are we done?

Well, not quite.  This allows us to run our application from the IDE with the new JNA module.  However, if you build a zip distribution you’ll notice that the old JNA module is still in the platform folder.  It shouldn’t cause a problem, but it takes up space and for safety’s sake it would be better to get rid of it.

To do that, I copied the build-zip target from the build harness into the build.xml file of my application, and made a few changes (see comment).

<target name="build-zip" depends="build,build-launchers" description="Builds a ZIP distribution of the suite, launchers, and selected modules from the platform.">
  <mkdir dir="${dist.dir}"/>
  <!-- pathfileset does not support 'prefix' and 'filemode' parameters,
       we have to copy them to temp location -->
  <tempfile property="temp.dir.nbexec" destdir="${suite.build.dir}" deleteonexit="true" prefix="nbexec"/>
  <tempfile property="temp.dir.rest" destdir="${suite.build.dir}" deleteonexit="delete" prefix="rest"/>
  <subant genericantfile="${harness.dir}/suite.xml" target="copy-cluster" inheritrefs="true">
    <property name="dest.dir" value="${temp.dir.rest}"/>
    <property name="nbexec.dir" value="${temp.dir.nbexec}"/>
    <property name="build.dir" value="${suite.build.dir}"/>
    <resources refid="zip.platform.clusters"/>
  <zip destfile="${dist.dir}/${app.name}.zip">
    <zipfileset dir="${build.launcher.dir}/bin/" filemode="755" prefix="${app.name}/bin"/>
    <zipfileset dir="${build.launcher.dir}/etc/" prefix="${app.name}/etc"/>
    <zipfileset dir="${temp.dir.nbexec}" filemode="755" prefix="${app.name}"/>
    <zipfileset dir="${temp.dir.rest}" prefix="${app.name}">
      <exclude name="platform/**/org-netbeans-libs-jna*"/>
      <exclude name="platform/**/jna-3.2.7.jar"/>
      <exclude name="platform/**/*jnidispatch*"/>

    <!-- Yes, the doubled app.name is a bit ugly, but better than the alternative; cf. #66441: -->
    <zipfileset dir="${cluster}" prefix="${app.name}/${app.name}">
      <exclude name="config/Modules/*.xml_hidden"/>

In particular, notice the three exclude lines that match various artefacts of the JNA module and exclude them from the zip file (and therefore also from the installers).

This all seems to be working fine, and will be used in the (slightly late) first full release of Praxis, which is based on NetBeans platform 7.0.  It may require tweaking to work with other versions of the platform.