Zoomfactor Offset

    Jan 02 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:
    Any pointers?

    • Jan 02 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.
    • Jan 03 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) {
    • Jan 03 2012 | 5:09 am
    • Jan 03 2012 | 1:41 pm
      Thanks Luke
    • Jan 04 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 !
    • Jan 04 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!
    • Jan 04 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.
    • Jan 05 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?
    • Jan 05 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.
    • Jan 26 2012 | 12:43 am
      I'm bumping this to post a little thing I did with the above javascript:
      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.
    • Jan 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
    • Jan 26 2012 | 1:47 pm
      Tak, Hr. Olsen.
    • Jan 27 2012 | 12:43 pm
      guden tak wii gates?
    • Apr 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:
      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); }
    • Apr 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.
    • Apr 24 2013 | 6:35 pm
      good to know that..