I'm wondering if there's a consensus on what the target screen resolution should be when making Max patches to share. I think most web pages usually target 1024x768 these days, so is that the best bet for Max patches too?
It's a question of taste, custom, and convenience.
For many years I was in the habit of trying to keep to 512x384 if possible. Many would consider this hyper-anal retentively safe given that the last Mac supporting this resolution was built in about 1989. OTOH (and the reason why I abide by the adage "small is beautiful") most people will have many windows open and will want to see all of them (not just mine).
But I wouldn't have any compunction about designing larger windows if needed to display information.
1024x768 is a relatively small & safe screen size (I forget: what do 12" laptops support?).
Web pages that target a particular screen resolution are brain-dead. It is not hard to design a web page that can stretch or contract for a variety of screen sizes. Max patches don't grow or shrink that easily.
If you've got information that really needs that size, then use it. Whatever size you assume, someone will have a larger screen. And someone will have a smaller screen.
My 12.1" Toshiba tablet is running 1400*1050. Usually the macbook pro/non-pro / powerbooks are the lowest common denominator in the DPI department, with the one exception of the 17", which is 1680 x 1050, quite a lovely res, normally.
I reckon it wouldnt be that hard to make an app that auto-scrolled when mousing towards the edge of the window, right?
Thanks for the replies. Ok, so I will keep patches under 1024x768.
I don't like the auto-scrolling idea either, but I suppose there could be situations where it might be appropriate. If a GUI starts getting too complicated I'd probably strip down the main patch to only show the most important stuff and push the rest into pop-up subpatcher windows. Another option is context-sensitive areas that show different things depending on the state of the patch (probably using a bpatcher with scripted offset). Tabs could be done this way.
Set nav_scale factor for overall window / navigation size.
a nice XY panel in a floating window for control, so it doesn't get hidden.
you could have a small screenshot of the overall patch in the XY control, so users would see where they're at (like the nav window in Sibelius, for example).
there's a ton more window commands in js too, as you probably know.
This doesn't address whether you *should* do this scrolling design, but it could be cool for a patch with a lot of repeated areas (like a line or grid of synth modules or something). Also keystrokes to go to each screen area would be nice, and straightforward with the js (just send the right coords). Maybe a whole array of video windows? Or tables? I could see the benefits, as long as the control is easy.
Actually a matrixctrl would be best if you don't want to *scroll*, just to jump to the exact spots on the large patch "grid". Interesting thought and pretty simple, you could also record the matrixctrl selections.... during a performance, maybe it goes to each spot automatically every 10 seconds, then you get that long to mess with the interface there. or maybe it chooses an area randomly... or it could be a "master control" where you see what your collaborators are doing on their machines, each section of the grid reflects their patch... nice.
It also actually helps during development too, not just in the final patch. If you have a lot of pieces in a patch you can spread them out horizontally (out to 32768 pixels I think), then easily navigate to them when you need to use them. Presets of window position are easier to recall than using the scrollbar. Or how about using a knob on your favorite MIDI controller? sure... it's all numbers ;)
Has anyone successfully used the MIDI Network to successfully send three different MIDI ports from 3 devices (each device had its own port number with multiple MIDI channels) using 3 sessions between two machines?
Spent several hours yesterday ( With Barry Threw) trying to make this work. One machine is a MacPro Core 2 Duo (running 10.41-sending machine) the other was a PPC machine running (running 10.4x receiving machine). Using all know good interfaces on the sending end and a MIDI monitor on the receiver end to examine the result. Each port had a valid Session name and said it was connected.
We had no trouble getting whatever was the first session in the list to work but neither of the other 2 would send anything. All ports were named and appeared to be connected with active sessions. We swapped hardware and all the usual tedious debugging semi-intelligent folks do but it always came down to whatever was the top session in the list (in "My Session" ) was the only working link.
So before more time is spent and hair pulled I ask, "Has anyone been succesful ine getting multiple ports over multiple sessions between two machine?