I have been using Max 4 for years now, just not really been too involved with the community. In the past 2 weeks I’ve been using the Max 5 demo. I have written up a few things I don't like about Max 5 or even Max in general. I am not a computer scientist although I throw around some terms quite copiously and I'm sorry for that. In regards, anywhere I am plain off just correct me. It’s not meant to be a flame rant at all and is just merely me expressing a few of the negative things I’ve come to find in Max.
[fonts]
Only 3 fonts on my system work on Max without any compromise. They are: Arial, Tahoma, and Microsoft Sans Serif. If I choose to set my default font to a wide font, say, like Lucida Console, Verdana, or Courier New and then restart Max, all my help files which use "Sans Serif" as their default font will be set to this default font. I thought this behavior was originally handled in the .init folder with the file "max-fontmappings.txt". Indeed, the file still exists in Max5, but seems to take less precedence, rendering it useless for "Sans Serif" help files. What the invariable result is 90% of my help files will become mangled due to the boxes object size being smaller than the width of the font + number of characters.
Proposed Solution: I for one would like to be able to use Verdana 10 again without it mangling all my max4 help files being as some of these may never be updated. My proposed solution is to make the "system font" the one that is used when Sans Serif is called. Or even a new option for what Sans Serif defaults to…
[GUI responsiveness#1]
I would really like to see a change in the way Max handles moving around objects with the mouse/arrow keys. What I theorize is happening is that, with every pixel that a selection is moved, the graph the interpreter creates is being rebuilt. I could be wrong of course, but it seems like there's more going on that just some objects being redrawn on the screen. Say if you have 1000 buttons and drag them around... why does the system become so sluggish? Is it because it needs to infer implicit right-to-left ordering while moving things around? If that were the case, I'd say that was a poor reason to let the graph rebuild so many times being as such that kind of ordering (implicit, i.e., not using trigger) isn't really, well, good programming to begin with.
Proposed Solution: If indeed my theory is correct my proposed solution would be as follows. Do not rebuild the graph until the mouse button is released. Drag whatever you want around freely at a high frame rate, then, when the final destination is selected and the mouse button let go, rebuild the graph. If using the arrow keys wait until the arrow key is released.
[GUI responsiveness#2]
I’ve noticed when making a small selection and dragging it around, the selection lags about 1/4th of a second behind the mouse cursor. Maybe this might be remedied with a better graphics card, I don’t know. I tested this on both Windows and Mac on different computers and the lag was about the same. Coming from Max 4’s instant responsiveness I find this adds to the underlying feeling I have that Max 5 is slower than Max 4 in almost every respect. (yes, the key commands help, obviously, but, I’ve had those since Max4 using the toolkit)
[scope]
First, I would really like to see something like ps and pr (private send/receive) as we have with pv (private variable). Pvar for me doesn't quite cut it and seems to have some instantiation problems. Pattr also seems a bit awkward as well in regards.
Second, sometimes I wonder why all patches have scope with each other. It seems to me like if one wanted to communicate with separate patches that using a localhost OSC model would probably be better. That would make send/receive operate only from the base patch (i.e, what you retrieve from thispatcher with the path message). This can create "state" overrides when opening an old version of a patch that uses, say, a named coll, or sends a bunch of data via sends and receives. Or if a patch shares a send/receive name it can be an issue.
Proposed solution: Change send/receive to patch wide, add local/private send/receive, and use OSC or a global send/receive object for inter patch communication.
[“seeable” interpretation]
Take this example. We have a bangbang object. The right outlet is connected to a big array of coll cut and copy operations and requires regexp and javascript and some other stuff. When it's done doing it's iterations/operations, it sends a "Right finished" message to a print object. The left outlet of bangbang is just a message saying "left finished" connected to print. Why is it that, in some cases, it's possible that the left outlet will print before the right outlet, even with vanilla objects. Of course one winds up using a delay or deferlow object on the left outlet to get the ordering which was suggested in the first place.
I don't have a solution for this because I'm not sure if it's even a problem. Maybe it's a design compromise from the get go. But, obviously, this can lead to bugs when you're counting on right-to-left being there always. Being able to see the ~flow~ is part of what makes Max useful and if you can’t always trust that, then, well… what’s the point?
[timing]
Over the years I've read so many complaints about Max and timing. Things like "I built a controller for my drum machine but Max can't send out steady beats" or "I build a sequencer and the timing is all off" or whatever. Anyone whose been around a while knows this. Max's bias towards creating interactive or algorithmic music _probably_ hasn't helped this. I had a hell of a time getting reproducible timing from the hostsync~ object. In the end, I found that turning off audio and using a “metro 1” actually improved the timing quite considerably, but still not to a point where I felt happy with it…. However, since I had to use audio, I would up making a standalone to receive the timing from a host and then OSC it into Max. Then I was delighted to find out that OSC was finicky, too.
[Warning: very opinionated] Max 5 is, I think, _partly_ an attempt to attract new customers. That's fine, but, what I think is missing is a solid determinalistic core to Max. I find it too hard to create reproducible results, especially with anything timing concerned.
Proposed Solution: I think if you Cycling wants to attract a greater following they need super solid, sample accurate timing. Some determinalistic objects might help too. Add a 21st century updated object which builds upon the ideas set forth by detonate/timeline. Not all of us are interactive/algorithmic musicians. In fact, most of the world’s “successful” music is pretty much 99.0% determinalistic (maybe Jazz accounts for 1% of albums sold, I’m just guessing). If Cycling really wanted to get new customers, they would make more of an effort to instantiate this sort of paradigm into Max. I mean, algorithmic music IS cool, but you won’t get past playing in coffee shops if that’s all you write. If trying to attract more mainstream musicians, they need to know that they can make money as well as useful tools with your program. And I don’t mean make money by selling software, I mean by being able to write hit songs with the help of Max.
In short, if Max wants to look “pop” (Apple) it should support primitives for making pop i.e. determinalistic music _without_ having to utilize a 3rd party sequencer. I for one have plenty of ideas what one could do with a “max sequencer”.
[speed]
As you may know, depending on the compiler you can get quite a lot of speed benefits. Now I’m almost 100% sure every last employee at Cycling is a hardcore devoted Mac user, and, I have my doubts about how much effort actually goes into compiling the vanilla objects for Windows.
I had a friend show me some speed results using some different C compilers along with flag settings. I am sure that Cycling would benefit us Windows users to hire someone that was “really into” this sort of thing and could make wMax as fast as possible.
If this isn’t the case then I apologize. I meant to mention it just because I think if all the externals were compiled and thoroughly tested on Windows we’d see like a 5-15% speed improvement. If this has already been done then, well, thanks.
Also, I would have liked to see some speed improvements with Jitter. I guess this probably isn’t possible with Max’s current core. I have no idea how or why or what kind of overhaul it would take. All I know is on Windows we have a freeware program called vvvv which feels infinitely faster than jitter, so I end up using that, instead. Anyone on a mac ought to check it out, it really is cool.
[closing statements]
Overall, I am pretty happy with Max 5. I am running the demo right now. I truly couldn’t use Max 5 up until version 5.03 because of the font rendering which, for me, made it unreadable. So, thank you to David for addressing that.
I like the new inspector, the debugger, JSON format, shortcut keys, layout….
Anyway, thanks!