DSP Robotics Support

In browsing through the schematics I've downloaded from the forum, I'm seeing a rather high percentage of otherwise decent-looking GUIs that, for no apparent reason, use darkish gray text over a dark background for the preset manager. The result is more or less unreadable, if not outright invisible.

Is it my monitor settings or is there some odd local convention that I'm unaware of?

It's just a way to encourage users to get stuck into detailed patch creation instead of being lazy and using presets, surely?.. No?.. Maybe I misunderstood, I was never much good at psychology.

You might not have noticed yet, but they get gradually darker over time until, a few weeks after download, there's nothing to see at all and the mouse pointer changes to the little hand icon (one finger raised if your default language is set to US English, or two fingers if it's set to British English)!

I have some visual perceptual wobbles that mean "dark modes" are more than just a cosmetic trend for me. It's something I would really like for FS, as after a while all the parts of the schematic seem to be different distances away from me, and my mouse co-ordination goes a bit wonky. But that said, I do rather prefer that the important stuff be in a strongly contrasting shade (no, not "shade", brightness!). If I want the WHOLE screen darker, I could just turn my monitor brightness down, or be really cool and wear shades indoors (that is still cool, right?)

My pet peeve is when the low-contrast colour scheme and tiny writing are erm.. "enhanced"?... by placing the labels directly beneath the controls, so that they can bask in the gloom of the drop-shadows. When I got into using VST, I was rather looking forward to having front panels that were easier to read than the ones on my old knee-level hardware racks tucked in dark, dingy corners. I'm very disappointed that, for all the beautifully rendered wooden end cheeks and taxonomy of machine-screw heads, not one plugin designer has ever thought to implement a virtual flashlight!

I don't think many of the most egregious ones I've seen have been SM/FS builds, and there are certainly a few people around here who I think really nail it. But there does seem to be something about simulating a screen on a GUI that tempts a lot of plugin designers to lower the contrast too much, IMHO - I quite often find them the hardest bit to read. And I would rather never see another simulated "ambient lighting coma" thingy in the top corner again. Don't people realise the lengths we used to go to in the CRT era so that we didn't have that kind of distraction? "Shiny" wasn't a design feature, it was an incredibly annoying limitation of making them out of glass. At least in real life you could make it go away by doing a funky chair-dance or buying a lampshade.

