[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!

I’ve noticed that I can move around far fewer objects before Max starts crapping out. In Max 4, moderately large selections of objects were moved around without any sort of graphical hit. It felt smooth. Now, when I decide i want to move around the contents of a big patch, maybe move it over, things crap out and crawl down to a few frames per second. I tested this by opening the same patch in Max 4 and 5 and, 5 definitely is far behind in the number of objects that can be moved at once (and I mean non CPU intensive things, my “mouse up” suggestion would remedy more intensive stuff, I think)…

thanks!

p

–
http://pure.test.at
http://www.myspace.com/pvre

http://www.heartchamberorchestra.org

As for your previous comments about Windows getting the short shrift, Cycling has a dedicated, extremely talented Windows programmer on staff who goes to great lengths to make wMax as efficient and splendid as xMax. Rest assured that the wMax kernel and objects are as carefully compiled and as thoroughly tested as
xMax. If you have specific complaints/concerns about particular objects or patches that you can demonstrate, we’d be more than happy to know about them.

Many of your suggestions/concerns are valid, although I think that some things (ps, pr) could be easily solved with JS. I think other things (timing) are the result of incorrect settings (timing is very tight with Overdrive enabled, and especially with Scheduler in Audio Interrupt, esp. if you use audio objects for timing tasks). Some of the things you mention can’t be changed, not out of lack of goodwill, but out of a need for Max 4 patches to work properly/reliably in Max 5+.

I’ve attached 2 js files for implementing private send and receives. They could be extended, but as an illustration…

Jeremy

Quote: pure wrote on Thu, 24 July 2008 10:04
—————————————————-
> vuxivl wrote:
> > 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.
> because you are starting two independent processes with bangbang.
> sometimes the right process might be finished first sometimes not
> depending on what else is going on on yr computer. in yr case you would
> have to temporarily store the “left finished” (e.g. with set $1 in a
> message box) and let it bang out when the right process is finished.
> oh, and timebased ordering (delay, deferlow) is almost always worse than
> condition based
>
> p
>
>
> —
> http://pure.test.at
> http://www.myspace.com/pvre
> http://www.heartchamberorchestra.org
>
—————————————————-

The JUCE engine, which is [one of?] the backbone[s] of cross-platform compatibility, exacts a toll. If there were an easy, or even just a straight-forward, way to speed this up, it would have happened.

> What I theorize is happening is that, with every pixel that a selection is moved, the graph the interpreter creates is being rebuilt.

I doubt it, although only the C74 developers know for sure.

> [scope]
>… 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.

Global scope was a design decision made in about 1987. Was your OSC proposal an option in 1987? (That’s a rhetorical question. The rhetorical answer is “no.”) I don’t know if you can appreciate just how difficult it is to change a paradigm that’s been in place forever if you’ve not been using Max for that long. For all the problems with global scope were well known back then, it does provide a simple solution for a lot of things a lot of people want to do.

What Max has offered for a few years now is the pattr system, which gives you a structured, hierarchical way to communicate between subpatches. For all it’s not as simple to use as send/receive, it will probably do what you need in terms of scope.

> [“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.

If an object defers processing, this happens. There are even plain vanilla objects that defer processing (or have exceptions to R2L order), and certainly javascript or “big arrays of coll cut and copy…” can do that to you.

You’re quite right that exceptions to strict right-to-left processing can mess you up badly. But part of learning Max is learning the exceptions to strict R2L.

Does the Debug->Trace not help?

> [timing]

A certain amount of the timing problems are set by the OS and hardware. I’ve actually written code that deals with timing, in my experience you can code till you’re blue in the face and an recalcitrant OS will still stomp over your careful timing.

You may ask “how come the plain-vanilla sequencers manage to get tighter timing?” It isn’t completely impossible that they’ve found some tricks that go beyond what Max has, but I suspect the really big issue is the overhead for message passing in Max. When your standard sequencer triggers a note on, it sends three bytes to your MIDI interface and it’s done. A metro bang triggers a lot of versatile processing in Max, and that versatility also exacts a toll.

That said, tighter timing has been a recurring wish since forever, as you’ll know if you’ve been reading the list for just a little while. If it were as easy as you imagine, it would have happened.

Also: your estimates of the marketability of algorithmic music fall seriously short of the mark. That’s actually fine by me, so if you want to go on believing that, go ahead;-

But if you want to build a ‘pop’ sequencer with Max, no one’s stopping you. It can be done. But if Max is supposed to turn into just another Cubic or LogBase, it doesn’t need to be Max, does it?

> [speed]
>
>…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.

Not true. There is at *least* one real, hardcore, whatever-the-equivalent-of-bleed-in-seven-colors-is, Windows guy working for Cycling ’74, as well as several highly “bilingual” (Windows/Mac) people. They know what they’re doing on the Windows front (and the compiler optimization front). There would never have been a Windows port if there weren’t “real” Windows programmers working on the project.

Again, the real processing bottle-necks, AFA-anyone-outside-C74-CT, are the cross-platform layers and the message-passing model.

You may wish to check out my samm~ external as a sample-accurate alternative to the timing systems currently provided in Max.

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/

Eric

I don’t want to work for that kind of boss.

David Z.

http://www.cycling74.com/twiki/bin/view/Company/People

It’s a small company, keeping steady by means of a few dedicated people who probably do it mainly for the love of it. In fact, aside from the lack of bulldozing corporate/capitalistic money-grubbing influences, the proof of that love is also shown by the fact that some contractors, perhaps others, aren’t even listed on that page and must, therefore, remain unseen and unappreciated (*ahem*) so a little patience over the general work-in-progress would be most appreciated. If you have specific features you want added, a constructive but specific non-rant might be more appropriate. A general assessment is also somewhat helpful but doesn’t really get your suggestions through, instead, people can argue against everything because they’ll follow the general attitude of criticalness with which it was originally/mainly written.
for example,
*you can achieve sample-accurate/non-scheduler timing with MSP alone(eric lyon’s objects are another way to achieve this as well);
*I personally, don’t care about how the GUI responds to movement of objects while editing so long as I can edit smoothly and so long as the graphics perform on-time in performance/presentation-mode(i.e. when locked), and on my G5 and my MacBook, as well as on my friends’ Windows Intel-Duo machines, it seems to be void of graphical lag, so your complaint there might be system specific, not sure… unless you were to be wholistic enough in your criticism to specify your system exactly.
*as for scope, I like that it’s automatic to some extent and that I must be specific if I’d like to draw boundaries, this makes it easier for modular designs to work with each other and you are still able to achieve private send/receives if you know the techniques well enough and, more importantly, keep track of what you’re doing, which you should be doing anyways no matter what programming interface you use
*the list can go on as other people’s answers have shown….

In general, you have to realize, when a company like Cycling’74 wants to remain small and honest, everything is always a work in progress. Compare it to Google, (whom I used to begrudgingly work for), and you’ll see that it gets way more done and faster considering the smaller amount of woman/man-power resources available(notice GMail, after years of being publicly available is still in beta along with many of their other sterile-looking products… but i digress due to personal resentment…).

Overall, I’d just like to say, have patience, Cycling’74 will work out the kinks and you will be pleased for sure in the days, months, and years to come.

I should, however, mention that your “rant” is certainly more constructive than others(for example, where unconstructive, childish comparisons to HelloKitty make no sense whatsoever and offer nothing towards improvement), and I do appreciate your comments for that.

I just had to get my 2 cents(or less) in, but David’s reply was probably the most concise and meaningful one here, so I’ll just quote him again so that it can be remembered as the last word on the subject that even I’d have wanted to say if I had the same level of patience and intelligence:

“I don’t want to be too hard on this constructive rant. However, it makes me appreciate the specific, documented, informed, and insightful suggestions and reports other Max users provide on a regular basis. Any of you ever have a job where the boss would come in and say, “Do it over, this is no good!” and, after you say, “Sure thing, we’ll get right on it!” you are left wondering where you are supposed to start?

I don’t want to work for that kind of boss.

David Z.”

(and by “boss”, he means YOU, the Max user-community-at-large.)

Dunno if you’ve checked out Mattijs’ and my oo-objects, but local private/public scoping is one of the issues we were looking to improve upon.

http://www.cycling74.com/twiki/bin/view/Share/MattijsKneppers

To Bernstein:
Thank you, and for the updates. Running your .maxpat made me think a lot about the one area I really wanted to talk about… GUI sluggishness. I noticed that the numbers getting sent to the print window were far less smooth than in Max 4…

**—–Heres a quick example. Connect a metro 10 to a counter to a print object. In Max 5 it seems like the whole system is bottlenecked based on the output of the Max window. In Max 4 the numbers run down the Max window so smooth and cleanly.—-** How is it people defend Max 5 as being just as fast as Max 4 with these relatively obvious things?

To Castine:
In regrards to R2L, I have actually pretty much mastered the concept of utilizing the deferlow object where necessary. I don’t rely on R2L to always occur, especially when doing big operations in a trigger sequence. Still, I think, that, while it definitely is good that speed is a priority, WYSIWYG is also important. Regardless, I think I am comfortable with the exceptions to R2L even though sometimes I’ll have a bug or two related to it but tracing it down isn’t hard.

To johnpitcairn/Eric lyon: Thanks.

[GUI responsiveness]

Peter made a point about JUCE… it was pretty obvious to me from the start that JUCE was going to be a controversial pick. While I can appreciate it’s graphical primitives and can speculate that Cycling thought the look and feel fit perfectly, and probably the audio libraries being useful… I, for one, cringed. It’s And not because of the look AT ALL, but, because I had tried out a few JUCE apps before that. One being the JUCEdemo.exe off their site, and the other being Mackie Traktion. I mean, if the JUCE demo is sluggish feeling, then I can only imagine what it’s going to do to an already do the psychology of using an already slow Max. In both, the sluggishness of the fader responses, drawing, whatever was completely too latent for me. I love fast, tactile responsiveness to things. I had an underlying suspicion that Max 5 was going to be significantly less “snappy” than 4 and it definitely is……..

Draw rectangles, dragging objects (plus the amount of objects you can drag before it slugs out), locking/unlocking a patcher, double click opening patches, max initial startup, moving things around with arrow keys, sliders, JSUI….; all feels noticeably slower to me…. I’ve literally spent the last 3 or 4 days sitting here on a 30″ monitor, split directly down the middle, with Max 4 on one side and Max 5 on the other, same patch open in both trying out various operation with interacting with the canvas and Max 4 blows it out of the water in terms of speed (not the Max is actually that fast to begin with)

My computer specs are decent enough. Q6600 processor, 7300GT video card, standard 2gigs of ram, fast harddrive…. I researched all the parts and it’s only a year or so old. For the sake of comparison I tested Max 4 & 5 demos on a brand new macbook. Same results, really. Max 4 seemed so much quicker for everything…

But, I mean, I suppose that can be expected. Max 5 is still new thing. I am bendable. I don’t mind the roundedness (yes that was a funny discussion). I just have gripes with the speed at this point. I just have this suspicion that Max is never going to speed up. That, as Karaokaze pointed out that Cycling is just a little company and that we all need to be patient with them. Yep, he’s right. Cycling is a small company it would seem which baffles me why they go on supporting buggy mxj Java or evil things like Javascript when theres limited manpower and the Max core itself could certainly use an update. Btw, Peter brought up the date 1987. Has Max’s core really seen a revision since then or has it just been maintenance and bug fixes? Curious about that.

Some folks program in Squeak and don’t give a hoot how sluggish it feels, they just like the smalltalk language and the ease of integration or whatever. Some people like programming in javascript and don’t care how much memory it uses or how slow it is in comparison to another equally useful extension language.

You know, I was thinking today, as a company Cycling seems to value “speed” very little. Max itself was never really fast, and, over time, one learns it isn’t really suited for building large scale applications. But how about JUCE on top of an already slow Max? Javascript as it’s extension language? Did anyone do any benchmarks?

Choosing Javascript and JUCE makes me think that Cycling doesn’t really understand the wants of some of their customers. I’m willing to go out on a line and bet _most_ Maxers at some point had a delusional fantasy about building a complete replacement for whatever non-programming music software they were using. If they’re anything like me, they found out the hardway that Max has a limit to how far you can go with it. It’s not a limitless program, and, the more things you implement into your Max program, the more compromises have to be made. When things start junking out, I start to look at the GUI objects first as a problem. I still don’t even bother with Javascript because of all the mixed discontent with mandatory gratitude at having “something” there seems to be on the JS forum. Yes, folks, you have _something_ now where as before you had nothing. Yee-ha.

Which brings to another point of is Max really a programming language at all? I’d say yes, because the term is vague enough, but, vanilla Max isn’t the speediest interpreter by a long shot and would die or not even be able to compete in a lot of the tests on “The great computer language shootout”. I’d even guess and say it’s probably one of the slowest interpreters in existence. That’s fine though, Max is still useful for moderate applications, but, I think that it should compensate for it’s slownesss by using the _fastest_ interface library and the _fastest_ extension language available. Instead it uses the _slowest_ for both, which makes things triple slow?

Now, I fear, the reality is that the bottlenecks I ran into while programming in Max in 2005 have become even more constrained. And despite this I’ve still been a very devoted Maxer, often times programming for 12-14 hours a day weeks on end. But, I’ve learned to not do any long term projects because I know Max is one finicky-mamasita that gets upset when you try and stack too much Thanksgiving turkey on your plate.

Let’s not forget that it really is just the old max with a new coat of paint. Well, maybe a little more. I do like Max 5 and I don’t think I could go back to 4 for any reason because some of the new functionality just makes life easier. I would really just like to see it sped up.

Side rant: I do collect VST plugins, and, one of my requisites, besides sound quality of course, is, that it be responsive… which pretty much eliminates things like Rob Papen, Native Instruments, Arturia. I can find a plugin that does the same as theirs and is programmed better, thank you. Why use a terribly slow Absynth when there’s a super quick, responsive U-He Zebra plugin that perfectly matches the niche Absynth represents and does it without all the slow sliders and terrible GUI junkiness. I don’t want the knobs lagging behind the mouse cursor, getting updated at 5fps. It makes it feel like my computer is crapping out when it really isn’t… However, the fact that Native Instrument’s plugins all have terribly slow interfaces doesn’t stop them from being one of the most successful companies. I tell ya, the world is backwards!

Another analogy is that using Max 5 to me feels like playing a high end game with just a slightly lower than minimum requirement graphics card. Sure you can run up and down halls or what not, but when the screen gets cluttered with enemies, forget it! Max 5 clunks out with doing things like moving around lots of objects. Why this is, well, I theorized that the graph was being rebuilt on a per pixel basis and proposed that dragging should not rebuild the graph until a mouse up event has occurred.

All in all, I don’t know where I truly stand. I miss how snappy Max 4 felt but I feel like I can’t continue to utilize Max 4… And there were lots of problems with Max 4 that have been fixed. The GL canvas zooming now is great, the documentation and inspectors and debugger…. all good things and probably should have been available 5 years ago being as how long Max has had to evolve to this point. I just can’t get my head around all that was lost. For small things I’ll still use Max, but, what Max 5 was supposed to fix only seems to have gotten worse, regardless of some of the new conveniences.

I already made another point in the last post that sending streams of numbers to the Max window is _very_ latent and “chunky” compared to the smoothness of the stream in Max 4.

That is test 1.

Test 2 is testing the responsiveness of dragging around lots of objects.

I find it very hard to not feel slightly defeated when trying to make a point and someone like Karaokaze comes along and says “I personally, don’t care about how the GUI responds to movement of objects while editing so long as I can edit smoothly and so long as the graphics perform on-time in performance/presentation-mode (i.e. when locked), and on my G5 and my MacBook”…

I find it logical to suggest it may be my hardware but I doubt that’s the case. Like I said above, I also tried this all out on an intel MacBook with a core 2 in it and on my own Windows computer and performance in the about the same. I even went so far as to take out my graphics card and throw in a different but similar offering by ATI and the results were no better or worse.

So my question to Karaokaze or anyone that thinks Max 5 is “smooth”… If you have both 4 and 5 installed on your computer and can compare either of my two proposed tests in any way shape or form remotely close to being nearly as responsive as Max 4?

______________________________
TEST#1 compare responsiveness of printing to max window in v4 and v5

#P window setfont Verdana 10.;
#P window linecount 1;
#P newex 243 153 33 11665418 print;
#P newex 243 105 59 11665418 metro 10;
#P newex 243 82 60 11665418 loadbang;
#N counter;
#X flags 0 0;
#P newobj 243 128 66 11665418 counter;
#P window linecount 4;
#P comment 283 187 100 11665418 watch the max window in v4 and 5 , which is more responsive?;
#P connect 1 0 4 0;
#P connect 2 0 3 0;
#P connect 3 0 1 0;
#P window clipboard copycount 5;

______________________________
TEST#2 responsiveness of dragging around large amounts of varied objects

[attached]

Would it be true to say there are a significant amount of people with more skill than either you *or* I who use Max successfully every day?

I once started writing a similar critical review of the Kyma platform but could never finish it. I looked at it a few years after and was humbled by how much my perceptions of technical shortcomings had changed. I never got much work done with Kyma *even though* it’s design focuses on results (IMO successfully).

The Max scheduler *is* tight when configured properly. We (DSPaudio) managed proper timing performance with Nortron (empirically) and I have built several other scheduler based sequencers with enough precision to satisfy right and left brains. Although my experiences with Windows 3.1/95/2000/Xp & Vista has always resembled an unplanned suicide; glass & blood everywhere. I’ve no idea how a platform that prone to diversity (chaos) could provide consistent *anything*.

JUCE seems a good choice for tons of reasons and faster computers and/or optimizations will take care of redraw speeds.

In principle a faceless Max made more sense to me, but I had better not worry about what Max looks like, listeners and users don’t care.

The time vector has been scrambled. Please follow the crumbs back to your time machine and return to the previous posts to understand my comments in turn. My previous post was not intended to directly follow the OP’s latest.

If read in order, I appear agnry, but this is simply time playing a trick on you.

Oi, The forums are more sluggish than the print window I say.

Note to the OP, please continue, you’re current line of inquiry could be as important as the barfight over font rendering I witnessed while drinking a Gin & JUCE.

++, -+, –, +-

I used to work at Tekserve in New York, fixing laptops. Every once in a while, we’d get a customer who would come in and tell us what was wrong with computer. I mean, would tell us exactly what was broken, based on stuff they’d read on the net or a hunch or whatever. A few of these people were well-informed and technically astute and were right, but the majority were way off. I regret to say that I am having a moment of deja vu.

I believe that that you are drawing the wrong conclusions based on insufficient data and a willingness to assume that A always means B. Comparison of Max 4 + Max 5 side to side is useful for identifying “things which work differently now”. WHY they work differently is a whole other discussion. I think that, if you compare Max’s scheduler and DSP performance, Jitter performance and so on, you will see that (with some exceptions in both directions) Max 4 and 5 perform approximately the same.

It’s no secret that JUCE is slower than QuickDraw. On the other hand, unless your work is based on realtime drawing of patch elements, it’s not going to be noticable when you’re running your patch.

OK, deep breath. I hope that you can come to terms with Max 5′s UI for long enough to discover all of the major and minor improvements we’ve been able to add since Max 4. We’re continuing to develop and improve Max (every day!), and hope you’ll be around to enjoy the next batch of goodies.

jb

Quote: vuxivil wrote on Fri, 25 July 2008 07:53
—————————————————-
> To Bernstein:
> Thank you, and for the updates. Running your .maxpat made me think a lot about the one area I really wanted to talk about… GUI sluggishness. I noticed that the numbers getting sent to the print window were far less smooth than in Max 4…
>
> **—–Heres a quick example. Connect a metro 10 to a counter to a print object. In Max 5 it seems like the whole system is bottlenecked based on the output of the Max window. In Max 4 the numbers run down the Max window so smooth and cleanly.—-** How is it people defend Max 5 as being just as fast as Max 4 with these relatively obvious things?

There was a back and forth in Paris which really intrigued me. Basically, if I understand correctly, you can get sample accurate max timing, if you:

A: turn on over drive,
B: turn on schedule in audio interupt
C: put deferlow before *everything* which isn’t time related (Gui stuff)

Now my well researched and inadequate understanding subject leads me to believe this means that if you are running audio vectors and you have a timing intensive max process, it interrupts processing the vector and executes the string of max objects. the exception to this rule is when you have a defer your gui objects.

I never meant to imply that I thought Max’s core itself was slower, but because of the UI being slower, _felt_ dramatically slower to me. The total Max experience feels like working in a smaller world to me… Everything is waaaaaay less responsive in Max 5 and it kind of kills the whole experience.

In fact, your whole reply is pretty much null, Jeremy. I said…

“Let’s not forget that it really is just the old max with a new coat of paint.”

“That’s fine though, Max is still useful for moderate applications, but, I think that it should compensate for it’s slownesss by using the _fastest_ interface library and the _fastest_ extension language available. Instead it uses the _slowest_ for both, which makes things triple slow?”

and then at the end

“For small things I’ll still use Max, but, what Max 5 was supposed to fix only seems to have gotten worse, regardless of some of the new conveniences.”

Max 5 fixes a ton of the interface problems that Max 4 had. I can barely even look at Max 4 anymore because Max 5 seems so much more complete to me. However, Max 5 is also incredibly slow in every respect. The Max Window is just one example. I cited..

“Draw rectangles, dragging objects (plus the amount of objects you can drag before it slugs out), locking/unlocking a patcher, double click opening patches, max initial startup, moving things around with arrow keys, sliders, JSUI….”

Are any of those core Max scheduler things Jeremy, or GUI related? No, I was never under any impression that the schedulur/interpreter itself was any faster/slower. I knew months ago that was barely getting an update.

The fact is, I am OVERLY aware that Max is just the same old, not-up-to-my-standards Max that I’ve spent hundreds of thousands of hours pumping time into. My gripe with the Max core is that the speed issues I’ve experienced with the scheduler throughout the years when trying to build obnoxiously audacious, over the top systems are no where near being realized, and, the slowness of the GUI itself makes the language _FEEL_ even smaller and less capable than it was before. Go on, accuse me of not optimizing my patches enough, I dare you ;-)

The way something responds is incredibly important. I’ll give you an example/analogy.

On windows, we have MME and Directsound as possible driver options other than ASIO. Sometimes, I’ll open up Cubase and it’ll reset to an MME driver which has a default buffer of like 5512 samples, very slow. I know it’s been reset to MME because I’ll hit play and every VU meter on the mixer updates at an incredibly slow rate. Setting things back to ASIO and a 64 sample buffer sets the whole thing straight and the VU meters don’t act all clunky. And yes, VU meters are just feedback, too, like the Max window.

Essentially, what you’re telling me Jeremy is that I shouldn’t care that my VU meters are updating every 5512 samples when I’m used to seeing them update every 64. Thanks, that’s really helpful. ;-)

