A php rant => general thoughts about (the future of) Max
I ran into this article (credits to Nick Rothwell for sharing it on Facebook btw) and it sparked some thoughts about Max.
Not sure if anyone is interested in random general thoughts about Max, but just in case:
1) Should Max be compared to languages that are used in commercial software development?
=> Commercial software development needs programming languages to be as good as possible
=> Max is a programming language
=> we want Max to be as good as possible
=> so yes, I believe the comparison is useful.
2) Should Max be compared to php?
=> Php was built for non-programmers and it is now used by many top-of-their-class programmers to build things like Facebook and Wordpress.
=> Max was built for non-programmers, namely artists, but there is an increasing amount of people (around me at least) with a technical education that use Max for big applications.
=> Max might become for real-time applications what php is for server-side web applications.
3) How do we (as you can see my love for Max extends to me feeling a shared responsibility for its development ;) prevent Max from falling into the same trap as php when it comes to the points the guy stresses in his blog under 'Stance'?
=> I realized several of his points already currently apply to Max
=> How would you say that the terms "predictable, consistent, concise, reliable and debuggable" in the context of this post apply to Max in its current form?
4) If these points are ever to be addressed in Max, backwards compatibility will almost certainly be broken.
=> How to overcome this backwards compatibility obstacle in Max?
5) How to raise $$ to invest in Max to address the issues in point 3 and 4?
=> get more commercial software development people to buy Max, but how?
=> problem is Max has a reputation, even in the art scene, of only being used by poor quality programmers, so now what?
=> Use it for commercial software development projects and prove them wrong
=> teach it at schools. Not Art schools, but Tech schools
Just thoughts :) I'm curious as to any counter-thoughts ;)
Cheers,
Mattijs
For me, the most important question raised here is that of backwards compatability. How important is it? Over the past 20 years, I have been constantly learning new things to do essentially the same work, and I have always been happy to learn them. I also have to buy new equipment every one or two years. Again, this is not terrible; just part of the game. If Max can benefit in the future from an overhaul, then I would support that.
In a parallel development: 13 years ago I did alot of work with Flash, and then did not touch it for a long time. A year ago, I had to do some more work with it and was confronted with ActionScript3, which had little to do with the ActionScript I worked with before. It had been changed from the ground up with really wonderful results, so that the learning curve I faced was a small price to pay for the increased power and conformity the language offered.
I would love to have Max continue to advance and be used for more and more purposes. I got into it for use with MIDI, then audio, then video and then OpenGL. Let it keep growing! The new features in Max6 are currently redefining my artistic output, and I am overjoyed. I can only guess at what that will look like in a few years.
I'm interested Raja, what work do you pick up where you use Max?
In a similar thrust to the question from Mike S:
Which existing posts examine the ways that Max is used commercially?
Who uses Max commercially in non-artistic pursuits?
As for myself, I use Max daily for profit, but that is because I am a paid musician and producer of a variety of types of shows. Max is my goto platform for quick experimentation and flexible interaction. For that, it is unbeatable, and I have helped many colleagues with it.
If, however, I work on a project which is intended to market a program instead of a show, there are a couple of basic problems:
1. Security. You can't simply anti-pirate a standalone.
2. Porting:
2a. Apps. Apparently it is possible (somehow) to create an app out of a maxpat, but it is not easily done. Also, the only article I have read deals with Apple apps, nothing else.
2b. The web. Something like vvvv.js?
Believe me, this is not criticism. I love Max. It makes me the most powerful musician in the universe. But if the question is how Max can integrate in the workworld better, the answer lies in another question: Where is the money, and how does Max interact with that direction?
Apart from my own artistic work I've been doing freelance Max development work. Some of it for university research groups, eg. an application that logs 'cognitive interference' between a visual stimulus and hand movement, and various systems for interactive architecture experiments.
About that reputation, I actually see it as a big advantage that Max is so easy to pick up and make totally clunky, inefficient stuff in a couple of hours starting from 0 experience. At least people get something to work. Give a random noob student the task to build something with sound, video and sensor input in C++ without any experience and see how long it takes. If he doesn't give up, that is.
To me it sounds elitist to say that this is not good, and that Max should be aimed just at pro developers/artists. It does as well, but not exclusively. There's the SDK, gen, etc. Very powerful for the advanced user. And lets not forget that advanced users usually started with the same totally clunky, inefficient stuff many years ago...
having previously sold plugins made that I made with pluggo, and having worked on a few complex apps that were built with Max I've had to consider these issues. If you make a product or develop software commercially for others, it is a horrible position to be in, to know that there are certain things that you simply cannot do anything about yourself, other than send a bug report or feature request to C74 and cross your fingers. If an end-user experiences problems or clunkiness with your work you are severely limited in what optimization and debugging you can do, due to the high level, closed-source nature of Max.
These issues led me to learn lower-level programming, and it makes me feel a lot more comfortable to know that if there is a problem I can methodically track it down, and eventually fix it. If I can't fix it yet it is often just a limitation of my current programming knowledge rather than some obscure peculiarity of a system that I am not the author of.
Nowadays I am of the opinion that for most complex apps Max is simply the wrong choice, and especially the wrong choice for things you intend to sell. I think that advanced Max programmers can probably pick up C++ relatively easily and the time that you loose from having to reinvent the wheel for certain aspects of the project, will often be saved later on in the project (in reality open-source libraries like portaudio/openframeworks/libcinder mean that you don't have to reinvent the wheel a lot of the time, and you can still detect/fix problems that are due to 3rd party code). Strictly text based code, version control and debugging are a huge blessing after having worked on complex projects made in max.
Of course, unless you are an extremely competent and knowledgable developer, low level programming works best when you have the luxury of time. Max does excel for situations when you need to get something working very quickly, or change it at the last minute, and so I continue to use it for various arts projects that i am involved with.
hey,
very interesting topic. As a student in music composition mainly, i must say i recognize myself in what dtr (and others) say about "random noob student" building something with sound, [rarely] video, and sensor input, certainly not in c++ for now, on which i would certainly have given up ages ago :) or maybe not by now, who knows. Anyway my little point here is that indeed Max is wonderful for beginners, also for doing veryy simple basic stuff that's not easily doable with other audio softwares because it needs flexibility, and it's really a good thing, and if i ever want to build a complete audio application i will maybe not do it in Max... and it's not because of bad design, because Max is i think (fwiw but eh) shaping well in where it should. Thanks anyway for your enlightened advices on the question !
Great thinking, thanks for sharing your thoughts! Very enjoyable, the random splattering of thoughts on the canvas of this forum.
- php is open source, max is not. I agree, this makes it hard to compare the two. Max is certainly not a clusterf*ck.
- raja says: max is predictable, consistent, reliable and debuggable (but not concise). I think it depends on the levels you expect. For example in the php rant strpos and str_rot13 are mentioned as not being consistent. I think we can see the same level of inconsistency in some areas of Max, just some small examples are the read/open/import commands, pack/pak vs join @triggers, counter's arguments. There are many more of those minor things that I didn't remember to write down as I ran into them when I was learning max. As for predictability, I still run into situations where I really can't explain what is happening just by looking at the documentation of the objects I use. These situations are mostly due to errors in my code of course (which is where debuggability comes into play) but also sometimes due to unpredictable behavior of objects, although I must admit I again didn't keep a list so I don't have concrete examples ready at the moment. Still, looking hard at the internal workings of an object is sometimes necessary to explain certain behavior. Reliable; same thing. Getting better all the time, but working out crashes is somehow still a substantial part of most projects I do with Max.
By the way I'm absolutely not implying that I expect the devs to have done a better job. I think that the quality of their work is insane for such a small team embarking on what appears to be the development of a completely new programming language and IDE. A brand new programming idiom. No, a brand new programming philosophy. Anyway. I can't imagine how much effort it took Sun to develop Java to its current state and Max represents an even larger quantum leap.
- raja: conciseness: are you sure that max is by definition less concise than text based languages? admitted, [counter] is a bit longer than 'i++', but [zl group] is not longer than 'array.push("new item")', and [jit.qt.movie] + [jit.window] is certainly not longer than adding quicktime support to any text-based app (https://developer.apple.com/quicktime/)
- We agree that max is great for quick prototyping, and most of you say that Max is not the primary choice for making a complete application. But is this inherent? Max is good at prototyping SO Max will never be good at making complete applications? I differ by the way, I believe that Max 6 (provided that copy protection is somehow solved elegantly, agreed, lembert) is a platform that is no less suitable for making complete applications than other languages out there, assuming it's used in the right way by the right programmers.
- 'we'. Yeah, I know, PR is something Cycling '74 does incredibly well, by accident or consciously, I don't know. Don't say that I'm the only who feels like he's part of a great adventure with the Cycling team in the cockpit ;) Often to the great annoyance of the Cycling team I'm sure, but still, having users that feel involved is usually a good thing in terms of marketing.
- backwards compatibility: so we agree that it's a hot topic. But shouldn't it be possible to give all objects a mayor overhaul allowing for an increase in predictability, consistency and conciseness but somehow still allow old patches to be loaded properly in all versions of Max?
- reputation: well, personally I strongly disagree that Max is or should be either for beginning or for advanced programmers only, but people using openframeworks, cinder, processing, even quartz composer etc etc all think of Max as a starting point only, to be dismissed whenever your programming skills exceed the level of the 'random noob student'. When posting a video online I somehow feel a bit restrained to explain that a project is made with Max. Why is that? I'm sure there are reasons, but it would be interesting to list them.
- A union would be awesome. The Official Labor Union for Maxers. Actually, this reminds me of an idea I once had, maxadvisors.com, where people add their profile (portfolio, experience with installations/performances/prototypes, reviews, proficiency with max/msp/jitter/max for live, contact info, etc). Sponsored by Cycling 74 I'd say, because this will hopefully decrease the amount of commercial work gone bad done by people who are mainly very good at making a slick presentation of themselves towards art institues ;)
- maxmsp.js would be pretty awesome. Note that maxpat files are already in json format as of version 5.. may the best man win ;)
i dont get wide parts of this thread but it is still interesting.
nice to hear that i am not the only maxer who is also an active occupier (fuck, may 18th
will get big in germany)
but what sounds strange to my ears is that there is a debate now about how to make max
better until it is as good as C++ or machine language in terms of optimisation possibilities.
i dont think it is required to reinvent C++ or assembler languages becaue they do already
exist, and when you are going to create a new super reverb for waves inc, you should not
use max but something else.
what seems also strange is that comparism with PHP. wtf? PHP applications are usually
work together with HTML, the http protocol, and browsers. it is totaly depending on other
stuff. max only depends on its own runtime and if back- and forewards compatibility would
not be given, most max users would have left the boat already.
it just seems not right to change something which seems to work perfectly in its niche only
to make it bigger or fit into some alien philosophical concept which isnt ours.
maxmsp is not a an occupy camp! on occupy camps it is unavoidable that the crowd
reinvents the wheel on a daily basis (or two times per day on good days) so that you
can count on nothing and nothing will be ever be finished.
max users should regulary question themselves and the way they work with max, but not
the programming enviroment they use.
the concept of creative chaos only works when there is a counterpoint of order and proven thesis.
110@occupyfrankfurt.de
My thoughts on backwards compatibility. Max is a language with a strong history, and in my opinion the evolution of the language has caused it to progress from a tool used by a handful of computer music academics to something capable of running very complex multimedia processes.
In my industry (entertainment, theatre and live events) technicians are crying out for something like Max to solve problems without having to invest huge amounts of money in specific hardware. There are so many situations in which a real-time graphical environment accessible to non-programmers can be used in this field. Unfortunately, Max is still only really well known to people working in the less commercial branches of theatre, installations and live music.
I really want Max to become a tool widely used in my industry because it's such a perfect fit (with a few additional externals, which I focus my time on creating). But in order to do this, I think it needs an overhaul, and a new branch that completely disregards any attempt at backwards compatibility, and mercilessly unifies everything.
For a start, the Jitter object model is far superior to the old Max model. It's much more consistent and useful, and easier to pick up quickly. Attributes work much better than endless and variable numbers of arguments, and the ability to manage objects outside of an actual graphical box when necessary (via Lua or Javascript) is much more elegant. I would love to see all Max objects adopt this model. This is a fairly massive sea change, but I believe it's a necessary one.
I don't however think all existing max objects should be abandoned. A switchable mode to enable support for old objects should be available. But all new users should be learning with a consistent set of objects.
I think the outstanding feature of Max is the integration of code and user interface. Thus it's quite easy and intuitive to put little programs together, but rather difficult to design complex programs according to the principles of software engineering like MVC.
I'm not sure if and how this conflict could be resolved.
"Non-artistic" is a bit ambiguous, I suppose. Data-visualization would be a likely use. An oceanographer I know was interested in using it to visualize data on currents, which he says are similar to audio streams. Today while at a café, a woman next to me was working out a way to plot weighted averages for demographics purposes. Basically, she was trying to store her data in a 3-plane matrix and do manipulations on it, but was limited to excel for this purpose. I showed her what I was working on, which was the plotting of points in a GL-world based on fractals. I could have solved her problems in a few minutes. I can see applications in robotics, medicine, education and any kind of communications.
I can see applications in robotics, medicine, education and any kind of communications.
Partially it does already exit :
I recently (and by coincidence) found this book: It?s unfortunately in German It' on sensory based robot controlling with Max.
Title:
"Roboterfernsteuerung mit Max/MSP: Eine paketorientierte Sensorikintegrationslösung"
There are also design schools that use max for quick prototyping of interactive product designs.
I don't however think all existing max objects should be abandoned. A switchable mode to enable support for old objects should be available. But all new users should be learning with a consistent set of objects.
Agreed! Would the proposed solution have any drawbacks?
For a start, the Jitter object model is far superior to the old Max model. It's much more consistent and useful, and easier to pick up quickly. Attributes work much better than endless and variable numbers of arguments, and the ability to manage objects outside of an actual graphical box when necessary (via Lua or Javascript) is much more elegant. I would love to see all Max objects adopt this model. This is a fairly massive sea change, but I believe it's a necessary one.
Good points, two things though about Jitter:
1) Jitter introduced the idea of linking objects by name (movie, textures, shaders) without a patch cord.
2) In Max 6 the option was introduced to leave out the name of the render context; objects will automatically find an available one.
Before Jitter, the only way objects could be linked without a patch cord was by using a send/receive pair, barring some exceptions (e.g. coll refer and buffer names). In Jitter, this is was made a common mechanism. This makes for inconsistency between jitter and the rest of max. I can see benefits of the Max way, especially for new users. It makes things more predictable, you only need have a good overview of sends and receives in your patch, apart from that you can always find bugs by tracing patch cords.
Thus it's quite easy and intuitive to put little programs together, but rather difficult to design complex programs according to the principles of software engineering like MVC.
(the pattr system definitely helps with MVC)
As far as I'm concerned [dict] is *the* solution to applying MVC in Max. A recent project is the ultimate proof of that for me. Plainly put my view consists of interface objects that, after some optional scaling, all feed directly into a large dict (model) where all variables are structured hierarchically, in some cases sending a bang to a javascript (controller) that then recalculates the output values and some interface updates from the dict. Perhaps I should make a tutorial or something of this.
I can see applications in robotics, medicine, education and any kind of communications.
There are also design schools that use max for quick prototyping of interactive product designs.
Well, technically everything is in there that you need to do anything you can theoretically do with a computer, right? I would be interested in a list of things you can't do (easily) with Max, assuming that cpu-efficiency is not a bottleneck.
Hi.
Very interesting discussion. I'd like to add my (slightly off-topic, maybe) two cents.
I am not so sure that Max, per se, really is a very easy programming environment. I tend to see it more and more as a great tool for quickly building user interfaces, and easily talking to hardware. But whenever I need to set up even slightly complex behaviors I find much easier to open Xcode and write some C. Nowadays each time I need to develop a non totally trivial project with Max I tend to squeeze the engine into a small number of externals (which, by the way, I find so much easier to debug) and having Max doing the UI, managing the audio and MIDI interfaces, etc. etc. And sometimes I end up doing some JS for small things not worth an external, but ultimately tricky to do in a patch. In this way I have the feeling of having the best of both worlds. (Moreover, I have found myself in need to convert a prototype I had developed in Max into C++ code - it was not a very large project, but not even a diminutive one. So I got Juce for sliders and dialog boxes and stuff like that, I wrapped the code of my externals into some C++ classes, with some very minor modifications, and the job was more or less done - which was kinda cool!)
Anyway. This "Max for the GUI, code for the cogs" approach looks so convenient to me that I am starting to question whether it is worth to teach Max as "your first programming environment" to music and art students, which is what I regularly do. Max looks easy at first sight - hey, you just hook together these two boxes and voilà, you get sound! - but as soon as you want to do more you need to wrap your head around the fact that you conceive a program as a recipe (do this and this and this), while Max asks you to build an assembly chain (there's a guy doin' this and a guy doin' that, how do I make them interact?).
Ok, it might be argued that I conceive programs as recipes because I first learnt BASIC in the early 80s. But it seems to me that when one of my students describes a programming problem to me, the problem is more often stated in a procedural-ish way than a functional/dataflow-ish way.
And so I am starting to wonder - maybe if I taught, say, a little bit of Python first, it would be slightly more intimidating and less rewarding at first; but it would help people to see how a computer works, and how to structure their thoughts in a way a computer can understand, and after that Max would make much more sense...
Dunno, just thinking aloud. I'd like to know your opinion about that - before screwing up all my courses ;)
aa
+1
I also find it very useful to give students a little introduction to scripting in JS or Processing before introducing Max.