Xhip Effects v6f

[EvilDragon]

p.s. this knob looks ridiculous in that flat environment. Haven't you noticed?

Not only that, but more than 50% of the GUI area is empty, function-wise. Knobs, LED nad switch can be at least 50% increased in size and it'd fill the area better.

[DuX]

Absolutely, ED.

[aciddose]

It would also look extremely cluttered. The GUI looks empty only because the fonts are the wrong size: I haven't included larger size fonts yet or added any of the associated code. It will take at least a week of work. (40 hours++.)

Ultimately the GUI is going to look the way I want it to look until the point an externally accessible skin system is working.

It's essentially a strip of knobs as in a rack-mount effects unit. Does the 2d face plate of a rack-mount panel look "out of place" with 3d knobs? That doesn't make much sense at all.

The GUI is "vectorized". It can be dynamically resized as I posted examples of.

Why don't I draw knobs? I do already draw knobs:

clipper2.0.png

Why don't I use them? They are extremely slow and so the code must pre-generate bitmaps anyway. Also they don't look all that great.

It all comes down to a massive amount of code that doesn't exist.

Why don't I write that code? Well because I'm too busy writing an AI that can write an AI that can write code for me instead.



If you want it to look "2d" that's great. Unfortunately I just don't really care.



I'll continue to work on things that I feel are actually important because I can see the big picture. If you think you can you're welcome to write your own GUI to prove it.

[aciddose]

I should have an alpha version available by some time next week. Most of the scaling functionality will work quite quickly but it will take a lot longer to tweak things like fonts, font kerning, bitmaps and so on.

multiplier2.0.png

So far I've created a configuration file (config.addb.txt) that you can edit like so:

Code: Select all

xhip effects
{
	version = 6.6;
	gui scale = 2.0;
	knob type = gearknob;
	knob color = gray(0.0);
}

It'll print the default options when first opened without a config file present. So lots of options can end up here like backgrounds (textures, gradients, borders, images) and widget selection or language translations.

That'll take ages to finish because an absolute ton of code is involved. I'd also like to update my NSIS installer for v7 of the effects.

[aciddose]

If anyone wants to muck around with fonts and kerning:
http://xhip.net/temp/fontselect.7z

This is the tool I use. Currently it uses the raw height provided by Windows' font renderer to name the fonts but this isn't accurate. It is however reliable that the raw height for every font in the same family will not be the same at differing point sizes. Unfortunately the renderer does not provide point sizes and the .ttf format doesn't deal in point sizes either; points are an arbitrary metric and don't correspond to pixels or anything at all really.

Most of the kerning tables (leading, trailing, kerning) contained in .ttf fonts and provided via Windows' API are bogus because most are automatically generated (the files don't include manual kerning done by the font author.)

In most cases it makes the most sense to render the raw data (will use the CWD = executable path) and then null (erase) the kerning table as well as leading and trailing tables. They should then be re-written from scratch.

This is a lot of work and so anyone wanting to volunteer could certainly help in this area.

