vuxivil

I have been using Max 4 for years now, just not really been too involved with the community. In the past 2 weeks I’ve been using the Max 5 demo. I have written up a few things I don't like about Max 5 or even Max in general. I am not a computer scientist although I throw around some terms quite copiously and I'm sorry for that. In regards, anywhere I am plain off just correct me. It’s not meant to be a flame rant at all and is just merely me expressing a few of the negative things I’ve come to find in Max.

Only 3 fonts on my system work on Max without any compromise. They are: Arial, Tahoma, and Microsoft Sans Serif. If I choose to set my default font to a wide font, say, like Lucida Console, Verdana, or Courier New and then restart Max, all my help files which use "Sans Serif" as their default font will be set to this default font. I thought this behavior was originally handled in the .init folder with the file "max-fontmappings.txt". Indeed, the file still exists in Max5, but seems to take less precedence, rendering it useless for "Sans Serif" help files. What the invariable result is 90% of my help files will become mangled due to the boxes object size being smaller than the width of the font + number of characters.

Proposed Solution: I for one would like to be able to use Verdana 10 again without it mangling all my max4 help files being as some of these may never be updated. My proposed solution is to make the "system font" the one that is used when Sans Serif is called. Or even a new option for what Sans Serif defaults to…

I would really like to see a change in the way Max handles moving around objects with the mouse/arrow keys. What I theorize is happening is that, with every pixel that a selection is moved, the graph the interpreter creates is being rebuilt. I could be wrong of course, but it seems like there's more going on that just some objects being redrawn on the screen. Say if you have 1000 buttons and drag them around... why does the system become so sluggish? Is it because it needs to infer implicit right-to-left ordering while moving things around? If that were the case, I'd say that was a poor reason to let the graph rebuild so many times being as such that kind of ordering (implicit, i.e., not using trigger) isn't really, well, good programming to begin with.

Proposed Solution: If indeed my theory is correct my proposed solution would be as follows. Do not rebuild the graph until the mouse button is released. Drag whatever you want around freely at a high frame rate, then, when the final destination is selected and the mouse button let go, rebuild the graph. If using the arrow keys wait until the arrow key is released.

    I’ve noticed when making a small selection and dragging it around, the selection lags about 1/4th of a second behind the mouse cursor. Maybe this might be remedied with a better graphics card, I don’t know. I tested this on both Windows and Mac on different computers and the lag was about the same. Coming from Max 4’s instant responsiveness I find this adds to the underlying feeling I have that Max 5 is slower than Max 4 in almost every respect. (yes, the key commands help, obviously, but, I’ve had those since Max4 using the toolkit)

First, I would really like to see something like ps and pr (private send/receive) as we have with pv (private variable). Pvar for me doesn't quite cut it and seems to have some instantiation problems. Pattr also seems a bit awkward as well in regards.

Second, sometimes I wonder why all patches have scope with each other. It seems to me like if one wanted to communicate with separate patches that using a localhost OSC model would probably be better. That would make send/receive operate only from the base patch (i.e, what you retrieve from thispatcher with the path message). This can create "state" overrides when opening an old version of a patch that uses, say, a named coll, or sends a bunch of data via sends and receives. Or if a patch shares a send/receive name it can be an issue.

Proposed solution: Change send/receive to patch wide, add local/private send/receive, and use OSC or a global send/receive object for inter patch communication.

Take this example. We have a bangbang object. The right outlet is connected to a big array of coll cut and copy operations and requires regexp and javascript and some other stuff. When it's done doing it's iterations/operations, it sends a "Right finished" message to a print object. The left outlet of bangbang is just a message saying "left finished" connected to print. Why is it that, in some cases, it's possible that the left outlet will print before the right outlet, even with vanilla objects. Of course one winds up using a delay or deferlow object on the left outlet to get the ordering which was suggested in the first place.

I don't have a solution for this because I'm not sure if it's even a problem. Maybe it's a design compromise from the get go. But, obviously, this can lead to bugs when you're counting on right-to-left being there always. Being able to see the ~flow~ is part of what makes Max useful and if you can’t always trust that, then, well… what’s the point?

