Xhip Synthesizer v8.1 (alpha & RC)

[aciddose]

I've created an agogo preset pair that doesn't implicitly beg for forgiveness. Lower pitched African-style sounds are far more difficult and I haven't attempted. Smaller western styled bells are quite easy though as they have fewer harmonics so are easy to more closely mimic.

https://soundcloud.com/xhip/samba-sm

[audiojunkie]

Cool! Sounds great!!

[aciddose]

I'm reusing this accidentally posted post. That means it won't trigger the usual notifications (?) but, oh well. I've been working on a handful of different issues.

The existing sound bank(s) need some update work and I need to assemble more sounds and banks.

Sadly although I did work on this a bit, yesterday I accidentally overwrote my work so far without thinking. That's not too bad since I didn't do much anyway that can't be quickly repeated and it was all of perhaps 1% of the total work needed.

The new voice-internal routing features (often known as misnomer "mod matrix") open up the possibility to use many new destinations.

For example, detune on the 1st oscillator and PWM on the 2nd. If there were more destinations (for example: mixer levels) it would be possible to envelope the noise mix level for "breath" timbres in a flute sound.

A complication of adding more routing is that if these are processed when they're not used there is some associated overhead cost. Even a simple "if (feature is enabled) { ... }" still includes the overhead of the check itself, albeit small. Inefficiency already existed in Xhip with regard to running modulation sources that weren't routed to any destination.

A solution for this problem is to entirely modularize the modulation/rendering code of the synthesizer. By building a "just-in-time compiler" to compile a "program" list of modules and the order they need to be run in, anything unneeded can be either removed or replaced with a low cost simplification. Breaking the existing synth down into discrete modules wasn't difficult as it was mostly built that way to begin with.

https://en.wikipedia.org/wiki/Just-in-time_compilation

To minimize the cost of this "compiler", the code has been broken into very small modular functions that take flexible pointer (memory address) arguments. This structure allows the same code to be used multiple times rather than being repeated. The small overhead of the JIT compiler is the indirect function-call overhead combined with the compilation step: assembly of a list of function and argument addresses.

To further minimize overhead, common "combinations" of modules are built. For example rather than having one function dedicated to each channel of the mixer (4x), a single mixer is built in all possible 2^4 (16) combinations. This increases total code size quite a lot and still does not entirely eliminate overhead.

The total benefit of this process (optimizing away unused code) is actually almost entirely cancelled out by the addition of overhead! So whilst this is by no means going to produce higher overall efficiency (and may in fact slightly reduce efficiency by average) it successfully unlocks modularity. The total cost of a voice is now no longer linked to how many potential sources/destinations exist, but only the number that are actually being used.

This allows for many more mod destinations to be added without adding any cost until they're actually used in a new sound. In addition, it provides the ability to entirely replace components like envelopes, modulators, glide, oscillators, filters, shapers or others and could be entirely modular in the future if desired. This may be a great advantage when new filter modes are added.

I've really wanted to allow manually entering the oscillator detune frequencies/levels for a while. I'd also like to generalize the oscillator unison to apply to all waveforms. This will allow tr-808 cymbals built from 6 pulse waves from a single oscillator. Gaussian/uniform noise and pink/red/brown filters would also be nice.

This is need-to-do, although I've already implemented all of this in prototype code so it just needs to be implemented/duplicated in Xhip now. The major effort here applies to making the existing stuff work with the new features. I may need to finally implement "back panel" or "pages" for oscillators somehow.

New effects still need to be completed. Many of these relate in some way to my "new filter(s)" code and so improvements/solutions there provide for the associated effects.

I've managed to perfect (?) my Sallen-Key filter implementation. This is related to other places such as Butterworth filters (and therefore the Linkwitz-Riley crossover effect.) Unfortunately I don't have a great demo of that because the old imperfect version was a very close approximation that rarely failed, so the new version is not so easy to tell apart in the general case. If you get into finely tweaking the follower effect with the new filter modes you'll definitely get to notice the overall much better experience, more so by not being bothered by the "buggy" behavior of the older approximations.

https://soundcloud.com/xhip/meteoriod

So that's a list of what I've completed so far and I'm glad to say the list of what I haven't completed is getting shorter!

[aciddose]

Danger!! this version may not work at all or may work just fine. Don'tsa Idn't warn ye. Get r1334 at the alpha page.

This version includes the incomplete filter types from the follower effect and voice level routing functionality (sources/destinations) that must be considered partially finished. Despite my attempts at coming up with some solution to handle the issue, it seems painful to have to deal with adding or swapping routing destinations in the future. For that reason, please let me know anything that should obviously already be in there that I for some reason, unbeknownst I'd assume perhaps maybe so, did not bother to add possibly or hid in a very clever way very clever indeed very tiny secrets (not big ones).

I have managed to make it crash but not while trying to make it crash, so there may be a crash issue hidden in there but it's very sneaky. I wanted to make a demo of the filters but I got bored and made this copy-paste instead.

