Jamoma Workshops

We rounded up the “Jamoma week” with a workshop for a small crowd of power Max users at Ars Longa in Paris today. This time I think we were more successful in explaining that Jamoma is not just a set of ready made patches, it is really mostly about creating a systematic approach to Mac patching, in addition to improving communication in and between Max and similar environments.

The week in Albi was to a great extent spent fixing bugs in the Jamoma 0.4 release. This was rounded up in a 0.4.1 release last night (as reported by Tim). We are continuing to find and fix new bugs, so there will probably be a 0.4.2 in not too long.

All in all, I think we have managed to build up a great momentum in development and I am very optimistic about the future for Jamoma.

jamoma_paris1.jpg jamoma_paris2.jpg

GUI and control

The idea behind the current implementation of Jamoma is based on separating GUI from algorithm. Currently this is solved by having the algorithm in a separate file which is included in the module file containing the GUI. This is better than having everything in one patch, but I don’t think that we could say that the GUI is separated enough from the algorithm.

We have discussed this a bit over the last couple of days, and I have been trying to think about various ways of dealing with this problem. Conceptually, I think it would be interesting to have the possibility to have multiple GUIs to one algorithm:

gui_algorithm1.jpg

This would make it possible to sometimes have a full-fledged GUI with access to everything, while other times just have some basic features. Similarly, I think it would be interesting to also have only one GUI that could could serve several different algorithms:

gui_algorithm2.jpg

This could be practical when having multiple algorithms (e.g. reverb) that might have the same technical and/or perceptual features, since it allows for swapping the algorithm without having to do any remapping in the system.

If we succeed in creating a real separation between GUI and algorithm, it is also possible to have any number of GUIs and algorithms that could be mixed:

gui_algorithm3.jpg

The biggest challenge, I think, is to create a set of namespaces that allow for this type of functionality.

Technical Parameters

I have been thinking a lot about GUIs, namespaces and control parameters over the last couple of days. One of the big challenges we are facing is how to make technology more human-friendly. Often it seems that technology controls us more than we control the technology.

Creating a user interface of any kind is very similar how we think about mapping in musical instruments. In essence, any type of control is one, or several, layers of mapping between one set of parameters to another. The problem is that the we tend to create interfaces with one-to-one mappings to the algorithms. This makes the GUI directly in control of the technical parameters, but it might be totally irrelevant from a perceptual point of view.

A good example of this can be found in some of the Jamoma modules I have made for the Musical Gestures Toolbox. There I have implemented the possibility to control two of the values by just mouse-clicking and dragging in the small video window in the module. Of course, there is also the possibility to actually change the values directly in the number boxes. What I have found is that I never use the number boxes to control these features, I always just drag in the window instead. I find this so much more intuitive. The question is whether the numbers have to be there at all, couldn’t they just be hidden somewhere inside for the computer to use?

mouse-dragging.png

If we want to make technology for people, we need to start thinking from the perspective of the person and not the computer. Less is more…