How large should a UI be at the most? Post your opinion.

[T-CM11]

because they are both unusably small on my 2560x1080 monitor.

21:9? Ableton user?

[chaosWyrM]

because they are both unusably small on my 2560x1080 monitor.

21:9? Ableton user?

21:9 yes

ableton no.

fl studio. 21:9...is glorious.

[T-CM11]

because they are both unusably small on my 2560x1080 monitor.

21:9? Ableton user?

21:9 yes

ableton no.

fl studio. 21:9...is glorious.

Less vertical resolution -> Less tracks simultaneous on screen (Ableton has that horizontal thing )
To me, 16:10 was the better widescreen format.

[BlackWinny]

so wait...both of those appear blurry in the post (because they are enlarged)...if i use "view image" on them...is that the actual size they are?

because they are both unusably small on my 2560x1080 monitor.

These images are those from the product pages at KVR:

• Here:http://static.kvraudio.com/i/b/xhip_0_7.png
• And here:http://static.kvraudio.com/i/b/reverb.png.

AndI have just checked and compared with my installed copies: it is the exact same size.

Hem... Don't be astounded if they appear so small at a resolution of 2560x1080. I think that you can easily admit that it's not at all a resolution very common... Perhaps that you use a screen chosen for your special (certainly professional) use... but certainly not a common screen on the usual market. The most common resolutions of today are a width of 1280 (on 15") and 1600 (on 17"). And I think that the developers try to develop for the most common resolutions of the moment, don't they?

[chaosWyrM]

because they are both unusably small on my 2560x1080 monitor.

21:9? Ableton user?

21:9 yes

ableton no.

fl studio. 21:9...is glorious.

Less vertical resolution -> Less tracks simultaneous on screen (Ableton has that horizontal thing )
To me, 16:10 was the better widescreen format.

well, fl studio will scale and fit however many tracks youre using onto the screen...does ableton not do that?

as it stands i can fit 32 plug ins onto the "step sequencer" panel without having to scroll, and for me the extra horizontal space is far more valuable.

besides...16:10 is nowhere near "wide" screen enough. i do a lot more on this computer than just use fl studio.16:10 is practically useless for some of the other things i do.

16:10 is not gonna work for me when making stuff like this:

[mhog]

IMO the various companies should adopt Tone2 synthesizers dimension as the standard GUI. These are the most comfortable ones.

[T-CM11]

well, fl studio will scale and fit however many tracks youre using onto the screen...does ableton not do that?

Every DAW does that. But the more tracks, the narrower they are.

besides...16:10 is nowhere near "wide" screen enough. i do a lot more on this computer than just use fl studio.16:10 is practically useless for some of the other things i do.

Makes sense, but I was only referring to music production (the only purpose my laptop has). And indeed, wider screens are nicer for graphics stuff (I do DTP at work).

[chaosWyrM]

it seems to me...not knowing anything about guis or how they are made...

the best solution is to just have several sizes of static ones like some devs do. it was mentioned that a resizable gui is too much work, how much work is it to have several static ones? that doesnt sound like a lot of work at all...but what do i know?

[chaosWyrM]

well, fl studio will scale and fit however many tracks youre using onto the screen...does ableton not do that?

Every DAW does that. But the more tracks, the narrower they are.

besides...16:10 is nowhere near "wide" screen enough. i do a lot more on this computer than just use fl studio.16:10 is practically useless for some of the other things i do.

Makes sense, but I was only referring to music production (the only purpose my laptop has). And indeed, wider screens are nicer for graphics stuff (I do DTP at work).

yeah, unfortunately i really only have the one computer, so it has to play a lot of roles. i *do* have a laptop, but thats strictly for travel purposes. i wouldnt use it for any kind of serious work.

all in all though, as far as guis are concerned...it seems obvious that the trend is moving towards larger screens in general. even before i went to a relatively large 21:9, when all i had was a single (i later went to 2) 19 inch 1440x900, i found a fair amount of vsts to be too small. granted they were older...but still.

[1wob2many]

it seems to me...not knowing anything about guis or how they are made...

the best solution is to just have several sizes of static ones like some devs do. it was mentioned that a resizable gui is too much work, how much work is it to have several static ones? that doesnt sound like a lot of work at all...but what do i know?

Yeah, it shouldn't take more than a couple of minutes...







