Xhip Effects v6f

[aciddose]

More screenshots (imgur)

http://xhip.net/effects/

This version is important to anyone using the effects due to the fact they now use "vst chunks" for preset data which includes version info. This will allow backward compatibility for future effects releases which add new parameters or change existing ones.

One interesting new feature is that I've converted from a decibels "threshold" value for the compressor to its scaling factor. The "threshold" parameter is actually compression depth and so had a reciprocal skew making it very hard to dial in small compression amounts in previous versions. That has been fixed.

I've also added parameter readouts for the compressor and limiter where they are most likely to be useful. I'd also like to go through a handful of minor issues with other effects and their readouts (displayed if you use automation in some hosts) being inaccurate, especially those displayed as a percentage rather than frequency as in some cases.

These effects have always been "quick and dirty DIY" and I regularly use them myself because I'm able to make them work exactly as I want. They are not "high quality" effects but they work well in the majority of cases where I want to apply effect plug-ins while I dislike a lot of the other plug-ins available out there. That's one of the reasons I've made them available: there may be someone like me out there who is looking for effects like these but doesn't have the time to do all the programming themselves; as rare as that may be.

There are also some unique things about each of these effects which could surprise you and they might find some uses that might not be obvious at a glance.

Posting here because I prefer not to post news for a minor release like this. A major release would need to include significant improvements or new effects.

Please let me know if I've messed anything up. I know the GUIs are small (people also complain about how they look?) and a resize feature is on my TODO list.

[Halonmusic]

Thanks. They look fine to me. Clean and simple. A resize feature would be great.

[BrokenTrance]

You always have to appreciate people that develop this plugin bundles, and then make them free.

Go aciddose, Go Canada

[Ichad.c]

The Jitter function on the Quantizer is quite useful, thanks!

[skyscape]

They're great and very useful. Love mdelay.

[Russell Grand]

Awesome! Thanks, acidose!

[HSum]

Dude, these plugin editors are tiny af

[aciddose]

Your pixels are just too small. Get bigger pixels and spare no expense.

[HSum]

Your pixels are just too small. Get bigger pixels and spare no expense.

I will use a projector then. No other chance to handle them on a 4k display

[aciddose]

Actually I've been unable to find a good quality >200 ppi display at sizes <25", they just don't seem to go for less than $1000 or so and I've never once seen a good one so I have no idea how much it might cost.

I'd never invest that amount in a monitor especially one that I'd almost never use. For detailed graphical work definitely but for programming? I use the 6 pixel wide "terminal" fixed-width bitmap font. I find it extremely readable and it is essential due to the tiny size: more text can fit on the screen at once while remaining extremely clear.

So for me on a 120 ppi display the size of the GUIs and fonts are perfect. At 90 ppi they were perhaps a bit larger than needed but I couldn't maintain clarity when rendering the anti-aliased glyphs at smaller sizes.

If you get into the 200 ppi range though I can see things appearing tiny as they're nearly half the size. Unfortunately in order to deal with scaling (as in Xhip synthesizer) it requires that I include additional scaled fonts and put in a bit of effort toward the skinning system to ensure the effects scale correctly. So it isn't something that would take a few hours. It's more like several weeks of work meaning it might not happen for years.

With so many programs/plug-ins pushing up the size of their GUIs and cramming in tons of clutter or alternatively huge areas of confusing whitespace (flat buttons anyone?) I can understand why people would want to upgrade to 4k monitors at smaller sizes. Obviously a 40" display isn't going to fit neatly on a desk. 25" or 22" is more practical. (22" at true 4096x2304 = 214 ppi?)

I suspect the office world just isn't ready for it though and with the "PC" desktop nearing its end I can't see it becoming commodity stuff rather than forever a high-end niche. So unless you're severely near sighted and sit an inch away from the screen I'd be willing to bet you run into a lot of trouble with a lot of software that can't handle such huge sizes and probably burn through an awful lot more watts running the processors (video card, etc) needed to supply that thing.

