Introduction to Jamoma modules

Jamoma modules

We could start these tutorials with a lengthy discussion on what Jamoma is all about. But it is probably better to introduce the concepts along the way in situations where we can play around with them and get a hands-on experience and understanding. So for now we will stick to a very simple description: Jamoma is a bunch of patches that can be loaded in other patches in a modular way.

In Max terminology patches wrapped so that they can behave as objects in other patches are sometimes called abstractions.

Prerequisites

This tutorial assume:

Building a Simple Patch Using Jamoma Modules

We will start out with a new patcher window, create two modules, connect them, and play around with them. In the process of doing so, we will introduce some fundamental concepts.

If you haven’t already, now is the time to start Max. If it running already, it might be an idea to close all open patches, in particular patches processing audio, and then open a new blank patcher window.

Instantiate Modules

In this tutorial we will use two simple audio modules, one providing audio input and the other one audio output.

As stated above, Jamoma modules are patches or abstractions, so they can be instantiated by typing the name of the module into a new object box. We will start of with jmod.input~, and give it the argument /myinput~.

As you can see we get an object with one input and three outputs. If we double-click it a nice little interface shows up:

none set

The interface seems handy to have available in the patcher itself, so we will delete the object and recreate it as a bpatcher instead:

none set

none set

none set

none set

As you can see Jamoma modules strive for a common look. Maybe you have noticed that behind the scene the bpatchers have been automagically resizing themselves to fit the size of the modules?

We could also have created these modules as well by using the Jamoma_Patcher template from the New from template item of the File menu… which can be easier for people not used to Max MSP. If you want to give it a try, the way to go is documented directly in the patch…

Give Your Modules a Name

In the examples above, we have provided an argument to the module (/myinput~ and /myoutput~ respectively). The argument gives the module a name. At the top menu bar of each module, you can see the name displayed with a slash prepended. Later on we will be able to address and control each of the modules based on the names we have given them. So, even though it will take a few more tutorials before it becomes apparent why it is useful, we strongly suggest that you right away get into the habit of naming your modules.

Connecting Modules

We now have one module that generate audio input to the patch, and another providing audio output from the patch. In order to start using the modules, we need to connect them. The way we do this might look strange at first:

none set

As you can see, we do not follow the MSP convention of the leftmost outlets and outlets being used for audio. Instead Jamoma introduce another convention.

In Jamoma modules the leftmost inlet and outlet is reserved for control messages to and from the module. All remaining inlets and outlets are used for passing signals in and out of the module.

Let’s play!

Now we have all that is required to start playing:

none set

The two modules we have created are useful as generic audio input and output modules. Below we will discuss the features of each of them a little further.

A More Detailed Discussion of the Two Modules

jmod.input~ – A Generic Audio Input Module

The input module enable you to quickly switch between some common input sources using the pop-up umenu:

Some additional useful features of the module should be mentioned:

jmod.output~ – A Generic Audio Output Module

The output module is doing some mastering of the signal before passing it out:

  1. First saturation is applied, softening and distorting peaks in the signal.
  2. Next the signal is passed through a limiter.
  3. Third DC offset in the signal is filtered out.
  4. The final gain level of the output signal is controlled.
  5. When audio is turned on and off, a soft fade-in and fade-out is applied.

In addition the mastered signal is forwarded to a sfrecord~ object so that the signal can be recorded on the fly. The mastering DSP chain has been inspired by how mastering of the output signal was done in the eminent but now discontinued radiaL looping application, mainly developed by jhno.

The file type and bit resolution of the recorded signal can be controlled from the module interface. When you hit the Record button a dialog window prompt you to provide file name for the recorded file. Once that is done, recording will start.

Also from the module user interface saturation and limiter can be enabled or disabled, and some of the settings of the respective processing algorithms can be controlled.

The Module Control Panel

In the toolbar of the module, in the upper right hand corner, there’s a tiny + button. Clicking this will bring up the module control panel, a window providing access to additional parameters. This feature can be found in several modules. If the module contain parameters that will be set on initialization, but are not expected to be changed continuously in performance, the parameters might be moved from the main interface of the module to the module control panel, so that the module takes up less screen estate in the completed performance patch.

Summary

Download

Here you can download the patch used for this tutorial (right-click and save).

What’s Next?

Now that we have audio input and output working, it is tempting to introduce some sound effect processing between the input and output module.

comments powered by Disqus