The Max window is just a debug window, with some text. Why then is it so difficult to make it run render it cleanly? The max objects are just flippin’ stupid little ovals, so why can’t I drag 50 of them around without the computer junking out? Is it really so off the mark to be asking why Max _feels_ slower due to the new GUI? No. Should I expect everyone to care? No. I made that quite clear in stating my surprise that people use Native Instrument’s software when the visual feedback their interface supplied was incredibly poorly rendered.

> I have a couple of tests to anyone that finds my claims of GUI
> slowness unfounded or weird.

I guess I don’t find them unfounded as much as I find your specific
issues mostly irrelevant, for most of my work.

The GUI may be slower, but it also offers _MANY_ more features. I
think that the benefit of anti-aliased, composited, alpha-blended
graphics to outweigh any slowness that I may encounter while patching.

On my largest patcher, it takes considerably longer to load in Max 5,
and considerably longer to lock/unlock, both of which are annoying.
That said, the plusses of Max 5 far outweigh the minuses, for me.

> TEST#1 compare responsiveness of printing to max window in v4 and v5

OK, Max 5 is a little “chunkier,” as you say. How does this impact you?

> TEST#2 responsiveness of dragging around large amounts of varied
> objects

Well, above some threshold of the number of objects selected, Max 4
drags outlines instead of the whole patch. It can do this faster than
Max 5 can drag the whole antialiased, alpha-composited patch,
patchcords and all.