Over the years I've read so many complaints about Max and timing. Things like "I built a controller for my drum machine but Max can't send out steady beats" or "I build a sequencer and the timing is all off" or whatever. Anyone whose been around a while knows this. Max's bias towards creating interactive or algorithmic music _probably_ hasn't helped this. I had a hell of a time getting reproducible timing from the hostsync~ object. In the end, I found that turning off audio and using a “metro 1” actually improved the timing quite considerably, but still not to a point where I felt happy with it…. However, since I had to use audio, I would up making a standalone to receive the timing from a host and then OSC it into Max. Then I was delighted to find out that OSC was finicky, too.

[Warning: very opinionated] Max 5 is, I think, _partly_ an attempt to attract new customers. That's fine, but, what I think is missing is a solid determinalistic core to Max. I find it too hard to create reproducible results, especially with anything timing concerned.

Proposed Solution: I think if you Cycling wants to attract a greater following they need super solid, sample accurate timing. Some determinalistic objects might help too. Add a 21st century updated object which builds upon the ideas set forth by detonate/timeline. Not all of us are interactive/algorithmic musicians. In fact, most of the world’s “successful” music is pretty much 99.0% determinalistic (maybe Jazz accounts for 1% of albums sold, I’m just guessing). If Cycling really wanted to get new customers, they would make more of an effort to instantiate this sort of paradigm into Max. I mean, algorithmic music IS cool, but you won’t get past playing in coffee shops if that’s all you write. If trying to attract more mainstream musicians, they need to know that they can make money as well as useful tools with your program. And I don’t mean make money by selling software, I mean by being able to write hit songs with the help of Max.

    In short, if Max wants to look “pop” (Apple) it should support primitives for making pop i.e. determinalistic music _without_ having to utilize a 3rd party sequencer. I for one have plenty of ideas what one could do with a “max sequencer”.

    As you may know, depending on the compiler you can get quite a lot of speed benefits. Now I’m almost 100% sure every last employee at Cycling is a hardcore devoted Mac user, and, I have my doubts about how much effort actually goes into compiling the vanilla objects for Windows.

    I had a friend show me some speed results using some different C compilers along with flag settings. I am sure that Cycling would benefit us Windows users to hire someone that was “really into” this sort of thing and could make wMax as fast as possible.

    If this isn’t the case then I apologize. I meant to mention it just because I think if all the externals were compiled and thoroughly tested on Windows we’d see like a 5-15% speed improvement. If this has already been done then, well, thanks.

    Also, I would have liked to see some speed improvements with Jitter. I guess this probably isn’t possible with Max’s current core. I have no idea how or why or what kind of overhaul it would take. All I know is on Windows we have a freeware program called vvvv which feels infinitely faster than jitter, so I end up using that, instead. Anyone on a mac ought to check it out, it really is cool.

Overall, I am pretty happy with Max 5. I am running the demo right now. I truly couldn’t use Max 5 up until version 5.03 because of the font rendering which, for me, made it unreadable. So, thank you to David for addressing that.

I like the new inspector, the debugger, JSON format, shortcut keys, layout….

