Xhip Synthesizer v8.1 (alpha & RC)

[audiojunkie]

This is fantastic!! Everything is so optimized!

I’m sure it’s been mentioned before somewhere, but I don’t remember. What libraries (if any) are you using for Xhip? I’m particularly interested in the Linux side of things. Or, did you write your own?

[aciddose]

Everything is my own code/frameworks that I've written over the past 20+ years. A few times releasing some under an open-source free license has been mentioned, but mostly that's an issue of a massive amount of additional work. I've always said if someone is interested in a particular element I'd be happy to share both some source and help with getting it to work.

An example is like here:
https://pastebin.com/pSAUPisW

Where I can already see several issues:

• I'm using C library strcpy, strcat functions without std:: namespace.
• Code is dependent on my own string library, smart heap-based array (like stl vector), debugging/assertion/runtime check code, string tokenization processing, linked lists, lists,
• The code is just generally "it's filthy, but it works."

There are a number of reasons I avoid using a library like STL in C++ which are benefit to me, but this makes my code far less useful (or useless) to others.

[aciddose]

This is fantastic!! Everything is so optimized!

I'm not sure about that, but I've uploaded the Linux version to the alpha page: xhip_r1284_linux_64bit.7z

[aciddose]

https://soundcloud.com/xhip/librtron

Just found a horrible bug in the code for ID tags less than the expected length: in the case of the new database chunk the id tag is "db" while the input string was expected to be length 4 without any assertion. So due to that the loop copied the next 4 bytes which were {'d', 'b', 0, random chance!} So projects saved with the last alpha(s) may have saved an invalid chunk ID like {'d', 'b', 0, 47} or similar which won't match and so won't load correctly.

Code: Select all

ad::u32 sub_chunk_id = sub_chunk->id;
// the chunk ID previously was defined as
// {'d', 'b', 0, whateversonthestack}
if (sub_chunk->id[0] == 'd' &&
	sub_chunk->id[1] == 'b' &&
	sub_chunk->id[2] == 0) {
	// force bad "db" chunks to load by
	// masking off the last byte! opps!
	sub_chunk_id = sub_chunk->id & 0xFFFFFF00;
}

Fixed by kludge. Opps.

Another confirmed bug: I've modified the code in previous unreleased versions to defer a lot of stuff. One example I've already given is drawing/loading/displaying bitmap resources on the GUI. Another is allocation of voices. The old structure of the synthesizer was designed with the assumption voices were always allocated first, ahead of time. The multi-threaded management of voices used mutex locks to "wait" for voices to be allocated and then "lock" the voices to perform an action on them mutually exclusive with the audio rendering thread.

To eliminate issues with future multi-threaded and multi-core rendering support, all of the communication into the synthesizer and then into the voices is deferred and buffered in a single direction. The GUI might specify to the synthesizer "switch to using 20 voices", the synthesizer then handles that input and allocates and configures voices and finally the audio thread(s) processing resumes once the associated voices are ready.

Blah blah blah quite the rambling description there; the bug is that while many of these communications have been switched to deferred application, not all of them have. Specifically unison/layering parameters still need to be upgraded and handled in this deferred manner. Loading a state with unison voices can lead to a crash where the state loading code attempts to directly interface with voices rather than delegating to the synthesizer.

That I fixed by finishing the job I started. (I hope.)

Updated xhip_r1288_windows_64bit and xhip_r1288_linux_64bit on the alpha page.

[aciddose]

I need to test more of the wild esoteric unusual strange weird oddball features rather than the plain old ordinary normal common usual expected day-to-day features.

https://soundcloud.com/xhip/meteoriod

[audiojunkie]

Everything is my own code/frameworks that I've written over the past 20+ years. A few times releasing some under an open-source free license has been mentioned, but mostly that's an issue of a massive amount of additional work. I've always said if someone is interested in a particular element I'd be happy to share both some source and help with getting it to work.

An example is like here:
https://pastebin.com/pSAUPisW

Where I can already see several issues:

• I'm using C library strcpy, strcat functions without std:: namespace.
• Code is dependent on my own string library, smart heap-based array (like stl vector), debugging/assertion/runtime check code, string tokenization processing, linked lists, lists,
• The code is just generally "it's filthy, but it works."

There are a number of reasons I avoid using a library like STL in C++ which are benefit to me, but this makes my code far less useful (or useless) to others.

Because of this, your plugin may be the most compatible and stable of all linux software. Absolutely zero chance of descending into dependency hell regardless of the distro it’s used in. Very cool!!

[aciddose]

Because of this, your plugin may be the most compatible and stable of all linux software. Absolutely zero chance of descending into dependency hell regardless of the distro it’s used in. Very cool!!

On that side of things for the most part I've used the generic libs, so it's somewhat true unless there are major changes to GNU-posix interfaces like <pthread> or such. For windowing and graphics I've used pure low-level X11/XLib, which is somewhat outdated. The code is quite heavy but doesn't differ much from the win32/gdi/ddraw interfaces and I hope it should last a bit longer before it needs to be replaced. A few bits are missing such as mouse/keyboard hooks for xlib (those messages are handled automatically by win32 with a 'passive lock' instead.)

There is still a lot I can't do like display utf-8 strings in arbitrary fonts for a file browser dialog... but yes, at least it works and will compile and work almost anywhere without changes.

[audiojunkie]

Very cool! Thank you!

[aciddose]