-C

Chris Muir
cbm@well.com

http://www.xfade.com

Hmmm – 100,000 hrs / 40 hours per week / 52 weeks per year = approx. 48 YEARS.

Maybe it just feels like hundreds of thousands of hours….

:-)

Brad

I’ve made commentary about being happy with the new features. Even stating that I would find impossible to go back to 4. Essentially what you’re asking me is to not care that the GUI operates at a 1/4 the speed in light of the new features.

>
> On my largest patcher, it takes considerably longer to load in Max 5,
> and considerably longer to lock/unlock, both of which are annoying.
> That said, the plusses of Max 5 far outweigh the minuses, for me.
>
>
> > TEST#1 compare responsiveness of printing to max window in v4 and v5
>
> OK, Max 5 is a little “chunkier,” as you say. How does this impact you?

It impacts me when I decide to make one giant patch and want to start moving things around. Having to keep my patches under 40 objects to keep things moving smoothly means I have to make compromises. Can’t I just patch and not have to worry about whether or not Max will let me move my whole big patch around in 2 hours?

>
>
> > TEST#2 responsiveness of dragging around large amounts of varied
> > objects
>
>
> Well, above some threshold of the number of objects selected, Max 4
> drags outlines instead of the whole patch. It can do this faster than
> Max 5 can drag the whole antialiased, alpha-composited patch,
> patchcords and all.
>

