Xhip Effects - Skinning

[aciddose]

Short version:

Xhip Effects and Xhip Synthesizer both include a skinning system with rudimentary configuration features. These features have been used in the code and to handle layouts internally, but never exposed to the user.

The latest version of Xhip Effects (6.7) includes skinning configuration, the ability to replace or override resources like fonts, background images, knobs, switches and LEDs and further improvements are planned.

About 20% of the work toward being "fully skinnable" is complete and is an ongoing process. I've posted this thread to encourage interest and participation in this process as I have limited interest in modifying the GUIs myself, so any features that are needed to support customization that skin authors might want need to be brought up here so they can be implemented.

You can get the latest version of Xhip Effects for Windows and Linux to test these features. Currently the MacOS port lacks a GUI and work in also ongoing to produce a working port.

[aciddose]

The configuration file format strips all unquoted whitespace. You can place aribtrary spaces between elements or even within them " = sp li n e ;" and the result will be "=spline;" This includes tabs and newline characters!

[skyscape]

Very cool, will certainly experiment with this a bit.

[aciddose]

For anyone interested/curious: Basically I'm looking for comments/requests for features to be added to this system from people who are experimenting with it.

For example: "Could you ..."

• Add png support? (Yes.)
• Add external library (plug-ins) support for scalable rendered widgets? (Yes.)
• Make it possible to adjust all text on the GUI for translation? (Yes, eventually.)

I've more or less ordered those as they are currently in my "mental TODO list". I feel png support is very important although the decompression overhead is quite huge. So in order to implement that I need to first implement deferred decompression of resources. This is currently noticeable due to the large number of compressed fonts included in the fonts/logo package.

Completed:

• Options to configure fonts.
• Options to set up the header (logo + title) and widget groups/sections.
• Shape/shade/border options for rectangles.
• Parameters for widget renderers.
• NSIS scripts for creating skinres packages.

Skinres NSIS example script:
http://xhip.net/effects/releases/skins/ ... example.7z

Unproductive posts:

• Subjective commentary that isn't related to the skinning system.
• Requests that the project use a different GUI framework.
• Requests unrelated to the existing framework with regard to what the poster thinks is "more important" for me to work on.
• Suggestions "it should be a simple matter of programming to: ..." that are arrogant regarding the required work. Everything orbits around the central point of work being done by someone. In this thread I'm here to help your work to produce the Xhip Effects skin you want to create.
• Suggestions involving "could have, would have, should have".

These are not at all exhaustive lists

[DPhil]

Nice work.

I just opened the compressor and intuitively wanted to edit the readout text of the controls. Would it be much work to make these editable? Or a similar "problem": some plugins don't have readouts at all. Would it be possible to add a global readout (just a horizontal textbox that shows "param x: 0dB" when the control is being touched. for example VPS Avenger synth has this at the bottom)? Or maybe a right-click context that says "enter value"?

Would it be possible to add an option if the space between groups and the border gets scaled? If I specified a scale value of 3, it looks nice but then there are these big borders that just contain nothing. It is totally fine in smaller scales.

[aciddose]

Would it be much work to make these editable?

It is a bit of effort. Conversion from a text value to the actual parameter value however needs an inverse function: both for text-to-value and value-to-parameter. Currently only parameter-to-text and parameter-to-value are implemented.

In addition each GUI element would need to be associated bidirectionally with parameters which would require a significant number of complex callback interfaces. (I do not / will not pass pointers!)

There are other issues (text/edit widgets, expression evaluator) that need to be solved to complete such a feature and I feel this is more a "full skinning" feature where you could set a global option like "display = edit".

It certainly could be a more long-term element on the TODO list though.

If you're asking due to "nice round" values: The GUI currently has two features to help with this.

One is right-click and shift both increase the div (zoom) factor. On most parameters like cutoff frequency using left+right-click and shift at the same time should allow you to adjust the value more accurately than the printed digits. So you can get "1000.0 Hz" if desired using only mouse input.

The second is mouse-wheel has custom step sizes for each widget as well as using shift for zoom works with a custom div factor. For example on parameters in decibels the usual is steps of 3.0 dB with a 1/3 div factor making the steps 1.0 dB. I use pure mouse-wheel input 99% of the time.

Or a similar "problem": some plugins don't have readouts at all. Would it be possible to add a global readout (just a horizontal textbox that shows "param x: 0dB" when the control is being touched. for example VPS Avenger synth has this at the bottom)? Or maybe a right-click context that says "enter value"?

This requires adjusting a lot of the spacing features of the GUI. For example the Compressor and Limiter GUIs have a single row of knobs which allow the readouts to actually fit, while in some of the other effects this space is not available.

