Forums > MaxMSP

Zooming in/out in code? (Display scaling and mini-display)

April 22, 2013 | 12:54 am

I’m working on a dynamic display/score system, and would like to do a couple of things, that would be sooo much easier if I could zoom in/out in code using Juce.

The first is to be able to adapt to different displays (all with the same aspect ratio). Because of moving/offset/font sizes, it would be a real pain to work out versions for different displays based on absolute pixels. If I could upscale to different displays, that would be amazing.

Additionally, part of my GUI will be a skype style mini-display of the upcoming section. Again, it would ideal if this could be a duplicate of my main display bpatcher, but scaled down.

Is it possible to access the command-plus/command-minus in code?


April 22, 2013 | 1:57 am

This patch:

– Pasted Max Patch, click to expand. –

is adapted from this thread:

http://cycling74.com/forums/topic.php?id=28322

have zoomy fun!


April 22, 2013 | 2:00 am

Awesome! I had a look through all the help/reference looking for something like that, but it’s unsupported!


April 22, 2013 | 3:05 am

Hmm, Ben refers to some JS solution in that thread, but there doesn’t appear to be any there. The zoom seems to zoom in into random places, which makes it less useful..


April 22, 2013 | 6:41 am

I think it works well for standard objects, but ui objects/3rd party might behave erratically / unpredictably (don’t think it’s that great with cellblock for instance), so best test it first with the objects you want to use… have no idea if it works in a bpatcher either.


April 22, 2013 | 8:08 am

"Is it possible to access the command-plus/command-minus in code? "
There is the aka.keyboard external,
http://www.iamas.ac.jp/~aka/max/
But I’m sure there are prettier solutions,
cheers!


April 22, 2013 | 9:41 am

For example, if I want to have a shrunk version of my bpatcher, I set the zoomfactor, and move around the bpatcher, but when I reload the patch, even though the zoomfactor is correct, the bpatcher location is moved around. I suspect the zoomfactor is ‘zooming in’ to where the mouse is?


April 23, 2013 | 6:16 pm

Hi Rodrigo,

This is from a rather large patch that does exactly what you are asking for

– Pasted Max Patch, click to expand. –

Even if you are not using FTM it should be self explanatory. I have the original size of my bpatcher loaded in a dictionary. The screensize object gets the resolution of any computer where the patch is open and automatically re-sizes and repositions the Bpatcher object itself and zooms in the embedded patch.

Let me know if it is not clear.

– Miguel


April 24, 2013 | 1:49 am

The notes are pretty clear, though it’s hard to tell where the ‘meat’ is happening. Are you using zoomfactor, and the this.patcher.wind.scrollto(x,y) things?

I wish ftm was compartmentalizable. I almost want to have a dedicated ‘mess with ftm’ install of max somewhere, as I’m scared to install/use it on any of my performance machines.


April 24, 2013 | 8:46 am

Hi Rodrigo,

I’m not using zoomfactor but presentation_rect. The logic of the patch works this way:

I use the height to determine the scale factor so that the inner bpatcher takes all vertical space. This way if the screens are different ratios the bpatcher is centered horizontally with empty space on the sides. So first:

Scale.factor = (screen.height / original bpatcher.height)

I then multiply the bpatcher’s original height and width by the scale.factor to get the size it needs to be for each computer’s resolution.

The meat is then a message:

script sendbox internal presentation_rect (($screen.width – $bpatcher.width) / 2) 0 $bpatcher.width $bpatcher.height

sent to [thispatcher] where ‘internal’ is the name of the bpatcher object (set in the inspector).

As a note, this is for a fullscreen patch and all dynamically loaded patches inside bpatcher are set to open in presentation mode.

hope this is helpful.

cheers

– Miguel


April 24, 2013 | 8:53 am

So presentation_rect actually scales the contents? I thought it just made the window (frame) bigger, but didn’t touch the contents.


April 24, 2013 | 9:31 am

You are right,

The above is from a different version of my patch where we weren’t scaling anymore. You do need javascript in the embedded patches.

This thread covers it: http://cycling74.com/forums/topic.php?id=37276

Now it should work :)


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