June 13, 2017 at 5:27 pm #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
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.
June 13, 2017 at 9:27 pm #72343
- This topic was modified 2 weeks, 1 day ago by Mr.ToR.
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..)
June 13, 2017 at 10:04 pm #72346
- This reply was modified 2 weeks, 1 day 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.June 13, 2017 at 10:29 pm #72348
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..June 13, 2017 at 10:57 pm #72349
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.
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.June 14, 2017 at 6:15 pm #72363
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.
Just don’t forget to implement a way to have the menu bar appear when you need it 🙂
Hope this helps someone.June 15, 2017 at 8:36 am #72365
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!)June 15, 2017 at 10:45 am #72369
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.June 15, 2017 at 12:24 pm #72372
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)June 15, 2017 at 12:34 pm #72373
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)
You must be logged in to reply to this topic.