Papers at upcomming conferences

Yesterday we were notified that a paper on Jamoma was accepted for ICMC 2008. We will also have a paper on the OSC namespace used for Jamoma presented at NIME 2008.

In addition there will be a panel session at ICMC entitled "Towards an interchange format for spatial audio scenes" set up by Gary Kendall, Nils Peters and Matthias Geier. SpatDIF - Spatial Sound Description Interchange Format, proposed by Nils Peters, has been developed in close relation to Jamoma development, with Jamoma being the primary test platform for implementation.

Jamoma 0.4.6

Jamoma 0.4.6. was uploaded a few days ago. It's mainly a maintenance release, and offers quite a few bug fixes as compared to 0.4.5.

Change log can be found here.

This might be the last Max 4.6 compatible release of Jamoma. Current development is now geared towards providing Max 5 compatibility, and we hope to have that ready sometime the comming summer.

Workshop in Brussels: Refining the OSC namespace

This week we are having a Jamoma developer conference in Brussels, generously hosted by IMAL. Alexander (1, 2, 3) has been writing some blog posts on ongoing discussions and work.

Today we have been discussing and reviewing the OSC namespace. As the functionalities implemented in parameters are growing more complex, it is an ongoing process reviewing and structuring the resulting OSC namespace. It is not only a question of moving towards syntax specific to Jamoma, but also trying to understand the underlying mechanisms and problems that maker us move in the directions we do. By searching for more general underlying principles we might be able to make more informed choices for Jamoma, but the discussions can also be presented and reviewed in a more general context, and we are currently considering writing a paper for e.g. NIME on the topic.

The discussions seems to be suggesting a partly standardization or organization of OSC namespaces, approached through the specific problems, issues and needs we run into along the way. Currently there are at least three areas of work that hint in this direction: (1) The tree-like structuring that is typically in the form of /computer/module/parameter, (2) the introduction of classes inside modules, such as the /limiter, /saturation and /record classes in the jmod.output~ module, and (3) the namespace for accessing the attributes of each parameter.

The following OSC message has served as a "worst case" scenario for the discussion:
/degrade~.1/audio/channel.left/gain:ramp/drive/parameter.get

Having discussed different ways of designing a message like this one, we seem to have agreed that the meaning of the different separating signs used need to be precisely defined:

• . (dot): Used to indicate instances of a specific class.
• / (slash): Used to indicate branching according to the OSC specification.
• : (colon): Colon is used to split the total OSC message into two parts. The first part is describing where you want to go. The second part describe what you want to access there.

The separation is a result of the functionalities implemented as part of jcom.parameter and jcom.message (ramping, clipping, unit conversion, etc.). These functionalities are commonly available to all parameters. While the part before the colon describe what parameter to access, the section after the colon provides access to the various functionalities available for each parameter, and represents a standardized namespace. Dave introduced the analogy to how URLs are generally designed. The first part of the url (www.jamoma.org) describes what server to access, while the next part (/wiki/workshops) describes what to access on the server.

Below is an attempt at structuring the namespace inside the paramers. This is very much a work in progress.

OpenAL

OpenAL is a cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications.

The library models a collection of audio sources moving in a 3D space that are heard by a single listener somewhere in that space. The basic OpenAL objects are a Listener, a Source, and a Buffer. There can be a large number of Buffers, which contain audio data. Each buffer can be attached to one or more Sources, which represent points in 3D space which are emitting audio. There is always one Listener object (per audio context), which represents the position where the sources are heard -- rendering is done from the perspective of the Listener.