swieser1

There has been a significant discovery (regarding Max 5 canvas performance) made in the midst of the past few flaming threads, but I seriously doubt that any of the c74 staff have wasted their time to wade through the dozens of childish name-calling posts to find it. So, I've started a thread to seriously discuss this performance issue, without the detrimental insult posts to confuse everyone.

The complaint is that Max 5's canvas is slower than many people would like. When dragging many objects around, the frame rates can get somewhat low. The discovery which was made was that Max 5, unlike Max 4, constantly recompiles the patch as you drag objects around. To prove this discovery, vuxivil created a patch with a metro object that bangs two message boxes. While the metro is running, you can drag one message box to the other side of the other message box, and the order in which they are banged changes BEFORE you've let go of the mouse. This seems to indicate that Max is doing a lot of behind-the-scenes calculations, which may or may not be unnecessary, and which may or may not be contributing significantly to the GUI slowdowns. The patch vuxivil created is below:

Continuing with this logic, how can we test if this is actually causing performance degradation? I thought of one way, which may or may not prove anything. I made a patch with 256 unpatched metro objects. When I select them all and try to drag them around (on my slow G4) I get a frame rate of about 4 FPS. Then, I made a patch with 256 metro objects, all connected in a line. When I drag these 256 objects around, I get a frame rate of about 2 FPS. To me, this is a possible hint. My theory is that Max has to do a lot of extra calculations to recompile the patch when the objects are connected vs. when they are not connected. This is why the performance is much lower when they are connected. Thus, if Max was not recompiling the patch during drags, and just recompiled once on mouseup (which I believe the majority of Max users would not cry about), then we should expect a significant performance increase. Below is the unconnected metro patch followed by the connected metro patch, for you to try yourself:

One other thing I've found while playing around: The frame rate drops way down even as you are selecting a lot of objects. If you drag a selection window across a number of objects, once you have 4 or 5 objects selected the frame rate is still fine, as you near 100 objects the frame rate gets noticeably lower, etc. The frame rate for selecting objects seems to be the same as the frame rate for moving that same number of objects around. This seems strange.

So, can anyone try these patches and confirm what I'm talking about? Also, c74 staff: do you have any comments to add?

Let's keep this constructive and professional.

There has been a significant discovery (regarding Max 5 canvas performance) made in the midst of the past few flaming threads, but I seriously doubt that any of the c74 staff have wasted their time to wade through the dozens of childish name-calling posts to find it.  So, I've started a thread to seriously discuss this performance issue, without the detrimental insult posts to confuse everyone.

The complaint is that Max 5's canvas is slower than many people would like.  When dragging many objects around, the frame rates can get somewhat low.  The discovery which was made was that Max 5, unlike Max 4, constantly recompiles the patch as you drag objects around.  To prove this discovery, vuxivil created a patch with a metro object that bangs two message boxes.  While the metro is running, you can drag one message box to the other side of the other message box, and the order in which they are banged changes BEFORE you've let go of the mouse.  This seems to indicate that Max is doing a lot of behind-the-scenes calculations, which may or may not be unnecessary, and which may or may not be contributing significantly to the GUI slowdowns.  The patch vuxivil created is below:

Continuing with this logic, how can we test if this is actually causing performance degradation?  I thought of one way, which may or may not prove anything.  I made a patch with 256 unpatched metro objects.  When I select them all and try to drag them around (on my slow G4) I get a frame rate of about 4 FPS.  Then, I made a patch with 256 metro objects, all connected in a line.  When I drag these 256 objects around, I get a frame rate of about 2 FPS.  To me, this is a possible hint.  My theory is that Max has to do a lot of extra calculations to recompile the patch when the objects are connected vs. when they are not connected.  This is why the performance is much lower when they are connected.  Thus, if Max was not recompiling the patch during drags, and just recompiled once on mouseup (which I believe the majority of Max users would not cry about), then we should expect a significant performance increase. Below is the unconnected metro patch followed by the connected metro patch, for you to try yourself:

One other thing I've found while playing around:  The frame rate drops way down even as you are selecting a lot of objects.  If you drag a selection window across a number of objects, once you have 4 or 5 objects selected the frame rate is still fine, as you near 100 objects the frame rate gets noticeably lower, etc.  The frame rate for selecting objects seems to be the same as the frame rate for moving that same number of objects around.  This seems strange.