That's another problem with Xhip: the GUI system is 100% software and uses complex rendering techniques which would require complicated shaders to blend textures for hardware acceleration. Every time you increase the resolution linearly you get a squared increase in bitmap sizes, processing cost, bandwidth and so on. Unless you're doubling light-speed or using some "quantum CPU" (fantastical nonsense) it just can't scale well.

There are a whole slew of problems and a massive amount of work that is needed in order to make GUI scaling work at all: even in a half-arse way. So don't get your hopes up. (I've already spent several days working on this. It's an on-going task.)

[aciddose]

Percentage of work done = ~5%

[Teksonik]

Maybe some more skilled with Knobman and Skinman could help you out.

[aciddose]

No, because you can already replace the knobstrips or other bitmaps effortlessly. The issue is the code.

Not that I wouldn't appreciate new skin resources. Just that the current ones are generated from 3d objects in blender and I also quite like them.

The switches are likewise.

The Xhip logo is also from blender. (Also the manual icon, windows icon and 64-bit icon.)

The font resources are generated using Windows' renderer with a tool I wrote myself. Font resources include characters 33 to 127 (US-ASCII) in a bitmap strip with constant height. They include a kerning table, (leading, width, trailing and character pair kerning) as well as glyph information (height, ascent, descent, space width.) Most of this process is automatic but character-to-character kerning information isn't present in the vast majority of fonts. Where it is present it is typically extremely inaccurate. So manually kerning each font requires hours of work.

The gradients and LEDs are generated inside the code. The LEDs are pre-generated bitmaps that are stored as files (programdata/xhip/bitmap cache/leds/....tga) while all the background gradients and other features are drawn directly in real-time by the code.

The whole system is designed to minimize the amount of work required to change things. It is truly a minimal GUI system. In order to create this example re-sized version (scale = 2.0) I needed to include some additional bitmap resources and adjust the widget rectangles for various controls as well as offsets for text and the like.

As you can see the label text uses a fixed offset without taking into account the widget size (for slide-switch labels) which requires more code be written to accommodate variable widget sizes.

The code to select the nearest sized widget is as follows:

Code: Select all

	template <typename T>
	typename T::bitmap *get_bitmap(float desired_dimension)
	{
		T::bitmap *selected = nullptr;
		float distance = 1000.0f;
		for (T::bitmap_manager_t::blist::iterator i = T::bm.bitmaps.begin(); i; i++) {
			T::bitmap *k = i.p->data;
			float new_distance = fabsf(k->size.x - desired_dimension);
			if (new_distance < distance) {
				selected = k;
				distance = new_distance;
			}
		}

		assert(selected != nullptr);

		return selected;
	}

Similar code exists in Xhip for selecting variable size fonts.

Normally this would all be accomplished by using some massive if() statement like:
if (scale == 1.0) {
copy the entire code to set up the GUI at 1.0 scale
} else if (scale == 2.0) {
copy the entire code to set up the GUI at 2.0 scale
}

That makes it a nightmare to maintain the code. With the methods I use it takes about 100x as long to initially write the code, but afterward I can add any scaling factor I like (1.36825?) and it works automatically.

[aciddose]

Here are some of the scalings that are already possible.

Since no additional fonts are present yet and due to the fact the GUIs use fixed offsets it'll require a lot more code is added to scale fonts successfully. Three fonts are currently present: the "logo" font (name of the effect), the "section" font (for headers) and the "normal" font for labels and readouts.

100%
120%
150%
200%
250%
http://imgur.com/a/OQm1N

So this is why having proper scaling code is very useful. Only one skin file is required and it can be scaled automatically to any ratio. Scaling is dynamic and even if a limited number of bitmap resources are available the nearest one is used. So skins can come with scaled bitmap resource sets that are added as needed.

Any modification of the skin only requires one modification. It is easily maintainable because everything else is automatic and based upon one source: there is no redundancy.

[DuX]

Why don't you vectorise the GUI AD? At least your GUIs are thankfully not too complex. Use a knob like Fabfilter or Valhalla plugins or something. It's the sound that matters in the end and I know your stuff is top notch.

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