Pd is not the end of history for the MAX language,
That's not what I mean, what I mean is that it's more worthwhile to fork Pd than to fork (or revive) jMax.
Well, i am not the right guy for that; i am the only guy in town that:
- Know deeply the jMax code.
- Have some (limited) time and the motivation to work on it.
So surely my personal contribution to the community can be on reviving jMax, and trying to fulfils its promises.
there is still a lot that can be done at the core level. jMax Phoenix is a kind of research project; for now, i am trying to make it usable; later, to provide strong reasons for using it, at least in some specific field or projects.
I think that some of those "core" features could become Pd externals (albeit rather unusual ones).
If jMax prove that some ideas are good, they may be translated in pd; i'll be happy to help, in this case.
But the pd core code base is do not offer a lot of help for core extensions; and as core extensions i mean for example a different DSP compiler, a different DSP execution engine, an extended object model.
The core code base offer little or no abstraction, direct access to data structure elements and so on; as i said, i emulate a part of the pd API on jMax, to allow porting of pd objects, but it is very* difficult to retrofit pd externals with for example an extended object model.
So, there are limits in what you can do. jMax, at least at the source level, make things a lot easier for a developer that want to hack the code base, there are less dependencies between the different parts, and more abstraction in the API (that is more verbose as a consequence).
And the fact there is no stable community of users (yet ?) reduce the fear of catastrophes :->
Maurizio