https://soundcloud.com/xhip/cpu-plower

New Xhip filters that are in fact rather old (~11 years now.)

Here's a version to play back at half the rate for the achronolly-challenged and hard of hearing:
https://soundcloud.com/xhip/cpu-pslower

Beware whatever rambling lack of sense that follows.

Utilizing the technology of the ancients (those once known as ones once whence before previously) it is possible to download the slower clip and untrack the downslow to upspeed, thereby probably (maybe) reversing the process back to the original.

Here's a very quick example of the different low-pass filter modes: naive KHN, new KHN, SK, C4, C4s, C4si. Note that the Sallen-Key mode allows far higher feedback levels so sounds "distorted", but that's just the diode clamp on the feedback while the direct signal path is almost entirely linear.

https://soundcloud.com/xhip/lp-modes
http://xhip.net/alpha/releases/presets/ ... xhippreset

See following quote section for rambling that you're only interested in if you have science hair and drank too much ubercaffeine:

In the Korg MS-20 "KORG35" filter, the main source of non-linearity is the diode clamp applied directly in the signal path. That isn't how this filter works. This SK filter is laid out more like my version of the circuit, with a proper diode clamp feedback path outside the forward signal path. In such a variant of the filter (still using npn transconductance + njfet sziklai buffer amp into an opamp, as in the KORG35) the buffer stage can add quite a bit of non-linearity, although if well trimmed it doesn't have to. The opamp is very nearly entirely linear due to feedback holding the differential inputs at the same voltage.

The main source of real unintentional non-linearity is actually the VCA circuit that comes after the filter. This adds asymmetric non-linearity because the input signal itself is influencing the transconductance. So typically IIRC the limit is around -10 mV input before you start to get very high (-40 dB and rising) harmonic partials generated, which is why these "cheap" circuits have such high noise levels and sensitivity to interference.

In this software implementation, the only non-linearity is the diode clamp applied to the feedback path. This can generate harmonics of the input signal because obviously the filtered input is "fed back" and clamped but a majority of the harmonics are of the filter's oscillation itself.

More of an attempt at varying things a bit to give a better demo of the SK filter:
https://soundcloud.com/xhip/spz-t
http://xhip.net/alpha/releases/presets/spzt.xhippreset

[Mutant]

I like danger.
Downloaded and will try later.
Thanks.

[aciddose]

Here's a bit more completely random noodling (not so random if you're chaotic enough):
https://soundcloud.com/xhip/erratic-radikeradik

squelch.xhippreset
zquelch.xhippreset

(I've left the SK filter asymmetry offset parameter mapped to Qmod, that'll change in future and I hope to get sat/asym + fmod/qmod working in a balanced way across all filter types.)

I definitely want to get the oscillator unison + manual tuning/gain parameters set up on the GUI in some way. It'll be pretty cool being able to produce a triad of pulse waves from a single oscillator, or other sorts of stacks like sub-pulse syncs and such. That should multiply the range of sounds you can get out of two oscillators (since "virtually" they'd be 16x2 with same/similar waveforms.)

Another thing I really miss is some ability to configure the AR "gate" envelope as AR/AD and adjust the times. This would act as a sort of 3rd envelope much like the one in the ms-20 which can be useful for pitching or giving initial cutoff/mixer level modulations. Probably possible to get that working as-is by fudging attack/release/mode widgets on the GUI and renaming "Gate" to ?

[aciddose]

Looks like I was squaring the mixer amplitudes. I noticed the issue but couldn't figure out what was causing it. Uploaded fixed r1334b to the alpha page.

[aciddose]

https://soundcloud.com/xhip/cpu-plower-48b

I've been working toward balancing the filter levels and fixing some small bugs. It's actually an irksome task, as you need to pick some level to settle on and then just accept that things differ wildly outside that target. For example, at the moment I've decided to normalize the filter drive at a "0 dB" input level, so given a normal wave set in the mixer at 0 dB (such as a square) all the filter modes should sound approximately the same with Q set to the threshold of self-oscillation and extra saturation values set at zero.

That's the case and that's all well and good ... but now the level you get when you drive the oscillation to maximum is quite different depending upon the filter. Up to around +12 dB (4x), although that's not too hard to deal with by reducing the waveshaper drive and/or the amplitude for the whole preset.

In addition, the range of mixer levels (to +12 dB) need to be able to drive the filter(s) hard enough to nearly silence self-oscillation. At least that would be ideal, although it isn't possible for the KHN filters as the oscillation just becomes lower ratio vs the input signal. In the follower effect I've allowed +18 dB to deal with this variation a bit.

And on top of all that, the original response of the alpha follower effect then requires you to drive the signal in at a different level and adjust the "reference" parameter to scale the envelope in the opposite direction.

Fun times.

Softer filter Q with velocity routing:
https://soundcloud.com/xhip/cpu-plower-e