So, can anyone try these patches and confirm what I'm talking about?  Also, c74 staff: do you have any comments to add?

Let's keep this constructive and professional.


serious-max-5-performance-thread

There's 2 separate but related problems in Max5 which shouldn't be lumped into one.

The problems are: JUCE's code, and MAX's code.

Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios-- a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE's performance couldn't be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt's software rendering of vector is also devastatingly faster than JUCE.

And this is the *foundation* of the future of Max... Think about that for a moment.

The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven't worried about it since.

It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.

If Max5 was truly pushing the envelope, right on the edge of what's even possible to do with our computers-- doing something amazing on computers just barely capable of keeping up with its demands, I'd be using it and loving it despite the flaw. But rather, the *missed potential* as a result of Cycling's choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.

If Cycling is interested in some CPP code to show how ridiculous JUCE is, I'll provide it, but this is trivial for them to whip up.

The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui's are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That's out of Cycling's control unless we started seeing commits by them, and that shouldn't be their job.

2) Specifically addressing swieser1 and vuxivil's point:

Cycling has coded Max5 in a way which is *straightforward* and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It's 'Solve the problem cleanly first, and then optimize later.' The patch which vuxivil provided demonstrates Max5's *straightforward* implementation.

If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won't work for Max5 because of its faulty foundation. JUCE's weakness triggers a chain of events which ruins Max's straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.

And this is the *foundation* of the future of Max... Think about that for a moment.
What a wonderful executive move.

It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.  

2) Specifically addressing swieser1 and vuxivil's point:
Max 5's code.

If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won't work for Max5 because of its faulty foundation. JUCE's weakness triggers a chain of events which ruins Max's straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.


- Kindly move this commentary into a new thread, perhaps titled "Juice

Tests to Examine Latency", and **post supporting code**. How do I know

what you're saying is true? Sounds to me like you're pulling numbers

out of thin air, so PLEASE prove me wrong. Post code, system specs,

and an XCode and/or VisualStudio project file so other people can test

- We're trying to keep this thread for SERIOUS isolation of Max5

performance issues. Continuing your last rant in this thread just

isn't right. Surely you can understand that. Competent community

members are now trying to follow up on your complaint; they don't need

more cathartic input from you at this time.

On Tue, Oct 21, 2008 at 5:15 PM, Zola wrote:

> There's 2 separate but related problems in Max5 which shouldn't be lumped into one.

> The problems are: JUCE's code, and MAX's code.

> Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios-- a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE's performance couldn't be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt's software renderin

> of vector is also devastatingly faster than JUCE.

> And this is the *foundation* of the future of Max... Think about that for a moment.

> The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven't worried about it since.

> It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.

> If Max5 was truly pushing the envelope, right on the edge of what's even possible to do with our computers-- doing something amazing on computers just barely capable of keeping up with its demands, I'd be using it and loving it despite the flaw. But rather, the *missed potential* as a result of Cycling's choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.

> If Cycling is interested in some CPP code to show how ridiculous JUCE is, I'll provide it, but this is trivial for them to whip up.

> The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui's are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That's out of Cycling's control unless we started seeing commits by them, and that shouldn't be their job.

> 3) Specifically addressing swieser1 and vuxivil's point:

> Cycling has coded Max5 in a way which is *straightforward* and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It's 'Solve the problem cleanly first, and then optimize later.' The patch which vuxivil provided demonstrates Max5's *straightforward* implementation.

> If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won't work for Max5 because of its faulty foundation. JUCE's weakness triggers a chain of events which ruins Max's straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.

- Kindly move this commentary into a new thread, perhaps titled "Juice
Tests to Examine Latency", and **post supporting code**. How do I know
what you're saying is true? Sounds to me like you're pulling numbers
out of thin air, so PLEASE prove me wrong. Post code, system specs,
and an XCode and/or VisualStudio project file so other people can test
your assertions.
- We're trying to keep this thread for SERIOUS isolation of Max5
performance issues. Continuing your last rant in this thread just
isn't right. Surely you can understand that. Competent community
members are now trying to follow up on your complaint; they don't need
more cathartic input from you at this time.

