Max 5 — slow edition

Oct 14, 2008 at 11:18pm

Max 5 — slow edition

Hello from Britian,

Getting back into Max after a few years, and, Ive been playing around with Max 5 for the past few weeks. I must say, Ive had more crashes than I really care to mention, stability seems to be in question and couple that with a user interface, while pretty, seems to make simple things like dragging around objects a chore. It seems like the upgrade gives some things, and takes away some things… There is a latency present in everything that just didn’t exist in Max 4 and I’m really having a hard time coming to grips with it.

My ultimate conclusion is that I can do LESS with Max 5 FASTER and PRETTIER than Max 4. Not quite what I was expecting. I would have prefered like a completely rewritten, true multicore engine with a lightning fast openGL interface. Instead, well, its sort of this hack of a multicore solution with a really, really slow canvas.

And, please dont use keycommands or autocomplete as an example that Max 5 is faster. Those help speed things up, but aren’t really apart of the canvas graphical things I’m observing. They’re welcome additions, but, whatever. Presentation mode is cool too but that’s a separate entity all together. All these things would be cooler if we had the speed of Max 4′s canvas.

I might as well mention that that programs like Bidule, Reaktor, Synthedit don’t suffer at all from dragging around hundreds of objects. Bidule especially is noteworthy because it uses a GL canvas, too. No weird graphical lagging or slowness there. So, if the argument is that GL can’t be fast, I Would use Bidule as my primary example to how I think things should feel. Try it, Cycling, see how it’s done.

So, tell me, what’s on the horizon? Can things be sped up? Do most users care? Is this hard coded? Is this an issue for anyone else?

#40345
Oct 14, 2008 at 11:23pm

My advice: Get a faster computer.

I have a 6 year old G4 tower, and I haven’t experienced anything close to what you’re talking about with Max 5. No crashes, and no slowdowns on the UI that have caused me any headaches.

Maybe it’s because that 50 Hz power over there is too slow. You need to upgrade to 60 Hz. :P

#142590
Oct 14, 2008 at 11:40pm

Quote: swieser1 wrote on Tue, 14 October 2008 17:23
—————————————————-
> My advice: Get a faster computer.
>
> I have a 6 year old G4 tower, and I haven’t experienced anything close to what you’re talking about with Max 5. No crashes, and no slowdowns on the UI that have caused me any headaches.
>
> Maybe it’s because that 50 Hz power over there is too slow. You need to upgrade to 60 Hz. :P
—————————————————-

Yeah, 8 cores @ 3.0ghz probably isn’t enough. Maybe I should upgrade my 8800gt to a 280 series card? I have a mac w/ bootcamp running both XP and vista and I perceive the latency on all 3 OS’s. Shucks.

#142591
Oct 14, 2008 at 11:52pm

Yes I totally agree, dragging lines or selecting objects by dragging is surprisingly too slow in the new update 5.0.5.
I work in iMacG5 2.1hz ppc with tiger 10.4.11.

#142592
Oct 15, 2008 at 12:07am

I’m still waiting for Max 5 interface to be as fast as Max 4 before stepping
in. Dragging many objects is very slow on my MacBook Pro 2.4GHz compared to
Max4. And buying a new computer doesn’t make sense. Mine is only one year
old and the new ones, announced today, are only marginally faster.
There is also the very important issue of blurred text, to the point of
being plainly unreadable. I understood Cycling team is working on it and it
will be fixed at some time. When?
At this moment the difference is huge, see an example: crisp and clear Max 4
on the left, fuzzy Max5 on the right; “dir” becomes “dr”, the number boxes
dwarf the font sizes in a way that make them unreadable at some distance.
I’m waiting that my most important tool comes in a version with the new
functionalities without sacrificing readability and speed…
>
> Hello from Britian,
>
> Getting back into Max after a few years, and, Ive been playing around with Max
> 5 for the past few weeks. I must say, Ive had more crashes than I really care
> to mention, stability seems to be in question and couple that with a user
> interface, while pretty, seems to make simple things like dragging around
> objects a chore. It seems like the upgrade gives some things, and takes away
> some things… There is a latency present in everything that just didn’t
> exist in Max 4 and I’m really having a hard time coming to grips with it.
>
> My ultimate conclusion is that I can do LESS with Max 5 FASTER and PRETTIER
> than Max 4. Not quite what I was expecting. I would have prefered like a
> completely rewritten, true multicore engine with a lightning fast openGL
> interface. Instead, well, its sort of this hack of a multicore solution with
> a really, really slow canvas.
>
> And, please dont use keycommands or autocomplete as an example that Max 5 is
> faster. Those help speed things up, but aren’t really apart of the canvas
> graphical things I’m observing. They’re welcome additions, but, whatever.
> Presentation mode is cool too but that’s a separate entity all together. All
> these things would be cooler if we had the speed of Max 4′s canvas.
>
> I might as well mention that that programs like Bidule, Reaktor, Synthedit
> don’t suffer at all from dragging around hundreds of objects. Bidule
> especially is noteworthy because it uses a GL canvas, too. No weird graphical
> lagging or slowness there. So, if the argument is that GL can’t be fast, I
> Would use Bidule as my primary example to how I think things should feel. Try
> it, Cycling, see how it’s done.
>
> So, tell me, what’s on the horizon? Can things be sped up? Do most users care?
> Is this hard coded? Is this an issue for anyone else?
>
>

