[REQUEST] better organization of the functionalities through the max objects
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.
you seem to have missed out on the pcontrol functions:
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 1022.3ocyXszaaiCD9r7uBAcpKfWAQQIYq81hhBzCAnG1iAAFzRL1rUlTkjN M6Vj+6KEojLodX6j0naLfUhmgOl4adqetvKXK6YrHv+O7u22y6mK77zjZH30 9aufCnmKpPB8xBn3ev190fkFVR7yRM4Z+83pJVGc5wCDZEVp2SbKwGYTIEc. q2vexInJqkyNJ6VOnkpgj7uqwFALHv+AqiRP9GMCPbXTK4ZjrXOgtaCGWHMa BlFtFlmmmszGDATqzOIKLIUQIeoebTXT+YRJ0BlR698r.6CDyawiV.Qc8jJ7 SXtfvnVBrW.pt1hrm0VZPwuxzGT1xdRDpgTTOIN9IR29WYH9xhti+jVEGuVq JIMOgqiZ9CHK6j1nLi6pXEeCWZe9ArZLkPq4XAlJQxgxeI9QzwJ4logWW9Oh JvNmsMyIMydA63jRFsQHb1YC4tq6dePpVaRsUF8Jnn5I1rPoGGEaQ7Ffaakq LIYrpYXobyQTxAjDKIFgMNpmI4PMmPkNa.SQpyXunfypplfySSvoTYNKv+fT J2qoaCkpkSp6LAA8XTIYGVHcoIQ6DtTbhas8yriecnOHNtIxc6QoTc8KOsDm 3VfEi4MpiiegVbFGCuz7UitOXsRamRq3WPJHLU4NDmGBUeRRZhi0961AumIo vbIFhyzAO.X7EO34hWFj0H2FR5yL9w69xe8o.GYgq.RIluw32ncL5X+xhEc+ yx2nksfc3fRZmTX97mt6tubyM3QW1LloyWEqskw44M+HGdF62pUgoIf0vXa9 7cacihlwzZxf.0WILY5K6JsoqBtgVFMROK5GMK9BNa.kqZMFMRM4SgZCPZ2S mcYovo1xWmqjN0yMDHLJwU4GdFOs4L71gzWVgS9Unv++X4AuJKe7qAHNUZth PmqRjVjZ3OMBIXG4EcJSaBTeWwSUkTRn8Ao22axFrt8jxR29BLkREMIXKmKC q+CKravJPfdBWtQcCJDbCRJ4DUERixY282+0tftbWVuhVClTHNykO2kp5VbK ppse298NQGHKNAh5mlfhqYzgCXg.sCOZ1ghJl.+9axg7jv3H0XB.UXiNDBpZ AYsYvAv5oGbHM3FhK5VceOOPUKrrJDlcdXA9Vfk4lzrPIppFsmDY.uSPllQw V5mBCSiO+jlf2Bx31g2In4CTl+8x8DQaX7C9b72OR33xe6lfVQmGRF0e1j0j xM0jVaFxaTC2tkls.G8Bbq1XvpgUYZQrQUWxrqZLSkkTm0LpphZh8xZlZzkV QHIU0nQ6KW.ZFBuYbk3j77jYHooDACW0lZAX0X53BVibLtVkM8JTVvET1amz .eWIMfqPZxdiRiwKcv6ApQPF79eF7teF9deTm1KK9WT0UHgK -----------end_max5_patcher-----------
other than that, i feel your pain.
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.
@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.
Forums > MaxMSP