[REQUEST] better organization of the functionalities through the max objects

    Alexandre
    Aug 30 2012 | 4:42 pm
    Hi, 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:
    An example: - 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)
    Other Example: - 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.
    Regards,
    • pid
      Aug 30 2012 | 4:52 pm
      you seem to have missed out on the pcontrol functions:
      other than that, i feel your pain.
    • Chris Muir
      Aug 30 2012 | 5:52 pm
      Patcher independence of the send/receive namespace is possible. #0 at the beginning of a symbol generates a unique-to-that-saved-patcher prefix. For example, if you had [send #0_clock] it might expand to [send 4545_clock] when it's loaded.
    • Alexandre
      Aug 31 2012 | 10:10 am
      @pid: oh yes, i forgot that message possibility to pcontrol. The thing is there are 997 maxobjects now... i need an ssd implant in my brain to remember how to use Max.
      @Chris: Well yes, ok that works... But only if you not using abstractions or poly˜ in which those [send] and [receive] have to go... Right now i have the case that i would like to put a send in a subpatch, and the receive in a poly abstraction... True I'm not totally sure how this should work in a ideal behavior, [send] and [receive] locally limited to few levels but not upper level parent patcher... A "local behavior" of [send] and [receive], depending on which upper-level you put the upper [send] or [receive] with that name, a bit like [pv] works locally or not locally, might be an idea.