#142593
Oct 15, 2008 at 12:15am

hi,

i completely agree with you jim,
max 5 canvas is really slower than the previous version.
for example, the more 3rd party externals i have in my paths, the longer i
need to wait for max to launch, and once it’s “launched”, max needs about 1
minute to be usable. all is very slow during this ‘so long’ minute (when
dragging the max window, the position is updated every 10 seconds…)

then, once i’m able to patch, i noticed that max is really suffering from
its gl interface. moving objects goes really slow into a patch containing a
lot of objects.

what about clearing the max console? is that normal it takes about more than
1 mn to clear 1000+ lines?

i think the graphical interface speed is what we really lost with this new
version.
maybe juce was not a good choice… ?

about the multicore feature, well, i must say i’m quiet desappointed about
it… it often makes my max to crash.

i’m not saying max 5 is crap, but i really would like to know where are
going my cpu & gpu resources :-)

i like the new design (even if the texts are pretty unreadable, i have good
eyes), the modify read-only feature, the textbutton object. but is that
enough to say max 5 is better than max 4 ?

anyway, keep going cycling ! i know you’re working hard. but these points
are really important i think.

cheers

g

2008/10/15

>
> Quote: swieser1 wrote on Tue, 14 October 2008 17:23
> —————————————————-
> > My advice: Get a faster computer.
> >
> > I have a 6 year old G4 tower, and I haven’t experienced anything close to
> what you’re talking about with Max 5. No crashes, and no slowdowns on the
> UI that have caused me any headaches.
> >
> > Maybe it’s because that 50 Hz power over there is too slow. You need to
> upgrade to 60 Hz. :P
> —————————————————-
>
> Yeah, 8 cores @ 3.0ghz probably isn’t enough. Maybe I should upgrade my
> 8800gt to a 280 series card? I have a mac w/ bootcamp running both XP and
> vista and I perceive the latency on all 3 OS’s. Shucks.
>

#142594
Oct 15, 2008 at 12:49am

Todor, by magnifying the screen shot you posted it appears you have native font rendering turned off. Maybe you should try turning it on. In any event, the expectation that you can have anti-aliased text as readable at the same miniscule font size that you have used for an interface that was originally developed on a 512 x 342 pixel monitor size is pretty unrealistic.

David Z.

#142595
Oct 15, 2008 at 12:54am

>Instead, well, its sort of this hack of a multicore solution with a really, really slow canvas.

What exactly makes you conclude the multi-processing features we’ve added to Max 5 (and/or Jitter) are a hack? Do you have any alternatives that would be less hack-like in your mind?

David Z.

#142596
Oct 15, 2008 at 1:10am

Hey David,

By hack I guess I mean not a global solution. I am only aware of poly~ allowing multicore processing, which comes with its own compromise. A true multicore solution would be one where encapsulating to allow multicore wouldn’t be the scenario, but would be available anywhere in the patch.

It’s less of an issue than the GL slowness I get. I can only drag around a certain number of objects before the objects start chasing behind the mouse cursor. Patches are slow to load. Max window seems kinda clunky, too. Kinda freaks me out because I’m so used to modular environments having zero penalties for interacting with the canvas, such as in Bidule, Reaktor, or Synthedit. Of course I can encapsulate and be sensitive to the amount of objects I drag around to minimize the effects but I still feel that latency hovering over me while I patch.

Perhaps this will be addressed in the future whenever more pressing issues (whatever they may be) are sorted?

cheers.

#142597
Oct 15, 2008 at 1:34am

I’m trying to imagine what Cubase would be like if it imposed a limit on the number of midi/audio events you could drag around. I actually know that REAPER does this occasionally when you have the piano roll window too large, things start to slow down.

It’s hard for me to agree that these sorts of things are considering acceptable for any program where moving around things is an important part of the creative process. I can understand some people would not be bothered by it but there are probably some people that find it rather an unpleasant side effect of the technology, especially when there are similar offerings which don’t suffer from the problem at all.

All in all, I think while Max is slicker on the surface and certainly looks very sexy, that quickly wore off for me when I started to play with it. To be fair, PD is like this, and Max 4 is like this as well. I have very vivid memories designing my own pluggos back in the day and having problems moving items around across panels or whatever and things grinding to a halt. What’s sad is that threshold of when things start to feel clunky is much smaller now than they were in Max 4. My big wish for Max 5 was to see these sort of graphical problems that I had in Max 4 remedied by offloading the work to the GPU.

The fact that I can drag like 500 object boxes around in Bidule without any degradation in performance also has me perplexed about what could be so fundamentally different about Max that these things seem to appear only in a Max-like program and nowhere else in the modular world. (well, to be fair, Synth Maker has a rather awful canvas that suffers a lot of the same problems with moving around objects as Max does)

#142598
Oct 15, 2008 at 7:53am
#142599
Oct 15, 2008 at 3:37pm

What I have to add is not much more than what people have already mentioned, but I’ll just discuss my problems anyway.

Many, much too many, times during a patching session Max will “unexpectedly quit” on me. Fortunately, this has ingrained in me habitual saving after every edit, but when I do forget to save, it can certainly be frustrating to lose all your work of the last 1/2+ hour.Dragging around objects, not even that many objects (though waiting time does increase with more) can create very intense lag; sometimes, when I just dragged/copied a bunch of objects, I’ll let Max5 do its thing while I go online and check my email. Why not? It’s either do something, or look at the screen blankly for vast periods of time while the program works on catching up.

