Xhip Synthesizer v8.1 (alpha & RC)

[nix808]

the odd number picks up the pointer fluffy

[aciddose]

Seven splines is the standard in many cases, those are parameters that could be adjusted in the skin to whatever you like once things are finished to that point. It's currently possible to define variables like "colors.mod[0] = named(red);" and have an individual knob "filter.env_a.color = ::colors.mod[0];"

Just no sense fussing with that until it's entirely done as it's a waste of time and would add useless work needing to be changed dozens of times. I have wanted to add a configuration file and that could contain a temporary setting which would later be overridden by the skin file.

[Mutant]

[e-crooner]

Seven splines is the standard in many cases, those are parameters that could be adjusted in the skin to whatever you like once things are finished to that point. It's currently possible to define variables like "colors.mod[0] = named(red);" and have an individual knob "filter.env_a.color = ::colors.mod[0];"

Just no sense fussing with that until it's entirely done as it's a waste of time and would add useless work needing to be changed dozens of times. I have wanted to add a configuration file and that could contain a temporary setting which would later be overridden by the skin file.

Never mind. I was just wondering...

[aciddose]

Never mind. I was just wondering...

https://en.wikipedia.org/wiki/Spline_(mechanical)

I think seven is a physical/practical thing. You need an odd number to feel even (ha ha #1). Three is too few, five is "some" and seven is the first number where you have plenty of splines without being too many. Nine and eleven become too many and can make the knob more difficult rather than easier to turn. For improved friction you want 30+ rather than splines the tips of your fingers fit comfortably into.

(#1: with an even number you need to arbitrarily choose a corner for the pointer. an odd number has a point that is exactly the center.)




This version should work with effects in presets, banks and states (projects), the effects copy/exchange menu should work and the bypass switches basically work but only with mousewheel/right click rather than left so as not to interfere with the tabs they're on.

Posted xhip_r1234_windows_64bit.7z to the alpha page.

To show whether effects are present I switch the color to yellow without and green with active effects. It's hard to make out the color while the effects are bypassed but I decided not to fuss with it.

[e-crooner]

Yes, I suppose there is a reason why most hardware knobs don't have such such gross splines to begin with. And when they do, the marker line usually runs down all the way to the base of the knob, but in software you don't see let alone feel that lateral line, you only see the mark on the cap's face.

[aciddose]

Well, you can certainly see the line when rendered with perspective. I switched to these quick-to-render drawn-by-plugin knobs from bitmap strips to make the overall size of the plug-in much smaller. The original knob strips (from pre-v8) do show the pointer, it just doesn't have excessive perspective/tilt so it doesn't show quite as much as it could.

These ones are all variations from 2005 - 2011;








It's the same underlying engine and any bitmaps could be put into the skin file. It also supports plug-in renderers to render bitmap strips (the simple 2d knob is one) which take parameters and can be adjusted. The pointer layer is potentially a discrete layer or a real-time render. In the case of the knobstrips I've used pointers rendered into the strips but the 2d "simple spline" knob actually only renders the frames for one spline of rotation (1/7th) and the pointer line is drawn on top in real-time.

So although the "simple spline" 2d knobs are rendered on the client system which means they don't need to increase the size of the skin data included with the plug-in; they're also designed to be again 1/7th the size a full knobstrip would be.

All very very old recycled code plugged together to serve the purpose of eliminating wasted effort on my part.

[Kott]

I think that selected tab is visual reversed, maybe it's better to make it convexed while other tabs will be flat?

[aciddose]

Yes I've considered making such a change it's something that will require aesthetic fine-tuning. It would also make sense for the tabs to open into a differently colored background. How the menu might fit is another question (the same menu applies to both tabs.) I haven't worked out exactly how I want it to look yet.






(I could talk a lot about the issues of making it work well and look good, but, instead please trust me that it would require a massive amount of additional work on the GUI and graphics engines. For example here you can see the requirement to draw the sides of a rectangle+corners individually; changing the background color impacts text contrast on labels; highlighted regions conflict with overall intensity; additional borders/windows reduce the space available for functional elements. the inverted style simply works better across all variations and provides uniform style and acceptable contrast.)

There is very little remaining on the todo list for v8.1 and some of it is very fussy stuff. I haven't taken much interest in these tasks which is one of the disadvantages of feature-creep: development can slow and eventually halt if it's allowed to expand too far.

For now I simply need to maintain a laser-focus and cut out the elements from the list one at a time. I have 100s of other things I could add of course but it has been many years since the last Xhip release.

[aciddose]

I've added the config.db.txt file import/export. This is the same database format as used in the effects which will eventually be used in the skinning system.



Here it is used to specify:

Code: Select all

color.default = grey(1,1/10);
color.mod[0] = var(color.default);
color.mod[1] = var(color.default);
color.mod[2] = var(color.default);
color.mod[3] = var(color.default);

For now those values are hard-coded in as a test. I'd like to enable, or more accurately disable the hover feature by specifying that a key like ctrl must be held for the hover to display the parameter value. It'll also have an option like "none" and "off" to always enable or disable it. The database was actually included in r1234 it just has a limited implementation and should be in ~/appdata/roaming/xhip/config.db.txt

I've tweaked the window/group panes and improved the tab switches along with other minor tweaks. You can change the default knob color but not its style or other parameters along with anything for other widget types. It's a big job to implement the full skinning system at this point but I may draw in little bits at a time like the widget factory objects after I ensure full compatibility.

Uploaded r1235 to the alpha page.

[aciddose]

Cherry, orange, creamsoda and raspberry!

https://youtu.be/EHjgnlZWlck

[gentleclockdivider]

Always liked xhip but never liked the filter overdrive , at high resonance settings and healthy amount of drive the filter becomes really unstable and wobbly
Did you even plan to improve on this ?

[aciddose]

Here's an example preset:
http://xhip.net/alpha/releases/rusty_ox ... xhippreset
http://xhip.net/alpha/releases/rusty_ox ... xhippreset

The self-oscillating (nearly, at ~99.%) Q version doesn't wobble around because that "pitch wobbling" effect is created by variation in the range of oscillation. This also occurs in analog filters due to non-linearity, the "frequency" at one point for the waveform isn't the same as another. The lower amplitude oscillations then have lower pitch and higher amplitude higher pitch. If the waveform is "forced" by driving into higher amplitude there is reduced variation in pitch for the oscillation which is always going to happen at that higher amplitude point instead. The same effect creates the pitch decay of the TR-808 kick drum for example.

https://soundcloud.com/xhip/rusty-oxide-brass
(This is actually a bad example since with the follower envelope the pitch shifts based on input amplitude/phase, but oh well.)

The way the saturation is set up has changed quite a bit over the years. The original method is still in there but I'm not exactly sure on the precise relationship it had early on between quadratic absolute saturation, asymmetric delta scaling, integrator delta scaling/limits and the hard limiting on oscillation.

At the moment the scaling coefficients are fixed and the quadratic and asymmetric terms are independent internally and linked here:

Code: Select all

void compute_saturation_coefficients(const ad::i32 &saturation)
{
	sat[0] = m32(saturation, 0x7FFFFFFF - (tf_min(0x3FFFFFFF, coeff) << 1));
	sat[1] = sat[0] >> 9;
	sat[2] = sat[0] >> 10;
	sat[3] = sat[0] >> 1;
}

If you use the Follower effect you can access these linked parameters a little more independently and test some of the other filters I've implemented for other applications. The Follower has a parameter drive which gives you +18 dB input drive as well as the discrete saturation and asymmetry parameters along with filter type. Unfortunately the Follower does not yet have parameters for fmod and qmod by the input signal.

What you should experiment with while understanding the limitations of this style of cheap filter (#1) are the mixer input levels up to +12 dB in combination with much lower saturation levels. Real analog filters will have the saturation parameter set near around 7.5% maximum and no higher. This will best approximate the way it would behave if it were a similar analog filter.

It's a naive Kerwin-Huelsman-Newcomb filter (often called "state-variable") and due to the nature of how it works it would introduce a lot of aliasing issues and add processing cost to modify it much. I have wanted to add additional filter types, but I think those are not needed as a solution to the issue you mention.

(note #1: You'll never be able to get "analog" timbres from this filter because it is simply not designed to work that way. In its current state Xhip is not at all capable of even approximating what a specialty synthesizer like the minimoog or korg ms-10, polysix or roland juno synthesizers can do. To do that it would require numerous changes including new oscillators, noise sources, filters, amplifiers and some "analog" signal handling techniques. Xhip is not a virtual analog.)

In the future (how many years?) it may be interesting to try to treat the synthesizer in a more modular sense and plug in various oscillator, noise generator, mixer, filter and other signal processing modules. For now if you want that sort of thing you'd best look at other software that already does that so you can understand the different set of limitations such a technique also has. Xhip can be used to produce output no other synthesizer can reliably produce because of the unique way it does things. Vice versa is of course also true.

Some fiddling about with asymmetry + saturation + drive:
https://soundcloud.com/xhip/fooling-about-woowoowooooo
All on the naive KHN filters 1x and 2x. The other filters will behave a little differently.

[Mutant]

at high resonance settings and healthy amount of drive the filter becomes really unstable and wobbly

Isn't that a good thing ?

[aciddose]

at high resonance settings and healthy amount of drive the filter becomes really unstable and wobbly

Isn't that a good thing ?

It's definitely bad if the desire is to get the harmonic content without pitch variation... but that isn't possible of course. Generally in an analog filter we only get such harmonic content by adjusting feedback far above 100%, such as 120%. The harmonics are created by the clamp/saturation of the feedback and this inherently forces the amplitude up, frequency rises slightly but remains mostly stable since it doesn't decay again.

The natural saturation of the analog filters is much lower, but the feedback gain is much higher. So this is like playing a low amplitude signal into a distortion effect vs. a high level signal, of course the harmonics are brighter for higher amplitude input.

In Xhip the feedback in the naive KHN filter is limited to 100% or less to avoid producing aliased harmonics. It also uses a 2nd order "quadratic" non-linearity and 1st order asymmetry to minimize aliases. This means the amplitude of oscillation can be forced to a lower point which generates a lower frequency and we get these variations between low/high amplitude and frequency.

One solution is to allow for aliasing by oversampling and allowing the feedback gain above 100% (used in Sallen-Key and 4-pole modes.)

Another option is to force the input amplitude upward (must be used in naive KHN modes by using higher input levels at mixer.)