Given the fact that jMax slept a few years, it cannot compete with
puredata in terms of available libraries, patches, and in general
maturity of the solution.No, it wasn't in this order : first it already couldn't compete with
PureData, AND THEN jMax 4 appeared, which finished killing it, as
the API was all different and no-one bothered porting externals to
it (well, I tried, and I had to give up because some features had
been removed from jMax). By the time the project was called dead,
everybody had already switched to Pd or was in the process of doing
so.
Well, as i said, i left Ircam around the 2.x version, just before the public announce of the GPL version. I am not familiar with what happened after that, including the history of jMax 4, that i read on the WikiPedia :->.
I know anyway that it was kind of sleepy; while under a GPL license it was never a community project, because driven by the internal Ircam needs, and even that wasn't very clear.
For the record, jMax Phoenix support the jMax 2.x API, not the 4; the APIs are extended wrt 2.x, but in a backward compatible way.
- The language: jMax support the use of expressions in object
definition, like in | int ( 10 + $foo) | so that objects in
abstractions can be parametrised with respect to the arguments.I gave up jMax because this feature was introduced. This is because
it removed the possibility to pass an arithmetic operator as an
argument. It was a showstopper for me.
I would call it a bug (even fatal), no a showstopper; ok, a fatal bug *is* a showstopper if there is nobody able to fix it :->, or anybody there to listen to complaints, but now there is.
I agree for different reasons. This syntax does seem overly
complicated and takes away from one of the things I like best about
the Max paradigm: really simple syntax.
Well, i have two different answers: the first is, yes, the syntax is overly complex: $args[1] instead of $1 make an object description unreadeable. There is another point: the syntax was built to complement a different paradigm for sharing data between objects; this paradigm was never exploited by a reasonable object set, so we are left with a syntax that would be adequate for objects using the new paradigm, but it is very heavy for objects not using the paradigm.
For example, using the new paradigm there would be *no* need of something equivalent to the pd '$0-foo'; but since the new paradigm is not used by the object set, the $0 is still needed, but in the new syntax is a nightmare today (something like ( $__ + "foo" ) ), and just impossible at the time.
On the other side, the complex syntax allows to do things that simpler syntax do not allows; the point is that simple things should be simple to do, and complex things may require more complex syntax; the syntax design failed to do this, but there is still room for improvement, if anyway want to discuss the subject and help the poor designer :->.
Actually, the point of view taken by jMax is/was the following: the main customers where people, inside the organisation, spending one year or more designing a single library of abstractions for jMax. In this context, the ability to industrialise the development and having more expressive power to simplify these developments were essential. The goal was to make this abstractions easier to use, in terms of patch programming and in terms of logistic and infrastructure.
In the process, we probably throw away the baby with the bath water, wrt simplicity of the language. I know, i was the guy implemented all this, with Norber Schnell doing the specifications.
Now, all this is 10 years ago; i now works on jMax for fun, i am free to listen critics and to make the system evolve; i would be more than happy to discuss the subjects in more details (may be in private or elsewhere).
The point is not to be competetitive with pd, is more matter to see things going on, and produce new ideas and system that may have their role and use.
You too write "Max OS X" instead of "Mac OS X" ? Is this a virus you
caught from Miller ? ;)
Uh, so that is where it came from .. i was wondering :->
Maurizio De Cecco