I never used Max4 with any intensity, but in an Audio Computing course I am currently taking at university, we have all been required to use Max4. At first, I found the lack of hotkeys and OS9 boxiness of it all rather irritating, and was embittered towards my teacher for not yletting us use Max5. But now I see why – Max 5 is not complete. It’s clear that C74 had put lots of effort into Max5, and it probably came to a point where they had to release what they had, for sake of the company’s well being, and just continue with the refinements after the release. But max5 isn’t stable and its performance isn’t where a commercial product’s performance should be.

That being said, I love MaxMSP and think the people at C74 are awesome, and trust that they will fix thes issues in due time. The OP said that other similar programs don’t suffer these same issues, but there really aren’t any other similar programs. You can’t build songs or whole live sets with other modular software. Aside from PD, MaxMSP stands alone in the level of its open endedness and adaptability. But, C74 should know that a lot of their customers are quite disappointed with the instability and slowness of Max 5.

My conclusion – Max 5 is slow and unreliable. If it’s too slow and urneliable for your taste, use Max 4 while C74 (hopefully) works on addressing these very significant issues.

#142600
Oct 15, 2008 at 3:54pm

Kyle Kaplan wrote:
> If it’s too slow and urneliable for your taste, use Max 4 while C74 (hopefully) works on addressing these very significant issues.

I’m having the same impression… but I have to say I only spent a
really short time with Max5.

Question to C74: is it still possible to buy a Max 4.6 license? I’d need
one for an installation which is intended to run for the next 20 years
(nobody there to hit the reboot knob). Couldn’t find it in the online store.

Olaf

#142601
Oct 15, 2008 at 4:24pm

If you have a Max 5 license, we will give you a Max 4 one. Just ask.

A plea to all those of you who report max 5 suffering, or any suffering.

Please try and isolate your problems and let us know about them in detail.

I know full well that in the middle of a horrendous patching nightmare with a rehearsal tomorrow it’s really hard to formulate nice bug reports, but if you get a chance to do so, this will really help us help you. As much as we would like to, there’s not much we can do with a report which says, “it’s slow, and it crashes”

-A

#142602
Oct 15, 2008 at 5:28pm

2008/10/15 Kyle Kaplan
>
> My conclusion – Max 5 is slow and unreliable.
>

I have to disagree, at least on the second part.

I have been using Max since 1990, and it is my preferred software
environment. I use it to make ridiculously huge patches, including ones that
explore aspects of AI. My current patch is over 11 MB, without any audio or
video, and it loads within seconds (on a MacBook Pro, 2.5 GHz, 4MB RAM,
10.5.5).

When Max 5 came out, I was thrilled that it addressed issues of programming,
and brought itself into the new millennia. I have grown accustomed to the
rounded corners. Like others, I have noticed two major issues: the font
aliasing, and the gradual slowing down.

In the former, this is offset by the ability to zoom in without losing
clarity (appreciated as I get older!). I took Tim Place’s suggestion, and I
use Verdana 11 point for my default font. I’ve seen some of the images that
people have posted, comparing 4.6 and 5, and it is clear there is a
difference. But perhaps this says more to user interface design than
anything else.

The latter problem happens after patching for longer periods (say, several
hours), particularly with the Inspector window open. I haven’t had Max crash
on me yet, although I’ve got used to the spinning beachball (formerly an
image of terror, now inconvenience). I’ve also learned to save before
testing the patch (but this is also a habit from working in Max 4.6).

I have Menumeters running on my Mac, which displays memory usage. Whenever
my memory usage goes above 50% (with 4 GB of RAM, with only Max running!),
Max definitely slows down. I can quit Max and restart to reclaim the memory,
but I’ve noticed that this only works a few times. After that, I have to log
out and back in again. Obviously, there is a problem here, but one that I’ve
found a relatively painless workaround.

All in all, I would never go back to 4.6.

My 2 cents, your mileage may vary.

#142603
Oct 15, 2008 at 7:16pm

#142604
Oct 15, 2008 at 7:18pm

I’m really not sure what you guys are talking about. You must have some really complicated patches. I just started copying objects over and over and trying to move them around, and it didn’t start to get choppy until I was up to 128 objects. And even then, while it was choppy (probably 100 ms between refreshes) it was entirely usable and it was certainly nowhere near “i’m going to get a cup of coffee while max catches up”. Even at 256 objects and 512 objects, it was increasingly choppy but absolutely usable. Not only that, but i have a 1GHz G4 (i.e. probably 100 times slower than your 8 core 3GHz behemoth).

Maybe this is an issue with Intel machines?

Furthermore, how often are you dragging around groups of 200+ objects at the same time? If you’re doing that often, then you may want to re-read the tutorial on encapsulation. I’ve got a reasonably complicated patch (6MB w/o audio or video files), but nowhere in it is there a singular patcher or subpatcher that has over 200 objects in it…

Anyway, I think what David and Andrew from c74 are trying to nicely tell you guys is that this thread is entirely non-productive, from the perspective of trying to fix the problem you are complaining about.

#142605
Oct 15, 2008 at 7:25pm

>i noticed that max is really suffering from
its gl interface

AFAIK Max 5′s patching interface is not done with OpenGL as Bidule’s is.

After adapting my patching style, i am now loving the new interface and miss so many of the new features when i use 4.6 (at work). There are some inevitable problems, but they are getting fixed pretty quickly.

