Various development work on Jamoma has been discussed on this blog in the past, be it with regards to Jade or Jamoma itself. Last week I mentioned that a preview download for 0.4 had posted to the Jamoma site (official release of 0.4 is still pending some testing and cleanup). I’ve mentioned this to a couple of folks personally, and they are curious what the big deal is all about. So I thought I would take a moment to summarize.

Jamoma is a framework for building modular Max patches. At the heart of this system is a set of objects that define parameters, handle communication, and do a variety of other ‘low-level’ tasks. These object comprise the Jamoma core. Prior to Jamoma 0.4 the core objects were implemented as abstractions (Max patches being used as objects). Now, all of these are implemented in C/C++ as Max externals.

This is important for a few reasons. One of the initial motivations is speed. There are improvements both in the operating speed, and in the time it takes to load a module in Max. It also includes an infrastructure that is easy for us to extend. One of the examples in the way that ramping of parameters and messages is implemented. The system is open ended so that additional modes may be added in the future (curves instead of lines, for example). Finally, the patches are clearer and require less ugly ‘glue’ patching. For example, the various core components no longer require the #0_ token to be given for every object.

Jamoma 0.4 also handles input and output from modules a bit differently. Instead of routing audio and video signals through the GUI, the GUI is now completely separate. This provides nice programming clarity and structure. It also provides a much more efficient muting and bypass implementation for audio modules, and especially for video modules. It also includes a feature for creating poly~ voices that are applied for each channel that is present, so modules can have flexible channel configurations instead of requiring separate dedicated modules for mono and stereo channel configurations, as an example. The input and output system will also allow future expansion of the system to occur so that modules can pass signals wirelessly — to and from a matrix mixer for example.

There is one downside to all of this new Jamoma goodness. Namely, we’ve broken backwards compatibility with version 0.3.×. The updates to modules made with 0.3.x to 0.4 should be very easy to do, but they will need to be done. About a year ago when we release 0.3, it introduced the OSC namespace and broke compatibility with 0.2.×. That’s why it is alpha-version software (not even beta yet). I am hopeful though, that we should not need to break compatibility like this again. I’m optimistic about that too, because the way we’ve created the new core is designed with the future in mind.

On a final note, I’ll just add that I’m really proud of what we have in Jamoma 0.4. This includes the software that we can now use, and reflects ideas I’ve been thinking about for the past 5 years. It also includes the amazing group of developers that have worked together to brainstorm, create, test, fix, and support Jamoma. I can’t imagine being part of a better group for a project like this.