I think people will naturally have a different take on this coming from the Max angle than from the Processing angle, as well. For Processing's part, I think a number of these problems are solvable within Processing and Java, so I'll put my money where my mouth is and as I'm doing more with it, see if I can't share the framework I'm building in a way it may be reusable to others.

The one big deficiency in Processing I see remains audio and signal processing, but there I think the most practical solution will be to continue finding ways to embed open source audio in Processing. That's not any philosophical statement about open source versus proprietary, either – it would mean that you could integrate it with the Processing build environment, which is a practical consideration.

Impressive that Max includes a JVM object, that had evaded me! I only thought it supported javascript, as opposed to full-on java.

That alone covers a great deal of ground; with exception of allowing the easy integration of generative visuals into the jitter workflow, which seems to be coming up as well!

A very good idea which hasn't yet been implemented would be to make it even more extensible, by embedding Processing into a freeframe plugin instead, which then in turn can be embedded in Max/MSP, or any other compatible host.

There was talk of embedding my Mother program into freeframe, but ultimately it turned out to be potentially too time consuming for me to be able to do it as a spare time project, the way I had developed Mother.

There's a great deal of cool visualist software out there, it's about time more than just control data is shared between systems!

You're certainly right about Max's language limitations. I had to use C to create a Max object in order to implement Euclid's algorithm which is recursive. (Which you can get here under the MIT license: http://github.com/Mattbot/mattbot.euclid)

Max includes a Java virtual machine object so it already has access to an external language more suited to things like recursion. Processing and Adam Murray's excellent [ajm.ruby] object are both built on top of Max's included JVM.

There is significant published work on the limitations of Dataflow languages in general (ie PD, Max, vvvv, etc). The two main problems this family of languages faces is that a programmer cannot define his/her own datastructures, and that there is no efficient way of implementing recursion. Both of the above happen to be crucial when programming procedural computer graphics, and are problems a declarative language (Processing) does not have.

The common solution adopted is to allow a programmer to write his/her own 'box' in a declarative language, implementing the problematic code. Max/MSP's way around the problem is allowing you to write javascript inside a box, but the speed of execution is so low, that it is unuseable for anything as demanding as real-time procedural graphics.

Integrating Processing into Max/MSP therefore not only allows more efficient procedural computer graphics in a dataflow language, but goes further, in that it helps address a general limitation inherent to Max/MSP's dataflow heritage.

The bit I specifically took issue with was this paragraph:

"The point I wanted to make – and this is not a criticism of this effort or Max – is that one strength of Processing is that it can run anywhere. It can go in a browser, in JavaScript, on a Linux netbook, and soon on phones and embedded devices. You can make your work in Processing and turn it into a standalone application that can run anywhere, and edit it on any machine. You can keep your sketches in the cloud, have your laptop catch fire, and then download Processing from the site and go right back to editing without registering or authorizing or anything like that. That may not be the case once you start cobbling it together with Max and the like."

You can still keep your sketches online and download them to the Plan B laptop, etc. They will still run independently of Max. In the context of using Live, Max's portability verses Processing's portability, its a bit moot. You're still stuck in Win/Mac land with authentication to deal with, as you scramble to get Live working. A bit of preplanning and proactive system administration can offset the effects of having to do a system rebuild in the wild regardless of the platform. (It's happened to me too.)

So it seems to me the point of your point is whether or not to go totally open source such as creating a Processing only solution as in our video mixer example. It just seems a bit unfair to introduce a criticism laboring this point without establishing the context of proprietary vs. open source software debate more clearly.

On the topic of meshing or a single solution, I'd love a single solution but I haven't seen it yet. Part of the attraction of using Max and Processing is that they are low hanging fruit. Trying to write a Javascript or Ruby drawing framework for [jit.lcd] is painful. Processing does it better. Recreating a GUI and video playback engine on par with Max's in Processing isn't what I'm really interested in either as they already exist in Max and Jitter. If I had to start coding stuff like that from the ground up, I'm going to bypass the JVM completely and reach for C/C++ and/or Objective-C.

– and The Field is doing things Processing currently can't, like responding to code live. Mac-only, but could be ported.

They, in turn, have also tried a bridge to Max. But I think technically, some of the strength here comes from the Python and Java platforms and the stuff that's built atop them. In the case of The Field, they're able to support JavaScript, embedded Java, Groovy, Clojure and Scala, all thanks to the Java VM beneath and the open work done atop them.

Of course, an artist looking at that list — or even Max and Processing — is likely to be overwhelmed with the number of choices. So I think, as with this combination of Max and Processing, the key is that there are this many choices because people have different needs and preferences.