Home Forums General Programming export restricted instance + zoom panel problem

Tagged: 

This topic contains 11 replies, has 4 voices, and was last updated by  human fly 3 weeks, 1 day ago.

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

    Mr.ToR
    Participant

    Hi,

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

    • This topic was modified 2 months ago by  Mr.ToR.
    #72343

    human fly
    Participant

    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 2 months ago by  human fly.
    #72346

    Mr.ToR
    Participant

    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.

    #72348

    human fly
    Participant

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

    #72349

    Mr.ToR
    Participant

    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.

    #72363

    Mr.ToR
    Participant

    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.

    panel:getCanvas():setSize(1910,1330)
    panel:getPanelEditor():setProperty("uiPanelZoom",0.7,true)

    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.

    #72365

    human fly
    Participant

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

    #72369
    Possemo
    Possemo
    Participant

    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.

    #72372

    human fly
    Participant

    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)

    #72373

    human fly
    Participant

    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)

    #72516

    rio
    Participant

    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?

    Greetings.

    • This reply was modified 3 weeks, 5 days ago by  rio.
    • This reply was modified 3 weeks, 5 days ago by  rio.
    #72535

    human fly
    Participant

    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.

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

You must be logged in to reply to this topic.

Comments are closed.