Windowed GUI (executable only)

[AngularMomentum]

Anijs, very anijs...

[Dj-Grobe]

Check this angular:

viewtopic.php?f=7&t=9110&p=64625#p64625

[MichaelBenjamin]

nice tech demo, runs good, although sucking up all cpu when moving.
for my personal preference i would like to rather not use windows apps inside windows. one windows concept is disorientating enough.
programs, and especially plugins need to be static, not floaty. what advantage do you gain by being able to shuffle around the little windows? wouldnt it be better if the controls were at the right place from the start?
but the tech might be also good for other usage i cant imagine, and perhaps i am just an idiot who is unable to enjoy dragging windows inside windows, so keep on going.

[mwvdlee]

nice tech demo, runs good, although sucking up all cpu when moving.
for my personal preference i would like to rather not use windows apps inside windows. one windows concept is disorientating enough.
programs, and especially plugins need to be static, not floaty. what advantage do you gain by being able to shuffle around the little windows? wouldnt it be better if the controls were at the right place from the start?
but the tech might be also good for other usage i cant imagine, and perhaps i am just an idiot who is unable to enjoy dragging windows inside windows, so keep on going.

Well, the idea was to use it for configuration, not the effect itself. Stuff like setting up which MIDI devices to use, color scheme, MIDI button/slider configuration, (if ever possible) audio output configuration, directories; stuff you don't want on your screen all the time.

A benefit of dragable windows is that you can test your configuration without having to move between configuration and effect views in the plug-in, since both are accessible at the same time. It's all a matter of user-friendliness, and no singular view on this topic is ever perfect for all circumstances and all users.

p.s. CPU% seems to be equally sucked up for any type of graphic update. It seems SM uses up as much CPU% as it can when updating graphics, which seems reasonable if you want a responsive interface. The only thing that changes is the amount of time the CPU% is sucked. The only thing that seems to affect the CPU% is the size of the graphics being updated. To demonstrate; try the attached schematic and keep changing the knob for a few seconds; it actually sucks up MORE CPU% than moving around the windows Perhaps a way to optimize would be to redraw only the old and new areas of the window instead of the entire area.

[MichaelBenjamin]

yes i might have been too harsh on that. maybe i am myself a bit too much kind of frustrated how the interface design sometimes seems to be much more complicated and time consuming than the actual dsp processing. and no solution is fine under every circumstance so its always a compromise. i am mildly annoyed by apps that only concentrate on the little windows everywhere like gimp for example. maybe i only need a second screen where i can park them.
that vector knob uses much cpu yes.

[mwvdlee]

i am mildly annoyed by apps that only concentrate on the little windows everywhere like gimp for example. maybe i only need a second screen where i can park them.

No, Gimp actually DOES have a crappy user interface For the right way to do that, look at Photoshop.

[Dj-Grobe]

mwvdlee
Think is possible resize windows?
I think not possible, but just asking : )

I asking about resize window and make content resize at same time : )

[mwvdlee]

Think is possible resize windows?

Resizing the windows should be possible (though not in the current way I do it), but the problem would be the content; it would have to be resizeable as well. And it would most likely have to be repositionable too. It's basically a lot of messy and hard-to-maintain work for something I don't really see much value in.