(where's the f***ing smiley for irony?)

[chaosWyrM]

it seems to me...not knowing anything about guis or how they are made...

the best solution is to just have several sizes of static ones like some devs do. it was mentioned that a resizable gui is too much work, how much work is it to have several static ones? that doesnt sound like a lot of work at all...but what do i know?

Yeah, it shouldn't take more than a couple of minutes...







(where's the f***ing smiley for irony?)

yeah, its like ten thousand smileys when all you need is a knife.

[aciddose]

the best solution is to just have several sizes of static ones like some devs do. it was mentioned that a resizable gui is too much work, how much work is it to have several static ones? that doesnt sound like a lot of work at all...but what do i know?

This depends upon how the code is written. Ideally everything is based upon an integer coordinate system in the code and to switch from a grid of 32 pixels to 48 pixels or 150 pixels simply requires adjusting a few numbers and everything else automatically falls into place, including the alignment of widgets and text and so on.

Unfortunately however it will require a new "skin" of bitmaps including knobs, background and so on to be created. Xhip is designed this way and I can trivially create a GUI at a larger scale. This sort of thing however is way far down the TODO list of "things that are actually important" and would happen after skin support is improved and multiple skins are provided.

Also, the current size is ideal for my 1920x1200 16:10 displays as well as for the 1080 displays I have. You can get larger displays, but they are physically larger. I don't want a theatre screen or television in my office, nor do I want to be sitting ten feet away from the monitor. Widescreen formats are also not ideal for myself because generally I have the browser/document in the center of the screen, close to square ratio or about 1100 x 1100 the majority of the time.

Unfortunately they've stopped making monitors for productive/office work. I'm hoping this fad will wear off soon, although it seems unlikely.

BTW, credit for the current Xhip layout goes to branis from the forum here.

[chaosWyrM]

the best solution is to just have several sizes of static ones like some devs do. it was mentioned that a resizable gui is too much work, how much work is it to have several static ones? that doesnt sound like a lot of work at all...but what do i know?

This depends upon how the code is written. Ideally everything is based upon an integer coordinate system in the code and to switch from a grid of 32 pixels to 48 pixels or 150 pixels simply requires adjusting a few numbers and everything else automatically falls into place, including the alignment of widgets and text and so on.

Unfortunately however it will require a new "skin" of bitmaps including knobs, background and so on to be created. Xhip is designed this way and I can trivially create a GUI at a larger scale. This sort of thing however is way far down the TODO list of "things that are actually important" and would happen after skin support is improved and multiple skins are provided.

Also, the current size is ideal for my 1920x1200 16:10 displays as well as for the 1080 displays I have. You can get larger displays, but they are physically larger. I don't want a theatre screen or television in my office, nor do I want to be sitting ten feet away from the monitor. Widescreen formats are also not ideal for myself because generally I have the browser/document in the center of the screen, close to square ratio or about 1100 x 1100 the majority of the time.

Unfortunately they've stopped making monitors for productive/office work. I'm hoping this fad will wear off soon, although it seems unlikely.

thnx for the explanation. i wasnt really talking about your plugs specifically. i was just talking in general, and more about devs creating new plug ins, not going back and messing with already released ones. you made it sound earlier as if using resizable vector graphics was a bit labor intensive. it would seem to me then that just using the same static images in differing sizes would be less so, which it sounds like you have confirmed.

[aciddose]

Using "vector graphics" means the code needs to draw everything itself. So you can't get an artist to create backgrounds and so on, they need to be drawn directly by the plugin. So the plugin becomes an implementation of photoshop or something rather than just being able to focus on being an audio plugin, obviously this takes a lot of additional effort that might be better spent elsewhere.

Yes, using differently sized bitmaps is easy as long as you render them from a high-res source. For example backgrounds created by an artist might be rendered at a very large size (such as for box art), then rescaled down and filtered to the low-res versions used on screen.

If at some point someone wanted a 2x resolution version it would be fairly trivial to simply repeat the down-scaling process, except this time only go half as far.

For new plugins designed with this in mind yes, it should be reasonably trivial. The problem is though that you should find most plugin GUIs are designed with hard-coded hand-written coordinates rather than having a flexible system of equations.

For example: widget_size = 32, spacing = floor(widget_size * 10%), font_pt = floor(widget_size * 37.5%) ...

widget[i = 1] = (offset.x + i > 0 ? (widget_size + spacing) * (i - 1) : 0, offset.y + ...)

vs.

widget[i = 1] = (742, 264)
widget[i = 2] = (777, 264)
widget[i = 3] = (812, 264)

So, in those cases the whole layout of the GUI would need to be computed and typed by hand, again specifically for each resized skin. A lot of GUIs are designed like this.

I only use Xhip as an example that I can talk about as I know 100% of everything about it. For other plugins we can only speculate, although it may not be too far from the way I describe the issue with Xhip.

Other plugin developers are also likely to prefer working on the actual plugin than to spend a lot of time creating different skins or layouts. As loud as they complain I don't think people with enormous screens in a studio sitting 20 feet away are a common thing.

[Ameyah Audio]

one pixel only

1000x700 is the limit, i have an ultra book which is doing 1366x768.