I have been using Max 4 for years now, just not really been too involved with the community.  In the past 2 weeks I’ve been using the Max 5 demo.  I have written up a few things I don't like about Max 5 or even Max in general.  I am not a computer scientist although I throw around some terms quite copiously and I'm sorry for that.  In regards, anywhere I am plain off just correct me.  It’s not meant to be a flame rant at all and is just merely me expressing a few of the negative things I’ve come to find in Max.

    Only 3 fonts on my system work on Max without any compromise.  They are: Arial, Tahoma, and Microsoft Sans Serif.  If I choose to set my default font to a wide font, say, like Lucida Console, Verdana, or Courier New and then restart Max, all my help files which use "Sans Serif" as their default font will be set to this default font.  I thought this behavior was originally handled in the .init folder with the file "max-fontmappings.txt". Indeed, the file still exists in Max5, but seems to take less precedence, rendering it useless for "Sans Serif" help files.  What the invariable result is 90% of my help files will become mangled due to the boxes object size being smaller than the width of the font + number of characters.

    Proposed Solution: I for one would like to be able to use Verdana 10 again without it mangling all my max4 help files being as some of these may never be updated.  My proposed solution is to make the "system font" the one that is used when Sans Serif is called.  Or even a new option for what Sans Serif defaults to…

    I would really like to see a change in the way Max handles moving around objects with the mouse/arrow keys.  What I theorize is happening is that, with every pixel that a selection is moved, the graph the interpreter creates is being rebuilt.  I could be wrong of course, but it seems like there's more going on that just some objects being redrawn on the screen.  Say if you have 1000 buttons and drag them around... why does the system become so sluggish?  Is it because it needs to infer implicit right-to-left ordering while moving things around? If that were the case, I'd say that was a poor reason to let the graph rebuild so many times being as such that kind of ordering (implicit, i.e., not using trigger) isn't really, well, good programming to begin with.

    Proposed Solution: If indeed my theory is correct my proposed solution would be as follows.  Do not rebuild the graph until the mouse button is released.  Drag whatever you want around freely at a high frame rate, then, when the final destination is selected and the mouse button let go, rebuild the graph. If using the arrow keys wait until the arrow key is released.

	I’ve noticed when making a small selection and dragging it around, the selection lags about 1/4th of a second behind the mouse cursor.  Maybe this might be remedied with a better graphics card, I don’t know.  I tested this on both Windows and Mac on different computers and the lag was about the same.  Coming from Max 4’s instant responsiveness I find this adds to the underlying feeling I have that Max 5 is slower than Max 4 in almost every respect. (yes, the key commands help, obviously, but, I’ve had those since Max4 using the toolkit)

    First,  I would really like to see something like ps and pr (private send/receive) as we have with pv (private variable).  Pvar for me doesn't quite cut it and seems to have some instantiation problems.  Pattr also seems a bit awkward as well in regards.  

    Second, sometimes I wonder why all patches have scope with each other.  It seems to me like if one wanted to communicate with separate patches that using a localhost OSC model would probably be better.  That would make send/receive operate only from the base patch (i.e, what you retrieve from thispatcher with the path message).  This can create "state" overrides when opening an old version of a patch that uses, say, a named coll, or sends a bunch of data via sends and receives.  Or if a patch shares a send/receive name it can be an issue.  

    Proposed solution:  Change send/receive to patch wide, add local/private send/receive, and use OSC or a global send/receive object for inter patch communication.

    Take this example.  We have a bangbang object.  The right outlet is connected to a big array of coll cut and copy operations and requires regexp and javascript and some other stuff. When it's done doing it's iterations/operations, it sends a "Right finished" message to a print object.  The left outlet of bangbang is just a message saying "left finished" connected to print.  Why is it that, in some cases, it's possible that the left outlet will print before the right outlet, even with vanilla objects.  Of course one winds up using a delay or deferlow object on the left outlet to get the ordering which was suggested in the first place.

    I don't have a solution for this because I'm not sure if it's even a problem.  Maybe it's a design compromise from the get go.  But, obviously, this can lead to bugs when you're counting on right-to-left being there always.  Being able to see the ~flow~ is part of what makes Max useful and if you can’t always trust that, then, well… what’s the point?

    Over the years I've read so many complaints about Max and timing.  Things like "I built a controller for my drum machine but Max can't send out steady beats" or "I build a sequencer and the timing is all off" or whatever. Anyone whose been around a while knows this.  Max's bias towards creating interactive or algorithmic music _probably_ hasn't helped this.  I had a hell of a time getting reproducible timing from the hostsync~ object.  In the end, I found that turning off audio and using a “metro 1” actually improved the timing quite considerably, but still not to a point where I felt happy with it….  However, since I had to use audio, I would up making a standalone to receive the timing from a host and then OSC it into Max.  Then I was delighted to find out that OSC was finicky, too.

    [Warning: very opinionated] Max 5 is, I think, _partly_ an attempt to attract new customers. That's fine, but, what I think is missing is a solid determinalistic core to Max.  I find it too hard to create reproducible results, especially with anything timing concerned.

    Proposed Solution: I think if you Cycling wants to attract a greater following they need super solid, sample accurate timing.  Some determinalistic objects might help too.  Add a 21st century updated object which builds upon the ideas set forth by detonate/timeline. Not all of us are interactive/algorithmic musicians.  In fact, most of the world’s “successful” music is pretty much 99.0% determinalistic (maybe Jazz accounts for 1% of albums sold, I’m just guessing). If Cycling really wanted to get new customers, they would make more of an effort to instantiate this sort of paradigm into Max.  I mean, algorithmic music IS cool, but you won’t get past playing in coffee shops if that’s all you write.  If trying to attract more mainstream musicians, they need to know that they can make money as well as useful tools with your program.  And I don’t mean make money by selling software, I mean by being able to write hit songs with the help of Max.

	In short, if Max wants to look “pop” (Apple) it should support primitives for making pop i.e. determinalistic music _without_ having to utilize a 3rd party sequencer.  I for one have plenty of ideas what one could do with a “max sequencer”.

	As you may know, depending on the compiler you can get quite a lot of speed benefits.  Now I’m almost 100% sure every last employee at Cycling is a hardcore devoted Mac user, and, I have my doubts about how much effort actually goes into compiling the vanilla objects for Windows. 

	I had a friend show me some speed results using some different C compilers along with flag settings.  I am sure that Cycling would benefit us Windows users to hire someone that was “really into” this sort of thing and could make wMax as fast as possible.

	If this isn’t the case then I apologize.  I meant to mention it just because I think if all the externals were compiled and thoroughly tested on Windows we’d see like a 5-15% speed improvement.  If this has already been done then, well, thanks.

	Also, I would have liked to see some speed improvements with Jitter.  I guess this probably isn’t possible with Max’s current core.  I have no idea how or why or what kind of overhaul it would take.  All I know is on Windows we have a freeware program called vvvv which feels infinitely faster than jitter, so I end up using that, instead.  Anyone on a mac ought to check it out, it really is cool.

