KVR Audio

DuX · Post by **DuX** » Mon May 14, 2018 7:17 pm

I am really thankful for it being multi-timbral.

I wish there were more multi-timbral synths like Xhip. I actually find opening the same synth on different tracks confusing, and you have to load another instance just to have a "whoosh", or a "blip" sound once in the whole project. It's wasting memory and CPU resources, and adding a lot to the project load time. Also, when you have a multi-timbral synth you can have its GUI open on another screen and add sounds quickly. It's much quicker to work with than with a mono-timbral synth since you don't have to find it and open it, to add a new sound. Simple.

That's why I love Kontakt and M1 so much. It's easy to make songs without too much finding/opening/closing and generally mousing around. I find the less mouse I have to use, the better.

I really wish Diva and Repro were multi-timbral...

Cheers!

Mutant · Post by **Mutant** » Mon May 14, 2018 10:37 pm

Thank you for the new version of my favorite softsynth.

aciddose · Post by **aciddose** » Wed Jul 04, 2018 1:19 pm

I was annoyed in trying to draw the background for the control section because I couldn't easily draw the unison background "surround". So I went ahead and implemented the background buffering scheme, partially, as I had planned to do.

The rendered "surround" background:

Result:

I'll focus on trying to implement this with all the backgrounds... unfortunately this means nearly doubling the bitmap data used for the GUI. As it is now a single bitmap is used for the full size of the GUI. This means for 2x size at 1524 x 1032 we have about 6mb of bitmap data per instance of the GUI.

The buffered backgrounds will add to that, but it will never be much more than twice as much. Given that 12mb is a tiny amount of memory (audio buffers for effects (like delays) alone use far more, sampled waveforms massively more memory than that!) it isn't much to be concerned about. The memory is being leveraged to speed things up by only actually drawing the backgrounds once.

I'll post again most likely with a new version to test when I have that finished.

Halonmusic · Post by **Halonmusic** » Wed Jul 04, 2018 1:25 pm

hivkorn · Post by **hivkorn** » Wed Jul 04, 2018 1:58 pm

do we have a gui for osx ?

aciddose · Post by **aciddose** » Wed Jul 04, 2018 2:15 pm

I haven't touched the MacOS version as I have far more important things to be working on. Same story as for the past 15 years. See the alpha page for information.

MacOS GUI = planned for v9, not planned for v8.1!
v9 = probably 2020.

hivkorn · Post by **hivkorn** » Wed Jul 04, 2018 2:19 pm

aciddose wrote:I haven't touched the MacOS version as I have far more important things to be working on. Same story as for the past 15 years. See the alpha page for information.

MacOS GUI = planned for v9, not planned for v8.1!
v9 = probably 2020.

..okay...thx for reply

aciddose · Post by **aciddose** » Wed Jul 04, 2018 2:49 pm

Things tend to happen in leaps and bounds, then silence for months or years at a time.

Currently I have no real reason to worry about porting the GUI to MacOS because I'm currently changing quite a few major things about the GUI.

My plans are to implement v8.1 ASAP, so major changes are mostly ignored completely. I had hoped to have 8.1 finished months ago, I was aiming for March, April, then May... Now we're into July.

The biggest issue is to allow basic configuration of the GUI... this requires quite a bit of work to get ready. Ideally it should be possible to configure which knobs, switches, fonts, colors and other options are used. For example the red/yellow/cyan/blue modulation colors should be configured from the skin file. This will be possible by applying groups such as "mod destination" and "envelope a", "modulator b" and so on.

For example:

Code: Select all

modulation destination {
	envelope a { color = red; } envelope b { color = yellow; }
	modulator a { color = cyan; } modulator b { color = blue; }
}
envelope a { color = red; }
envelope b { color = yellow; }
modulator a { color = cyan; }
modulator b { color = blue; }

This will allow users who don't like the knob styles or colors to change them to what they prefer.

That work needs to be completed before I worry about porting to another platform, because when making these kinds of major changes they often need to be made once for every platform!

There is a massive amount of code reused across all three platforms but one key element of designing to allow code reuse is to design each component fully before focusing on another. By knowing the full design of one component, it allows other components to be designed to eliminate redundancy throughout the system and across all components therein.

A great example of this is the fact I spent over a month working on the dialogs in Linux. I had to completely redesign the way the code worked in Windows (and therefore also MacOS!) in order to allow for it to work on Linux at all. I wasn't willing to maintain several different versions of the code implemented differently for every platform.

In that sense it would be valid to argue that ideally all platforms should be taken into account during the preliminary design phase long before maintenance. That is true, but the essential thing in this case is that I'm aiming to update the current Linux and Windows versions to 8.1 before making further foundational changes to the code.