Oli

#142606
Oct 15, 2008 at 10:49pm

Quote: swieser1 wrote on Wed, 15 October 2008 13:18
—————————————————-
> I’m really not sure what you guys are talking about. You must have some really complicated patches. I just started copying objects over and over and trying to move them around, and it didn’t start to get choppy until I was up to 128 objects. And even then, while it was choppy (probably 100 ms between refreshes) it was entirely usable and it was certainly nowhere near “i’m going to get a cup of coffee while max catches up”. Even at 256 objects and 512 objects, it was increasingly choppy but absolutely usable. Not only that, but i have a 1GHz G4 (i.e. probably 100 times slower than your 8 core 3GHz behemoth).
>
> Maybe this is an issue with Intel machines?
>
> Furthermore, how often are you dragging around groups of 200+ objects at the same time? If you’re doing that often, then you may want to re-read the tutorial on encapsulation. I’ve got a reasonably complicated patch (6MB w/o audio or video files), but nowhere in it is there a singular patcher or subpatcher that has over 200 objects in it…
>
> Anyway, I think what David and Andrew from c74 are trying to nicely tell you guys is that this thread is entirely non-productive, from the perspective of trying to fix the problem you are complaining about.
—————————————————-

Well, this is pretttttttty funny.

I said pretty much the same thing about Max 5 a few months back and have decided to give it a year before trying it again because it was so slow and unusable. I could change the way I patch and be all uber careful about the number of objects I want to move around but what’s the fun in that. I have plenty of complex subpatches (well “had” is probably the better word) that acted as isolated functions that had at least 50 objects or more in them.

swieser1, you’re guestimating the speed of moving things around to be at around 10 frames a second…… 10 whole big whopping frames…? You’re saying that 10 frames per second when moving 100 little ovals (with alpha layers at that) is _fine by you_? Well, holy b-jesus, mother have mercy, thank you for having absolutely NO degree of quality standards with the software that you use. You’re the kind of happy-go-lucky customer every company lusts after.

On my computer it’s more like 10 frames a second with 50 objects, and I have plenty of subpatchers and everything’s encapsulated into functions and modules and components, etc.

I loaded up Bidule to try that out and can move around 1000 objects at a solid 60 frames or higher. No slowdown or any chunky bullshit. The point is not necessarily that you would ever move around that many objects, but stress testing the canvas to know that it can handle anything you throw at it.Lame. It speaks volumes about the state of things.

How can you call this a platform for video when the canvas starts throwing out frames when moving 50 or so objects? A platform for interactive performance shouldn’t junk out at all when you interact with it…. at all.

I only use Windows and noticed tons of crashes with 5.04 and the latency that’s already been mentioned. I’ve ditched Max all together. I’m not sticking around with 4.6 because all the little perks that Max 5 added to the table pretty much make 4 seem obsolete, but, the inherent sludginess of Max 5 drives me batshit crazy.

#142607
Oct 16, 2008 at 12:10am

Quote: ComfortableInClouds wrote on Wed, 15 October 2008 09:37
—————————————————-
> That being said, I love MaxMSP and think the people at C74 are awesome, and trust that they will fix thes issues in due time. The OP said that other similar programs don’t suffer these same issues, but there really aren’t any other similar programs. You can’t build songs or whole live sets with other modular software. Aside from PD, MaxMSP stands alone in the level of its open endedness and adaptability. But, C74 should know that a lot of their customers are quite disappointed with the instability and slowness of Max 5.
>
> My conclusion – Max 5 is slow and unreliable. If it’s too slow and urneliable for your taste, use Max 4 while C74 (hopefully) works on addressing these very significant issues.
>
>
—————————————————-

Dude, it’s not gonna get faster. I railed this forum about the same problem and eventually got a few people to spew out the awful truth. No one at Cycling nor some of the Greater Xenophobes Denizens of this forum give a hootin-holler if it feels slow. Either that or a flat out incapacity to perceive the latency, which is probably the more disturbing. LOL.

I was always perplexed how people could use Mackie’s Traktion. That program is pure molasses. It’s the most junky sequencer I think that is available. Yet, people use it, heh. It’s all slow as hell and people still use it. Mind-boggling. Ask them how they feel about how slow the whole thing is and they’ll go “huh, what the hell are you talking about?”. Their senses and ability to perceive time are probably dulled from too much reefer or something.

As for solutions, “Encapsulate and drag less stuff around”. That’s the best you’re gonna get.

#142608
Oct 16, 2008 at 12:47am

>
> Dude, it’s not gonna get faster.
>

Hmm, I was at first going to label this as pessimistic, but maybe you’re right? Could it be that C74 is working to address these issues, or is the slow nature of Max 5 ingrained in it? Will it be like this for “the next 20 years”? Let us ask C74.

To C74 employees – do you currently see this as a problem? Are you currently working to reduce lag time and crashes that occur in Max 5? Do you know of specific instances where crashes seem to be occuring? Do you know why Max 5 slows down significantly after prolonged use?

Also – Max 4.63 was stable, but that was after 63 upgrades (does it work like that, with each upgrade adding +.01 to the version number, or is it like +.1 for a major upgrade, +.01 for a minor upgrade?). Max 5 has had 5. Saying it won’t get faster, EVER, this early in the game is fairly ridiculous.

