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

    Apr 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?

    • Apr 22 2013 | 1:57 am
      This patch:
      have zoomy fun!
    • Apr 22 2013 | 2:00 am
      Awesome! I had a look through all the help/reference looking for something like that, but it's unsupported!
    • Apr 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..
    • Apr 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.
    • Apr 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!
    • Apr 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?
    • Apr 23 2013 | 6:16 pm
      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
    • Apr 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.
    • Apr 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.
      - Miguel
    • Apr 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.
    • Apr 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.
      Now it should work :)