Yep. And I propose the same solution for 5. It would make things easier. That and… I’ve bitched a theory out about how often the graph is rebuilt while dragging things around and proposed that.. while the mouse button is down, The interpreter doesn’t rebuild things.

> -C
>
> Chris Muir
> cbm@well.com
> http://www.xfade.com
>
>

Btw folks, I’m a bit surprised that you think it’s _okay_ that things are clunky. How is it that we have games with tens of million polygons flying around and physics engines running all super smooth at over 60 frames per second, yet, Max 5 can’t drag fifty 2 dimensional _OVALS_ without completely crapping out the graphics and driving one of my CPU cores to 100%? It can’t draw 2 characters on a white background every 10ms? You expect me to believe that this is asking to much of the developers?

I’m Peter Castine would have me believe that if there was _anything_ that could be done to speed it up, there would be.

So far, Ziccarelli won’t join in because the wording isn’t good enough, Bernstein & Muir think it’s pointless to care about a slow Max window, Castine thinks everything that Max is operating the best it can given the JUCE library, and everyone else just wants me to lay off Cycling because it’s a small company. Oh, and Anythony thinks my whole thread is irrelevant because I’m a “m$ windowz” dude.

Great.

It’s fine you disagree with the choice to use JUCE, but it’s an error to claim it was a mistake or that they don’t care about some of their users because of that choice. As I understand it, it was becoming way too difficult for C74 to support cross-platform releases and they found a solution that let’s them do a cross-platform/resolution independent GUI easily at the cost of some efficiency, which seems like a good compromise. Should they reach a larger user base with a slightly slower app that allows the company to stay profitable so we can all keep enjoying a Max that grows and evolves over time, or just keep chugging along with a stagnant product that will eventually die? As users we sometimes feel like our individual needs aren’t being addressed, but keep in mind the Max user base is large (and growing) and there are a lot of people with varying needs and I’m sure C74 is doing the best they can. Software is never perfect, and we’re sometimes really annoyed with its limitations, but that’s life.

