Xhip Synthesizer v8.1 (alpha & RC)

[audiojunkie]

Nice!!

[aciddose]

Uploaded r1299 which has preset route chunks working (mostly.)



There are a few minor issues and this is not multi-timbral but as with the preset effects the route should switch and work correctly as you switch through presets. Tons more work needs to go into a ton more areas so I'm not sure I want to face that multi-timbral spicy weasel right away. I think time to take a little break and do a lot more testing/bugfixing with what I have done so far.

I uploaded a couple presets into the presets folder on the alpha page that use route chunks. They're static FM sounds that map "key" to scale modulation depth to eliminate aliasing on high notes.

To get the colors in the config ~/.xhip/ or ~/appdata/roaming/xhip/ ... synth/config.db.txt you can either rename it old_config and load the plug-in to export a new copy of the file, or you can just copy-paste the earlier example of colors I gave.

[Mutant]

Thank you very much !

[fmr]

Thanks for all the work put into this synth. I remember the knobs were rounder before. I liked those more. Is there a way to get them back?

[aciddose]

Thanks for all the work put into this synth. I remember the knobs were rounder before. I liked those more. Is there a way to get them back?

If you peek into (~ is your home directory) ~/AppData/Roaming/xhip/synth/ you should find config.db.txt which is a text-based configuration file. To get Xhip to output a fresh up-to-date file, rename or delete the existing one and restart Xhip in a fresh instance.

The current file appears like so:

Code: Select all

version = alpha {
	revision = 1299;
	special = "Preset route (almost)";
}
color {
	default = grey(1,1/10);
	mod[0] = hsl(0/8,1,1/5);
	mod[1] = hsl(1/8,1,1/5);
	mod[2] = hsl(4/8,1,1/5);
	mod[3] = hsl(5/8,1,1/5);
}
knob {
	type = spline {
		segments = 5;
		depth = 4/5;
		gap = 1/3;
	}
	color = var(color.default);
	size = (33,33);
}
switch {
	type = simple;
	color = var(color.default);
}
colors {
	constants {
		l = 2/5;
		s = 7/8;
	}
	Red = hls(0/12,l,s);
	Orange = hls(1/12,l,s);
	Yellow = hls(2/12,l,s);
	Chartreuse = hls(3/12,l,s);
	Green = hls(4/12,l,s);
	Spring = hls(5/12,l,s);
	Cyan = hls(6/12,l,s);
	Sky = hls(7/12,l,s);
	Blue = hls(8/12,l,s);
	Purple = hls(9/12,l,s);
	Violet = hls(10/12,l,s);
	Pink = hls(11/12,l,s);
	Dark = hls(0,1/5,0);
	Gray = hls(0,1/2,0);
	White = hls(0,1/1,0);
	RGBK = blend:hls(0/3,1/2,1)hls(1/3,1/2,1)hls(2/3,1/2,1)hls(0,0,1);
	Pink-cyan = blend:hls(8/9,5/9,1)hls(8/9,7/9,1)hls(5/9,5/9,1)hls(5/9,7/9,1);
	Purple-orange = blend:hls(11/15,2/5,1)hls(11/15,1/2,1)hls(1/15,2/5,1)hls(1/15,1/2,1);
	Slate_dk = hls(7/12,1/5,1/7);
	Slate = hls(7/12,3/7,1/7);
	Slate_lt = hls(7/12,5/7,2/7);
}

The section you're interested in is "knob". If you use these settings (segments(7), depth(3/5), gap(1/2)):

Code: Select all

knob {
	type = spline {
		segments = 7;
		depth = 3/5;
		gap = 1/2;
	}
	color = var(color.default);
	size = (33,33);
}

You should get very close to the older defaults. It's also possible to use the old knob strips or any custom bitmap knob/switch strips you like. The details of how everything works are a bit complicated and I'm still working on the configuration/skinning systems.

I really like this one (segments(3), depth(1/5), gap(1/3)):

[fmr]

Thanks. It worked. I have to say your synth is very good sounding and has an excellent choice of features. I will use in my classes as an example of modern subtractive. The look is raw, but efficient. I believe that with a beautiful skin (you know, the eyes also eat) this will be a winner.

One last question: Is it possible to draw all knobs with the same color (like E.G. the dark grey used in the CONTROL section)?

[audiojunkie]

I agree! Xhip is a fantastic sounding instrument! It may well be my best free (non-open source) synth I have for my Linux setup.

[aciddose]

