GUI Design offer (+20 samples)

[grooves1200]

any of you guys work in flash doing ui design at all?

sean
groovesmag.com

[grymmjack]

any of you guys work in flash doing ui design at all?

sean
groovesmag.com

i have used flash to do some animation tricks before i found rlh knob renderer, the tweening in flash is killer, that with motion guides and masks, and there is quite a lot of power to be had. what i did was something like gol was saying, i used a pot with no tick mark on it, and drew the tick in vector in flash and tweened it's rotation. it worked out well.

i've not done a full interface using flash entirely though, could be interesting. is it possible to work with vst/audio stuff with a swf format? i know visualbasic can embed flash stuff and would assume c++ could do it too, and the communciation to the movies are now possible with remoting. hrm.. interesting.

do you have something in mind? have you done any yourself? i've done a bit of flash work for web clients but nothing super hip or trendy or anything. nothing like www.sytrus.com

[AdmiralQuality]

The other "secret", that I'm tired of keeping to myself, is what you can do with 32 bit PNGs

here's a "secret" I will share: if everyone uses plain bitmaps it's to spare memory by using 8bit ones. Because some do care about resources.

My knobs can support about everything, plain bitmaps, RGBA ones (from PNG's or targa's), fixed background with line, and pie-slice. It's not because I can use masked ones that I abuse them. I still use 8bit ones, and I more tend to use procedural/vectorial knobs that eat no resource, are clearer to read, can be resized & recolorized.

tony^2, you're wrong again.

32 bit images SAVE resources, because you can use the same control everywhere it's used, instead of needing as many different versions of the bitmap as the control has positions (assuming your controls integrate with the background, as 95% of the plug-in GUIs out there do, whether "2D" or "3D". Also assuming you have more than 3 of the same control.)

And this is 2006. Even you probably have a graphics accelerator on your computer, I'm sure. All the compositing is essentially free. And everybody has 24 bit displays these days, so using 8 bit is just backward.

Compare SCAMP's file size and memory footprint to any plug-in of similar area. THIS...

...is a 1.57 MB .dll file and a 7 MB memory footprint.

THIS...

... is a 8.49 MB .dll file and about 24 MB Memory footprint.

Compare those figures to whatever other products you like, just make sure they're relatively the same size on screen, and you'll see. And vectorized knobs are RASTERIZED on screen, so while you might save file size, the memory footprint will be the same as any image of the same size.