Overall, I am pretty happy with Max 5.  I am running the demo right now.  I truly couldn’t use Max 5 up until version 5.03 because of the font rendering which, for me, made it unreadable.  So, thank you to David for addressing that.

constructive-rant-i-hope

Also, in addtion, under GUI responsiveness...

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

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

> Take this example. We have a bangbang object. The right outlet is 

> connected to a big array of coll cut and copy operations and requires 

> regexp and javascript and some other stuff. When it's done doing it's 

> iterations/operations, it sends a "Right finished" message to a print 

> object. The left outlet of bangbang is just a message saying "left 

> finished" connected to print. Why is it that, in some cases, it's 

> possible that the left outlet will print before the right outlet, even 

> with vanilla objects. Of course one winds up using a delay or deferlow 

> object on the left outlet to get the ordering which was suggested in 

because you are starting two independent processes with bangbang. 

sometimes the right process might be finished first sometimes not 

depending on what else is going on on yr computer. in yr case you would 

have to temporarily store the "left finished" (e.g. with set $1 in a 

message box) and let it bang out when the right process is finished.

oh, and timebased ordering (delay, deferlow) is almost always worse than 

vuxivl wrote:
> Take this example. We have a bangbang object. The right outlet is 
> connected to a big array of coll cut and copy operations and requires 
> regexp and javascript and some other stuff. When it's done doing it's 
> iterations/operations, it sends a "Right finished" message to a print 
> object. The left outlet of bangbang is just a message saying "left 
> finished" connected to print. Why is it that, in some cases, it's 
> possible that the left outlet will print before the right outlet, even 
> with vanilla objects. Of course one winds up using a delay or deferlow 
> object on the left outlet to get the ordering which was suggested in 
> the first place. 
because you are starting two independent processes with bangbang. 
sometimes the right process might be finished first sometimes not 
depending on what else is going on on yr computer. in yr case you would 
have to temporarily store the "left finished" (e.g. with set $1 in a 
message box) and let it bang out when the right process is finished.
oh, and timebased ordering (delay, deferlow) is almost always worse than 
condition based