Xhip incorporates a global readout for this purpose and it is trivial to implement. It is more of a "full skinning" feature though which could be added to custom effect skin layouts.

I suppose an option "readout = enabled;" could be added to the default skin but I prefer to avoid adding too many features like this ("cherry on top") as it makes the skin too complex. So for that reason I would prefer this to be handled as part of the complete skinning system instead. As a temporary feature however it may be interesting to play with. Requires a lot of work to ensure sizing works correctly; while the current skins only just barely work now.

Context menus and menu-triggered edit boxes are trivial; assuming it is already possible to convert a string to a parameter value (which it isn't.)

Would it be possible to add an option if the space between groups and the border gets scaled? If I specified a scale value of 3, it looks nice but then there are these big borders that just contain nothing. It is totally fine in smaller scales.

Yes I could add those options which are the most simple. Currently the variables at play for the standard skin are:

Code: Select all

int header_height = 26;
point widget = (40, 40);
point spacing = (12, 12);
point knob_size = (33, 33);
point switch_size = (32, 16);

I'd need to add a distinct group_spacing value. I suspect CSS/HTML conventions (float/align/margin/padding) would work best although for now the simplified "spacing" values are far easier to compute.

Adding the ability to set these values from the config is extremely simple.

[aciddose]

Small amounts of progress so far adding more flexibility to the config parser.

I've improved spacing, fonts and other features enough to produce this:

compressor0.5.png

I've compressed the compressor!

quantizer0.5.png

reverb0.5.png

[aciddose]

I found the reverb to be still far too large and so I've kerned some microfonts to allow it to work at 1/3rd the size.

reverb0.3.png

This is still huge in that it uses 17703 pixels of course but without a microscope I can't effectively shrink the GUI much further.



(BTW: this really works. Using the GUI like this is the most hilarious thing ever.)

[aciddose]

A little more progress. It still isn't possible to configure 100% of the variables at play but this is getting closer.

I've added a keyed-data input for named parameters as well as a color parser including expression evaluation.

This allows:

background { shading = bevel_tl_gradient; color = hls(1/6,1/2,1/2); }
group { border = on { style = rounded; } }

Most importantly the code is super simple for handling this stuff (without proper error handling ...):

Code: Select all

	read_bool(opt, "background", b->o.background.enable, bool_key, error_message);
	read_color(opt["background"], "color", b->o.background.color, error_message);
	read_bool(opt, "border", b->o.border.enable, bool_key, error_message);
	read_keyed(opt["border"], "style", b->o.border.style, border_style_key, error_message);

quantizer3.0.png

Still to come: adjustment for font parameters and control of the "inline spacing" that is strewn about the engine in places like:

Code: Select all

point size = widget.get_destination() * offset;
point spacing = widget.get_spacing() * (offset + pointf(1, 1));
point widget_offset = size + spacing + scale(point(0, 9));

(Here point(0,9) is the extra space for the group name/caption.)

Example of the config.addb used for the screenshot:

Code: Select all

version = 6.6;
guiscale = 3.0;

background {
	shading = bevel_tl_gradient;
}

header {
	height = 26;
	logo = left;
	border = 0;
}

group {
	spacing = (12, 12);
	background = off;
	border = on {
		style = rounded;
	}
}

widget {
	size = (40, 40);
	spacing = (12, 12);
	border = off;
}

led {
	size = (16, 16);
}

knob {
	type = spline;
	size = (39, 39);
}

switch {
	type = simple;
	size = (38, 20);
}

I'd like to add stripping of comments (// c++ and /* c */) to the pre-processor stage and I can add all the documentation to the built-in configuration, but this is a bit complex. Each comment would need to be tokenized with a hash-name. The manual version would be:

Code: Select all

background {
	available_values {
		shading = "one of:
			flat, tl_gradient, top_gradient, bevel, bevel_tl_gradient, invert_tl_gradient, user_gradient,
			rounded, rounded_tl_gradient, rounded_alpha, rounded_user_gradient, rounded_no_fill,";
	}
}

That might actually be nice to use instead because it doesn't require extra complexity to deal with comments but it's arguably not nearly as nice as c/c++ style comments. Another positive aspect is the value itself would be somewhat self documenting and it would maintain its position and allow the configuration to be edited programmatically.

Before anyone mentions something about another format: XML/json/etc can suck a big one.

[aciddose]

Even better: (Or worse if we're talking about the appearance, IMO of course)

quantizer4.0.png

Still no configuration for fonts but margin/padding exists for most elements.

Code: Select all

version = 6.6;
guiscale = 4.0;

background {
	shading = tl_gradient;
	available_values {
		shading = "one of: flat,
			tl_gradient, top_gradient, bevel, bevel_tl_gradient, invert_tl_gradient, user_gradient,
			rounded, rounded_tl_gradient, rounded_alpha, rounded_user_gradient, rounded_no_fill,";
	}
}

header {
	height = 26;
	padding = (4, 2);
	logo = left {
		offset = (4, 3);
	}
	border = off;
}

group {
	padding = (4, 22);
	margin = (4, 4);
	title {
		offset = 4;
		spacing = 0;
	}
	background = on;
	border = off {
		color = named(black);
		style = rectangle;
	}
}

widget {
	size = (40, 40);
	spacing = (8, 8);
	border = off;
}

led {
	size = (16, 16);
}

knob {
	type = spline;
	size = (39, 39);
	name = 7spline_ba;
}

switch {
	type = simple;
	size = (39, 20);
	name = slide_switch_tilt;
}

[aciddose]

I've updated the version posted on the alpha page to r1008 and I've uploaded my example config.addb.txt file.

Still no further changes (fonts, etc) but this version now supports everything I've posted about to date.

[aciddose]

The flat background is obviously very simple and five minutes ago it popped into my head for some reason to try this:

limiter2.0.jpg

Not surprisingly it works quite well with a simple brushed metal jpg texture at 1024x768 (must be large enough for the largest GUI.)

Rather than relying upon pre-processed textures the software shaders in my graphics engine can be used to do complex blending.

In this case I've used:

• Multiply
• Blend 1/2

So this should be producing: background/2 + (background * texture)/2. Since the brushed metal texture is very dark the modulation of the background intensity is roughly equal to the intensity of the texture and depth is adjustable via the blend parameter from 0 to 100%.

Hopefully I can expand this system to make it very flexible to allow textures to be applied in various ways to both groups and the overall background. It isn't practical though to allow unique backgrounds for each effect without a more advanced skinning system, at which point each individual skin will be able to define that kind of thing.

[aciddose]

Very slowly another 2%...

gate2.0.jpg

...should've used wasps for the texture.

[aciddose]

https://i.imgur.com/VO3BbK6.png (2x)

The knob renderer now takes input for parameters like color, shading options and spline count. It is also now possible to resolve variables by using for example:

Code: Select all

knob { color = var(background.color); }
switch { color = var(background.color); }

I realized that since // and /* are valid variable names it is possible to use c++ style single line comments so long as the resulting variable name is unique.

The full current config on my test machine:

Code: Select all

version = 6.6;
guiscale = 2;

skin = brushed_metal;

text {
	normal = "tahoma" {
		border = off;
	}
	header = "sofachrome";
}

background {
	//shading = "one of: flat, tl_gradient, top_gradient, invert_tl_gradient, user_gradient,";
	shading = flat;

	//shape = "one of: rectangle, rounded_rectangle,";
	//effect = "one of: none, bevel,";

	//color = hls(7/12, 5/8, 3/8);

	image = "texture/micro_a" {
		blend = transparent(0x40), xor, delta(0x20202020), scale(0xC0);
		tile = on;
	}
}

header {
	height = 28;
	padding = (4, 2);
	logo = left {
		offset = (4, 3);
	}
	border = off;
}

group {
	padding = (8, 4)(8, 4);
	margin = (12, 12);
	title {
		spacing = 6;
	}
	background = on {
		shape = rounded;
		shading = flat;
		color = gray(1/2, 0);
	}
	border = off {
		shape = rounded;
		color = gray(1/2, 1);
	}
}

widget {
	size = (40, 40);
	spacing = (12, 4);
	border = off;
}

led {
	size = (27, 27);
}

knob {
	type = spline;
	size = (39, 39);
	name = 7spline;
	blank = 0.1;
	//color = hls(1/12, 1/2, 1);
	color = var(background.color);
}

switch {
	type = simple;
	size = (32, 16);
	name = slide_switch;
	//color = gray(1, 1/6);
	//color = hls(1/12, 1/2, 1);
	color = var(background.color);
}

I will eventually get most of this stuff working in Xhip and merge the engines into one before developing the full skinning capabilities. So far this is an example of Xhip being resized and drawing the text directly rather than relying on a scaled bitmap overlay.


https://i.imgur.com/rrZDAeZ.png (1x)
https://i.imgur.com/KzBJ8xM.png (2x)

[peterpiper]

WOW. Just wanna say Thank You! for your work. It's very nice that you implement skinning in the plugins. I can't help being someone who got a problem if a plugin doesn't LOOK interesting. That doesn't mean I wouldn't use them if they sound good but if I got a plugin that can handle the job and look better I will use this one instead of the "ugly" one.
So now it's time to skin the xhip bundle and use your plugins more often!
thanks again.