On Tue, Oct 21, 2008 at 5:15 PM, Zola  wrote:
>
> There's 2 separate but related problems in Max5 which shouldn't be lumped into one.
>
> The problems are: JUCE's code, and MAX's code.
>
> 1A) JUCE's performance.
>
> Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios-- a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE's performance couldn't be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt's software renderin
 g!
>  of vector is also devastatingly faster than JUCE.
>
> And this is the *foundation* of the future of Max... Think about that for a moment.
> What a wonderful executive move.
>
> The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven't worried about it since.
>
> It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.
>
> If Max5 was truly pushing the envelope, right on the edge of what's even possible to do with our computers-- doing something amazing on computers just barely capable of keeping up with its demands, I'd be using it and loving it despite the flaw. But rather, the *missed potential* as a result of Cycling's choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.
>
> If Cycling is interested in some CPP code to show how ridiculous JUCE is, I'll provide it, but this is trivial for them to whip up.
>
> 1B) JUCE's latency.
>
> The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui's are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That's out of Cycling's control unless we started seeing commits by them, and that shouldn't be their job.
>
> 3) Specifically addressing swieser1 and vuxivil's point:
> Max 5's code.
>
> Cycling has coded Max5 in a way which is *straightforward* and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It's 'Solve the problem cleanly first, and then optimize later.' The patch which vuxivil provided demonstrates Max5's *straightforward* implementation.
>
> If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won't work for Max5 because of its faulty foundation. JUCE's weakness triggers a chain of events which ruins Max's straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.
>
>


At this point, further pontification on the subject of performance, including speculation about our coding practices, executive decision-making, use of third-party technology, etc. is no longer of any interest to anyone at Cycling '74, and does not serve the purpose of obtaining the desired performance optimizations in future versions. It just wastes the time of the people who could be working on the problem, but, like passers-by at the scene of an accident, feel compelled to look at the latest uninformed screed.

I appreciate that a small number of users are concerned about the speed at which hundreds of objects can be dragged around. Frankly, we haven't spent a lot of time optimizing this particular case up to this point. However, since pretty much anything can be optimized with effort once it has been identified as a problem, we are currently in the process of looking at it. I can tell those of you who might care that based on our preliminary analysis, all the speculation about the source of the performance problems that has been posted here is, unsurprisingly, wrong.

David, Max5's performance shows just how right you've been so far.

You fail to address the point of JUCE's underlying vector performance, and say your analysis was "preliminary."

Why would your analysis be preliminary if you're well aware of the problem?

The speculation I'm 'wrong about' (sure, we have no idea what's going on in your codebase) is everything *ON TOP OF* JUCE's problems. Yes, I'm sure you've got some rather specific and detailed context in your mind about your own codebase, and where you can improve on your end of the bargain, but that's just your efforts to try to get Max5 to be as fast as it can possibly be *given the baseline of JUCE's maximal performance*

That doesn't mean we have an awesome and fast future in store. It means Max5 won't be "horribly slow", just "slow" when you fix it.

I do appreciate you admitting Max 5 performance is a car-wreck, though...

Where in my original post did you see anything about JUCE? You are attempting to hijack this thread for your own purposes. I'm trying to provide a forum that might just begin to scratch the surface of doing what we can to help c74 identify the problem, and you're just confusing the issue and pissing off c74 with meaningless drivel. The creation of this thread was precisely for the purpose of preventing posts like yours. None of your claims are verifiable, remotely helpful, or relevant to this topic of discussion. Please take jerzy's advice and start a new thread.

I hope you can ignore max5pariah's posts and take the remaining members of this forum seriously. When you said that the speculation about the source of the performance problems was wrong, did you mean speculation about JUCE or speculation about the repetitive patch recompiling during object moving (or both)?

On the one hand, I agree with you that peak performance when dragging hundreds of objects around is a low priority, and it is not a problem that is significantly affecting me at the moment. However, on the other hand, it does seem like a legitimate performance issue that could have unknown implications in areas other than 100+ object dragging.

