Forums > MaxMSP

Smallest resolution to support?

December 15, 2007 | 2:47 am

Hey all,
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 1024×768 these days, so is that the best bet for Max patches too?

-Adam


December 15, 2007 | 1:40 pm

It’s a question of taste, custom, and convenience.

For many years I was in the habit of trying to keep to 512×384 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.

1024×768 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.



jln
December 15, 2007 | 2:18 pm


December 15, 2007 | 7:50 pm

Quote: Peter Castine wrote on Sat, 15 December 2007 14:40
> 1024×768 is a relatively small & safe screen size (I forget: what do 12" laptops support?).
—————————————————-
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?


December 15, 2007 | 9:39 pm

Adam Murray schrieb:
> 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 1024×768 these days, so is that the best bet
> for Max patches too?

Yes, as my 12" screen has this resolution, I’d consider any bigger
design as bad interface anyway. A limited space does teach to
concentrate on the essential btw…

After my 15" got stolen, I had to switch to the smaller Powerbook. This
was a very good decesion. I am much happier with the smaller machine. A
shame that all MacIntels are bigger… ;-)

(I long for an EeePC. but that would allow me to run only MaxPlay under
wine or to use Pd…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


December 15, 2007 | 10:11 pm

Andreas Wetterberg schrieb:
> I reckon it wouldnt be that hard to make an app that auto-scrolled
> when mousing towards the edge of the window, right?

If I’d see a beast like that I’d either not use it or if I have the
sources change it. A scrolling user interface is a nightmare…
Ever tried to read a website designed for bigger screens? Better boykott
them… Its too likely that the rest isn’t worth anything either…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


December 17, 2007 | 12:03 am


December 17, 2007 | 3:29 am

Thanks for the replies. Ok, so I will keep patches under 1024×768.

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.

-Adam


December 18, 2007 | 5:48 pm

scrolling is pretty simple with javascript (with props to whoever it was I stole it from awhile back):

function my_scroll(a) // list of x,y in
{
this.patcher.wind.scrollto((arguments[0] * nav_scale),(arguments[1] * nav_scale));
}

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 ;)

–CJ


December 18, 2007 | 6:03 pm

this could also get a lot more interesting with the zoom feature in Max 5.


December 18, 2007 | 6:11 pm

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?

John Lazzaro sent me docs :

sources for how it’s claimed to work:

http://www.soundonsound.com/sos/jul05/articles/tiger.htm#3

http://homepage.mac.com/edgarrothermich/.Public/Manuals/Logic7_1-MIDI_2005-0905.pdf.zip

Which make you think it is possible and indeed our setup
matches all the pretty pictures.

Thanks for anything resembling a reality check.

Keith

Keith McMillen
BEAM Foundation
http://www.beamfoundation.org/
510.502.5310


Viewing 11 posts - 1 through 11 (of 11 total)