Max for Complex System Diagrams

mtennie's icon

Having used Max the right way for years, I am finding that the patching environment is a great tool for visualizing complex hardware systems. I make objects for each piece of equipment in a hardware system, determine the number and type of inputs and outputs, and connect them accordingly.

A simple example:
I make an object that represents a VCR with audio and video inputs and outputs. The outputs go to an object that represents a TV, and the inputs connect to an object that represents a cable box.

Now imagine this for a more complex system, like a concert tour set up with 64 cabled instruments, dozens of pieces of rack gear, 40 speakers, a lighting board, 9 projectors, and a Mechanical Turk. Using Max for a system diagram quickly becomes a very useful planning tool when you have hundreds of pieces of equipment to keep track of.

Furthermore, when I take this concert on tour I need to scale the system for each venue, so the equipment and configuration I'm using can change depending on the room. To keep track of my many different shipping manifests, I export the system diagram patch as a JSON file and parse it to create a list of the equipment I need and to document the connection schedule.

It's super useful in many ways that the 10 million available diagram tools (yEd, Visio, OmniGraffle, etc) are not. Namely that you can make diagrams with granular input/output specificity. You can also make the diagram interactive by asking individual objects for information and connecting those objects to the equipment they represent (thanks to shell, et al). But Max being intended for other things has its own shortfalls in this use. But that's ok, because you can make anything in Max :)

So here are the problems I'm having trouble solving:

1) There are three choices for representing equipment as objects: abstractions, sub-patches, and externals.
- abstractions are clean and fast to add in a diagram, but when you export the patch as JSON it does not include any of the patch stuff inside of the abstraction (such as an inlet's @comment attribute).
- sub-patches include all of their internal info when a patch is exported as JSON, but every object has a [p] at the beginning and makes the digram look stupid.
- there is no way to change the outlet type for either of these, so it becomes a project when you want to parse the JSON to find out how many of each cable type you need. (copy a couple objects and connections into a text editor to see what I mean)
- I don't believe you can define outlettype or inlettype when writing a Max external. If you can, are you able to stray from the standard types (like saying HDMI or 1/4"TRS instead of jit_matrix or signal)?

2) If you don't have a Max license, it's hard to explore complicated diagrams closely. I can export the patch and have my colleagues look at it in Runtime, but without Edit mode they can't click a patch cord to highlight a connection. It would be awesome to draw a glow over the diagram itself (using the patch cord path detailed in the patch JSON) or command the patch cord to change colors, but I can't figure out a way to make either of those happen.

I look forward to your thoughts! I like trying to use Max in funky ways and it's easy to get snow blind with convoluted work arounds o_O But more often than not there are elegant solutions to be found somewhere!