Where in my original post did you see anything about JUCE?  You are attempting to hijack this thread for your own purposes.  I'm trying to provide a forum that might just begin to scratch the surface of doing what we can to help c74 identify the problem, and you're just confusing the issue and pissing off c74 with meaningless drivel.  The creation of this thread was precisely for the purpose of preventing posts like yours.  None of your claims are verifiable, remotely helpful, or relevant to this topic of discussion.  Please take jerzy's advice and start a new thread.

I hope you can ignore max5pariah's posts and take the remaining members of this forum seriously.  When you said that the speculation about the source of the performance problems was wrong, did you mean speculation about JUCE or speculation about the repetitive patch recompiling during object moving (or both)?

On the one hand, I agree with you that peak performance when dragging hundreds of objects around is a low priority, and it is not a problem that is significantly affecting me at the moment.  However, on the other hand, it does seem like a legitimate performance issue that could have unknown implications in areas other than 100+ object dragging.


Quote: max5pariah wrote on Tue, 21 October 2008 16:55

----------------------------------------------------

> I do appreciate you admitting Max 5 performance is a car-wreck, though...

You are a complete idiot. With a personality like yours, I can't imagine you have many friends left in your life.

If you don't like Max 5, then why don't you just continue to use Max 4 and stop posting about Max 5? By this point, you can't possibly believe that you're helping the situation in any way, can you?

We'll let you know when Max 5 is ready to meet your exacting professional standards. In the meantime, leave us alone.

Quote: max5pariah wrote on Tue, 21 October 2008 16:55
----------------------------------------------------
> I do appreciate you admitting Max 5 performance is a car-wreck, though...
----------------------------------------------------

You are a complete idiot.  With a personality like yours, I can't imagine you have many friends left in your life.  

If you don't like Max 5, then why don't you just continue to use Max 4 and stop posting about Max 5?  By this point, you can't possibly believe that you're helping the situation in any way, can you?

We'll let you know when Max 5 is ready to meet your exacting professional standards.  In the meantime, leave us alone.


If max's recalculations of object order while dragging is slowing the program down considerably, can I suggest that a feature be included to allow users to disable this feature? I'm thinking something along the line of a toggled menu option that would be on at default, but could be bypassed at the user's will.

Real time order calculation is what allows it to dynamically

renumber inlets and outlets when you delete them. As well

as maintain wire connections when an inlet is deleted.

I don't know why such a fuss is made of performance in

edit mode. I really don't need to move 256 objects around

and maintain high frame rates. If you are really doing that

then you need to redesign your patch. Granted Max5's UI 

may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.

What is more important to me is how it preformes when I am 

doing a performance. I don't edit things while I perform.

Real time order calculation is what allows it to dynamically
renumber inlets and outlets when you delete them. As well
as maintain wire connections when an inlet is deleted.
Why would you want to disable that? 

I don't know why such a fuss is made of performance in
edit mode. I really don't need to move 256 objects around
and maintain high frame rates. If you are really doing that
then you need to redesign your patch. Granted Max5's UI 
may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.

What is more important to me is how it preformes when I am 
doing a performance. I don't edit things while I perform.
The whole argument seems silly to me.


> If max's recalculations of object order while dragging is slowing the program down considerably

As I said before, outlet sorting is not the source of performance problems when dragging large numbers of objects.

Quote: Anthony Palomba wrote on Wed, 22 October 2008 09:40

> Real time order calculation is what allows it to dynamically

> renumber inlets and outlets when you delete them. As well

> as maintain wire connections when an inlet is deleted.

> I don't know why such a fuss is made of performance in

> edit mode. I really don't need to move 256 objects around

> and maintain high frame rates. If you are really doing that

> then you need to redesign your patch. Granted Max5's UI 

> may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.

> What is more important to me is how it preformes when I am 

> doing a performance. I don't edit things while I perform.

On Max 4 the graph isn't rebuilt, on 5 it is, while dragging things around that is.

I wouldn't want it disabled, I would want it shut off while I dragged things around because no new outlets are going to be made, and any implicit right-to-left ordering could be done after the user lets go of the mouse.

Quote: Anthony Palomba wrote on Wed, 22 October 2008 09:40
----------------------------------------------------
> Real time order calculation is what allows it to dynamically
> renumber inlets and outlets when you delete them. As well
> as maintain wire connections when an inlet is deleted.
> Why would you want to disable that? 
>
> I don't know why such a fuss is made of performance in
> edit mode. I really don't need to move 256 objects around
> and maintain high frame rates. If you are really doing that
> then you need to redesign your patch. Granted Max5's UI 
> may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.
>
> What is more important to me is how it preformes when I am 
> doing a performance. I don't edit things while I perform.
> The whole argument seems silly to me.
>
----------------------------------------------------

