Home Forums General Programming export restricted instance + zoom panel problem


This topic contains 12 replies, has 4 voices, and was last updated by  human fly 5 months, 2 weeks ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
  • #72341



    I’m using MAC Ctrlr v5.3.163 and Ctrlr v5.3.198.

    When I export a restricted vst instance, I can not get a properly sized window.
    since “uiPanelMenuBarHideOnExport” does not work at all, I can set the menu bar to be hidden at ‘onPanelLoad’ with
    panel:getPanelEditor():setPropertyInt("uiPanelMenuBarVisible",0 )
    which works fine.

    v5.3.163 leaves a window space below and v5.3.198 crops the panel.
    however, on v5.3.198 if you add 24 to the height, the panel and window size becomes correct after it crops it. 🙂

    The problem is when you need to change the zoom of the panel, more specifically the zoom of a restricted vst, you end up with different size panel and window, which either results in small panel in large window having spaces around the panel or you get large panel with scrollbars in small window.

    This is very frustrating. if your “uiPanelZoom” is 1 then there is no problem. There has to be a way to have a proper panel size at different zoom settings.
    unfortunately setting the “uiPanelWidth” and “uiPanelHeight” does nothing.

    I don’t know if this is working on windows.
    Please atom fix this.

    • This topic was modified 8 months, 1 week ago by  Mr.ToR.

    human fly

    it hasn’t occured to me to use zoom. you want it as
    an active feature? why not just stick to x1? get your
    panel finished at that size and be done.
    what are the benefits?
    that’s just my thinking.
    i’ve found panels with an active zoom setting to be
    awkward, i can’t see the benefit (i’m not even very
    sympathetic to user requirements. they dig it or they
    don’t. my way or the highway 🙂 )
    (not that i’ve managed to finish a sodding panel yet..)

    • This reply was modified 8 months, 1 week ago by  human fly.


    my screen is three 1680×1050 displays.
    whatever I design on my screen, without a proper zoom feature would look like an interface from the last century on a 21.5-inch iMac 4K display or something similar.
    Believe me, regular stuff looks disturbingly small on modern hi-res displays.

    The problem is you can not set your panel size to be as a percent of the current display size, which you normally want. You set it’s dimensions in pixels and pixels have nothing to do with size.

    Now, consider two screens, both having the same size, but the second one has twice the resolution of the first one. Your panel will look twice as small on the second display.

    Since magnifying pixels usually looks like shit, a very common method in UI design is starting with the highest resolution and decreasing the size by adapting to the current screen. In UI design, this ‘zoom’ feature is mainly to decrease the original size to fit the current screen, not the other way around, so you can still get a clear and nice looking interface when it’s on a big high-res screen or on a low-res small screen.

    Basically, it is very very difficult to say programmatically, ‘I am designing my panel to be viewed from 1 meter and it should be in 25cm wide and 15 cm high’. Obviously, you can not dictate the screen specs for your panel, so you implement a ‘zoom’ feature. Normally, your program gets the screen size, the screen resolution, and use an adaptive algorithm to present the user the most appropriate size. If it’s too small, it will be difficult to use and see, if it’s too big, it will be invasive and childish basically unprofessional.

    So the simplest method is to let the user set the size with a couple of simple clicks and keep that zoom setting either as stateData or something else.


    human fly

    so would you suggest, if i’m working on a laptop, that
    i should aim to draft at a higher resolution when the
    time comes – and use the kind of zoom feature you’re
    talking about? i’m on 1366×768..



    Currently, as far as I can tell this is a missing feature of Ctrlr when your end product is a restricted instance. If your end product is an instance or just panel etc, I would definitely recommend considering higher resolution screens.
    resolution comparison

    try to imagine by considering this image how small your panel would look when you design it on your laptop and how someone with a 4k display would see it.

    If you design your panel to be full screen on your laptop, it will look almost like 9 times smaller on a 4k display. Now imagine properly filling that 4k display with your awesome panel 🙂

    That’s why you need a zoom feature 🙂
    you design for 4k and use the zoom for your 1366×768.



    ok, I got restricted vst instance to work with zoom in correct host window size.

    Currently, Ctrlr does not provide an interface to modify host window size in a restricted instance. This is very sad. I hope Atom would provide a method at some point. If you need to set host window size, you can only do this before exporting. After export, host window stays fixed to what was initially set.
    Here is how it works with any zoom setting.

    Let’s consider you have a panel with a size of 1910 x 1330 and you want it to be at 0.7 zoom, which makes 1337 x 931, so set your “uiPanelCanvasRectangle” to “0 0 1337 931” by entering the values manually and insert the following line to your ‘onPanelLoad’ method.


    This will make your panel programmatically cropped but have it viewed at the correct size. The issue here is that host window size is set by the panel:getCanvas():getWidth() and getHeight() parameters, which does not change with zoom. That’s why we’re using a cropped panel. However, panel:getCanvas():getParentWidth() and getParentHeight() gives a size dependent on the zoom setting, and host window size should use those, even when if you still don’t have the ability to change the host window size on runtime.

    Also, Ctrlr v5.3.198 on Mac, crops the window with 24 pixels from the bottom when you export a restricted instance, so to compensate that, set your “uiPanelCanvasRectangle” to “0 0 1337 955” adding 24 pixels to height.

    Finally, if you want the menu bar to be hidden add the following as well.
    panel:getPanelEditor():setPropertyInt("uiPanelMenuBarVisible",0 )
    Just don’t forget to implement a way to have the menu bar appear when you need it 🙂

    Hope this helps someone.


    human fly

    great info for the zoom, thanks for reporting back
    with your findings. it would indeed be nice to be
    able to offer at least a couple of different sizes
    once the thing is loaded. i guess ‘the culture’ is
    to distribute as a bpanelz so user can draft for their
    particular platform. but from creator’s point of view,
    it is preferable to distribute restricted instances if
    you want to preserve your mystique 🙂 (work)

    menu hide is nice.
    have to think of a nice way to present it for users.
    (after using regular VST plugins, it looks a bit
    incongruous to have all that on top without having
    the option to hide it, imo)

    in the wider world, your average VST user is going to
    be quite nonplussed once they start digging to see
    how to create a panel, when they encounter Lua. and there
    is still some misunderstanding out there re: how to
    use a bpanelz file – something Goodweather might like
    to consider for the manual (ie: the quickstart section!)


    Yea great findings Tonguç 🙂

    @humanfly: because you are allowed to sell panels one could steal your code and make money with it. I don’t see why Roman allows to sell panels, really: you will sell the Juce libraries, Ctrlr and in case of vst you will even sell Steinberg proprietary code AND you will sell your humble little panel. There are people that got badly cheated and won’t ever share a line of code again. That’s why some people will publish nothing else than restricted instances and I can understand them very well.


    human fly

    i quite agree. the ‘free’ culture out there has changed
    a lot in recent years, with some users taking a lot for
    granted. i’ve only recently become aware of commercial
    Ctrlr instances. then, you have the issue of how to
    distrubute, protect and sell your work, same as it ever
    was with plugins..
    interesting, what you say about the fact that it involves
    trading on the JUCE license, even if Roman is agreeable to
    people selling their creations. not actually an aim of mine,
    in any case, as i simply want to master enough to produce
    something presentable that works well enough to be useful.
    (and shall of course credit help and sources)(should i ever
    finish the d*** thing)


    human fly

    i do however think it would be good to have a ‘Utility’
    thread for establishing some basic practice for the
    minimum panel requirements for getting single preset
    data feedback-updating, so the panel keeps up with
    what’s on the device. i know this is all available to
    view with midireceived methods, but lots of different
    approaches out there – i’m looking at this now: it’s the
    first question i got back when i showed a first version
    (other than ‘will it work on mac?’ haha). ironically,
    i now see it is almost the first thing i should have
    started with, since you have to establish a parameter
    map with names right at the beginning, if you want to
    save reworking it all later on, eh.(and it is what i do,
    in some form, when i make my list for sorting out the
    sysex messages. if i’d known, i would just have done this
    in a lua document, rather than a scrappy notepad file,
    because it is essentially what i’m doing again now)
    (oops offtopic)



    sorry, i am not familar with Lua scripting, but how/where do you have to add this:

    panel:getPanelEditor():setPropertyInt("uiPanelMenuBarVisible",0 )

    .. so that my restricted instance will hide menu on start?


    • This reply was modified 7 months ago by  rio.
    • This reply was modified 7 months ago by  rio.

    human fly

    try it with an on/off button, with the method ‘called when
    value changes’. setPropertyInt 0 for off, setPropertyInt 1 for on.

    edit: sorry: you need to include that in a ‘called when panel has
    finished loading’ method. but as MrTor says, have a button somewhere
    to show it again once it’s loaded.
    – – – – – – – –
    okaaay, so i have a nice compact layout going on now, minimalist,
    panel action,.. and i have to consider what it’s going to look like
    on higher res / bigger monitors – because i went nuts with some small
    stuff haha.. i could resize it all, but it’s just the workspace size
    i’m working with on this monitor (13xx x 7xx), and i tend to mash things
    down every now and then to try to keep size under control 🙂 …

    what do you suggest doing? having a few sizes with buttons to select them?
    i have to check what you wrote, to see what code, and how to trigger it.


    human fly

    waaaah 😀 zoom is awesome !! i just tried it out
    with -/+/reset buttons and three zoom methods.
    everybody needs this.

    zoom zero (reset):

    	-- This stops issues during panel bootup
    	if panel:getRestoreState() or panel:getProgramState() then return end
    	panel:getPanelEditor():setPropertyInt("uiPanelZoom", 1)
    --	panel:getModulator("GUI_Style"):setValue(0,false,false)

    zoom in:

    	-- This stops issues during panel bootup
    	if panel:getRestoreState() or panel:getProgramState() then return end
    	local actual=panel:getPanelEditor():getProperty("uiPanelZoom")
    	local val=actual+0.0999999999999999778
    	panel:getPanelEditor():setProperty("uiPanelZoom", val,false)

    zoom out:

    	-- This stops issues during panel bootup
    	if panel:getRestoreState() or panel:getProgramState() then return end
    	local actual=panel:getPanelEditor():getProperty("uiPanelZoom")
    	local val=actual-0.0999999999999999778
    	panel:getPanelEditor():setProperty("uiPanelZoom", val,false)

    this is of course cribbed from an existing panel, by Possemo, i believe.
    i’ve linked them via ‘when mouse is down’. very happy with this. took
    a few minutes to make a few buttons and copy these methods in. i’m using
    your scaling values as i found them. *thank you-u*

    • This reply was modified 5 months, 2 weeks ago by  human fly. Reason: code tags
Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.

Comments are closed.