So you can either submit patches that demonstrate specific performance problems and be patient and trust that Max 5 will get better over time, or you can decide it’s not worth and go write your own software or use Pd or something. I’d go with the former option, but that’s me. Don’t expect rants to solve any problems or get the response you want.

PS – speaking of varying user needs and how rants make people defensive, I personally was a little upset about the java/javascript comments you made. These features are immensely important to me and a lot of other people, and they work great if you know what you are doing. The forums are normally a place to post problems, not success stories, so if you just read the forums and don’t try it for yourself then your perspective will get skewed.

But please, by all means, package up a few of your example patches and send them to support. We’ll take a look and see what, if anything, is to be done. We’re more than happy to investigate any of this — just use the support mechanisms available.

Just because we’re a small company doesn’t mean that we shouldn’t be held accountable. On the other hand, our time resources are more limited than, say, those at Microsoft (although we do tend to release updates a lot quicker than they do), which means that we have to set priorities and devote energy to certain problems and aspects of the software, while letting other stuff wait a bit longer for attention.

All that said, I can use Max to make the kind of work I make with Max with efficiency and pleasing results, just as Max is today. Which isn’t to pretend that we don’t have plenty of work to do, but what we’ve got is imminently usable.

Finally, try to remember that Zicarelli, Bernstein, Muir and Castine and whoever else are just people like you and not part of some faceless corporate mass. We’re mostly just trying to be helpful, despite any underlying disagreements.

