XHip--Please finish your synth!!

[chicken muffin]

onur_77's version isn't coming up, but if i had to take a guess, it looks something like this?

nice dude. jessica alba doesnt look that good.












but if she was a synth she would be a virus c

[gsoto]

Thanks for all the comments.

onur and beng, nice colors! I started the design with a dark scheme in fact, but at some point changed it to the current light one (temporarily). However, this thing definitely should have configurable color schemes. Mmmm, maybe a gamma slider could be handy too...

I think the main reason the old GUI was more aesthetic was simply the asymmetry of it.

Agree.

Think about it. Nobody has written down a rule that a synth GUI must be rectangular. That means you could go with the original very unique shape instead.

Sure that means a lot of dead space, if thinking in utilitarian terms, but there is also no rule that says a synth GUI must be utilitarian.

Well, it should be, in my opinion . I love blank space in design. But I think that one of the main problems here IS space. For some people the screen size of the synth is a really important usability factor. I became kinda obsessed with it; maybe too much...

the reason gsoto dropped that is due to the fact i was complaining.

Not at all; I'd never drop anything because of you complaining.

you should notice the control between "panning" and the modulator is actually exclusive

I wasn't aware of that.

I thought of the A+B thing just because of how the rest of the synth works. Now I see that things are more complicated.

If something will be added I'd go for your option 2 all the way.
Something like this is what I feel as the natural behavior:
pan = clip("output" + (modA + modB) * "depth")
(hopefully I'm making sense here).

On the other hand, may I ask why is there the "A+B" option and not independent depths for each modulation?
For example, like: frequency = "frequency" + envA * "depthEnvA" + envB * depthEnvB" + ...
where "depthEnvA", "depthEnvB" are parameters.
I think that it would add more possibilities without increasing the complexity. But again, I'm not exactly qualified to give a meaningful opinion here and certainly I don't want to distract you from the TODO stuff.

[aciddose]

"I think that it would add more possibilities without increasing the complexity."

well, depends how you define complexity. it'll add extra parameters, extra multiplications, extra parameter processing. on the other hand it does increase the flexibility of the synth. what i can do is i think i'll create a test version which replaces the modulation select parameters with 2nd depth parameters, then we can compare the performance of each. if there is a minimal performance hit, i'll use the modified version. the same issues (not just complexity) apply to the amplitude/panning modulation. they require more cpu power if multiple modulation sources are allowed. these things do need to be solved before the gui is created.

i'll make the changes now, then upload the new version.

[speccyteccy]

...I started the design with a dark scheme in fact, but at some point changed it to the current light one (temporarily). However, this thing definitely should have configurable color schemes. Mmmm, maybe a gamma slider could be handy too...

I'd love to see more software in general with customisable palettes like in Reaper. You could still have fading effects by cross fading between two colours in the palette.

[computercontrolled]

is there any version with some od these gui's available?

[gsoto]

Nope. Just images.

I'd love to see more software in general with customisable palettes like in Reaper.

Indeed. With the class loader aciddose is implementing we'll be able to share files with different configurations.

well, depends how you define complexity.

Sorry, I meant from a user perspective. Like you are not adding a new parameter at all, it just feels natural.
Nonetheless, a decrease in performance is a good reason for not including it.
If you want to implement it that's cool! But it is just my opinion, it would be interesting to hear other ones.

[Kingston]

aciddose and gsoto,

what are your stances on bump maps or detail textures? looking at gsoto's design a very simple metal/textile/sand bump map (something very unobtrusive) would make it even more aesthetic. Would it be a trivial thing to add?

say, bump map 1 to the module boxes (maybe a subtle drop shadow as well?), and bump map 2 on the background?

here's a quick knock up:



the module bumpmap is *very* subtle in this, but it adds up to a smoother overall result.

oh man I wanna start using that now!

[gsoto]

Looks really cool. It has a nice "I wanna use it" factor.

Regarding the question, acid should answer it, but I think there's no problem in doing something like that. His graphics engine can handle bitmaps and blending.
My plan with the GUI was to resolve the basic stuff first (layout, widgets, ...) and then move to the more eye candy stuff. However it's nice to see these kind of suggestions anytime.

[Kingston]

oh and I have to say. I quite like the way your color coding works, gsoto. It's almost like a pseudo module cabling as such, and makes things easier to read.

[funkadil]

is there any reason that my projects that use version 0.6.11.5 now have some goofyness going on in the patches. The problem there until I downloaded version 0.6.11.9? I have them in the same folder..... Maybe I should just reboot my computer. Its been acting funky.... Theres a distortion going on where it bursts out in really raw clipping sync-like way. Mostly on my low bass patches. Its not that I am using the new version, its not in my project, its just in the same folder and I tried it out earlier.

[DuX]

The colours on onur_77's version are so perfect it almost makes me wanna cry . Beeeaaaautiful! Kingstons idea is not bad, either, just as long as the background's dark . Cheesus, I can't wait to use it.

[Kingston]

just as long as the background's dark .

I quite prefer my scheme though. It's nice to have it dark, but not *too* dark and the beige contrast makes things easier to read.

Also, the problem with onurs scheme (when compared to gsoto) is that it lacks the handy color coding. It's a fresh idea and should be kept.

My version certainly could be improved with less of a draft feel on the shadows, and with simplistic pseudo 3d effects on the buttons and sliders maybe, and with more emphasis on warm colors.

Anyway, this is all in the name of urging people to throw more ideas around.

[Lance]

Darker GUIs are less exhausting for the eyes, and also less exhausting for the display and power consumption.

[Mighty Pea]

Kingston, you don't mean actual bumpmaps, do you? Or actual detail textures?
Why wouldn't it just be a background texture with these things baked in? I'm guessing the bumpmap won't be cheap. The detail texture might actually be easier on resources than a fully baked background though, depending on how it handles alpha's.
Gsoto: i'm liking both versions of your design. The colours just really work for me. Wether they'll get painfull after a while remains to be seen, but one'll always be able to change the colours himself, so no worries there.

[aciddose]

in the configuration file you can specify like:

Code: Select all

background
{
 color = 0x00000000;
 bitmap = ("c:/vst/xhip/mygui/bitmap.jpg");
 tile = 1;
}

this is already implemented. (unreleased though - it isnt practical for anyone to use yet other than me)

not only can you load bitmaps as textures, but i can generate them in the code too.



this is a "wood" texture generated by using filtered noise to adjust the lightness of an HSL color value, which has a brown hue. it takes less than a single ms during startup to generate this texture. it takes no more time to draw than a flat color. the graphics code is equal in power to photoshop.