To me, vuxivil, it seems that you are simply overcome with frustration by the state Max is in and are letting those emotions influence your post.

#142609
Oct 16, 2008 at 1:42am

Welllllllll, theres no point in asking. I already did, they said no. They see it as small time.

But, let us not forget, my brother, that there was graphical problems in Max 4. You can get the same latency weirdness in Max 4, it just takes more objects, heh. Not in the other modular programs though.

#142610
Oct 16, 2008 at 3:57am

I did however, propose a theory and a solution which I still think might be valid. I theorized that the reason why Max junks out when dragging things around is because the whole thing is being reinterpreted and translated into code at intervals so long as the mouse button is being held down, probably due to the so called implicit right to left ordering that can be found in wiring things up without using outlets to determine order.

Think about it. You move a portion of code that has implicit connections (implicit meaning based on wire versus outlet ordering) well, if you cross a certain point, Max needs to know when the ordering, based on the position of the wires, changes, so it must constantly rebuild things while there is something being dragged around.

Damn, this is a really easy theory to test, too. I think I’ll test it now and write back.

#142611
Oct 16, 2008 at 4:03am

Once more, with feeling.

When we recieve specific reports of concrete problems, we try as best we can to reproduce them and fix them.

If you are unhappy, please let us know in as much detail as you can what’s going on in your specific case.

support at cycling 74 dot com is your friend.

Cheers

-A

#142612
Oct 16, 2008 at 4:09am

Damn, doesn’t work.

You can see that the graph or whatever the fug the end result of the interpreter doesn’t get updated until the mouse button gets released.

All you gotta do is drag message box “a” to the left of “b”, but hold the mouse button down. You’ll notice that max doesn’t put the “b” before the “a” (in the max window) until the mouse button is released, so my theory is fudge. The pound signs just act as a separator.

#P window setfont “Sans Serif” 10.;
#P window linecount 2;
#P message 216 188 103 196618 ###################;
#P window linecount 1;
#P newex 143 98 70 196618 metro 1000;
#P newex 143 125 27 196618 b;
#P newex 204 278 26 196618 print;
#P window setfont “Sans Serif” 10.;
#P message 163 190 14 9109514 a;
#P window setfont “Sans Serif” 10.;
#P message 143 189 14 196618 b;
#P newex 143 70 53 196618 loadbang;
#P window linecount 6;
#P comment 30 115 100 196618 drag the a to the left of the b , but don’t let go til you’ve seen that a is still perceived as right of the b , then let go;
#P window linecount 5;
#P comment 243 47 100 196618 does max constantly update the scheduler while dragging stuff around? NO.;
#P connect 6 0 3 0;
#P connect 6 0 4 0;
#P connect 6 1 8 0;
#P connect 7 0 6 0;
#P connect 8 0 5 0;
#P connect 3 0 5 0;
#P connect 4 0 5 0;
#P connect 2 0 7 0;
#P window clipboard copycount 9;

#142613
Oct 16, 2008 at 4:20am

Quote: Andrew Pask wrote on Wed, 15 October 2008 22:03
—————————————————-
> Once more, with feeling.
>
>
> When we recieve specific reports of concrete problems, we try as best we can to reproduce them and fix them.
>
> If you are unhappy, please let us know in as much detail as you can what’s going on in your specific case.
>
> support at cycling 74 dot com is your friend.
>
> Cheers
>
> -A
—————————————————-

Okay, there is something funny about the way Andrew is almost begging. It almost seems like he’s so obsessed with making sure people follow the “rules” that he can’t seem to understand that the problem doesn’t even need a bug report.

The one person whose stated the problem doesn’t exist, swieser1, is the one who explained the symptoms in the clearest detail! What he says is acceptable, working at 2 frames a second (in the canvas, nothing to do with jitter), is exactly what other people are having issues with and calling slow.

swieser1 is getting around 100ms update latency moving around 128 objects. I get about the same but with less objects, more around 45-50. Everyone whose stated Max is slow is talking about how this starts happening depending on how many objects you drag around and want to know why. I also get the rubberband mouse effect where the objects chase behind the mouse cursor if I try to drag too much. We just wanna know what the deal is and why Max is so slow with moving things around.

It’s all in the thread. LOL.

#142614
Oct 16, 2008 at 5:18am

(long sigh) Here it goes again. ;)

#142615
Oct 16, 2008 at 7:26am

jim_scumford@yahoo.com wrote:

“Bidule especially is noteworthy because it uses a GL canvas, too. No weird graphical lagging or slowness there. So, if the argument is that GL can’t be fast, I Would use Bidule as my primary example to how I think things should feel. Try it, Cycling, see how it’s done.”

Bidule doesn’t handle video at all. Please don’t try using a GL canvas, Cycling! I want to apportion my GPU the way a professional Maxer SHOULD: using Jitter’s GL rendering functionalities.

vuxivil wrote: “Damn, doesn’t work.”
Story of your life, vuxivil, get used to it.

And to the rest of the posts about crashes:
I haven’t had that many crashes at all: i’m on a regular MacBook with 2GHz IntelCore2Duo, 2GB RAM, and Leopard 10.5.5; i’m running 4 intensive samplers i’ve made on my own using granular-style-hanning-windowing over play~ objects, 4 tapin-tapout style delays with 10,000milliseconds of buffered delay, and 4 shapee~ objects(FFT-beauty by Eric Lyon) with a total of 53% CPU usage at 48kHz(i/o and sig vector sizes of 128 and the scheduler in overdrive) and NO CRASHES) what the hell is everyone doing to crash so much?! No really! Try and trace it and then write it down in a concise bug-report(with full-system specs and DSP status specs) if you actually are crashing. Otherwise, you probably aren’t bothered enough about those crashes so why write anything.