On Max 4 the graph isn't rebuilt, on 5 it is, while dragging things around that is.  

I wouldn't want it disabled, I would want it shut off while I dragged things around because no new outlets are going to be made, and any implicit right-to-left ordering could be done after the user lets go of the mouse.


Quote: max5pariah wrote on Tue, 21 October 2008 15:14

Man, why would you even debate this? Whip it up already. David's already stating that constant reinterpretation isn't at the heart of the issue, so it really leaves only JUCE.

I'm afraid you're gonna have to open whatever coder it is you use and write one up, not just for Cycling, but for anyone with a complier/IDE setup that is interested in benchmarking JUCE.

Quote: max5pariah wrote on Tue, 21 October 2008 15:14
----------------------------------------------------
> If Cycling is interested in some CPP code to show how ridiculous JUCE is, I'll provide it, but this is trivial for them to whip up.
----------------------------------------------------

Man, why would you even debate this? Whip it up already.  David's already stating that constant reinterpretation isn't at the heart of the issue, so it really leaves only JUCE.

I'm afraid you're gonna have to open whatever coder it is you use and write one up, not just for Cycling, but for anyone with a complier/IDE setup that is interested in benchmarking JUCE.


Baseless speculation. Technical blather. More assumption. ignoring of stated facts from expert sources. Faulty conclusion. Personal attack.

If the problem is JUCE, and, if Zola can make a case against JUCE with real benchmarks... I can put a bullet in the head of Max 5 forever.

Despite my desire to just move on I am still clinging onto a hope that there's more of an interest in this topic from Cycling. David has just reiterated what Bernstein said 4 months ago. The graphical issue could be optimized, but it's not a big concern.

If the problem is JUCE, and JUCE is here to stay, then I'll feel completely fine with moving onto another platform, despite the 42 trillion hours Ive invested in building things in Max... give or take 2 trillion.

For your own sanity, post some benchmarks of your findings. Quit assuming that Cycling knows about JUCE's dirty secret and bring it all to light. You are being somewhat difficult in that you're making it sound like this is just some big cover-up operation. If JUCE sucks as hard as you've stated, we'd all like to know.

Despite my desire to just move on I am still clinging onto a hope that there's more of an interest in this topic from Cycling. David has just reiterated what Bernstein said 4 months ago.  The graphical issue could be optimized, but it's not a big concern.

If the problem is JUCE, and JUCE is here to stay, then I'll feel completely fine with moving onto another platform, despite the 42 trillion hours Ive invested in building things in Max...  give or take 2 trillion.  

For your own sanity, post some benchmarks of your findings.  Quit assuming that Cycling knows about JUCE's dirty secret and bring it all to light.  You are being somewhat difficult in that you're making it sound like this is just some big cover-up operation. If JUCE sucks as hard as you've stated, we'd all like to know.


"I can put a bullet in the head of Max 5 forever."

I sincerely hope you were wearing black leather pants and a jacket, no shirt, and a red bandana all while fondling a switchblade in one hand while polishing the silencer for your fully automatic sub machine gun in the other. Motorcycle parked out back, in a dusty motel room somewhere in the Mexican desert. Dusty boots on a table next to a carton of cigarettes and a few bottles of tequila, with a guitar case full of grenades to your side. You grimace, and log onto the cycling 74 forum to taunt your prey. Your stolen military spec satellite uplink renders you untraceable. You are killing machine!

Just a few more posts, and your target is yours! Swoop in for the kill!

I cant wait to see the juicy fragments of skull and brain matter to fall to the ground, finally putting Max 5 out of its misery...

You step back from the shadows, your gun still smoking. You light a cigarette and breathe deeply.

All is well in the world. Your job here is done.

I cant wait to see the juicy fragments of skull and brain matter to  fall to the ground, finally putting Max 5 out of its misery...

All is well in the world. Your job here is done.


Quote: vade wrote on Wed, 22 October 2008 18:19

