Xhip Synthesizer v8.1 (alpha & RC)

[aciddose]

More specifically,

Xhip is a multi-timbral instrument. Every voice has its own preset assignment and is fully independent from all other voices. Unison is a quick&dirty application of this to "layer" multiple voices with the same note and unique tuning, amplitude and panning values, but this is actually fully layered. As it is now each of the up to 16 unison voices internally has preset "-1", which forces the preset[0] index to override and make all layered presets identical... but you could pause in the debugger and modify this array to contain whatever preset values you want, and it already works. I have a flag in the code where I enable (uncomment) a "layer" and "keymap" tab/page and I can already fudge the values in the array to test it out. I haven't yet bothered to write the GUI code, because it doesn't actually fit on screen.

https://i.imgur.com/RTgxAGU.mp4 (if KVR phpbb supports a video tag I don't know how to use it.)

In the future the unison will be replaced with preset layers, and presets will be used in "sounds". There will be 128 "sounds", but the bank doesn't need to be limited to 128 presets anymore. The interfacing work for all this layered preset/sound/pcm/keymaps/layers stuff is quite complicated and I haven't touched it in 20 years.

The reason for that is despite Xhip being fairly reasonable, it's also very CPU intense due to the fully independent voices. A lot of synthesizers use a single centralized "preset" that includes everything: effects, unison, polyphony mode and so forth. This means those parameters don't need to be computed 100s of times once for every voice, but only once when a new preset is loaded.

While it's really exciting to set up a "sound" with stereo voice pairs and 8 layers of presets... once everything is factored into that you're running 256 voices and the CPU is hot enough to fry eggs.

[aciddose]

Just wanted to report that loading the Init preset or any other preset for that matter does not change the Unison settings. Same with FX. They are not changed when loading another preset either.

If you're using the global pages, the global route page is for stuff like "brightness" multiplied to filter frequency, or "volume pedal" to volume. The global effects page is for stuff like a reverb, cross-blend or limiter effect that you want to apply globally as you switch through presets. The preset pages are (or should be) saved with presets.

Both of them can be disabled by right-click of the LED on the tab to turn them off, although the route tab LEDs still don't update when you add/remove rows because I haven't finished the code that scans for active rows to auto-light the LEDs yet. (In fact it seems the route bypass doesn't even work yet because it doesn't trigger the routing tables to rebuild either.)

[aciddose]

I've uploaded r1332 with a ton of changes. I'm too lazy to list them all out at the moment, but:

• Bank (hold shift clicking menu) sort by category/preset name
• Fixed issue with bank preset list not having correct size
• Implemented bank database chunk, will also add data (file) chunk
• Implemented knob options to disable blending/sharpening/animation. (knob { blend; sharp; animate; } boolean.)
• Further unified the Xfx and Synth GUIs, the synth now scales a bit differently (needs tweaks)
• Fixed some major memoryleak issues (will test fully before next release)
• Implemented preliminary effect tail lengths + silence auto-bypass for some effects (WIP)
• Added gamma-corrected gradient blend modes (use "gblend:")
• Fixed latent text update when rapidly switching presets
• Added option to disable hover (hover; boolean.)
• I think I unified the different knob options correctly (C++ thing, inheritance hierarchies.)
• Tabs seem to work better now (no more wrong colors on click/hover.)

Blah blah I'm sure I forgot something. I've also placed a reaper project for the "cubanb" track on the alpha page, to ensure it was up-to-date I resaved it as "cubanc". If you're running reaper give it a try. I'll update the effects again little later after I've fully implemented and tested the tail/bypass feature. At the moment it definitely applies the bypass sometimes when it shouldn't, like on the mdelay or reverb effects and others with non-monotonic decays. I also don't believe it applies to in-synth effects yet where it would be the biggest efficiency boost during inactivity for an instance.

Everything seems to work, I was going to make a better demo of the "layer" page as a video but I spent way too long fixing a couple crashes (which I sure hope are fixed now!) and I need a break.

Instead, here's a 3x layer "e-rhodes" sound. Use unison to set number, adjust detune/panwidth, usually you need narrower width or disable panning modulation in the presets. This has the tremolo and reverb "wet too high just like usual" applied to factory bank presets with some tweaks: "Rhodes", "Rhodes b" and "Dingalingdong". I think there might be some master effects (RC low, high, compressor, limiter) on the master track I didn't bother to disable. Single instance otherwise.

https://soundcloud.com/xhip/cubanbc-rhodes3x

Remember the layering feature is very hackish with no really good UI yet. This sort of thing is a lot less useful without UI features and stuff like per-voice routing or keymaps. You should notice if you use a short release on the first "main" voice that will cancel longer release layered presets early. The other voices aren't allocated using oldest-note stealing, they just assume the unison layers match by marking the whole voice group as inactive.

I could go in and allocate unison voices using a more full featured voice stealing, which would probably be the best aim if this feature becomes more serious. At least it'll allow authentic drum synth cymbals and hihats, so it is sort of cool, it just requires the whole set all working together (layers, keymaps, allocation, "sounds") to really work at all.