Don’t be a hater.

#142616
Oct 16, 2008 at 9:31am

On 16 oct. 08, at 06:09, vuxivl wrote:

> Damn, doesn’t work.
>
> You can see that the graph or whatever the fug the end result of the
> interpreter doesn’t get updated until the mouse button gets released.
>
> All you gotta do is drag message box “a” to the left of “b”, but
> hold the mouse button down. You’ll notice that max doesn’t put the
> “b” before the “a” (in the max window) until the mouse button is
> released, so my theory is fudge. The pound signs just act as a
> separator.

That’s not correct:

http://www.e–j.com/dl/troll2.mov

Feel free to provide serious bug reports.
Best,
ej

#142617
Oct 16, 2008 at 10:00am

Quote: Emmanuel Jourdan wrote on Thu, 16 October 2008 11:31
—————————————————-

> That’s not correct:
>
> http://www.e–j.com/dl/troll2.mov
>
> Feel free to provide serious bug reports.
> Best,
> ej

Thank you for disproving this BS, e–j.

Completely OT: what program did you use to make the screen capture?

regards,
klaas-jan govaart

#142618
Oct 16, 2008 at 10:24am

On 16 oct. 08, at 12:00, Klaas-Jan Govaart wrote:

> Thank you for disproving this BS, e–j.
>
> Completely OT: what program did you use to make the screen capture?

Snapz Pro. Although the last time I looked into that I found
ScreenFlow really really cool, just a little bit expensive for my needs:

http://www.ambrosiasw.com/utilities/snapzprox/

http://www.flip4mac.com/screenflow.htm?utm_source=vara&utm_medium=referral&utm_campaign=varahome&utm_term=screen

ej

#142619
Oct 16, 2008 at 10:29am

To continue near topic.

The core argument (memory leaks aside):

Max5 has a sluggish canvas. This is important to many users because they enjoy programming at the speed determined by their keyboard and mouse.

The faces behind Max5 are developing with text based languages like C and Java. If they were suddenly forced to use a 300baud terminal connection to write code, they would probably set about finding faster ways to transfer data before continuing the work.

Race car drivers need responsive steering. Computer users need a snappy canvas. A lagged response from any UI results in fatigue.

*Every* user of Max5 would benefit from the UI being sped up.

Solutions / Responses:

Using Max5 what speed machine today or tomorrow will bring us in range of a Max 4.6 patching experience?

If the sluggish canvas is likely to persist on 3 & 4ghz machines will C74 consider working with the developers of JUCE to improve the library’s rendering speed?

Specifically for this thread:

Perhaps a better categorization of the Max5 ‘slownesses’ and their effects on the user experience would benefit all. When describing your experience please include, Platform, CPU, GPU, Ram and Bus speeds as that will help other readers know where you are coming from.

The main thread points I could pick out so far:

* Slow load times – [Of what exactly?, patchers, collectives,
Standalones, Max5 itself, etc.]

* Slow Canvas – [group drag, what else is slow?]

* Message, Signal & Jitter processing appear to be unaffected

-Anthony

#142620
Oct 16, 2008 at 3:21pm

Quote: Emmanuel Jourdan wrote on Thu, 16 October 2008 03:31
—————————————————-
> On 16 oct. 08, at 06:09, vuxivl wrote:
>
> > �Damn, doesn’t work.
> >
> > You can see that the graph or whatever the fug the end result of the
> > interpreter doesn’t get updated until the mouse button gets released.
> >
> > All you gotta do is drag message box “a” to the left of “b”, but
> > hold the mouse button down. You’ll notice that max doesn’t put the
> > “b” before the “a” (in the max window) until the mouse button is
> > released, so my theory is fudge. The pound signs just act as a
> > separator.
>
>
> That’s not correct:
>
> http://www.e–j.com/dl/troll2.mov
>
> Feel free to provide serious bug reports.
> Best,
> ej
>
>
>
—————————————————-

EJ…EJ…EJ,

It was never, from the start, ever meant to have anything to do with displaying a bug in Max (4). .I was just testing out a certain aspect of the scheduler, and, on Windows, I had disproved what I theorized a possible reason for graphical sluggishness if the behavior existed, which it doesn’t.

Original Question: Does Max rebuild the graph, at intervals, when you drag objects around?

Original Guess: Yes.
Actual Answer: No.

The patch I posted was proof of concept. Max doesn’t rebuild the graph until you’ve let go of the mouse button.

#142621
Oct 16, 2008 at 3:25pm

Also, if Max DID rebuild the graph while dragging objects aroudn, that additional CPU burden could have been the reason for the graphical problems people experience with the more objects they choose to drag around. Since that is NOT how Max behaves, I personally know now the problem exists elsewhere.

#142622
Oct 16, 2008 at 3:31pm

@EJ

You know, sorry to keep talking about this, but on Max 4, which is what I made the patch on, on Windows XP, when I drag the “b” to the left of the “a”, the “b” doesn’t start printing before the “a” until the mouse button is released.

In your video, EJ, your scheduler is rebuilt while the mouse button is down. I don’t get that at all.

