What is alpha?

These are some of the latest alpha (untested/unstable) files that I've bothered to upload. For anything related to this stuff, please contact me via e-mail. "Unstable" in this case refers to the fact that features being worked on may change and compatibility is not guaranteed.

Alpha versions are essentially "direct from source" and represent the current work-in-progress version of the source code. Please keep in mind that these versions are only for testing. They could contain bugs or behave improperly or unexpectedly.

If you are interested in verifying a bug, asking for new features and other changes or testing the latest features the alpha version is for you. If you are interested in a free synthesizer for general use please use the latest stable release version (8) from the synth page.


  • Use alpha versions only for testing and not for regular use.
    • You'll need to continue to use the specific alpha version and will not be able to upgrade projects.
    • Expect that alpha versions will NOT work. New features and changes can lead to bugs or issues.
    • Bugs in the alpha will never be fixed and it is very likely future versions will not be compatible.
    • I do use the alpha version myself although I don't care much if the host crashes and I lose all my work. You can use the alpha for whatever you want as long as you're aware of the possible consequences.

    The alpha is "unstable" or in other words features of the alpha version are expected to change. This is distinct from a stable release version in that if for example a bug is discovered in the release version a fix may be provided with no other changes.

    For a bug in the alpha version however an in-place fix will never be provided. Instead a replacement version may be made available including potentially a fix for the bug as well as other changes which may be incompatible with the previous version.

    The reason for this is that in order to maintain a stable version it is necessary that a lot of work is invested to ensure any changes are fully compatible with the previous version. This involves a very large amount of overhead and due to that fact unnecessary changes and additions are not made to a stable version in order to reduce the effort required.

  • Please report any bugs or issues you have with the alpha version[s].
    • After checking the bug & todo lists below, if your issue isn't on the list yet let me know so I can add it.
    • In normal use the plug-in should never crash. If it does please report it immediately! If you can reliably reproduce the crash providing instructions on how to do so will be extremely useful to me in fixing the problem. Reporting "it crashed" doesn't help me much, I have nearly nowhere to go from such a report without any information about what may have triggered or caused the crash.

At times testing may be focused on specific issues.

Otherwise the general idea is to try to come up with new ideas to improve Xhip further before the next release as well as to keep an eye out for any bugs that might show up during use.

Until the final testing stage before release small bugs (if on the known list) are not too concerning as the code may continue to change.

That said I'd be interested to hear about any bugs that are discovered in any version.

If you have read the "rules" (please do) the download section is at the bottom of the page.


15 Jun 2017

For version 8

Linux and OSX alpha versions
Attempts have been made to create native Linux and OSX versions.
OSX is a bit problematic for me as I do not own a Macintosh PC although compiling for Linux is similar and can be accomplished via virtual machine.
I do not forecast that a complete implementation will be made available although working to compile up-to-date code on these target platforms will make it easier to complete the work in the future.
Currently the Linux version is missing several key components but does essentially function on the platform including the GUI.
A functional OSX version has been built without a GUI.
Linux xlib getopenfilename compatible dialog.
Due to the nature of Linux dynamic linkage and the way existing frameworks (such as GTK) operate it appears impossible to utilize them directly from within a plug-in instance without interfering with the host or other plug-ins.
One solution I've come up with (purely theoretical) is to wrap the messagebox and openfilename implementations in their own library and load this into its own namespace to avoid such conflicts. This is based upon a whole heap of assumptions (hope really) and may not work at all.
Due to this difficulty it seems likely that I may attempt to create my own implementation. A functional messagebox implementation is already finished although it has some issues with modality. A file browsing dialog is slightly more difficult and may take a considerable amount of time to accomplish.
Update NSIS installer
The installer needs a "getting started" chapter and a nice Xhip logo.
Other modifications are possible too; I'll investigate more later.

Fixed or new features

2 Jul 2017

Xhip 8 Linux /w GUI

2 Jul 2017 (r974)


Implemented xlib SHM buffer.
In the end it turned out that the SHM implementation was less important than I thought. It was reasonably easy to accomplish though and is massively more efficient than the naive XPutImage method. The current implementation uses XPutImage as a fallback in case SHM isn't available but doesn't include checks associated with SHM support. Instead error-codes are checked and upon failure to allocate the SHM buffer the standard methods will be used.
Fixed issue with GUI redraw.
The function get_client_rect() was calling XGetWindowAttributes() as part of set_clip_rect() associated with every GUI item redrawn. Since this uses xlib's high latency communication protocol and xlib does not buffer the response the function call overhead was absolutely, unbelievably huge.
The data is now read from cached values rather than calling into the sysdep/xlib functions.
Improved xlib messageloop and associated code (timers, etc).

Xhip 8 Linux

30 Jun 2017 (r970)


It's ALIVE!!!
Seems I need to implement a slightly different bitmap blit using an xlib shared-memory extension (SHM) as the current implementation is ridiculously slow.
Launch the plug-in first without installing the skin. It should work fine (no warning messages implemented yet but it obviously won't have the skin resource data.)
If it works extract the skin data into ~./xhip/synth/8/ and delete the ~./xhip/synth/8/bitmap cache/ directory and content.
Close your host and re-open the plug-in GUI and you should have bitmaps and fonts!
TODO includes embedded resources, SHM support and beta testing before an announcement and release can be made.
Various parts are missing: Dialogs like messageboxes and open/save file and a few other bits still need to be implemented. I'll likely use wxwidgets for this if possible. Beware the horrible messagebox stub implementation: hit a key to close it; it doesn't actually work at all.

Xhip XP

2 Jun 2017 (r880)


Windows XP compatiblity
Some small changes were made to fix issues on Windows XP.
Previous releases [+]

Known bugs or issues

15 Jun 2017

If bugs are found please let me know and I'll update this list as well as my TODO.

Xhip 8 Issues:

Some features are nonintuitive (left/mid/right click on logo.)
This requires an updated installer with a short "getting started" page.
Additional menu-trigger buttons are not ideal; sub-menus may improve ease of use.
There are remaining minor imperfections in import of v7 presets.
If this is noticed by anyone (mostly KBT-zeropoint related) please let me know.
Currently it does not seem important enough to warrant further effort.


You've read the rules, right?

namesizedate Jul 2017
xhip_8_linux_skin_data.7z810k30 Jun 2017
xhip_8_windows_xp_32bit_r880.7z1.1 mb30 Jun 2017

I've switched to 7z format for the alpha. It can be extracted with 7-zip, a free archiver.

  • Windows Vista (recommended Windows 7 SP1 or greater)

    (this can be solved in the future, a compiler issue.)