Somehow although I thought the state file I was loading had a database chunk in it, it seems it didn't. Also my quick & dirty code was broken which is now fixed.

Fixed the broken fix in r1289 on the alpha page,

• Will load the effects enable/disable switches correctly from old broken states/projects.

https://soundcloud.com/xhip/mystic

Next up: implement the route page exactly like the effects and allow routing to be saved in presets in mono-timbral "load from the currently selected preset only" fashion. I think I'll leave multi-timbral functionality for the v9 alpha series but I really want to get the route functionality working correctly for v8.1 release. That'll include any tweaks to filter coefficients to eliminate clicks/pops on volume, panning and so on.

I'd also really like to get the internal signal routing exposed as another sub-tab on the route page. That allows stuff like routing envelope.b to xmod depth = the "mystic" soundcloud clip.

[aciddose]

Getting there, very slowly step by step. I've encapsulated the routing functionality. I haven't decided if I want to run multiple "route lists" in parallel or combine everything into one. I need to think it through in terms of multi-timbral and decide on the best possible design ... although I think a single manager/router will work.



It should be possible to implement the route global/preset pages exactly the same as in the effects and run the preset route first - again, exactly the same as the effects - as if there were twice as many rows globally with the first half being "preset" rows.

In addition I'll be able to add another layer of pages/tabs in the future for "parameters", "synth" and perhaps "signals". It would be nice to get effect plug-in parameters in there too at some point in the future.

Obligatory obscene reverb effect:
https://soundcloud.com/xhip/xiano

[aciddose]

Mix attempt #2 with a bit more work put in:
https://soundcloud.com/xhip/mystic2

With the simple A<>B you really can't get a wide range of FM sounds which require more complex 4-op layers, but the very basic 2-op stuff seems to mostly work. I haven't played with waveform variations yet (although PCM will work!) but the range of sounds Xhip could produce with the internal matrix accessible would obviously be quite significant.

I've found/fixed a few issues with threading where in r1289 if you remove the plug-in while the rendering thread(s) are active it can lead to a crash. I've also been able to trigger unexpected crashes loading/unloading some effects such as the quantizer and crossfeed that I still need to track down and fix. Routing presets work continues ...

[Mutant]

Wooo ! So many updates.

[aciddose]

So many updates.

Well, lots of me posting and rambling at least

Hopefully more to come soon. I might not finish the routing feature for another week or two depending upon how difficult it is. Getting a prototype of the internal routing would be extremely fun, but again we'll see if it's possible.

[aciddose]

Might get routing working with presets soon. I'm nearly to the point where I can test it per-preset, even multi-timbral. Most of my effort has gone into cleanup/restructuring stuff so far. The parameter routing system currently uses brute-force methods, so it has yet to be seen whether that'll need some optimization. All just simple stuff like pre-computed tables and such.

https://soundcloud.com/xhip/smw
(FM-square timbres!)

I put r1296 up on the alpha page which fixes quite a few issues.

[aciddose]

Finally got around to importing the colors from the GUI configuration database. So now it's possible to set up more custom colors and gradients/blends. I'll need to double-check and modify the way the colors get saved into the state files. Looks like I currently just save the index in the color list like "7". So that'll need to add a temporary item to the list "State = ..." if the default doesn't match one of your colors. In the future I'll export the color string including its name to ensure state files load the same regardless of the user config.



I'll need to start using this more for all the configuration it opens up.

Code: Select all

colors {
	constants {
		l = 2/5;
		s = 7/8;
	}
	Red            = hls(0/12, l, s);
	Orange         = hls(1/12, l, s);
	Yellow         = hls(2/12, l, s);
	Chartreuse     = hls(3/12, l, s);
	Green          = hls(4/12, l, s);
	Spring         = hls(5/12, l, s);
	Cyan           = hls(6/12, l, s);
	Sky            = hls(7/12, l, s);
	Blue           = hls(8/12, l, s);
	Purple         = hls(9/12, l, s);
	Violet         = hls(10/12, l, s);
	Pink           = hls(11/12, l, s);
	Dark           = hls(0, 1/5, 0);
	Gray           = hls(0, 1/2, 0);
	White          = hls(0, 1/1, 0);
	RGBK           = blend: hls(0/3, 1/2, 1) hls(1/3, 1/2, 1) hls(2/3, 1/2, 1) hls(0, 0, 1);
	Pink-cyan      = blend: hls(8/9, 5/9, 1) hls(8/9, 7/9, 1) hls(5/9, 5/9, 1) hls(5/9, 7/9, 1);
	Purple-orange  = blend: hls(11/15, 2/5, 1) hls(11/15, 1/2, 1) hls(1/15, 2/5, 1) hls(1/15, 1/2, 1);
	Slate_dk       = hls(7/12, 1/5, 1/7);
	Slate          = hls(7/12, 3/7, 1/7);
	Slate_lt       = hls(7/12, 5/7, 2/7);
	Scintillicious = hls(7/18, 5/9, 14/34);
	Mauve          = hsl(276/360, 0.31, 1/2);
	RGBette        = blend: hls(2/3, 0.5, 2/3) hls(0/3, 0.33, 2/3) hls(1/3, 0.25, 5/6) hls(3/3, 0.0, 1);
	Mauvette       = blend: hsl(276/360, 0.31, 0.6) hsl(276/360, 0.31, 0.5) hsl(276/360, 0.31, 0.3) hsl(276/360, 0.31, 0.2);
}