Another option is of course to modify the GUI lib to use something like freetype to render fonts internally but this just moves the problem around: freetype produces inferior results in many cases and it requires the inclusion of a licensed font file while rendered bitmaps are typically allowed for non-commercial use in the license for most fonts. (Otherwise you couldn't distribute a paper printed with the font which would make the font useless.)

That would allow UTF-8 characters and far more flexibility in the text system; it would however be ridiculously complex and not at all worthwhile for me to do.

If anyone wants to play with fonts please keep me up to date on your work (tell me you're aiming to kern a font before you waste your time) so I can verify what you're doing is useful and can be included in Xhip/effects.

In the kerning table the default is -1, so it doesn't make sense to type "AB-1" because "AB" is the same.

See here for an example: (mmm, donuz)
https://imgur.com/a/Donuz

Code: Select all

leading {
}

trailing {
}

kerning {
---3
ck-2
ef-6
ff-10
fo-6
fi-4
fr-4
ft-2
if-5
lg-4
li-2
th-3
ig-4
bj-2
tc-2
of-4
hy-2
gh-2
gy-2
uf-6
gi-2
gr-1
ge-2
og-2
go-2
tg-4
ug-3
di-2
Ja-6
Tw-7
Th-2
Ju-4
Tu-6
He-4
}

[camsr]

Are bitmaps truly worth the effort? Vector graphics are inherently scalable AND your current designs are simple enough to do without a lot of overhead.

[aciddose]

Do you even know what "vector graphics" means?

It means a list of instructions sent to a graphics package to render bitmaps.

So it means: bitmaps that you need to render first.

Only it requires a graphics rendering library in order to render those bitmaps which is huge and expensive. It also requires a ton of processing power.

For example the existing knobs are "vector graphics", they're 3d models with lighting and shading properties in the 3d renderer "blender". I could incorporate blender if it's possible to utilize it via GPL through external tools and call into those tools via my own code to render the bitmaps. The knobs take about five minutes to render on highest quality at high resolutions like 200x200.

The knobs in the last screenshots are "vector graphics": my own code already includes a rendering library and can draw them in "real-time", which is actually at about 5 fps depending upon your processor. Older versions of the effects (2007-2009) used these knobs and did render in real-time: in other words they were 100% scalable and vector based.

ad_limiter.png

xhip_6.jpg

(Do you remember this vector version of the Xhip GUI? http://xhip.net/temp/xhip.17.5b.zip )

In 2011 I decided to buffer them into bitmaps because blitting a bitmap is about 1000x faster. As the number of knobs on the screen increased (or their resolution) the frame rate dropped to 1 fps, 1/10th fps and worse. By pre-rendering the bitmap strips the frame rate is always 1/60 or more until resolutions get into the 100x100 range (default size = 33x33.) This is because even the bitmap blit is 100% software and doesn't use hardware acceleration.

Do you want to write the code? You are very welcome to.

Create a free BSD-licensed GUI library which includes a "vector" rendering library and all the associated components and I'll provide you the interface Xhip uses for its GUI so you can incorporate your GUI into the plug-ins. (You probably don't remember but this is originally how it worked. There were several 3rd party Xhip skins that were never updated. The GUI was an external dll linked in via a defined/stable interface.)

The real issue is these are total shit effects/synths and you people bitch and bitch endlessly about the GUI! The GUI is already 90% of the work (which is why I never included GUIs to start) and you're successfully making it 99.999% of the work.

The tiny 0.001% left over means absolutely no work gets done on the plug-in itself.

You people (GUI/aesthetics) are incredibly stupid. To be honest I have no idea why I've ever listened to you and have wasted so much of my time. You should really just do the work yourself and shut the f**k up for once.

I honestly should release the next version without GUIs and never release the GUI code again.

ads-x1-layout-sttex.jpg

You do realize there are about ten other synthesizers and 30+ effects that would exist if it wasn't for you. If these vector based GUIs I wrote ten years ago were good enough for you.

[aciddose]

Is this oldschool enough? Or should it look more like Windows 3.0?

mdelay3.0.png

Should I also switch the code to draw in real-time rather than pre-rendering and caching the bitmaps? I could do that if you want to severely reduce the frame rate.

I could also switch to using built in Windows fonts, although this would eliminate about 9/10 features of the GUI and be much slower too.

The really funny thing is: these features are all available for you to set up in retarded ways yourself by modifying the skin/config.

[DuX]

Some really in-depth explanation of how vector graphics works. Thank you so much aciddose!

Personally, I just like the solution that uses the least CPU and RAM. Or GUI-less, like Airwindows plugins. Plugins that have up to a dozen parameters work quite fine without any GUI.

And in the end what matters is the sound anyway... yes.

[chk071]

Is this oldschool enough? Or should it look more like Windows 3.0?

mdelay3.0.png

Actually, that doesn't look bad. Prefer it to the original GUI. Just the mode switch looks a bit weird and misplaced. Doesn't fit to the other controls.

[Halonmusic]

Why are you getting all angry though? Sheesh!

[aciddose]

Well for any self-drawn widget I need to actually write the code to draw it. My graphics lib includes primitives like line, circle, rectangle, triangle, polygon and so on so technically it may be possible to use something like svg files, but I haven't ever bothered to do that.

If bitmaps are used it's super easy for anyone to edit the skin file to point to the right knob-strip or slider-strip bitmap and the same identical widget code works flawlessly with any appearance.

That's why bitmaps are great: they're super flexible, super simple, easy to use and optimal in every way. The only negative part is that they obviously take up a lot of memory (4 mb?) but that isn't such a big deal these days. Especially when a vector-based knob would need to be pre-rendered into a bitmap strip anyway to get the efficiency benefit.

Another option is a "real-time" vector GUI that uses something like open-gl with shader-based primitives. That's ridiculously complicated though and very difficult to maintain portability. (A bitmap/software system is ideal, can be ported anywhere, even c-64.)

With something like open-gl you end up having to pick the lowest common feature set which means you have really bad quality in general and can't do any advanced tricks. It does however open up hardware acceleration where it's available: but that encourages the design to require acceleration and things won't work efficiently (if at all) on older systems or where open-gl + shaders isn't available.

So that sort of thing isn't going to happen. That's a project in and of itself (a GUI engine) that would probably sell for a huge amount of money. Engines like that are used in games and so on for the in-game menu systems. Not my cup of tea.

Going in the direction I've already headed though: lots of this stuff will be possible by editing skins or configuration files and if the world goes in the direction of 500 ppi or 1000 ppi (ridiculous) 160000x90000 (ultra-ridiculous) resolution screens it's always possible to render bitmap strips and primitives (lines, circles, etc) using an updated hardware accelerated engine when it becomes necessary.

[aciddose]

Why are you getting all angry though? Sheesh!

To be honest I'm not angry at all. I'd be stabbing people in the face if I was any less than even calmer than a stoned Dalai Lama.



>>> http://bash.org/?4281

[Halonmusic]

Why are you getting all angry though? Sheesh!

To be honest I'm not angry at all. I'd be stabbing people in the face if I was any less than even calmer than a stoned Dalai Lama.



>>> http://bash.org/?4281

Aight. Just a whole 'angry' vibe. MY bad.

[aciddose]

No bad. It certainly is an angry vibe. I'm trying to express how much I feel you guys are assholes when you can't comment about anything but how some tiny unimportant element of the GUI on a free plug-in looks "out of place", without specifying how or what would fix it.

That's just your general common ignorant asshole. It gets taken up a notch when people start explaining "why not just do X, which would be super simple" when they clearly have absolutely no idea how X even works let alone how incredibly complicated it is. It goes up another notch because they're demonstrating their own ignorance and then in addition a complete lack of appreciation for the amount of work that has already been done and provided to them absolutely free of charge.

If you think my anger is somehow misplaced here I think you're 100% wrong. I do not want to "punish" people for their ignorance or especially when people are absolutely innocent. You have to realize though that hearing these kinds of dick comments non-stop whenever I post anything I've done just makes me want to curl up and die, literally. I just want to delete all the source code, flip you all off and say go f**k yourselves.

So in other words I really do not appreciate such stuff. It isn't helpful, it's just extremely annoying. It's the opposite of helpful. Being helpful is where you actually do something that matters or makes a difference: it would be doing something that reduces the amount of work I have to do.

Even if someone were to write their own GUI: maintaining the interface for such a GUI would increase my work rather than decrease it.

Would it be helpful if I gave up and stopped distributing all of my software? If I just outright quit? Probably not. It might very well happen though if people aren't capable of acting in a more sensible way.

In general, if you don't like the GUI: f**k you and go f**k yourself. Don't use the software. It isn't any skin off my sack.

If you see something that can be improved and want to help, recognize the limits of your knowledge and ability. Start asking questions: "would it be hard to ... ?" and actually listen to my response. If I tell you "that isn't going to happen" or "it wouldn't make sense" then take it to heart and STFU.

Having you act like a "back seat developer" just pisses me off and doesn't help anyone.