-- 
http://pure.test.at
http://www.myspace.com/pvre
http://www.heartchamberorchestra.org


Well, it depends on how your patch is hooked up. Is the 'right finished' message directly attached to 'bangbang'? Because if it is, and if 'left finished' gets triggered first, that's something which should really never happen. If it is, you should send a patch to support. If 'right finished' is attached to the output of, say, coll or js, then your expectations about event ordering are probably wrong.

As for your previous comments about Windows getting the short shrift, Cycling has a dedicated, extremely talented Windows programmer on staff who goes to great lengths to make wMax as efficient and splendid as xMax. Rest assured that the wMax kernel and objects are as carefully compiled and as thoroughly tested as 

xMax. If you have specific complaints/concerns about particular objects or patches that you can demonstrate, we'd be more than happy to know about them.

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

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

Quote: pure wrote on Thu, 24 July 2008 10:04

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

> > Take this example. We have a bangbang object. The right outlet is 

> > connected to a big array of coll cut and copy operations and requires 

> > regexp and javascript and some other stuff. When it's done doing it's 

> > iterations/operations, it sends a "Right finished" message to a print 

> > object. The left outlet of bangbang is just a message saying "left 

> > finished" connected to print. Why is it that, in some cases, it's 

> > possible that the left outlet will print before the right outlet, even 

> > with vanilla objects. Of course one winds up using a delay or deferlow 

> > object on the left outlet to get the ordering which was suggested in 

> because you are starting two independent processes with bangbang. 

> sometimes the right process might be finished first sometimes not 

> depending on what else is going on on yr computer. in yr case you would 

> have to temporarily store the "left finished" (e.g. with set $1 in a 

> message box) and let it bang out when the right process is finished.

> oh, and timebased ordering (delay, deferlow) is almost always worse than 

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

Quote: pure wrote on Thu, 24 July 2008 10:04
----------------------------------------------------
> vuxivl wrote:
> > Take this example. We have a bangbang object. The right outlet is 
> > connected to a big array of coll cut and copy operations and requires 
> > regexp and javascript and some other stuff. When it's done doing it's 
> > iterations/operations, it sends a "Right finished" message to a print 
> > object. The left outlet of bangbang is just a message saying "left 
> > finished" connected to print. Why is it that, in some cases, it's 
> > possible that the left outlet will print before the right outlet, even 
> > with vanilla objects. Of course one winds up using a delay or deferlow 
> > object on the left outlet to get the ordering which was suggested in 
> > the first place. 
> because you are starting two independent processes with bangbang. 
> sometimes the right process might be finished first sometimes not 
> depending on what else is going on on yr computer. in yr case you would 
> have to temporarily store the "left finished" (e.g. with set $1 in a 
> message box) and let it bang out when the right process is finished.
> oh, and timebased ordering (delay, deferlow) is almost always worse than 
> condition based
>
> p
>
>
> -- 
> http://pure.test.at
> http://www.myspace.com/pvre
> http://www.heartchamberorchestra.org
>
----------------------------------------------------


Sorry, there was a problem with the previously attached JS scripts. The attached ones are good.

Quote: vuxivil wrote on Thu, 24 July 2008 03:26

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

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

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

>... sometimes I wonder why all patches have scope with each other. It seems to me like if one wanted to communicate with separate patches that using a localhost OSC model would probably be better.

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

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

> Take this example. We have a bangbang object. The right outlet is connected to a big array of coll cut and copy operations and requires regexp and javascript and some other stuff. When it's done doing it's iterations/operations, it sends a "Right finished" message to a print object. The left outlet of bangbang is just a message saying "left finished" connected to print. Why is it that, in some cases, it's possible that the left outlet will print before the right outlet, even with vanilla objects.

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

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

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

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

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

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

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

>...Now I’m almost 100% sure every last employee at Cycling is a hardcore devoted Mac user, and, I have my doubts about how much effort actually goes into compiling the vanilla objects for Windows.

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

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