jb

Quote: vuxivil wrote on Fri, 25 July 2008 19:24
—————————————————-
> So far, Ziccarelli won’t join in because the wording isn’t good enough, Bernstein & Muir think it’s pointless to care about a slow Max window, Castine thinks everything that Max is operating the best it can given the JUCE library, and everyone else just wants me to lay off Cycling because it’s a small company. Oh, and Anythony thinks my whole thread is irrelevant because I’m a “m$ windowz” dude.
>
> Great.
—————————————————-

If there were a quick fix for any of the points you brought up, yes, they would have been dealt with by now. I’ve had the opportunity to directly discuss details of how Max works with quite a few of the development team over the years (btw, a word of thanks for the help that’s been extended when I’ve needed it), and these guys are all smart and capable.

I understand you were trying to be constructive in your original post, but… how can I put this? The idea that someone who’s not a developer and who doesn’t actually know what’s going on inside the code base, that someone in that position is going to have the solutions for all the problems, is not entirely realistic.

If you want good examples on how *not* to be constructive, try < http://www.cycling74.com/forums/index.php?t=msg&goto=53455&rid=250&S=7f2bb69f6d2ee21fa1d69233f0ac3d07#msg_53455> and follow the thread (there is one contributor in particular one can learn a lot from… arguably in a negative sense).

If you want to be constructive, < http://cycling74.com/twiki/bin/view/FAQs/BugReportGuidelines> is a good place to start. Caveat: it’s a lot of work to put together a good bug report. But experience teaches those are the ones that get fixed.