Xhip Synthesizer v8.1 (alpha & RC)

[BlackWinny]

Thanks a lot for these quite deep explanations ! I now understand why that kind of feature must be thought from the very start of the design. And in the DAWs as well as in the plugins.

[aciddose]

Even Reaper doesn't seem to support re-mapping automation lanes. I should ask about this on the forum and post a feature request.

Getting additional VST "opcodes" added is a bit more trouble but a deprecated code could be reused along with a plug-in "can do" message to enable it. Something like can_do("get/set string data"), and using the "pin connected" opcode 4 for set_string(id, data) and opcode 5 for get_string(...).

Such a feature is a very core element and could be used to replace all the other get/set string opcodes if applied to the plug-in interface too.

I use such a system internally in Xhip, so for example the GUI can call set_string("synth.effects.global.dirty", "true"). The overhead is small enough that for infrequently used functions it works very well... after all, modern web browsers use similar string databases via CSS to handle 100% of webpage configuration as well as all data in JS code.

[BlackWinny]

It goes way beyond my knowledge in programming but I think I have understood the sense of what you wrote... thanks to the parallel you made with webpage programming regarding the final user browsers by the use of JS and/or CSS to match their specifities.

[aciddose]

It's mostly "thinking out loud" anyway I think I'll ultimately need to apply work-arounds to v9 to allow me to escape from the "VST parameter prison". Without going into too much detail, I can say no need to worry, I know exactly how to solve it for v9... I just wish I didn't have to

I've updated the alpha "todo" page which now makes what I need to do for v8.1 a lot clearer. I should focus on getting 8.1 done before I worry about 9! Always good to be mindful, but rarely useful to go overboard and lose focus.

http://xhip.net/alpha/ (click to expand the to do section.)

[BlackWinny]

All in good time.

[aciddose]

edit: try to trim down rantiness

I've uploaded a new alpha r1191 + a bunch of individual preset files.

http://xhip.net/alpha/

Note the "to do" list and that some of the effects (follower, compressor, ?) are still in a work-in-progress incompatible state in this alpha version. It looks like this version saves the preset effects correctly in all cases when saving projects, presets, banks, states, switching presets, adjusting voices and so on. I've also improved my filter kernel generator and oscillator aliasing + noise floor should be much better in this version, down to -120 dB.

There are some presets I've uploaded to the alpha page. I've been wanting to update and expand the "factory" banks. The support for reduced modulation rates means you can in many cases use 1/16th rate (in the control section) and see no timbre difference and ~4x faster rendering and performance. This means you can get ~320 oscillators on a single core of my older CPU or ~170 full dual-osc + filter voices. I've considered defaulting this parameter to 1/16th (saved in init state). For basic sounds like pads it doesn't make any difference at all, so you get most of your sounds for ~1/4 the cost!

I'm not sure if I'm forgetting anything, but there are tons of under-the-hood tweaks that just make everything work better or more efficiently but shouldn't have too much influence from the user perspective.

[Mutant]

and ~4x faster rendering and performance

[aciddose]

Oh yeah! The "steal voices" switch lets you disable active voice stealing completely. So you can use 6 voices to get a "roland juno" sound, the junos like many old poly synths didn't steal voices and if you played more than 6 notes, any others would be ignored until you released some. This doesn't completely disable inactive voice stealing, so it doesn't solve the issue of routing with velocity changes on stolen voices... solving that is a bit more complicated.

[BlackWinny]

Great update ! Thanks a lot !

[aciddose]

https://soundcloud.com/xhip/quinker-qfx-qixen-quop

Made with r1191_presets/with_fx/qlinker_qfx.xhippreset


If control codes are used note that v8 won't work "correctly", as the colored text will display but the width for text won't be computed correctly, so won't line up. It also doesn't strip the control codes from strings it passes to the host, so a host like reaper will display a bunch of garbage content in the preset name. It does "work"... but it isn't really backward compatible. There is no way to fix a few of the issues with v8, so all newer presets will require v8.1 for everything to work right.

I've tweaked the xhip_factory_bank_v8p1.xhipbank presets slightly and I'll eventually finish up and add effects to most of them. Before I do that I've wanted to add a preset effects bypass switch. That's next on the to do list.

[aciddose]

and ~4x faster rendering and performance

That generally won't be the case since that relies on situations where a lot of modulation processing is happening vs. audio processing. In some situations like with a single envelope + square wave, no modulators, no modulation via routing and only env to amplitude with nothing else, modulation/audio is about 50+50. So in such a case you might normally get N voices and if you use moddiv, it'll apply to the modulation side of the total. So with 1/16 you get 50/16+50 = 53.125, which is almost but not quite 2x (1.94x).

If you turn on absolutely all modulation you can get the expense of modulation quite a lot higher. If I do that I get 70vcs/240vcs with 1/1 and 1/16th ratios. That's ~3.43x higher performance with a 1/16th modulation rate. That's of course without any activity on the route page, which means no parameter filters are active making a significant difference.

I haven't bothered to test the absolute highest I can get by maxing out route/automation/modulation, but my guess is it's probably around 4x in situations where you're using heavy modulation. In most ordinary sounds you'll end up somewhere between slightly less than 2x and 4x, and if you really max out the modulation you might get more than 4x.

[Kott]

I see new Windows build 1191. Do You plan to compile new Linux version?

[aciddose]

It might take a little work, no.

You should ask "I'd be interested in a 64-bit Linux compile, would that be possible if not too difficult?"

Sure! I'll try and let you know.

[aciddose]

Looks like GCC is going overboard on strict limitations for c++14 and c++17 rules (or doesn't yet implement them correctly), so there is a lot of work I need to do to make the current code compile correctly under GCC.

Really weird error here:

Code: Select all

./library/ad/smart_array:148:10: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
      p = new T[length];

Seems GCC is stupidly trying to resolve a run-time variable's value during compile time? I have no idea how to fix such stupidity.

18446744073709551616 = 2^64, so it appears it doesn't like the fact I'm passing a size via size_t type in new T[int(size_t arg)]. This is some kind of really dumb compiler bug. (Nope, not due to size_t, deleting that overload does nothing.)

It's a known bug in GCC's optimizer that's currently marked "wontfix".
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783

The workaround is something like:

Code: Select all

... = new T[length & PTRDIFF_MAX];

I seem to have discovered a new case where it appears that doesn't involve overloading operator new[].

[Kott]

Oh, sorry, I don't try to push You
Maybe gcc9 has this bug fixed?