Seems there is a different, either in how Max operates on Windows or how it operates versus 4 and 5.

I’ll try and find some Windows movie capture software I guess.

#142623
Oct 16, 2008 at 3:55pm

For god’s sake, could you collect all your thoughs in one post, instead of making a news post for each paragraph?

Also, your attitude isn’t too far removed from that of an arrogant a-hole, so I’m not really surprised you’re not getting the help you are begging for.

Just my two cents, of course.

#142624
Oct 16, 2008 at 4:10pm

Quote: Anthony Bisset wrote on Thu, 16 October 2008 03:29
—————————————————-
> Max5 has a sluggish canvas. This is important to many users because they enjoy programming at the speed determined by their keyboard and mouse.
> …
> *Every* user of Max5 would benefit from the UI being sped up.
>

Yes, absolutely.

> If the sluggish canvas is likely to persist on 3 & 4ghz machines will C74 consider working with the developers of JUCE to improve the library’s rendering speed?
>

I don’t think we can necessarily assume JUCE is at fault here, or at least not completely at fault. It might have more to do with the new underlying JSON object model, or who knows what. The only way to effectively improve performance in complex software is to use software tools to find the bottlenecks. We can’t talk our way through these problems on a forum, because we don’t know what’s going on under the hood.

> Perhaps a better categorization of the Max5 ‘slownesses’ and their effects on the user experience would benefit all. When describing your experience please include, Platform, CPU, GPU, Ram and Bus speeds as that will help other readers know where you are coming from.

Although this is generally a good idea for bug reports, it may result in unhelpful information overload here. I think everyone will agree that the Max canvas is slower in Max 5 than in 4. It’s certainly doing more work in 5, so it makes sense.

One thing vuxivil said that I agree with is this problem does not require a bug report. File it under “general performance improvements”. It doesn’t matter how slow it’s running on some specific computer, just do whatever you can to speed things up. Any noticeable improvement will be appreciated by the user base.

The C74 programmers seem like smart people. I’m sure someone there knows how to use profiling tools, they can track down some of the worst bottlenecks and try to flush them out.

> The main thread points I could pick out so far:
> …
> * Slow Canvas – [group drag, what else is slow?]

This seems to be the main issue people keep complaining about. Hopefully speeding this up could become a priority once some other high priority items (SDK, Pluggo) are taken care of.

For me, I have found duplicating objects to be waaaaay slower than in Max 4. 4 was “instantaneous”, in 5 there is up to a multi-second delay depending on the complexity of what I’m duplicating (big abstractions, for example).

#142625
Oct 16, 2008 at 4:25pm

Re. your slow-down-patch, vuxivil: Am I supposed to move the “a” to the left of “b” while the patch is running in unlocked mode, all while holding down the mouse button?

This is working just fine on my machine. No lag, no nothing.

Please let me know if I’ve misunderstood.

#142626
Oct 16, 2008 at 4:35pm

Quote: oivindi wrote on Thu, 16 October 2008 10:25
—————————————————-
> Re. your slow-down-patch, vuxivil: Am I supposed to move the “a” to the left of “b” while the patch is running in unlocked mode, all while holding down the mouse button?
>
> This is working just fine on my machine. No lag, no nothing.
>
> Please let me know if I’ve misunderstood.
>
—————————————————-

Oooops, guess I should have anticipated this.

Oivindi, it’s not about speed or lag or anything like that. I was testing to see if the interpreter rebuilt things while dragging objects around.

On my computer, when I drag and hold the A to the left of the B, the B doesn’t start printing in the Max window until I let go of the mouse button. I think this is enough to prove that the graph (or whatever the interpreter “builds”) is put on hold til the mouse button is let go.

However! On Emmanul Jordan’s Max 5 OSX machine, the A does appear after the B before he let’s go of the mouse button. I would be able to test this if my Max 5 demo hadn’t expired, but….

It seems there’s a difference between how Max 4 on XP and how Max 5 on OSX handles dragging objects around in regards to when it decides to rebuild the code currently in the canvas.

You don’t need to run this test to confirm anything at this point if you’re still confused about what it’s about. Feel free to disregard.

#142627
Oct 16, 2008 at 4:38pm

> On my computer, when I drag and hold the A to the left of the B, the B doesn’t start printing in the Max window until I let go of the mouse button. I think this is enough to prove that the graph (or whatever the interpreter “builds”) is put on hold til the mouse button is let go.
——————————-

Sorry, this should say… the B doesn’t start printing BEFORE THE A in the Max window until….

#142628
Oct 16, 2008 at 5:21pm

Quote: vuxivil wrote on Thu, 16 October 2008 09:35
—————————————————-
> On Emmanul Jordan’s Max 5 OSX machine, the A does appear after the B before he let’s go of the mouse button.

I know what you are talking about, and it is a good point.

I personally don’t see why the right-to-left order needs to constantly update while dragging the mouse. Maybe some people think it is good for usability or whatever, but it is really necessary to try to keep the patch in a completely accurate state every instant while dragging objects around? It seems to me that waiting until the mouse button is lifted, and then recalculating the object graph *once* would potentially improve canvas performance by a noticeable amount.

Of course we’re just guessing based on what we can observe, but it certainly seems like Max 5 is doing a lot of unnecessary work as the mouse drags.

#142629
Oct 16, 2008 at 5:35pm