However, I must admit, the preset manager is always a bit of an afterthought for me - and every time I think to make a prettier one, I peek inside the stock one, have flashbacks to the last time I tried to tweak its GUI, and slowly back away again (it's a fun party game to try predicting which bits you can move independently and which... - oops, careful! - nearly spoiled the all fun for you there! )

Ooh, I really enjoyed that - I haven't had a good forum rant for ages!

I strongly suspected it was some sort of "screw with the newbies" deal, but didn't want to jump to conclusions.

trogluddite wrote:My pet peeve is when the low-contrast colour scheme and tiny writing are erm.. "enhanced"?... by placing the labels directly beneath the controls, so that they can bask in the gloom of the drop-shadows.

Don't get me started. One of my pet peeves is gratuitous "3D-ness": the shadows always point toward the lights over my desk, and my subconscious just latches onto the resulting "wrongness" and won't let go.

I'm guilty as all h**ll, as far as the preset manager with dark text. I only realized recently that the gamma of my PC screen is way off, making those dark grey texts much easier to read than what most people are seeing. I'm getting a handle on that now. I've probably overdone the drop shadows on knobs here and there too.

I should also keep in mind that I always customize the appearance of my PCs so that all windows/folders and workspaces have medium to darkish BGs; just easier on my eyes, which are a bit over-sensitive to light. I imagine if someone has a DAW with a very bright workspace BG, the PMs with dark grey texts would be quite hard to see. I do most of my project testing with VSTHost, and I've installed a non-standard GUI BG in it that is the color dark chocolate - I love it, but probably most DAWs' workspaces are much lighter, which would make the PMs hard to read.

trogluddite wrote:However, I must admit, the preset manager is always a bit of an afterthought for me - and every time I think to make a prettier one, I peek inside the stock one, have flashbacks to the last time I tried to tweak its GUI, and slowly back away again (it's a fun party game to try predicting which bits you can move independently and which... - oops, careful! - nearly spoiled the all fun for you there! )

I should communicate more often to experience the relief of not being alone with a problem. Because this is exactly me. Can't count how many times I wanted to to give the preset manager an overhaul and ended in painful surrender. I always thought I'm just too stupid to understand the genius of the module's workings, but now I see that it might just be a bad circuit.

Surely you just do something like make most of it wireless, like in my example...

Cheers

Spogg

It's sometimes confusing working with presets. Recently I had a fairly large project i was working on. Maybe something really handy for you to know is that if you wisth to add subcategories without them showing up in the default list produced by the daw. Merely use an array split and then add a comma followed by a <<:





It's a neat idea, that there are two ways to join an array innately. Then you merely re-assemble the array with the primitive and you have dropdown categories exactly where you wished them, without the need for strange symbols in the daw generated dropdown menu list.

I hope that makes sense to you and you find that useful.

Spogg wrote:Surely you just do something like make most of it wireless, like in my example...

That's a massive improvement, Spogg - I'll be keeping that one!

TBH, with me, it's more a matter of my character. The reason I post so many "toolbox" modules and hardly any complete VSTs is that I rarely finish them! I have a thing for digging into software just to see what I can bend it into doing, and once I've proved to myself that I can contort it in whatever bizarre way strikes my fancy, I tend to get a bit bored and impatient with tarting things up with a nice GUI etc. I just move on to the next crazy "software bending" experiment. My hard-drive is littered with half-finished plugin projects, and I routinely use plugins every day which have a bunch of stock controls haphazardly arranged on the stock "graph paper" background - so I'm my own worst enemy when it comes to terrible GUI's very often!

If I had been born a few centuries ago, I'd probably have been the guy who made hammers or fixed the handles back onto broken kitchen utensils. I just have the natural temperament to be a tinker rather than an artisan. Hence, a caveat to my previous rant: It's very easy for me to criticize other folks GUIs, because I've produced so few of my own to give away how inept I am at it!

tulamide wrote:I always thought I'm just too stupid to understand the genius of the module's workings, but now I see that it might just be a bad circuit.

I think it's quite telling that even those of us with so much experience still struggle with some of the stock modules. I really do think that many aren't "modularised" sensibly. For example, the stock knobs have the code to centre them in their GUI; but it's buried in a nested module which seems to serve no purpose except to make the feature unavailable to module re-sizing. The stock knobs still output dozens of triggers and redraws when their output value hasn't changed - something we solved in SM over a decade ago. And don't get me started on the Ruby code; it often seems to make Ruby look like bad Pascal (I don't have any nostaligia for vintage-style single-letter variable names!)

Between us, I'm sure we could easily create better set of stock modules for FS4 - not loads of extras to overwhelm people with choice; just replacements for the "everyday" modules which are more efficient, easier to customise, or better examples for novices to learn from (Spogg's "flexi-GUI" preset manager might make a good start!)

Of course, it's pure laziness that I haven't replaced them all with versions that I'm more comfortable with, and a little encouragement from Adam has convinced me to put a bit more effort into some better Ruby controls. But I always find another arcane "under the hood" aspect of FS to whisk my attention away!

trogluddite wrote:I think it's quite telling that even those of us with so much experience still struggle with some of the stock modules. I really do think that many aren't "modularised" sensibly.

I agree wholeheartedly. I'm under the impression that the modules were created in a hurry - and nobody cared, because those with enough confidence just made their own versions, and newcomers simple don't realize that they are bad examples.

trogluddite wrote:And don't get me started on the Ruby code; it often seems to make Ruby look like bad Pascal

Replace "Pascal" with "code" and I agree. Whenever I read the code from the stock modules, I see the result of a C-programmer's idea of what Ruby might be - without ever actually having coded in Ruby before.

trogluddite wrote:Between us, I'm sure we could easily create better set of stock modules for FS4 - not loads of extras to overwhelm people with choice; just replacements for the "everyday" modules which are more efficient, easier to customise, or better examples for novices to learn from

I tried. I really did. For example, I created all-purpose knobs that, thanks to "vector graphics" (if I call it "runtime generated graphics" most don't really understand it, and vector graphics is a familiar term, that in realtime generated graphics with Ruby share most of their properties with) were resizable in any way shape or form. Nobody got excited. I created ACM, an advanced color management module with a photoshop like color selection and even import of Photoshop palettes, nobody is using, although it's miles ahead of the color prim.
I saw my chance again, when Martin, years ago, published his fantastic arithmetic oscillators. I bundled them and programmed a selection module without the trigger issues, with readable code (although not documented, I'm very lazy as well) and a modern look. First thing people did? They ripped the new selection module off and replaced it with the old one.

trogluddite wrote:But I always find another arcane "under the hood" aspect of FS to whisk my attention away!

Similar here. I work on something specific, but suddenly something behaves unexpectedly and I discover new land in form of undocumented "features". And of course I immediately think of ways to make use of it. The original project? Out of my mind

Thanks Spogg .... very useful