Another issue... unlike certain industry leaders, I chose to have those resources returned when you close the GUI. So if you need some more RAM for your samples, you can get some back by just closing my plug's interface (even though it's still running). Try that with the other guys' stuff.. you don't get a single byte back. (Granted, it's a trade-off, their's open faster the 2nd time. Mine has to recreate all the controls. But their plugs always hold that memory, even when they're not onscreen. I figured the half second wait for the interface to re-load was worth the memory "refund".)

Check your facts please next time you feel like "correcting" someone here. You're embarassing yourself and your(???) company, and spreading a lot of disinformation and flat-out lies. (Surely you're the boss's kid or something? FLStudio isn't THAT bad a product. I can't believe you built it alone, if you indeed had any part in it at all. )

[tony tony chopper]

32 bit images SAVE resources, because you can use the same control everywhere it's used

Not if you have a flat background, or arrange the design so that knobs do, or if you make it so that knobs are all rounded (no moving shadow) and the inner moving part is a rectangle 100% inside the knob (I have knobs like this).

And it's not about speed - RGBA or not, most of the speed is lost in the GDI doing bullshit anyway. Unless you're using D3D or OpenGL of course. But I just hope you're not using that laughable VSTGUI - does its still have that for loop for its know tweaks, the one that blocks every host?.

7 MB memory footprint

You mean a 12MB initial footprint + a 7MB/instance?

I have a FULL synth (Sytrus) that has a 4MB initial footprint + 2MB/instance.

But of course you don't care, since your effect already eats 15% CPU, you don't actually expect users to open more than once instance of it.

And vectorized knobs are RASTERIZED on screen, so while you might save file size, the memory footprint will be the same as any image of the same size

That's pure nonsense(?)

You're embarassing yourself and your

Oh because you weren't embarrassing yourself with your 'hey look I made, I mean I discovered the PNG format, you're all dumb'

Btw, the way you mix same sized knobs with a totally wrong perspective with unreadable contrast, THAT's embarrassing.

[Blue Cat Audio]

any of you guys work in flash doing ui design at all?

I think using flash is a bit overkill for plug-ins UI. It would require to develop a heavy interface between the flash and C++ code and would require the customer to install flash etc...

And this is 2006. Even you probably have a graphics accelerator on your computer, I'm sure. All the compositing is essentially free.

I do agree with you that most computers now have graphics accelerators, and in this case alpha blending is (usually) very fast (it depends on the way the driver was implemented). But some graphics accelerators are very very slow, even on some modern computers (I have seen performance issues with some Intel chipsets), as soon as you do massive alpha blending (in your case it could happen for example if all the knobs were moving at the same time, due to automation or MIDI control).

But you are right that using 32 bit RGBA images (png or whatever) have many advantages. Even if we do not support the png format yet, we already use alpha masks in our skinning engine (see http://software.bluecatonline.org/Skins ) for transparency. It's the only way to easily skin a plug-in without having to re-create all the widgets bitmap when you want to change the background, as well as share one single bitmap for all the controls.

But I presume it essentially depends on your graphics creation workflow. There is no optimal recipie anyway .

Did you notice any plug-in on the market that takes that much memory because of duplicated bitmaps?

Another issue... unlike certain industry leaders, I chose to have those resources returned when you close the GUI.

So do we. Even if it may increase loading time, that's the usual way to deal with it: closing a window usually means freeing the associated resources. I am surprised you found "Industry Leaders" that keep resources. If loading time is a concern though, caching in memory is necessary. As usual it's a matter of compromise between CPU and memory. And with today's computers, most programmers decide that there's plenty of memory (which in a sense is right thanks to virtual memory).

[nollock]

And this is 2006. Even you probably have a graphics accelerator on your computer, I'm sure. All the compositing is essentially free. And everybody has 24 bit displays these days, so using 8 bit is just backward.

That is simply not true for Windows, GDI does not support per pixel alpha blending, you have to use GDI+ for that. And the features that GDI+ supports above GDI are all implemented in software, and are often incredibly slow at that. To get hardware per pixel alpha blending for a 2D interface you would need to use Direct 3D, which hardly anyone does cause it's a huge pain in the ass.

All though you are correct to sugest that a reused 32 bit composite will save memory, a lot of memory if it is reused enough times.

Compare those figures to whatever other products you like, just make sure they're relatively the same size on screen, and you'll see. And vectorized knobs are RASTERIZED on screen, so while you might save file size, the memory footprint will be the same as any image of the same size.

Thats not correct, for windows, vectorized knobs in GDI or GDI+ can be blited directly into the device context which will be either video ram or system ram. You dont need to pre-blit into a temporary bitmap in memory, although some may do so.

chris

[tony tony chopper]

as soon as you do massive alpha blending (in your case it could happen for example if all the knobs were moving at the same time, due to automation or MIDI control).

Here I don't ask windows to alphablit for me (it's not even available in win9x, and the whole GUI has always been total crap anyway, and GDI+ didn't make it better). I'm still using old unoptimized (no MMX/SSE) asm blocks.

But I can tell you that more CPU is spent in the GDI and DIB's (I want to access my pixels, so no DDB), than in my actual blitting. The GDI has always been the bottleneck for me.

Another issue... unlike certain industry leaders, I chose to have those resources returned when you close the GUI.

All I hope is that he shares his resources between instances. I just do not understand why plugins often don't share their graphics. I mean, 2 instances should at least use the same knob graphics.

[tony tony chopper]

GDI does not support per pixel alpha blending

It actually does but it's new to winXP (or maybe ME I don't remember), so it basically means you can't use it. But I wouldn't believe it's any hardware-accelerated anyway.

vectorized knobs in GDI or GDI+

I would also avoid GDI+. I had high expectations for it, but it turned out to be crap. Its vectorial drawing is a poor 4x oversampled one. Near-horizontal lines look like crap.

I have 2 advices: avoid GDI/GDI+, and avoid VSTGUI.
Do your own blitting (and even though I never cared for macs, if your plugins are multiplatform it's better for you).
Or use D3D or OpenGL, but then you enter a support nightmare. But you still have to use either GDI or D3D/OpenGL to do the final blitting anyway.
..or wait to see what Vista has to offer here.

(and about the original problem, even using a temp bitmap doesn't eat the resources of a knob strip)

[nollock]

GDI does not support per pixel alpha blending

It actually does but it's new to winXP (or maybe ME I don't remember), so it basically means you can't use it. But I wouldn't believe it's any hardware-accelerated anyway.

It does alpha blending in that you can draw an entire bitmap semi transparent, but it does not do *per pixel* alpha blending. You cant blit ARGB bitmaps and get each pixel blended by its individual alpha value.

vectorized knobs in GDI or GDI+

I would also avoid GDI+. I had high expectations for it, but it turned out to be crap. Its vectorial drawing is a poor 4x oversampled one. Near-horizontal lines look like crap.

I avoid it because is so slow tbh, i use my own custom graphics lib.

I have 2 advices: avoid GDI/GDI+, and avoid VSTGUI.

For some things they are perfectly adequate, but with GDI+ you need to be very careful, it has some very quirky behaviour speed wise. If you load a certain image format then do a certain operation it can slow to a crawl.

Do your own blitting (and even though I never cared for macs, if your plugins are multiplatform it's better for you).
Or use D3D or OpenGL, but then you enter a support nightmare. But you still have to use either GDI or D3D/OpenGL to do the final blitting anyway.

I looked into both of those as well, D3D wasn't a good solution because it just isnt geared for 2D. OpenGL was alot moe straight forward but like you say it has a big support problem.

..or wait to see what Vista has to offer here.

They probably forgot about HW accelerated 2D again, knowing MS.

(and about the original problem, even using a temp bitmap doesn't eat the resources of a knob strip)

You're right.

[tony tony chopper]

They probably forgot about HW accelerated 2D again, knowing MS.

well it's Vista, it's supposed to be all HW-accelerated (and critisized for that). I think it's about time.
I just hope there's some kind of nice GDI, with at least a subpixel coordinate system, basically the 2D part of any 3D system.

[AdmiralQuality]

But of course you don't care, since your effect already eats 15% CPU, you don't actually expect users to open more than once instance of it.

Hey asshole. Stop telling lies about my product. As you should know, CPU usage is RELATIVE, but you speak about it as if it's absolute. (Or perhaps you're computer is just puny, your Win 9x comment should indicate where you're coming from there.) Secondly, SCAMP is a 6 channel effect and if you're only processing a stereo track, and all 6 channels are active, you're wasting 200% more processor power than you need to. Bypass channels 4 to 6 and shut the f**k up. Or drop the Quality switch to "Econo" and half the CPU usage again. A philistine like you won't hear the difference in quality anyway.

Again, all you're doing is TRYING to make other people's products look bad by INTENTIONALLY misusing them. You are a fantastic twit.

And vectorized knobs are RASTERIZED on screen, so while you might save file size, the memory footprint will be the same as any image of the same size

That's pure nonsense(?)

You're embarassing yourself and your

Oh because you weren't embarrassing yourself with your 'hey look I made, I mean I discovered the PNG format, you're all dumb'

Btw, the way you mix same sized knobs with a totally wrong perspective with unreadable contrast, THAT's embarrassing.

You're a twit Tony.

[tony tony chopper]

As you should know, CPU usage is RELATIVE, but you speak about it as if it's absolute.

Very true. That can only mean a lot more CPU for most people since I have a quite recent one.

you're wasting 200% more processor power

No, you are.
Here's another tip: don't process silence, because it's useless. And don't blame the user for CPU that you waste.

[AdmiralQuality]

As you should know, CPU usage is RELATIVE, but you speak about it as if it's absolute.

Very true. That can only mean a lot more CPU for most people since I have a quite recent one.

you're wasting 200% more processor power

No, you are.
Here's another tip: don't process silence, because it's useless. And don't blame the user for CPU that you waste.

Twit, it's an IIR. I can't just f**king turn off the process because an input goes silent. If YOU want to process silence, I have to let you. It's actually your host's issue for not negotiating the number of connected channels correctly. But I added an .ini file option for users with those hosts for disabling that behavior, which you'd know about if you read the docs.

I think it's clear how you work. Go ahead and be misinformed as you want, but quit telling lies and spreading intentional misinformation about my product. Scum.

[tony tony chopper]

Twit, it's an IIR. I can't just f**king turn off the process because an input goes silent.

You can. I do. If it's not self-resonant, after some time its memory will be zeroed out and you can stop processing it.
If it's self-resonant, it's not yet at the beginning, so you can skip processing until it's fed at least once - which means never, in my case.

Because your plugin WILL be processing silence for a big part of an average project. And it's not up to the user to disable it manually. But keep wasting CPU, it comes for free, right?

[AdmiralQuality]

Twit, it's an IIR. I can't just f**king turn off the process because an input goes silent.

You can. I do. If it's not self-resonant, after some time its memory will be zeroed out and you can stop processing it.
If it's self-resonant, it's not yet at the beginning, so you can skip processing until it's fed at least once - which means never, in my case.

Because your plugin WILL be processing silence for a big part of an average project. And it's not up to the user to disable it manually. But keep wasting CPU, it comes for free, right?

How about we give TSV his thread back and you and I go to war in our own thread? You start it somewhere. Go ahead. Liar.