One last question: Is it possible to draw all knobs with the same color (like E.G. the dark grey used in the CONTROL section)?

Yes, feel free to experiment with the config.db.txt file as the worst you should expect is a crash, and most database format errors should have error messages.

Internally the colors are scanned in to a table which is used to set up the skin and all knobs on it.

The default input:

Code: Select all

color {
	default = grey(1,1/10);
	mod[0] = hsl(0/8,1,1/5);
	mod[1] = hsl(1/8,1,1/5);
	mod[2] = hsl(4/8,1,1/5);
	mod[3] = hsl(5/8,1,1/5);
}

A simple modification for fun:

Code: Select all

color {
	default = named(yellow);
	mod[0] = var(color.default);
	mod[1] = var(color.default);
	mod[2] = var(color.default);
	mod[3] = var(color.default);
}

The color variable input parser supports the following formats:

Code: Select all

grey(alpha, intensity) or gray(...),
	If only a single argument is passed alpha defaults to 100%.

rgb(red, green, blue), hls(hue, luma, saturation), hsl(hue, saturation, luma),
	Converts real-number input according to color space/model. Evaluation of input (1/9, or 0.3 + (1/3)^3) is supported. Variables are not, that's a special feature of the background color list resolver.

named(color name),
	This attempts to find a color from an internal database which is currently not possible to populate externally. It's mostly useful to type simple tests like named(white) or named(blue).
	
var(complete.path.to.database.entry),
	This will look up another database entry from the same database. The color will be resolved completely from the discovered database string and can also be a var(...) entry. (WARNING: this is recursive! don't trigger an infinite loop!)
	
hex(00beef),
	Hexadecimal, no prefix!

re: the "var()" input being recursive with no depth limit. Try to avoid doing naughty things like an evil gremlin aciddose does:

Code: Select all

color {
	infinitude = var(color.default);
	default = var(color.infinitude);

[fmr]

Thanks again

[aciddose]

The error reporting functionality needs a ton of work

Code: Select all

color {
	default = hex(ff0000) * oops(0.5);
	mod[0] = var(color.default);
	mod[1] = var(color.default);
	mod[2] = var(color.default);
	mod[3] = var(color.default);
}

Fortunately (I suppose?) it should just crash in the last versions, and I hope I'll give some sensible error that trims the redundancy to something simple like:

Code: Select all

There were errors detected while configuring the GUI.
Please check and fix the skin or configuration file.

Unrecognized function: oops()
Not a valid color specifier: "hex(ff0000)*oops(0.5)" specifically "oops(0.5)"
Unhandled error: var()
Not a valid color specifier: "var(color.default)"

[aciddose]

I've uploaded a r1306 which should have the route preset functionality mostly working. Again I haven't tested it extensively, and I've made some other changes that could need new fixes. One issue I know of is the font selection at different GUI scales previously relied on "first found" in a couple cases and because the order changed, different fonts might be selected now. I'll need to test things more and continue to improve everything, but I feel the route functionality is finished. This opens up more chances to play with adding new features to the related systems... but there is still a lot of fine-tuning work left to do.

I know the LEDs still don't update immediately upon adding a new valid route and there are a few other minor tweaks left to make. Again, make sure you test it before investing too much effort, but I feel pretty safe now to start creating presets with built in routes+effects populated now.

[pigfront]

All new versions after r1235 crashes Renoise.

[aciddose]

All new versions after r1235 crashes Renoise.

Try r1306b. The uninitialized state of the voice allocator returned "0" if the flags weren't set which lead the GUI to assume the last active voice was #0 rather than non-existent I've changed it to "-1". It seems Renoise does some sort of parameter scan immediately after it started the plug-in and with an open GUI. The GUI tried to animate while a monophonic mode is set without the voices having been allocated (since no processing had yet occurred).

Tested with Renoise 3.4.1, seems to work fine now.

[pigfront]

All new versions after r1235 crashes Renoise.

Try r1306b. The uninitialized state of the voice allocator returned "0" if the flags weren't set which lead the GUI to assume the last active voice was #0 rather than non-existent I've changed it to "-1". It seems Renoise does some sort of parameter scan immediately after it started the plug-in and with an open GUI. The GUI tried to animate while a monophonic mode is set without the voices having been allocated (since no processing had yet occurred).

Tested with Renoise 3.4.1, seems to work fine now.

Thanks, is now working.

[aciddose]

Lots more work done, at r1313 now which is... uh, lucky, I guess?