To All Devs: please cater to BIG SCREENS!!!

[Shabdahbriah]

So what have we learned: people don't mind a little bit of [edit]aesthetic[/edit] imperfection, if it drastically increases usability.

Doubtless there are many for whom that will be a great comfort.

[tony tony chopper]

So what have we learned: people don't mind a little bit of graphical imperfection if it drastically increases usability.

yes, some people are less demanding than the programmers themselves, but that's not a reason to make steps backwards in quality

Vector UIs are perfectly doable these days

They are doable, they just won't match the quality a bitmap UI can achieve.
They also look obviously vectorial, but that's not a matter of quality, more taste. They also have some advantages, like you can easily recolor stuff or perform other transforms than rescaling.

[koalaboy]

Vector UIs are perfectly doable these days

They are doable, they just won't match the quality a bitmap UI can achieve.
They also look obviously vectorial, but that's not a matter of quality, more taste. They also have some advantages, like you can easily recolor stuff or perform other transforms than rescaling.

Why won't they match bitmap UI quality ? Most Icons and many other UI bitmap elements these days are created as vectors and then converted to a bitmap at the end of the process.

They won't match 'photographs' but then, this isn't something you often find in a UI. A bitmap is just a grid of single point vectors

[tony tony chopper]

Most Icons and many other UI bitmap elements these days are created as vectors and then converted to a bitmap at the end of the process.

I know I still have to hand-draw small things, because they would just look like blurred crap if vectorial & scaled down too much.

Vectorial scaling requires hinting. Hinting can be done for fonts, basic geometry, but not everything. And hinting usually only exists for fonts anyway, so even if you want a proper hinting, it's hard to find tools to manually add hinting. And without hinting, it will just look blurry.
No one in a bitmap editor will draw a vertical 1-pixel line by drawing 2 half-grey lines. With non-hinted vector art, it will happen all the time.

They won't match 'photographs' but then, this isn't something you often find in a UI.

I won't really argue because that's a matter of taste. I like simple, vectorial stuff too.
However look at all the existing plugins, they often have very fancy backgrounds with metallic/wooden textures, fake scratches, handles, etc. It's unique to audio plugins, but it's there.

[foosnark]

The other side of having all that screen real estate on a large, high-res screen is the feeling of wasted space when GUIs are too small.

Ogun for instance... I love it as a synth, but it uses 5-pixel-high fonts and two-letter abbreviations to cram everything into a tiny little space. Maybe that's good for small, low-resolution screens or maybe not, but I hope you don't hold it up as a triumph of bitmapped graphics over vector...

[Penis Arcade]