The layer settings are never saved anywhere although they are maintained by an instance.

[gentleclockdivider]

Not sure if it's a bug or intentonal behaviour
When oscA --->.oscB sync , Osc A is Ramp with a tiny bit of width to turn it into a supersaw
The osc sync effect is automatically disabled

[aciddose]

Not sure if it's a bug or intentonal behaviour

It's definitely unintentional and I'm not sure why it doesn't work actually. It's probably because at some point after v6 when I know it was working (at least I recall it working) something was changed about the way unison is applied for an oscillator that made it not output the sync pulses anymore. It's trivial to get it working and I've already done it in the other prototype oscillator, so I'll look at fixing it. It should just be like so:

Code: Select all

if (unison) loop (1 to count) do_unison_saw(n);
else do_saw();

Essentially I did a quick hack to create the unison feature, so rather than using a generic system where with it disabled it only runs the first waveform it actually has completely independent "solo" and "unison" oscillators. Upgrading it to be generic is required to get unison to work on all waveforms but in my attempts so far I wasn't able to get same-or-better performance with my tests. Instead, I can layer on another hack and just copy the phase from unison#1 to the main phase, and sync should work again.

Unfortunately I've deep-dived into something pretty horrible and introduced some real nasty memory corruption bugs somehow. I'll need to be reasonably certain those are fixed before making more releases. Seems related to resizing the GUI, probably an automatic copy-constructor or something equally awful to track down and fix.

[aciddose]

That was pretty rough like these sorts of heap-corruption bugs usually are. Turned out I simply forgot to clear out the list of GUI elements requiring redraw while resizing the GUI. In most cases that would lead to only minor corruption as the element was removed from the list and a single byte was written to mark it as redrawn, but rarely that tiny bit of corruption or even worse, the complete redraw of an element that no longer existed (and a lot more corruption therefrom) would muck things up big time.

I also notice I typo'd the revision and then just went with the typo. That shouldn't cause any real issues, usually, but any projects saved with the last alpha might not load again up until the version number crosses r1332 again (it was actually r1322!)

I've fixed the heap corruption bug and along with a few other tweaks, the oscillator sync now works correctly with super-saw osc unison enabled.

https://soundcloud.com/xhip/syncunison
https://soundcloud.com/xhip/cubanlayered

r1326 on the alpha page.

[audiojunkie]

Hey Acidose, are you OK? It’s been a while seens you’ve posted.

[Boy Wonder]

Hmm...I tried logging onto Xhip.net but my browser couldn't get in. I checked isitdownrightnow.com and it said xhip.net is down for everyone.

[audiojunkie]

That is not good. Now I’m even more worried.

[Mutant]

Lets hope it is just long vacation. Sending good vibes.

[aciddose]

I've been mucking about with the serber, there are a lot of issues associated with it and it can be sort of a pain in the neck. There are things I've just put off for years on trying to fix and just ignored

I'll post this copy of the win64 r1326 alpha here for now, although this is quite an old version now and I'm not 100% sure if it has issues I've fixed already. Still r1326 in the internal synth version info, but next time I commit my changes I'll be on 1330. I was sort of hoping to hit a semi-complete alpha before 1337 ^_^

xhip_r1326_windows_64bit.7z

I've been working a bit on an auto-kerner for text. It still needs the ability to draw "edge ramps" between the tips of a character like "E" or "k" to determine limits on where to push glyphs together and what's "too far". You can see the ^ (caret) gets kerned right into the % (percent) glyph here, because the two characters have too much vertical difference. I can either manually override the auto-kerner, or add some more features to figure out how to make it work in more cases automatically.

... obviously an auto-kerner that can't kern glyphs on its own isn't very automatic.