Ariginal AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~~!!
https://soundcloud.com/xhip/ahhhhhhhhhh

New improved A+ Alternate edition:
https://soundcloud.com/xhip/ahhhhhhhhhh-v2

[aciddose]

https://soundcloud.com/xhip/trexercise
http://xhip.net/alpha/releases/presets/ ... xhippreset

Uploaded r1334c with minor tweaks + filter changes since that doesn't really count yet as 1335. I plan to try to get back panels working and add some more features (possibly store control section parameters in presets with little lock icons to switch global/preset mode + oscillator unison applied to all waveforms + discrete adjustment of filter parameters like sat/asym/hp and so forth.)

I've added a useful clickable "voices" text in the display area. You can now switch it to display core % time utilization or absolute process time measurement in microseconds. The absolute maximum time for rendering in process is blocksize/samplerate, so the percentage is based upon the ratio of that to the absolute time spent. This is always going to over-estimate the available time because it doesn't account for the audio driver or other processing on the same core. It is useful though to quickly guess at the rough amount of processing power being dedicated to different presets or filter modes (wink wink.)

[aciddose]

I've finally more or less got the simple page flipping working in a neat and tidy way:


I'm quite troubled by how exactly I'll manage to fit what I want to fit into those tiny spaces. It'll likely require popup dialogs and/or additional floating windows. This could be a real can of worms, I don't really want to make Xhip have fractal complexity.

[audiojunkie]

I’m not sure I understand where from the picture the page flipping takes place. Are you talking about the tabs in the Control section?

[aciddose]

Are you talking about the tabs in the Control section?

Nope, see the "| <" buttons on the top-right of each group?



So this just takes the group panes, doubles them up, hides the "back" pane and the switch inverts their states. So "front" gets hidden, "back" gets shown, then if you press the "|<-" button from the back, "back" gets hidden and "front" gets shown. That'll give me a little "back-panel" space per section without being as annoying to use as "flipping the whole synth around".



Those spaces (like "Osc A") are still very small though so I'm having trouble so far working out exactly how to manage. I want to put in the controls to allow me to specify what every oscillator unison's tuning is ... and currently it uses an equation by default. So I'm leaning maybe toward allowing the user to specify equations ... but then that takes a ton of text and you're writing a little "pitch program", which is also annoying.

I want to be able to do things like:

Code: Select all

"[i] = 1 + detune * i/n"

, which would give linear detune, but making that work sensibly might be just too damn complicated. I also want to be able to specify like:

Code: Select all

"[0] = 440 hz; [1] = 472 hz; [2] = 511 hz; [4] = 9001 hz;"

or

Code: Select all

"[0]=1;[1]=0.9;[2]=1.1;"

for direct pitch ratios, and

Code: Select all

"[0]=0hz;[1]=-50hz;[2]=50hz;"

for direct linear detunes. Something flexible that can handle pretty much anything you throw at it in spread-sheet format is needed to do drum machine hi-hat pulse wave "metal" sounds and similar.

I'm thinking most likely if I do this in this "pitch program" format, I'll allow input/import/export directly and you can have "pitch program presets" from a little menu there to make it easier to use. I don't have a text-edit set up, and that may be a slight bit of pain in the arse, but worst case maybe I can just fudge one up (I have this exact stuff working in other tools of mine) and people can just use notepad or whatever if they prefer because mine is broken/sucks/etc.

[aciddose]

Not a lot to report in terms of new code changes. I've been taking a long break from working on the code. I have been using the plug-in though, and been thinking quite a bit about the features I'm aiming to finish next. Those include the section "back panels", new parameters (mono/poly legato glide switch, semitones/cents preset tuning, envelope asymptotes, ...) and little "lock" switches and right-click popup menus to allow saving unison or polyphony settings with a preset. By default the mode will be "locked" for each parameter, but then assuming you want to load the data in the preset (represented by the icon lighting up or glowing ?) you can unlock/lock to switch between the global and preset setting. Storing the preset setting or clearing it will require a right-click and popup menu, I think is the best design.

https://soundcloud.com/xhip/cubanj

I've been fussing a bit over how difficult it is to get great flute sounds. I've been able to manage pianos and reeds, but woodwinds and ("realistic") brass, cymbals and so on seem to absolutely require layering features to be accomplished decently. Hopefully I'll get more into the code side of things and get some new features implemented before 2025.

[audiojunkie]

Thanks for the update!

[glokraw]

I've been taking a long break from working on the code. I have been using the plug-in though, and been thinking quite a bit about the features I'm aiming to finish next.

Sometimes rest is more productive than work

I'm not a coder, but have you looked at the parts bin of the Reaktor ensemble Steampipe II ?
Maybe there's something unique in the type and order of the modules that can be translated and applied to your code on your flute sounds project? Or maybe Chet Singer's work on breath controlled wind-instrument sounds might have clues?

https://www.native-instruments.com/en/r ... &t=userlib
Cheers