Maurizio De Cecco professional site

As of today, we don’t know if jMax Phoenix will succeed in having a reasonable developer community. For this reason, the objectives in term of platform and portability are reduced, they may be revised later if resources are availables.

The target platform is Linux. Development is currently done on Xubuntu on amd64, and personally plan to shif to Studio 64.  The strategic objectives are to cover all the main Linux distributions, 32 and 64 bits.

Today jMax is pretty open in terms of I/O systems, but future evolutions will tie it more to jack and to callback audio systems. The basic compilation environment will be gcc, and no effort will be done to be compatible with other compilers. Future versions will be heavily based on Posix Threads.

For what regard other operating systems, only environments based on gcc/jack will be supported, if we find developers willing to help. So, MacOSX yes, Windows with some limitation.

Remember anyway that the graphic UI of jMax is written in Java, and portable to all environments supporting Java 6. The UI is even able to connect thru the network to the computational server, so you may image in the future the UI running on a Windows laptop with the computation done in a back end 8 cores Linux server.

We do not plan integration with Windows or MacOSX specific I/O subsystems or plugin standards, like ASIO or VST.

We do not plan directly supporting non-jack audio or Midi I/O on Linux. We do plan to integrate support to host LADSPA plugins as jMax objects.

Producing LADSPA plugin from  jMax patch is an interesting strategic direction, under the condition that we are able to compile a patch and produce an atomic object (to really use the plugin as an independent object that do not need the jMax UI, and for performance reasons).

Just a small note to let you know that a couple of old friends, Enzo Maggi and François Dechelle, joined the jMax Phoenix project. They were both in the Ircam jMax equipe, and François was the project leader.

I will follows a small number of basic principles in the future development of jMax, technical and strategical. I will ask all the contributor (if any ) to follow these principles too. The following are the first four.

1. If it isn’t broken, don’t fix it.

There are thousands of ways of doing things, and most of the time there is a least one that is better of the solution adopted in jMax. This is not a good reason to change the architecture, re-engineer the system, or change a part of it. Unless the fulfillment of an actual, real, requirement cannot be achieved as a consequence of a technical choice, this choice will not be changed.

1. Good enough is enough.

Same story. If a choice satisfy the requirement, we will not change it for the fun of it.

1. The intelligence is in the UI

The computational server (fts) must do what is it role to do, I.e. compute, and be the simplest and lighter possible. Configuration, higher level abstraction like packages and projects, aggregation and all high level functionalities must be implemented in Java in the UI, within the architectural limits of the system.

1. The UI is scripted

jMax is a system for power users. I assume that users that spent an year in developing a composition, a package, objects and so on can write also a few line in a scripting language.

More over, power users want the freedom to customize the system and change its behavior.

The jMax 2.45 UI already offer a set of scripting primitives that are not documented; in jMax Phoenix these primitives will be document and the role of scripting will be extended to allows customization of most or all of the user interface aspects.

1. The scripting language is jacl

Jacl (tcl for java) is a fine language. It actually had a nice success and it is currently used in mission critical environments to manage the WebSphere application servers. Yes, there are nicer languages.

See points 1 and 2.

Rumors of the jMax demise have been greately exaggerated. Free software never die, just sleep for some time. For jMax, it has been a long sleep, but I decided to wake it up.

As I describe elsewhere on this site, I was on of the original designer of jMax, and it was one of the project where I had the most fun. When I left Ircam, for various reasons, I left the project knowing that I did not not had the time to bring it to the technically excellency I was looking for, and to develop all the ideas I originally put in the design.

Have never though of going back in the past and fix some fundamental problem in your life ? Well, with free software, you can. OK, you cannot fix your life, but you can fix the code. I don’t write code anymore in my daily job, it was time to have some serious fun in a personal project.

The time is also correct: jMax was written for an high end high performance system; at least two processors were required to run it correctly, and a high computing power; it happens today that most of the PCs have at least two core, and plenty of computing power. Now jMax can easily run and be developed on any machine. The project was also very in advance of his time in its use of Java as a portable UI environment; at the time the performance of Java was not exactly optimal, and the swing UI toolkit just a first approximation of what we have today; also, no free implementation of Java were available, thing that reduced the interest of the free software community in jMax.

What were at that time the limits of jMax, are today his strength.It can use multiple processors, it use a very reach and powerful graphic environment, and have a architecture defined for the future.

Please not that the jMax Phoenix project is a fork of the original code base and cvs, taken around the time I left Ircam. For those who know the jMax history, jMax Phoenix will start from jMax 2.4.5. Later developments will be backported if judged interesting.

I’ll use this post to trace design and coding decisions for future reference.

If you are interested, take a look to the source forge project called jMax Phoenix; you can subscribe to one or both of the mailing lists there (users, developers), and get an idea of technical work going on from the archives. If you want to know more about all this, you can also contact me directly at maurio at dececco dot name.