jMax Phoenix is the new instantiation of the jMax projet. jMax is a system of the Max family, like notably Max/Msp and Puredata. It was developped in IRCAM at the end of the 90s, and was restarted in 2008 by a part of the original developers team, as a community and independent projet. It was initially presented to the community at the LAC 2009 conference; since then the development continue, with the ambition to become in the next year the most innovative project in this area.
Latest news on the jMax development.
The main goal of the jMax Phoenix project was to keep alive the work the original jMax team did in the 90s. It was refreshed with more modern technologies, like XML for configurations, or the integration with portaudio/portmidi and Ladspa plugins under Linux. From this point of view the project was successful. The web site have around 600 unique visitor a month, and the last version was downloaded 350 times; enough to say that the work i have done up to know was not wasted.
At this point, the real question is where to go from now; different directions are possible, from using jMax as a research environment to try out new techniques (just in time compilation is for example very promising for DSP and control computation), to extend and finalize the features oriented to industrialize the patch development; multi-core is still an unfulfilled promise, and i got event the suggestion to dig Java and rewrite a more efficient user interface in a native toolkit.
The problem is, all this cost time and human resources; and the big problem today is that i am alone in development (and potentially busy in other projects), and i have no feedback from the people reading the web site and downloading the latest version; without feedback from potential users, i have no way to choose the most interesting direction; without collaboration from potential users and potential developers, i do not have the time to implements the most interesting ones, like switching to a JIT based architecture.
Unless i receive some meaningful feedback and possibly contributions, i will be forced to stick to plain maintenance for jMax Phoenix, for the time being.
So, if you are vaguely interested in jMax Phoenix future, it is the time to speak up; write me at email@example.com or join the jMax mailing list on sourceforge and speak up.
PS: feel free to forward this text in the contexts you feel appropriate.
I just upload to the sourceforge project site the binaries for jMax Phoenix 0.7.
This release include the recent work on restructuring the DSP engine, and provide the results of some optimization work; the performance increase is (on my core i7 sandy bridge) of around 3 times for Mac OS X and 2 times under Linux, for patches that has a typical mix of simple and complex DSP objects; simple DSP objects run around 4 time faster than before. (also, if you used the 0.6.2 distribution, performance increase is more in the 10x range, because it was compiled using the wrong flags).
Most of the performance increase come, on Mac OS X, for using the clang vector extensions, and for Linux, from using the latest compiler with the right flags.
The Linux distribution include the usability fix included in the last Mac OS distribution.
A couple of incompatible changes: the ISPW like switch~ object has been dropped, because its semantic prevented any changes in the DSP engine (the ISPW switch~ was different than the pd switch~). New forms of conditional execution may be provided later.
On Mac OS X, the personal preference file moved to the
and the caches to
Well, considering the strong impact i got by introducing the GCC/LLVM vector extensions in the basic operator code, i played around a bit with the implementation of some other objects; i used the examples i have running, and profiling to identify the functions taking the bigger slices of CPU time, and i tried to optimize them using the vector extensions.
Results, the good old CDG demo patch run today at 29 Mega sample per seconds (on my development machine, a macbook pro 13” 2011, 2.7 Ghz i7 processor, latest clang compiler), against the 14 Mega sample per second it gave one week ago.
Well, this point clearly on the generalisation of vector extensions, at least for the simplest dsp function; so, slight change in my roadmap, this optimization work will go on a little before releasing a new version. I'll introduce vector optimizations in the vector library and in simple objects. It is not always a win; for reasons probably related to the CPU architecture, some code is even slower using vectors, notably the oscillator code. By the way, the oscillator code is a lemon; it did a number of bit mangling on floats that may be were justified with CPU architecture of 15 years ago, but today is the slower object around; anybody have a nice open source table based oscillator implementation :→ ?
I am getting the first interesting results on the DSP, so may be it is the time to share .
The main goal of this work is to gain performance for patches using a mix of complex objects and basic operators (+, *, etc) by optimizing the execution of the common operator parts, and to simplify object writing by moving optimizations from the objects, where they are now, to the engine itself, so that they are shared by all the objects generating basic DSP operators.
The work essentially consisted in two points: re-implement the intermediate FTL representation using an object oriented approach (actually done in Objective C) and re-implements the DSP execution engine to use a more “virtual machine” approach.
The new execution virtual machine have a larger instruction set: the original execution machine just did function calls thru a pointer, like the old ISPW implementation and like (AFAIK) pure data does. The new one add a number of opcodes for builtin vector and scalar-vector operations. The objective is twofold: first, to centralize the basic operator implementation, to share all the optimizations and reduce duplications; second, to have declarative knowledge on the operations to be able to apply semantic based optimizations. In itself, without optimizations applied, the new engine run marginally faster than the original one, probably because a number of function calls are avoided; but see below.
The new intermediate representation allows for some analysis and optimizations at this level: in particular, things that where done before in the jMax objects themselves, like taking care of anti-aliasing constraints, and optimizing between three and two arguments functions are now done at the intermediate representation level, so they are shared between objects; more optimizations will be implemented using the knowledge available here (more later, if it works :).
The new implementation allows to shift basic vector arithmetic objects (like +~, *~ and -~) to the use of the gcc vector extensions; this fact alone brought, on some test/demo patches with a 'typical' mix of basic and complex objects, an improvement in speed around 30% (in terms of samples per seconds computed by a free running, unsynchronized, patch).
More over, a rapid profiling of the running code shows how the execution time of basic operators (+~, -~, *~) dropped dramatically from around 35-40% of the total time to a mere 8-12%. (i am testing on a Sandy Bridge i7). Apparently, moving to vector types (using the gcc/llvm vector extension) dramatically reduce the load/store time.
This also shows that at this stage is pretty useless to invest too much time in optimizations of the basic operators (like compressing a *~ and a +~ to a multiply add) because this may only produce a few percent of improvement.
My current roadmap is to release a version including the DSP work i have done (after some testing, of course), and to start working on the second phase of the new DSP engine work: transforming the current intermediate representation from a linear form to a graph form, and to all the actual compilation with this representation, suppressing the old dsp compiler code, and introducing source level optimisations (including dead code elimination, constant propagation, and possibly composed operation generation). This new structure will allows to start working on multi-type and multi-rate DSP graphs, and later on multi-threading.
I started the actual work on DSP code. It is something i wanted to do for almost 15 years (no, really !), but it was somehow blocked by the need to keep compatibility with the old ISPW patches; in particular the ISPW switch~ object semantic depends on the algorithm the DSP subsystem use to schedule the dsp function calls; if the ordering of the function calls change, the switch object would not work anymore. So, it was impossible to change and improve the DSP compiler.
So, first thing, the old switch~ object is gone.
Second, i am moving the intermediate representation of the DSP program, called FTL, from a almost textual, linear representation to an object based representation; the first implementation will be equivalent in role and semantic to the current FTL (and quickly done), but later i'll move to this intermediate representation all the major dsp compiler function, scheduling and buffer allocation, and i'll add a few one (essentially, support for optimization rules based on graph transformation, and later multi type and generic operations). This work is also needed before any serious work can be done on multi threaded DSP execution.
In parallel, and thanks to the more flexible intermediate representation, i am working on the execution engine itself, playing around with some ideas that may improve DSP execution; i'll post more information later, once and if i get the first positive results.
Revision 302 has been uploaded: this version fix a few graphic bugs, notably the editing and resizing of multiline objects that was completely broken. This will finally allows to edit comments and message boxes.
The MacOSX build and the 32 bit Linux binary has been uploaded, but the 64 bit Linux version requires a few days more (i do not have a 64 bit VM handy).
I just uploaded to the jMax Phoenix sourceforge page the version 0.6.1 beta for Mac OS X. Other than fixing a couple of bugs, this version is delivered as a Mac OS X application bundle within a dmg disk image. You can just grab the application where you want and run it with a double click.
Against all evidence, the project is still alive. I have been busy with an other project, and slowly coming back to jMax, to implement the promised Mac OS X bundle version of jMax Phoenix.
In the meanwhile, i worked on some experimental work that i'll soon describe and commit; essentially exploring some different ways of doing a Max like system; one test is based on a limited model that allows to compile a control patch directly to C, with speed improvements of more than one order of magnitude; the other explore the opposite extreme: how to map MAX objects to Objective-C objects, so to use directly the language features to implements the MAX language instead of having a complex and heavy run time library. It turns out that is possible, that it would allows to use *any* Objective-C type as messages, it would provide for free a number of language features like persistency for example, and it would even allows to keep a reasonable performance, thanks to some of the Objective-C optimisation mechanisms.
If you wonder why Objective-C and not C++, it is because Objective-C have some dynamic mechanisms that map pretty well to Max. I'll soon post some example.
By the way, yes, this wiki is periodically hacked, i have been to busy to fix it, but i'll soon do what is requested to stop the hacking.
New snapshot have been uploaded to the sourceforge site for Linux 32/64 bit and MacOSX, fixing a problem in the handling of connection errors. An update is recommended !!!!.
An ongoing discussions on the pd mailing list highlight the fact that the introduction of expressions in jMax was done by making simple things very complex to do; the syntax vwas (is) very powerfull and complex, but it stay complex when you want to write simple things; in some way, the paradigm is broken. Moreover, it was buggy: something that was possible to do before wasnèt possible anymore, like for example passing an symbol operator to an object.
The funny part is that for jMax Phoenix it is quite easy to modify the syntax; there is no stable user base, we are still in a beta and debugging phase, and the code implementing the syntax is quite simple and small (a few hundreds lines of code). Moreover, *i* wrote that code.
I think that expression are something valuable, expecially in the framework of preparing libraries to be used by third party; but the syntax complexity introduced should be optional, and shouldn't appear if the power of expression is not needed.
So, the point is which syntax to use; personally, i think the best solution is to introduce a explicit syntax for introducing expressions, and reintroduce the $n notation for accessing arguments.
int 10would be ok
int $1would refer to the first argument
int $foowould be ok, in a context where foo is bound to an integer
int $(10 + $1)would add 10 to the first argument.
Sure, the last case use a more complex syntax, but is a syntax that is used only when the relative power is needed, and it is not in the way otherwise.
Without the special syntax expression, only scalar values and $ values are accepted, the latter possibly concatenated with symbols; $0 should have the same semantic as in pd.
Well, anybody would like to comment, before i actually implement this ? Write at firstname.lastname@example.org, or join the jmax mailing list at the sourceforge project site.
As written before, the resources available for the projet at this point in time are quite limited.
There still a lot of things to do: improve the user interface, add a property editor for objects and an editor for the configuration files (not everybody want to write/edit XML by hand); complete the parser for Puredata patches, add the puredata object set; migrate to jMax Phoenix the objects and editors developped for jMax 3.x and 4.x, and so on.
All this would contribute to make jMax a more mature and functional solution for real projects.
But would this be enough to justify switching to jMax, when the currently used system are good enough ?
So, our current priority, once completed the Mac OS X Application Bundle, is to implement the innovations that can make jMax Phoenix unique, and require its use even in a early maturity stage; the objective for next year is to build a new DSP engine, focusing essentially on three points:
This effort will surely take a lot of time, but it will be implemented following an iterative cycle, leaving the system function in the intermediate state.
The design will be discussed in this page; comments and feedbacks are always welcome.
We are happy to announce that a binary distribution for Mac OS X of jMax Phoenix 0.6 beta is ready and uploaded to the project sourceforge site.
The distribution require MacOSX 10.6.4 and run in 64 bits; if you need a binary for an earlier version of the OS you'll need to compile yourself from the sourcetree. We surely do not support Tiger, and i am ready to help in trying to have it working on Leopard, but i do not have access to a Leopard machine.
The distribution format is still a gzipped tar; in a few weeks i hope to release a 0.6.1 version coming in the standard .app bundle format that simplify installation and give a better integration with the OS.
I focused the last couple of month in fixing bugs, and to do so i focused only on the Linux platform.
The result is that there is some work to do on the MacOSX side, especially regarding the new Objective-C code, include files and makefiles.
This means that jMax currently do not compile on MacOSX; i'll put the Linux version in maintenance-only mode and work on the MacOSX port; considering the interest for the MacOSX version (most of the visit to this site come from MacOSX machines, and i got 200 hundreds downloades for the latest MacOSX snapshot) I'll produce a 0.6 snapshot for MacOSX as soon as possible.
I'll later produce a 0.6.1 packaged as an application bundle later, trying to push a bit more the integration with the system, so this will make it more natural and more integrated in the Mac environment.
At the moment, i do not have the time to work on a Windows version; it should be easy to have jMax working on Windows *with cygwin*, but it would be a substantial amount of work to have it working natively on Windows; i do not have the time *and* the competence to do this, i am ready to support anybody that want to step in and take this task.
After many month of development, we are proud to announce the version 0.6 beta of jMax Phoenix.
The major highlights for this version are:
Full release notes are available in the release notes section of the site.
This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, Fedora 13 and Mandriva Spring 2010; check the installation instruction on this site for specific caveats for Debian and Fedora.
The Puredata compatibility sub-project has been *very* time consuming; in order to better manage my scarce time resources, i need some user feedback (and possibly help) to be able to evaluate the actual interest of pursuing this development direction.
A MacOSX version of the beta will follows in the next weeks.
I read a lot of interesting discussions on scoping on puredata, and in some thread it was said that jMax has scoping. So, what's the deal ?
I decided to write a page to clarify this point; also, in beta 0.6 (soo to come) a new mechanism has been added to simplify reusing the old object libraries (and the pd objects), similar to the $0. Check the release notes when ready :→.
I am a puredata external object developer, can i use my objects with jMax ? I am a puredata user, can i run my patches with jMax ? What can i do today, what will i be able to do tomorrow ?
To get some answers to the above and to similar questions, check this page.
I'll slowly add a couple of sections to this wiki: a section jMax for Puredata users, that highlight the major differences and similarities between the two system and point to the proper documentation, and a section jMax for Puredata object programmers, to help Puredata object programmers to understand the main differences and similarities between the APIs of the two systems.
Actually, more a symbolic milestone than a real, usable, result: the current committed code base is able to load simple puredata patches; just to let you know about the progress in development :→.
You can find older project new in this page .
To download the various releases, go to the project sourceforge site, at http://sourceforge.net/projects/jmax-phoenix/.
You'll find the release notes of the various snapshots and releases here.
This page contains some general information about jMax history and some discussion about its motivations and strategy.
The document is stored in this wiki, and include the following sections:
Help patches and tutorials are integrated in the distribution (look under the Help menu). The tutorials are actually the old MAX/ISPW tutorials and do not cover many of the jMax new features. They will be updated, hopefully.
To get help with jMax, you may:
There are currently two mailing list, developers and users; in this beta phase, you'll probably want to join both, or the developers one.
You can check out sources from the project SVN repository at sourceforge site, at http://sourceforge.net/projects/jmax-phoenix/.
The project is released under an LGPL license.
For any question, you can contact us at email@example.com.