Quote: Adam Murray wrote on Thu, 16 October 2008 11:21
—————————————————-
> Quote: vuxivil wrote on Thu, 16 October 2008 09:35
> —————————————————-
> > On Emmanul Jordan’s Max 5 OSX machine, the A does appear after the B before he let’s go of the mouse button.
>
> I know what you are talking about, and it is a good point.
>
> I personally don’t see why the right-to-left order needs to constantly update while dragging the mouse. Maybe some people think it is good for usability or whatever, but it is really necessary to try to keep the patch in a completely accurate state every instant while dragging objects around? It seems to me that waiting until the mouse button is lifted, and then recalculating the object graph *once* would potentially improve canvas performance by a noticeable amount.
>
> Of course we’re just guessing based on what we can observe, but it certainly seems like Max 5 is doing a lot of unnecessary work as the mouse drags.
—————————————————-

Yes… I agree. There are two things which Max 5 apparently does that Max 4 doesn’t, albeit I can’t test Max 5 on Windows because I’m outa demo, and I can’t test Max 4 on Mac because, well, I don’t own one.

In Max 4, objects aren’t drawn (they are merely outlined), and the interpreter doesn’t rebuild things, until the mouse button is let go.

In Max 5, objects are redrawn when moved and the interpreter rebuilds the code while dragging objects around.

Obviously, in Max 5, there more things you drag around the more redrawing is done and the more rebuilding that is done, which would explain why things degrade pretty linearly based on the number of objects you drag around.

#142630
Oct 17, 2008 at 11:18pm

I’ll agree that the canvas is slow, but it’s not slow enough to really interfere with anything I’m doing. It may also be that I expect it to be slow, because I have a relatively slow computer and everything is slow on it. In a few days when my new MBP arrives, I will certainly expect it to run a lot faster than my 1GHz G4. If it doesn’t, I’d probably change my stance on this issue.

However, I think there are probably more important things for c74 to deal with right now than speeding up the frame rate of dragging objects around. In the end, what really matters is that your patch performs well during a performance. You’re not going to be dragging objects around and creating new objects in a performance. So, let’s let them get that right first, fix any objects that are crashing, and concentrate on the luxuries later.

If I remember correctly, I believe in Max 4 (for Mac), once you started dragging a lot of objects, like more than 20 or so, instead of actually redrawing the entire object each “frame”, it just drew a dotted outline of the objects instead, which made for much faster frame rates. Perhaps this quick fix could be implemented in the interim?

#142631
Oct 18, 2008 at 6:24am

Olaf Matthes schrieb:
> Question to C74: is it still possible to buy a Max 4.6 license? I’d need
> one for an installation which is intended to run for the next 20 years
> (nobody there to hit the reboot knob). Couldn’t find it in the online
> store.

If its intended for running 20 years, I’d set it up to reboot from time
to time automatically, and I’d either use Max 5 for the better file
format, usability and graphics, or Pd for its open nature (especially if
no UI is involved…)

Only the graphical/visual part is slower in Max 5 and this is something
which can be optimized. You don’t need a separate Max license for an
installation. That will run on a runtime…

I’d love to see Max projects intended for running the next 100 or 1000
years, painting and scribbling scores still seems more durable… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#142632
Oct 18, 2008 at 7:37am

A piece of advice:

if you are frequently trying to drag 100-200 objects around, you have big big problems with your patching style. Your patches must be utter clusterf*cks.

Learn to encapsulate. Also, look into poly~. Use sends/receives instead of patch cables. Your patches will get better and your problems will disappear.

It’s your own fault, because you’re patching stupidly.

#142633
Oct 18, 2008 at 7:40am

ugh

#142634
Oct 18, 2008 at 8:27am

Stefan Tiedje wrote:
> If its intended for running 20 years, I’d set it up to reboot from time
> to time automatically, and I’d either use Max 5 for the better file
> format, usability and graphics

Hi Stefan,

who needs better file format, usability and graphics for an already
existing Max patch that’s running on a machine somewhere in a basement
without even a screen attached to it? :-)

As for the rebooting, of course we do that (once a week).

> You don’t need a separate Max license for an
> installation. That will run on a runtime…

But I will contact C74 to see whether I can still get an iLock license
for Max 4.6 since it regularly happens to me that I service existing
installations that run on Max 4.(5|6) Runtime. It’s really a pain to
always have to copy the patch again from another machine when small
changes have been made.

Getting really OT now: The main issue for not upgrading to Max5 on that
particular machine is that we spent about 2 month until we got Max4
working with Windows Remote Desktop. After logging into the machine the
second time even an idle Max (no patches loaded) would eat up 30% CPU
power. Took a lot of tricks to get that sorted. I don’t want to fight
that again with Max5. Ah, and before anybody says use VNC or something
else (or a Mac): we can’t since the local admin says we can’t (i.e. are
not allowed to).

Olaf

#142635
Oct 20, 2008 at 6:36am

Olaf Matthes schrieb:
> who needs better file format, usability and graphics for an already
> existing Max patch that’s running on a machine somewhere in a basement
> without even a screen attached to it? :-)

I was thinking of an art archaeologist who might find that still running
patch long after we’re buried in the dust of history, it would be easier
for her to find out what the hell is going on. (only the file format is
relevant for that, they’ll laugh about usability and wonder how we ever
where able to create anything with our ancient tools… ;-)


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#142636

You must be logged in to reply to this topic.