> "I can put a bullet in the head of Max 5 forever."

> I sincerely hope you were wearing black leather pants and a jacket, no shirt, and a red bandana all while fondling a switchblade in one hand while polishing the silencer for your fully automatic sub machine gun in the other. Motorcycle parked out back, in a dusty motel room somewhere in the Mexican desert. Dusty boots on a table next to a carton of cigarettes and a few bottles of tequila, with a guitar case full of grenades to your side. You grimace, and log onto the cycling 74 forum to taunt your prey. Your stolen military spec satellite uplink renders you untraceable. You are killing machine!

> Just a few more posts, and your target is yours! Swoop in for the kill!

> I cant wait to see the juicy fragments of skull and brain matter to fall to the ground, finally putting Max 5 out of its misery...

> You step back from the shadows, your gun still smoking. You light a cigarette and breathe deeply.

> All is well in the world. Your job here is done.

Holy crap I'm not sure I've ever laughed so much at anything I've read on the internet! Bravo!

Quote: vade wrote on Wed, 22 October 2008 18:19
----------------------------------------------------
> "I can put a bullet in the head of Max 5 forever."
>
> I mean, really, do you hear yourself?
>
> I sincerely hope you were wearing black leather pants and a jacket, no shirt, and a red bandana all while fondling a switchblade in one hand while polishing the silencer for your fully automatic sub machine gun in the other. Motorcycle parked out back, in a dusty motel room somewhere in the Mexican desert. Dusty boots on a table next to a carton of cigarettes and a few bottles of tequila, with a guitar case full of grenades to your side. You grimace, and log onto the cycling 74 forum to taunt your prey. Your stolen military spec satellite uplink renders you untraceable. You are killing machine!
>
> Just a few more posts, and your target is yours! Swoop in for the kill!
>
> I cant wait to see the juicy fragments of skull and brain matter to  fall to the ground, finally putting Max 5 out of its misery...
>
> You step back from the shadows, your gun still smoking. You light a cigarette and breathe deeply.
>
> All is well in the world. Your job here is done.
----------------------------------------------------

 Holy crap I'm not sure I've ever laughed so much at anything I've read on the internet! Bravo!


I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max's head" is putting an end to any sort of hope I have of ever using it.

So, let's get some benchmarks. Fair enough, right? We don't have to use our feelings to gauge Max 5's worth, but raw data could support that the things I value in a program will never be a reality for Max. I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.

Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that's left on the stack, unless someone else has a better theory?

Max 5 feels hopeless. All I want is to move on from it. Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don't wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won't accept anything less.

I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max's head" is putting an end to any sort of hope I have of ever using it. 

So, let's get some benchmarks.  Fair enough, right?  We don't have to use our feelings to gauge Max 5's worth, but raw data could support that the things I value in a program will never be a reality for Max.  I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.

Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that's left on the stack, unless someone else has a better theory? 

Max 5 feels hopeless. All I want is to move on from it.  Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don't wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won't accept anything less.

Vade, you are my favorite poster on the internet.

As to some useful comments - I've never run into TOO much of a problem dragging things around in max. However, many of my interface elements involve numerous objects (a single slider is about 11-12 objects, for various reasons - settings saving, linking to an editbox, etc) and every couple of weeks the thing I"m working on grows out of hand and I need to rearrange it a bit. This issue of dragging lots of objects becomes a problem here, because these aren't elements I can easily encapsulate, and I get a lot of slow down.

Honestly though, I come across it so rarely that it doesn't bother me much at all.

As to some useful comments - I've never run into TOO much of a problem dragging things around in max.  However, many of my interface elements involve numerous objects (a single slider is about 11-12 objects, for various reasons - settings saving, linking to an editbox, etc) and every couple of weeks the thing I"m working on grows out of hand and I need to rearrange it a bit.  This issue of dragging lots of objects becomes a problem here, because these aren't elements I can easily encapsulate, and I get a lot of slow down. 

Honestly though, I come across it so rarely that it doesn't bother me much at all.


Should David Z. post a technically detailed explanation of why there

is latency at his convenience? Do we have "a right to know"?

Reply with +1 for Yes, -1 for no, 0 for don't care.

Please stop speculating on this problem and let's get productive. He

may refuse to do this, but this would stop people complaining about

