Forums > MaxMSP

Zoomfactor Offset

January 2, 2012 | 10:10 pm

Hi all,

Is there any way to control the offset when zooming in a patch?

I have a patch that loads other patches into a bptacher. The main patcher is displayed in full screen, and the bpatcher window is always resized to fullscreen as well.

Inside the bptacher I have it so that I calculate the difference between the screen size and the contents of the bpatcher. I then use zoomfactor message to [thispatcher] so everything is scaled and it fits into the window.

All of this works so far but there is a problem since the zoomed contents "move" and are not positioned correctly inside the bpatcher.

This shows the problem:

– Pasted Max Patch, click to expand. –

Any pointers?


January 2, 2012 | 10:44 pm

I’m not sure that it’s exposed to thispatcher. It can clearly be done behind the scenes, as the zoomer object does it when Navigate Zoom is selected.


January 3, 2012 | 4:38 am

Save the following as a javascript file and instantiate it in your patch. Send it a list of the co-ordinates you want to scroll to, in this case "0 0" and trigger this after every "zoomfactor" message and the positioning should be reset.

function list(x,y) {
    this.patcher.wind.scrollto(x,y);
}

January 3, 2012 | 5:09 am

Cool.


January 3, 2012 | 1:41 pm

Awesome!

Thanks Luke


January 4, 2012 | 12:53 pm

So there are hidden-non-referended possibility to thispatcher!
i’m so glad to discover zoomfactor ! anything else ?
luke, may be you’ve got the same type of magic formula to zoom only horizontal or only vertical ?
(just asking)
happy new maxing years !


January 4, 2012 | 5:49 pm

You can set the co-ordinates of the scrolling destination by altering the x or y in the javascript above. You can even hook this up to a [line] to get smooth scrolling (good with offsetting [bpatcher] contents). Zooming by it’s nature is done in both directions so you don’t get horribly stretched objects!


January 4, 2012 | 9:03 pm

Yes,
but if my bpatcher contains panels or bpatchers with function inside and nice background color, they won’t look horrible stretched and I will get a wonderful look-like-a-timeline patch.
witch is possible with scripting but this zoomfactor command wouldl simplify everything a lot.


January 5, 2012 | 12:48 am

I can’t picture what you mean so I’m not really sure if it is possible or not. You’re definitely talking about zooming only horizontally or vertically, rather than scrolling?


January 5, 2012 | 7:40 am

yes, exactly.
rather than managed the two dimensions at once (witch is actually what zoomfactor does)
I’m talking about zooming the x axis only while leaving the y axis unchanged.


January 26, 2012 | 12:43 am

I’m bumping this to post a little thing I did with the above javascript:

– Pasted Max Patch, click to expand. –

It allows zoom and scroll in your patch using a 3dconnexion SpaceNavigator, ala Google Earth. I like it a lot more than the built in zoom, BUT it can totally be improved, which is why I turn to you:

Now, as you can see it requires both the js AND the thispatcher to be in the parent patch that you want to zoom about in. I am certain that this can be circumvented, but I lack the js chops AND the thispatcher hackery knowledge.

what I’d like it to do is have an option to simply get the current mouse position in the main patcher and zoom to that.


January 26, 2012 | 3:54 am

add this to the js

function zoomfactor(a)
{
	this.patcher.message("zoomfactor", a);
}

and it redirects the message to thispatcher.
[mousestate] can report cursor loc in patcher.

@fixrobert there’s also "topmost 1/0" wich isn’t documented

O.


January 26, 2012 | 1:47 pm

Tak, Hr. Olsen.


January 27, 2012 | 12:43 pm

guden tak wii gates?


April 24, 2013 | 1:01 pm

This is super handy!, though for some reason it’s not working when I do it inside of a subpatcher. If I’m inside the patch (of the bpatcher) it works fine, but sending the messages from outside the bpatcher, it does the ‘randomly zoom in position’ thing.

Another quirky thing I’ve noticed is that if you send a zoom factor less than 0.5, it seems to break the scroll.to thing. 0.5 + scroll messages goes where it should, but 0.49 + scroll message goes to an offset of what it should.

Here’s the meat of my patch:

– Pasted Max Patch, click to expand. –

The body of the js file is:

function zoomfactor(a)
{
this.patcher.message("zoomfactor", a);
}

function list(x,y) {
this.patcher.wind.scrollto(x,y);
}


April 24, 2013 | 6:31 pm

Just using a regular offset fixed the problem from controlling it from the outside.

The not zooming below a certain value has to due with the window size. If you stick something in the far bottom right corner out of sight (really really far) it works perfectly.

– Pasted Max Patch, click to expand. –

April 24, 2013 | 6:35 pm

good to know that..


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