This patch:

is adapted from this thread: https://cycling74.com/forums/zoom-in-locked-patcher

have zoomy fun!

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

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

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.

"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!

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?

Hi Rodrigo,

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

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

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.

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

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

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: https://cycling74.com/forums/zoomfactor-offset

Now it should work :)