If I try to create a MacOS version now, most likely it will require further major changes to allow all three platforms to work with the same code. This will mean a massive amount of time and effort will be spent before 8.1 can be released, which is totally unacceptable. Obviously it is already taking a massive amount of time to accomplish what I have planned... so for now I'm going to stay the course and get 8.1 finished!

After that, major changes like a MacOS GUI are more sensible to aim for.

aciddose · Post by **aciddose** » Thu Jul 05, 2018 6:05 pm

I've uploaded r1125 to the alpha page.

This version now buffers the background into a single bitmap. This means far more complex drawing methods can be used if desired. It seems to redraw significantly faster albeit not as fast as I'd like it to be (∞ speed!!!)

I've also modified the follower effect slightly but haven't finished yet... so in the future it'll be fully backward compatible but currently works slightly different. I'm hoping to add many filter modes and some options for the follower. Currently the follower includes an additional 18 dB low-pass filter on the envelope. It also uses per-sample modulation rather than 1/16 mod rate as it did previously.

Now it's just a matter of clearing those last few things off the list and it'll be time for the RC stage... since so few bugs have been discovered to date it seems the RC stage won't be very important

I'm very tempted to keep adding things to the list (like background buffering!) but NO!!! Must resist the urge to add 25 new filter modes...

Mutant · Post by **Mutant** » Thu Jul 05, 2018 8:14 pm

aciddose wrote:add 25 new filter modes...

aciddose · Post by **aciddose** » Thu Jul 05, 2018 8:43 pm

25 is too few.

I've just been able to think of 94, including the 8 modes it already has, so 86 new ones although the current KHN model doesn't include anything fancy, while I could implement a better "analog" model so it would be about 102 modes total, plus bypass if you count that.

It just gets a bit boring when you realize there are really only 7 types of filter there and then all the sub-modes each filter can provide, plus series stacks of them (like KHN 2x.)

Actually that just made me realize I left out the fact the KHN stack currently uses Q=sqrt(1/2) for the second stage rather than geometric mean... so that gives another four modes at least not counting non-linear stuff separately. That's about 106 so far...

Sure... that just doesn't seem very interesting to me

I'd also love to add more multitimbral features like sub-presets. So each preset could have "layers" added. No real reason to limit the layers although obviously you'll run out of voices pretty fast. So probably a limit like 4 or 8 would be good for most purposes. For example most of the good synth snares have four parts: low tone, high tone, noise and click/attack. Cymbals usually have stick, attack, decay, rivet/rattle and wash parts for five.

Ugh... all that stuff makes it use more CPU time though while in an ideal universe I'd prefer it used a lot less. Less CPU time and infinite amounts of time for me to do all that programming work. Maybe one day when I'm a brain the size of several galaxies.

https://soundcloud.com/xhip/garfunclelux

Halonmusic · Post by **Halonmusic** » Thu Jul 05, 2018 9:44 pm

86 new filter modes? Yes please !

What about a butt load of famous filter emulations?

aciddose · Post by **aciddose** » Fri Jul 06, 2018 6:18 am

Hate to break it to you, but "famous filter emulations" are a butt load of bullshit

https://soundcloud.com/xhip/isitressenough
(This is a "semi-analog" version of KHN 12 dB. Without non-linearity.)

As far as additional modes this is entirely possible but it doesn't make much sense to provide so many modes with the way the preset data and menus are currently handled.

I will try adding some new modes though soon, at least just in the alpha version. I'd hate making presets incompatible though... so one possibility is to store additional preset data that would be ignored by older versions while still storing the existing filter mode data in a compatible way.

For example Sallen-Key 12 dB low-pass = KHN 12 dB low-pass in the old mode. So if you load the preset using an old version it still works with the old filter.

The current filter modes are "1 times CPU", any new modes are between "0.8" and "10" times!, most ~2 to ~5 times as expensive. I can currently get about 32 voices in Xhip "maxed out", with about 80 voices with simple waveforms and minimal modulation; per-core.

Also you might be very disappointed when you try different modes: as far as "sound" in a majority of cases it makes almost zero difference. So it would only encourage people to burn up 10x as much CPU power and complain a lot!

aciddose · Post by **aciddose** » Fri Jul 06, 2018 1:09 pm

Here is an example of a "digital" filter I did way back in ~1999. It's super simple but to my knowledge has never been used anywhere.

https://soundcloud.com/xhip/megaliasing

That one sounds pretty cool. Major aliasing though! Although since it's already second-order, low amounts of over-sampling should handle it well.

Stefken · Post by **Stefken** » Fri Jul 06, 2018 1:34 pm

Nice synth. Is there a possibility to skin the synth?
Not just colors but provide different buttons, different backgrounds etc...

Xhip Synthesizer v8.1 (alpha & RC)