More examples of that:
(I'll try track down the issues it has a little later on maybe.)


Green dots = good overlaps



Red dots = questionable overlaps

Might be easier to just upload/attach the font program but I haven't tested it much (and I know it breaks based on configuration!)

It may be hard to see, but the hyphen in snicker-snack! looks clearly off here. If you imagine the hyphen having arrow-like ramps on each end <-> it should fit better.



Some fonts look better/worse than others. I've also implemented a dynamic gamma-ramp adjustment that computes the intensity of the background pixel, then chooses a palette/ramp to mix the foreground + background colors together. This means white-on-black text looks equally good as black-on-white, grey-on-grey or checkerboards and random background images should hopefully also look excellent. More testing planned for those ones!

[Mutant]

Good to know you are alive.

[aciddose]

Good to know you are alive.

We humanoid-mutant forms are hard to kill as I'm sure you know!

I've managed to implement the system I imagined, and the configuration for fonts currently looks like so:

Code: Select all

name = Tahoma

pt = 7
space = 3
ascent = 9
descent = 2
default_leading = 0
default_trailing = 1

width {
	! 1,3,7,5,9,6,1,3,,5,,2,,1,3,4,3,4,,5,4,,,,,1,2,5,6,5,4,7,8,5,6,,5,,6,,3,,5,4,7,6,7,5,7,5,,,6,8,7,6,5,4,2,3,2,5,,2,4,,3,4,,3,4,,1,2,4,1,7,4,,,,3,,2,4,5,8,3,5,3,,1,3,6
}

leading {
	-1 w
}

trailing {
}

shaping {
	flat (0, -)
	ramp (0.5, -)
	step (0, 1), (0.5, -)
	n_px (0, 3)
}

edge {
	flat !@#$%^&*_;':/?\|=`CEI
	ramp ~(){}[]<>,.+T
	step "Pf0123456789-
	n_px eF
}

kernovr {
	A -1 NPRn -2 V
	I -1 A
	F -1 -VXz -2 a
}

kernadj {
	A 2 w
}

This is a hand-written parser so it isn't using the ad:db_t parser as for the Xhip configuration files (yet, although it could in future, if required.)

The "shaping" rules are a series of two floating point values: {delta, length}.
A length of "-" represents infinity where the same angle/slope continues until the edge of the glyph is reached. It's possible to specify up/down and left/right rules on a per-glyph and per-kern basis but I haven't found any case where that's needed yet.

So in these rules I've specified "flat" which is a flat edge. This has the effect of measuring the maximum extent of the glyph edge and using that for the whole glyph. It achieves this by basically drawing up/down vertical lines from each glyph pixel and then the greatest extent is taken for each row.

"Ramp" is a 22.5 (45 = 1) degree descent rather than a flat edge. So each pixel vertical distance gives 1/2 horizontal less than the source pixel. "Step" is the same, only with an initial vertical step outward by a single pixel before the descent begins. So for example in a glyph like "=" at 7 pt, the two horizontal bars are spaced usually 1 or 2 pixels apart. The effect the edge shaping rule has then looks something like this (quickly hand-drawn example):
edit: oops I drew this wrong on the 1st attempt! (It'll be nice to implement a renderer for this in the tool so it can be used to tweak kerning rules and view the results.)

Red pixels = the 1st (0, 1) rule, and blue = 2nd (0.5, -).

So that has the effect of "filling" single pixel gaps so something like a hyphen of single pixel height becomes three pixels tall with arrow-like ramps above/below <-> on both sides from the auto-kerner's point of view.

The "n_px" rule does the same thing only spreads edges by 3 pixels for 1 + 6 = 7 total height. That fills in the gaps in "F" and "e" making them look more like "H" and "o" to the kerner.

The "kernovr" section specifies direct overrides, and "kernadj" specifies adjustments that apply to any override as well as auto-kerned outputs where overrides aren't defined. These rules should allow any pt scale of any font to be kerned perfectly with minimal amounts of work. I'd like to implement the ability for the font tool to render the edges with a zoomed display to fine-tune kerning on problem cases once they're identified.



Now it's just a matter of tweaking the 32 base fonts used in Xhip + Effects to use these new systems to get better kerning results across the board.

Code: Select all

1 DejaVu Sans 5
2 Small Fonts 5, 6
3 Sofachrome Rg 14, 16, 24, 28, 36
4 Tahoma 6b, 7, 8, 9, 10, 11, 12, 13, 14
5 Terminal 6, 13, 14
6 Verdana 5b, 6b, 7b, 8b, 9b, 10b, 11b, 12b, 13b, 14b, 15b, 16b

Hopefully for most scales I can re-use the same rules by copy-paste with minor variations to length and delta values and once done this will be another one crossed off the to-do list!

In the meantime I've fixed a few more issues with the routing and I've been examining some rare oscillator bugs like spurious pulses at very narrow (99.x%) widths.

[audiojunkie]

Very cool!! As always, I am grateful for your support of Linux!! These new additions look really cool!

[aciddose]

Very cool!! As always, I am grateful for your support of Linux!! These new additions look really cool!

Hopefully the next alpha version I throw together won't have any platform issues and I'll do both windows + linux at the same time. I did change a fair bit of code, so it has yet to be seen if I'll need to tweak anything to work right on GCC under linux.

Here's a comparison of before/after auto-kerning rules on Verdana 7 pt bold:

Code: Select all

leading {
	-1 w
}

shaping {
	flat (0, -)
	ramp (0.5, -)
	step (0, 1), (0.5, -)
	n_px (0, 3)
}

edge {
	flat !@#$%^&*_;':/?\|=`CEI
	ramp ~(){}[]<>,.+T
	step "Pf0123456789-
	n_px eF
}

kernadj {
	- -1 -
	A 1 w
}

(Leading -1 w seems a bit sketchy here, might need a bit of fine-tuning individual kerning adjustments instead of that easy kludge solution! For the most part however so far this seems to work great!)

I'll just need to sit down now and copy-paste copy-paste and make tweaks as needed some day, hopefully soon. I've also got this idea stewing on my brain back-burner to automate the rendering of each font, but maybe I'll just skip that for now. (At the moment I have to manually hit a key and select each font in a dialog, which is probably better for immediate review of the output anyway. It does already automatically build the output files and those are quickly stored in an archive using a zip-like command line tool.)