Quote: vuxivil wrote on Thu, 24 July 2008 03:26
----------------------------------------------------
> [GUI responsiveness#1]

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

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

> [scope]
>... sometimes I wonder why all patches have scope with each other.  It seems to me like if one wanted to communicate with separate patches that using a localhost OSC model would probably be better.  

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

> [“seeable” interpretation]
>
>     Take this example.  We have a bangbang object.  The right outlet is connected to a big array of coll cut and copy operations and requires regexp and javascript and some other stuff. When it's done doing it's iterations/operations, it sends a "Right finished" message to a print object.  The left outlet of bangbang is just a message saying "left finished" connected to print.  Why is it that, in some cases, it's possible that the left outlet will print before the right outlet, even with vanilla objects.  

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

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

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

> [speed]
>
>...Now I’m almost 100% sure every last employee at Cycling is a hardcore devoted Mac user, and, I have my doubts about how much effort actually goes into compiling the vanilla objects for Windows. 

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


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

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

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

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

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

https://cycling74.com/twiki/bin/view/Company/People

It's a small company, keeping steady by means of a few dedicated people who probably do it mainly for the love of it. In fact, aside from the lack of bulldozing corporate/capitalistic money-grubbing influences, the proof of that love is also shown by the fact that some contractors, perhaps others, aren't even listed on that page and must, therefore, remain unseen and unappreciated (*ahem*) so a little patience over the general work-in-progress would be most appreciated. If you have specific features you want added, a constructive but specific non-rant might be more appropriate. A general assessment is also somewhat helpful but doesn't really get your suggestions through, instead, people can argue against everything because they'll follow the general attitude of criticalness with which it was originally/mainly written. 

*you can achieve sample-accurate/non-scheduler timing with MSP alone(eric lyon's objects are another way to achieve this as well);

*I personally, don't care about how the GUI responds to movement of objects while editing so long as I can edit smoothly and so long as the graphics perform on-time in performance/presentation-mode(i.e. when locked), and on my G5 and my MacBook, as well as on my friends' Windows Intel-Duo machines, it seems to be void of graphical lag, so your complaint there might be system specific, not sure... unless you were to be wholistic enough in your criticism to specify your system exactly.

*as for scope, I like that it's automatic to some extent and that I must be specific if I'd like to draw boundaries, this makes it easier for modular designs to work with each other and you are still able to achieve private send/receives if you know the techniques well enough and, more importantly, keep track of what you're doing, which you should be doing anyways no matter what programming interface you use

*the list can go on as other people's answers have shown....

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

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

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

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

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

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

Take a quick look at the people page:
https://cycling74.com/twiki/bin/view/Company/People

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

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

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


Quote: vuxivil wrote on Thu, 24 July 2008 13:26

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

https://cycling74.com/twiki/bin/view/Share/MattijsKneppers

Quote: vuxivil wrote on Thu, 24 July 2008 13:26
----------------------------------------------------
> [scope]

https://cycling74.com/twiki/bin/view/Share/MattijsKneppers


I think that a lot of my questions have been answered. There are some good [scope] and [timing] suggestions. I'll definitely check out samm~. The [fonts] one maybe is a little too vane to even bother with this time around, but.. whatever, it's been bugging me since I would rather patch in verdana 10 than tahoma 11 (12 is too big for me). Seems I was a little short sighted in not utilizing really basic javascript to help with scoping problems. I have a hard time investing in it when I've read so much discontent and failure from utilizing it in the javascript forum.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I think that a lot of my questions have been answered.  There are some good [scope] and [timing] suggestions.  I'll definitely check out samm~. The [fonts] one maybe is a little too vane to even bother with this time around, but.. whatever, it's been bugging me since I would rather patch in verdana 10 than tahoma 11 (12 is too big for me).  Seems I was a little short sighted in not utilizing really basic javascript to help with scoping problems.  I have a hard time investing in it when I've read so much discontent and failure from utilizing it in the javascript forum.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Constructive rant (I hope)