Vector UIs are perfectly doable these days (I'm writing them for work - non music, in Java) and the resolution is easily enough. They're the best solution, but require more effort generally.

No offense, but to make sweeping statements like that - maybe you should post examples and let others nitpick through your "perfectly doable" interfaces.

There are valid technical reasons why vector UIs are a big compromise at this time due to available technology. I am sure that some people place less importance on visuals - but i am sure you'll find an equal amount of those who hold the opposite opinion.

[koalaboy]

Vectors may not be suitable for every thing, but they are perfectly suitable for a resizable user interface. You may not think it's as glamorous as you'd like but a good UI is about usability and not glamour.

Graphs, curves, dials, buttons, selections... all of these are easily rendered as vectors. I'm not sure why you think vector UIs are a big compromise, but they've been usable for years.

I'm not going to post examples - partly because I don't 'own' my work, but mainly because it'll just turn into an opinionated flame-fest on what looks good.

The point is, vectors will work, and it's down to the developer whether to use them. There are some limitations, as Tony mentioned with small scale vectors and hinting, but they're just as easily worked around as the bitmap workarounds. Vectors have been around a long time.

[setAI]

I disagree- I think there should be more consideration for those of us who are using the GUI's directly on our touchscreens- controls that respond better to touch and have size/form for fingers-

ideally this would mean more large sliders / X/Y controllers and drawable envelopes/waves- and less knobs and small switches

[aciddose]

the solution is to render a gui with textures, not apply a "background texture". it's easy as heck to resynthesize a texture or bitmap at any size.

"vector" should simply mean that you use relative coordinates rather than absolutely coordinates. you can automatically hint important features by writing intelligent code to do so. the real reason nobody does true vector guis (vector does absolutely not take away your ability to use bitmaps or photographic elements!) is that there is no free code to do so. nobody is willing to write their own code.

my code is just about 100% capable (requires some better rendering code to remove bitmap based fonts, for example) but in order to write a vector gui with the same quality as a absolute coordinate based gui would require 3x more effort than writing the graphics code did in the first place.

there are solutions to the problem, for example using proper object models and rendering using d3d or opengl. you don't need to render in realtime, just render the bitmaps while drawing the first time and render again when properties change. i would already be doing this if i had some proper models to start from.. blender doesn't work right on this ati card for some reason.

another problem is the fact it isn't possible to resize reliably in older vst versions.. maybe some new plugins might come out that allow resizing...

http://xhip.cjb.net/hardware/images/ads ... -sttex.png

this is a vector gui, the texture is synthesized and it's resizable to absolutely any size - except for the fonts, which are bitmap. this is the type of "vector looking" thing that has been talked about. it's possible to make this look equal to a fully 3d rendered bitmap gui, it's just very difficult and time consuming. would you pay $1500 for a vsti that had this type of 3d looking gui, or would you rather keep the one i posted and pay $200? that's what it would take.

(by the way, it's possible to recolor bitmaps too, just store them as HLS, not RGB...)

[tony tony chopper]

it's easy as heck to resynthesize a texture or bitmap at any size.

to each his own minimum quality requirements, but rescaling bitmaps is always to be avoided in my book (unless it's animation where you can't spot artefacts)

by the way, it's possible to recolor bitmaps too

changing the hue is not exactly the same

[emdot_ambient]

LCDs have native resolution. If I run mine at anything other than 1680x1050 it gets harder to read.

Exactly. My DAW has a 17" LCD screen with native 1280 X 1024 resolution. Run it on anything other than that and text looks horrible...blurry every couple of letters.

And even at that resolution many VSTi's are so small I acan hardly use them. And even if you can see them often the knobs are so small it drives me crazy.

Ultimately I want like 3 24" or bigger monitors. But even with one huge one you could have much larger synth GUIs and still gain screen real estate. And anyway, do you people really leave the synth GUIs up all the time? I don't. I open them when I'm making presets...one synth at a time usually. After the preset's done, there's no point having the GUI open. All the rest is MIDI file recording and graphic manipulation of CCs. So having a huge synth GUI, even if it eats up most of my screen, would make preset creation much easier. It's not like I'm going to be doing a lot of live knob twiddling directly from the GUI.

[emdot_ambient]

...I'm still overjoyed at...how many more plugins I can have up...

While I would be one to ask, what's the point of having all those plugins up at one time anyway? How many of them do you work on at one time? In Cubase every plug-in is at most two clicks away. At most I'll have 3 up at one time: a BEFORE spectrum, an EQ, and a AFTER spectrum. Once you've finished editing, close the freaking things. Even with a big screen, what's the point of cluttering up the workspace with junk you're not actively tweaking?

Unless your'e doing live work, I don't see the point of having all that stuff open.

[emdot_ambient]

...there should be more consideration for those of us who are using the GUI's directly on our touchscreens- controls that respond better to touch and have size/form for fingers...

And that will be more and more a real issue as multi-touch screens become more widely available/cheaper.

Editing a small UI synth with a mouse is like someone handing you a Doepfer modular synth and a toothpick and telling you "Here, edit it only using this one toothpick, and . . . Have fun."

[tony tony chopper]

And that will be more and more a real issue as multi-touch screens become more widely available/cheaper.

Size of UI is really the least problem with multi-touch screens. You're not likely to see multi-touch supporting plugins any time soon because NOTHING in Windows is made for multi-touch, everything is based on mouse control through very old messaging. There are new SDK's but since our domain is always the last to evolve..

[aciddose]

to each his own minimum quality requirements, but rescaling bitmaps is always to be avoided in my book

resynthesize, not rescale. major difference. the texture must have been synthesized at some point whether it was in a graphics app like photoshop or whatever. it's just that you need to actually do the synthesis in your plugin rather than depending on a static bitmap. it's like the difference between a synthesizer and a sampler.

here is the code for the texture in the above screenshot i posted:

Code: Select all

void genbgbmp2(gfx &van)
{
 ADGFXVANILLA v2(van.width(), van.height(), 0);

 float nx = rand()/32768.0;
 float ny = rand()/32768.0;
 float r1 = 1.0 / 8.0;
 float r2 = 1.0 / 8.0;

 long hx = van.width()/2;
 long hy = van.height()/2;
 long xx = van.width()-1;
 long yy = van.height()-1;
 long zx = van.width();
 long zy = van.height();

 if (!van.Lock())
 {
  van.Clear(0x00000000);
  van.pushMode(transparent, 32);

  long n = 1000;
  while (n--)
  {
   float ra = rand()/32768.0;
   float rb = rand()/32768.0;
   float rc = rand()/32768.0;
   nx += r1 * (ra - nx);
   ny += r2 * (nx*nx - ny*ny) * 2.0;

   float s = 1.0 + ny * xx/5.0;
   float x = rc * xx;
   float y = rb * yy;
   
   long xh = (xx - s);
   long xl = s;
   long yh = (yy - s);
   long yl = s;
   long c = (0xFF000000 * nx);
   if (ny > 0.2) c |= 0x00FFFFFF; 
   if (x > xh || x < xl || y > yh || y < yl) ;
   else van.Circlef(x, y, s, 0, c);
  }

  van.popMode();
  van.Unlock();
 }

 if (!v2.Lock())
 {
  v2.Clear(0);
  v2.Rectblt(0, 0, xx, yy, (long *)van.pixel.mem, zx, zy, hx/2, hy/2);
 
  long y = hy;
  while (y--)
  {
   long x = hx;
   while (x--)
   {
    long c = v2.Read(x, y);
    v2.Pixel(x+hx, y, c);
    v2.Pixel(x, y+hy, c);
    v2.Pixel(x+hx, y+hy, c);
   }
  }

  v2.Unlock();
 }

 van.Lock();
 van.Rectblt(0, 0, xx, yy, (long *)v2.pixel.mem, zx, zy, 0, 0);
 van.Unlock();
 
}

this is quickly made code, it took about 5 minutes. it can do a large range of marble-like textures and it can generate at any resolution in a matter of a couple ms. the later block of code is to tile-ize the bitmap. you can write FAR better texture synthesizers than this one in the same five minutes time frame.

changing the hue is not exactly the same

ever heard of planar bitmaps?

(three seconds of thought should make you realize how easy it is to provide bitmap data of monocolor planes or properties and then adjust those properties rather than providing static color data.)

again, it's just a LOT more work. the fact is developers don't want to do the extra work, it's not a technical problem or anything like that. it's just pure and simple laziness.

laziness - of course if you were paid to do it you might change your mind.