From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
Here's just a fun little demo of some GUI ideas I worked on today. I may or may not end up using these in a finished product, but I thought it would be cool to show since I don't think I've seen something like this in SM before.
GUI (zip file)
I guess this is also the first "public" thing that I'm not giving away the schematic for, sorry, but I think you'll all understand when I say I want to keep some tricks for myself if I ever want to earn the steep purchase price of S|M back 🙂
I think all the controls are what made the file a bit big, so I'm hosting it on my own server instead of uploading here. I just grabbed a bunch of controls from my toolbox, nothing's actually hooked up to anything. Except the "About" button.
trogluddite ·
Oooh, that's rather nice 🙂
I've experimented a little with pop-up windows, but this blows mine out of the water. I'm imagining a synth with a totally user customisable front panel - 'just show me the bits I want to see right now!' If you could make the windows dock, and then store the window layout as part of a preset it would be an absolute killer for putting big synths on small screens!
philter5 ·
nice stuff
😉
Dj-Grobe ·
really nice,
check please the private message.
MegaHurtz ·
Strakke graphics hoor 🙂
Nice occasion to state they really have to include html one day.
Edit: Java.. OOh
Dj-Grobe ·
Really be nice see the OSM : )
please ! : )
needaname ·
awesome, congrats
mwvdlee ·
Dj-Grobe wrote: Really be nice see the OSM : )
please ! : )
As I said in the original post, I won't be giving the OSM away, this includes private messages.
I may be willing to share some parts of it though, if other people get stuck in trying to recreate something like this.
Dj-Grobe ·
For be honest i trying do exactly this for years, and never can do, for taht reason i really want see how you do thsi on SM.
Can share that part you comment? or can sell it?
I really suprise when see you do this : ) this work is awesome !
MegaHurtz ·
LOL Mwvdlee you can make cutting the V input seem like quantum mechanics.
Jay ·
what is it that's so special you ppl want to learn from Mwvdlee's example? The same thing as me? is it the fact that he has managed to stop the triggers passing through to controls hidden on the non focused layer? that is kinda cool
Ive managed to recreate the rest of his example except that little bit! in my version the controls only work on the window that has focus i.e the one that's in front 😕
this is an easy thing to accomplish in other dev environments! but atm it eludes me as to how its done here! I will crack it though eventually!
Best regards
Dj-Grobe ·
How he do that.............simple like that..... : )
mwvdlee ·
Jay wrote: stop the triggers passing through to controls hidden on the non focused layer?
Im not using a focused layer, rather z-ordering.
Stopping the mouse-event passing through is as simple as catching all mouse events on the entire window area and doing nothing with it; just like you would do in Windows, although in SM you have to be a bit more explicit about it.
Dj-Grobe ·
Please mwvdlee, can helpme?
really stuck on this...
Jay ·
ah cool! i will have to research some on that! z-ordering! i probably already know how to do it just,i don't know the proper terminology for half of what i do 😉
I notice also that your example works better than mine in respect to moving the little internal windows around the screen! works much more smoothly on yours!
my implementation is probability much more clunky and elaborate for what its doing! i would like to learn your superior methods!
lol i am still trying to understand your GUI catching system!
@ DJ Grobe. I am about to post my example sometime today! so if it is any help to you it will be in the graphics area! just don't lol too loudly at my feeble implementation! and a i said above mine ain't as good as mwvdlee's but it might help give you a few pointers
Best regards
AngularMomentum ·
Anijs, very anijs...
Dj-Grobe ·
Check this angular:
Windowed Gui
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 ·
MichaelBenjamin wrote: 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 ·
MichaelBenjamin wrote: 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 ·
Dj-Grobe wrote: 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.
mwvdlee ·
Here's the schematic for this nearly two year old example.
Since I don't think SM will ever be stable and bug-free enough for me to sell any product, the strategic benefits of closed source no longer outweigh the potential quality benefits of open source for the schematics I use for my own music playing. Either way a windowing system is hardly the most significant feature in an audio product.
The demo shows only four windows, but it's capable of eight in it's current state.
With some more effort it should be quite possible to support many more windows but if you look at the schematic you'll quickly find that it can get out of hand rather quickly. Extending to 9 should be easy. Any more would require a rebuild of the innermost Z-Order module since it relies on decimal digits, and those stop at 9. I guess if you started at 0 you could have 10 windows, but rebuilding that module might require less effort.
As for a license; MIT license will do. It'd be nice if improvements were shared, but not legally required.
Acrobat ·
I should say, in this case, I already imagined it exactly as it is...
but thank you for both the effort and the realization! 😀
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker