I really like Max,
And this software gets cooler and smarter all the time,
But sometimes i'm confused about the messy organization of the functionalities / redundancy of some old objects / miss of some basic access to functionalities:
- To open remotely a window: You have to send the (open) msg to a [pcontrol] object, that is connected to the inlet of the sub-patcher...
- To close remotely a window: You have to send the (wclose) msg to another object, called [thispatcher], which, this time, is located in the sub-patcher itself...
- If you want to know remotely if a patcher window is open or close by the user, my feeling is that you can't. (Or can you?? With a third object this time, somewhere hidden in the doc?)
Well, i know that max has a long evolution story of nearly 30 years, but maybe it's time for a redesign in some old stuff like those objects in a more intuitive and logical way.
A new [thiswindow] object clearly receiving everything, and sending in realtime any change, about this window, open, close, resize, etc. would be great. And i feel many others maxobjects, in many different fields could have the same king of treatment. (You could still keep the old versions of the objects, for compatibility, in the corner of the doc as deprecated/not recommended to use)
- You start a simple patch. It's getting more complex. To see better though it, you start to put many [send] and [receive] everywhere to not have all those patchcords messing-up... Then you're happy with your sound but now you want to hear several of them at the same time (opening several of them, or as a poly˜)... ...but this doesn't work at all! Because [send] and [receive] are not patcher-independant! Patcher-independent [send] and [receive] is really something missing in Max.