PS Zola, I'm still waiting for the code sample that proves your

accusations. Hmm, and you were so quick to reply before...

On Wed, Oct 22, 2008 at 8:07 PM, vuxivl wrote:

> I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max's head" is putting an end to any sort of hope I have of ever using it.

> So, let's get some benchmarks. Fair enough, right? We don't have to use our feelings to gauge Max 5's worth, but raw data could support that the things I value in a program will never be a reality for Max. I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.

> Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that's left on the stack, unless someone else has a better theory?

> Max 5 feels hopeless. All I want is to move on from it. Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don't wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won't accept anything less.

> Max 5: Looks like OSX, performs like Vista.

Should David Z. post a technically detailed explanation of why there
is latency at his convenience? Do we have "a right to know"?

Please stop speculating on this problem and let's get productive. He
may refuse to do this, but this would stop people complaining about
juice with ZERO proof.

thanks for keeping it professional,
-Jerzy

PS Zola, I'm still waiting for the code sample that proves your
accusations. Hmm, and you were so quick to reply before...

On Wed, Oct 22, 2008 at 8:07 PM, vuxivl  wrote:
>
> I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max's head" is putting an end to any sort of hope I have of ever using it.
>
> So, let's get some benchmarks.  Fair enough, right?  We don't have to use our feelings to gauge Max 5's worth, but raw data could support that the things I value in a program will never be a reality for Max.  I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.
>
> Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that's left on the stack, unless someone else has a better theory?
>
> Max 5 feels hopeless. All I want is to move on from it.  Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don't wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won't accept anything less.
>
> Benchmarks!
> --
> Max 5: Looks like OSX, performs like Vista.
>
>


fine, jesus x christ, just fricking move on already. go use 

On Oct 22, 2008, at 8:07 PM, vuxivl wrote:

> I want to know, based on data, that Max is in non-salvageable for my 

> standards. Hence, "putting a bullet in Max's head" is putting an end 

> to any sort of hope I have of ever using it.

> So, let's get some benchmarks. Fair enough, right? We don't have 

> to use our feelings to gauge Max 5's worth, but raw data could 

> support that the things I value in a program will never be a reality 

> for Max. I wanna know if JUCE is really as bad as Zola said. I dont 

> wanna base that on merely my making observations that every JUCE app 

> Ive ever used is complete latent crap, but based on vector 

> Since David has rebuked my one hope for the easy fix, my 

> reinterpretation speculation, pinpointing/exposing JUCE is all 

> that's left on the stack, unless someone else has a better theory?

> Max 5 feels hopeless. All I want is to move on from it. Benchmarks 

> are the foundation for objectivity here, a middle ground we can all 

> observe, and without them, what hope is there for finalization? I 

> don't wanna sit around thinking version 5.x.x will fix this. As Zola 

> stated, "really slow" would only become "slow" under his assessment. 

> I want blazing fast, and won't accept anything less.

fine, jesus x christ, just fricking move on already.  go use  
solidworks or something.

>
> I want to know, based on data, that Max is in non-salvageable for my  
> standards. Hence, "putting a bullet in Max's head" is putting an end  
> to any sort of hope I have of ever using it.
>
> So, let's get some benchmarks.  Fair enough, right?  We don't have  
> to use our feelings to gauge Max 5's worth, but raw data could  
> support that the things I value in a program will never be a reality  
> for Max.  I wanna know if JUCE is really as bad as Zola said. I dont  
> wanna base that on merely my making observations that every JUCE app  
> Ive ever used is complete latent crap, but based on vector  
> performance graphs.
>
> Since David has rebuked my one hope for the easy fix, my  
> reinterpretation speculation, pinpointing/exposing JUCE is all  
> that's left on the stack, unless someone else has a better theory?
>
> Max 5 feels hopeless. All I want is to move on from it.  Benchmarks  
> are the foundation for objectivity here, a middle ground we can all  
> observe, and without them, what hope is there for finalization? I  
> don't wanna sit around thinking version 5.x.x will fix this. As Zola  
> stated, "really slow" would only become "slow" under his assessment.  
> I want blazing fast, and won't accept anything less.
>
> Benchmarks!
> --
> Max 5: Looks like OSX, performs like Vista.
>


SERIOUS Max 5 performance thread