Adam Murray

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?

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

smallest-resolution-to-support

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.

But I wouldn't have any compunction about designing larger windows if needed to display information. 

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.


Quote: Peter Castine wrote on Sat, 15 December 2007 14:40

> 1024x768 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?

Quote: Peter Castine wrote on Sat, 15 December 2007 14:40
> 1024x768 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?


> 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

Yes, as my 12" screen has this resolution, I'd consider any bigger 

design as bad interface anyway. A limited space does teach to 

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 

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 1024x768 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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> 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...

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...

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.

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

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

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

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. 

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

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

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?

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 

Thanks for anything resembling a reality check.

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.

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

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


Smallest resolution to support?