Hello all, and particulary Jules,
Your API is really welcome in music soft, of course, and many people thank you for your job. Im wondering of the limits of an API when developed by only one person, even skilled and genius this one is…
So I red it on a cycling74 forum :
Can answer to it ? How ?..
Sorry for this unfriendly post, but I think you have your word to say about it, and it can interest lots of people.
[quote]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 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.
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.
- 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.
[Updated on: Tue, 21 October 2008 15:15][/quote]