Improving the appearance of CSD applications in KDE Plasma 5

UPDATE: Full support for CSD applications was introduced in KDE Plasma 5.18, so these instructions are only necessary if you are running an earlier version. If you followed the instructions below and then upgraded to Plasma 5.18, you will want to reverse the steps below to avoid any conflicts with Plasma’s built-in CSD application support.

If you’ve tried running GTK3 applications in KDE Plasma 5, you may have noticed that some of them appear and behave a bit strangely. As an example, here is the GNOME document viewer (“evince”) running in Plasma using the default “Breeze” visual style:

This application, among many others, uses “client side decoration”, or “CSD”, which means the control of the window is provided by the application rather than the window manager, allowing buttons and custom controls to be drawn in the window’s title bar (here called a “header bar”). This feature works fine within GNOME, but does not translate well to Plasma due to technical and philosophical differences between the two environments, as I understand it. You can read about some of the issues this feature has caused here and here.

Besides appearing ugly (square corners, no window shadow or defined boundary), these applications also cannot easily be resized (there is no way to grab the border) and only basic window management is functional.

A workaround for this issue is to use “gtk3-nocsd“, which adds a kwin window border and title bar around the application, and removes the window controls from the GTK3 header bar. Here is the result:

We now have a proper window border with rounded corners and shadows. The window can easily be resized, and all of the wonderful functionality of the kwin window manager can be used. However, the dark header bar–now just beneath the title bar–is visually inconsistent with other applications, and also looks buggy due to being misaligned at the edges with the window frame color. Furthermore, the window title is duplicated between the title bar and header bar.

Fortunately, GTK3 themes are written in CSS, so it is not difficult to fix these remaining issues. Changing the header bar background, button and text colors, hiding the window title and vertically centering the subtitle text gives the following result:

Aah! Now this fits much better into the Plasma ecosystem. If you’d like to replicate these results on your own system, follow these instructions:

  1. Install “gtk3-nocsd“. In Kubuntu / KDE neon, you can find the package in the distro repositories. In Arch / Manjaro, it is in the AUR. For other systems, please follow the instructions on the gtk3-nocsd page.
  2. In System Settings, choose the “Breeze” visual style for both Qt and GTK applications, along with the “Breeze” color scheme. These settings are located in:
    1. Appearance -> Colors
    2. Appearance -> Application Style -> Application Style
    3. Appearance ->Application Style -> GNOME/GTK Application Style
  3. Copy the following into “~/.config/gtk-3.0/gtk.css“:
    headerbar {
      border-radius: 0;
      color: #232627;
      background-color: #eff0f1;}
      headerbar .path-bar button {
        color: #232627;}
      headerbar button {
        color: #232627;}
        headerbar button:disabled {
          color: rgba(35, 38, 39, 0.35);}
        headerbar button:backdrop {
          color: #bdc3c7;}
        headerbar button.flat {
          color: #232627;}
          headerbar button.flat:disabled {
            color: rgba(35, 38, 39, 0.35);}
          headerbar button.flat:backdrop {
            color: #bdc3c7;}
        headerbar button:hover {
          color: #232627;}
          headerbar button:hover:backdrop {
            color: #bdc3c7;}
      headerbar .title {
        color: transparent;
        font-size: 0pt;}
  4. Log off and back on.

Please let me know how this works for you, and whether or not you run into any issues. I made this fix using KDE neon with Plasma 5.16.4, so I don’t know how well it will work with earlier versions. There is also the possibility that a future update to breeze-gtk might conflict with my CSS tweak, so keep that in mind when updating.

Using SoundFonts in 2016

I made my first SoundFont instrument in 1995. I was fifteen. At that time, it was a brand-new technology only available on the Sound Blaster AWE32 PC sound card. I used to bring boxes of floppy disks to my piano lesson so that my teacher could let me use the university computer lab for downloading SoundFonts; we didn’t yet have Internet at home. SoundFont technology was my introduction to virtual instrument design, and over the next several years, I continued working in this format, honing the skills that would eventually lead to my current job with Acoustica.

Over the years, SoundFonts have remained a pretty universal way of distributing sample-based instrument sounds. The format has long been surpassed in features by the likes of SFZ and Kontakt, but yet, SoundFonts still persist. A great many DAWs and audio plugins support the format, as well as programs such as DOS game emulators, notation software, and media players.

The SoundFont spec went through a few revisions at the hand of the format’s creator, Creative Labs, the most significant being version 2.01, introduced in 1998. Supported at the time on Creative’s new Audigy series sound cards as well as pro audio hardware by E-MU, SoundFont version 2.01 added support for “modulators”, allowing different types of MIDI input (key velocity, key number, continuous controllers, etc.) to control any number of synth parameters. Using these modulators, a sound designer can determine exactly how note-on velocity affects note loudness or filter cutoff, map the mod wheel to control filter cutoff, crossfade samples, and much, much more.

These modulators are actually very powerful, but few SoundFonts today make use of them. There are a number of reasons for this:

  1. Earlier Sound Blaster sound cards (AWE32/64 and Live!) did not support SoundFont 2.01 modulators, so any SoundFont banks created using those sound cards do not make use of modulators. Only the Sound Blaster Audigy, Audigy 2, X-Fi, and E-MU APS sound cards featured full SoundFont 2.01 functionality (to my knowledge). In addition, people haven’t really been using hardware SoundFont synths for a while now.

  2. Most software SoundFont synths are not compatible with the 2.01 spec, and many aren’t compatible with any version of the spec! This has lead many SoundFont designers to code for the lowest common denominator. Alas, many SoundFonts today are nothing more than samples mapped to keys, with scant little in the way of actual sound programming.

  3. I am aware of only two SoundFont editors that allow both A) editing modulators, and B) being able to hear the effect of the modulators. These editors are:

    1. Vienna SoundFont Studio 2. Not to be confused with another SoundFont editor, Viena (one “n”), Creative Labs’ Vienna SoundFont Studio requires a supported sound card (specific cards by Creative Labs and E-MU) to run. To make matters worse, the latest version of Vienna (2.40.60) removes access to the instrument and sample pools, making it very difficult to properly manage a SoundFont bank. An earlier version (2.3 version 1.31.0) doesn’t have this problem, and it is what I still use as my primary SoundFont creation tool to this day. However, this version was never made available for download (it shipped on certain install CDs), and is very difficult to find online. Furthermore, it is a 16-bit application, which means it will not run in 64-bit Windows.

    2. Swami. This SoundFont editor uses the excellent FluidSynth at its core, and is able to not only edit modulators, but all effects can be heard and manipulated. Unfortunately, Swami is currently a bit of a work-in-progress, and only supports Linux at the time of this posting (unless you compile it yourself for Windows/Mac).

Of the other available SoundFont editors, Viena and Polyphone allow editing modulators, but the editors’ built-in SoundFont playback does not allow you to hear their effect. In addition, out of all of these, only Vienna SoundFont Studio properly displays the list of default modulators, allowing the sound designer to easily turn them off. (Here is a video I made that covers this, for any interested developers. It was originally made to help the Swami dev team.)

This state of inconsistent support is not unique to the SoundFont format. Other complex formats attempting widespread use suffer from the same problems. SVG files, for example, don’t display properly in some applications. Older audio players can’t handle variable-bitrate MP3s. Another popular sampler format, SFZ, sees a wide disparity of compatibility as well, with some samplers unable to handle the more complex instruments.

“I’m not dead yet!”

It is 2016. Gone are the days when dedicated audio processing hardware is required to achieve a professional sound. Music is created using software synths and effects now. So, if you are wanting to use SoundFonts in your home studio, chances are you are looking for a VST plugin rather than grabbing a Creative sound card off the shelf at your local Best Buy (do their current sound cards even support SoundFonts anymore? I doubt it…).

So if you are looking for SoundFont-compatible software, you’ll find there is a lot out there. And as you might expect, the quality varies quite widely. The available software can be broken down into three categories:

  1. Programs that emulate a General MIDI device. These programs usually install an internal MIDI device that adheres to the General MIDI (GM) standard. This is also how the onboard SoundFont synth of the Live!, Audigy, etc. sound cards worked. These virtual MIDI devices are less useful for modern music production, but are ideal for things such as DOS game emulation or playing General MIDI-compatible files. Some of the programs in this category are: CoolSoft VirtualMIDISynth, FluidSynth (and its various installable GUIs), SyFonOne, and TiMidity++.

  2. DAW plugins (VST, AU, LV2). These programs integrate directly into your DAW, and provide the best music production workflow, including the ability to bounce out audio with the rest of the project (unlike synths from the first category above). Unfortunately, this category is also the most bleak in terms of full SoundFont support, the lone exception being the Calf Fluidsynth plugin, which currently only runs on Linux. Most DAW plugins that advertise SoundFont support aren’t even trying to be compatible with the spec, often just pulling the samples out of the SoundFont file and re-mapping them in the plugin’s native format. There are some decent options available, however. Some of the programs in this category are: bismark bs-16/bs-1/bs-0 (PC/Mac), bismark bs-16i (iOS), Calf Fluidsynth (Linux), DLSMusicDevice (Mac), Jeskola XS-1, LinuxSampler, Phenome, SafFronSE, sfz, VSTSynthFont. There are many samplers available as well that can import SF2 files, but I have excluded them from this list.

  3. Self-contained programs. These applications aren’t trying to make a SoundFont synth that is available to other programs. Rather, the SoundFont support is only accessible within the program. Examples include SynthFont, JOrgan, VLC media player, and some DAWs such as FL Studio and LMMS.

The Tests

I created a test to determine a synth’s compliance with the official SoundFont specification. I have chosen to test the synths that A) stand out for their quality/popularity, and B) were available to me. In cases where multiple programs use the same synth engine, I only tested one. For example, LMMS, MuseScore, and others all use FluidSynth under-the-hood, so I only tested FluidSynth. Same thing with SynthFont, which shares code with VSTSynthFont and SyFonOne. A good many programs were left off of the compatibility chart as they were unable to complete even the most basic compatibility tests (Phenome, SafFronSE, and a good many other VST instruments).

I have posted the results of my tests in a  compatibility chart (the contents of this document may change as tests are added/updated). The legend for the test results: green = full support, yellow = working but not a proper/ideal implementation, red = broken or not supported. You can read detailed notes on each of the tested synths here.

Here is a document explaining how each test is performed. Any software developers interested in improving their SoundFont software can e-mail me at “s_chriscollins AT”. I will be happy to test the SoundFont compatibility of your product. Or you may run the tests yourself if you’d like, although I must forewarn you that my documentation is not as comprehensive as it could be.

Test Results

As you can see from the test results (as of 2/29/16), there is only one software synth with complete support for the SoundFont 2.01 spec: FluidSynth. Nothing else even comes close (apart from the Audigy 2 hardware implementation, of course). FluidSynth is a command-line application that runs as a General MIDI device. There are also GUIs that you can install such as Qsynth or FluidSynthGUI if you’d rather not type commands. FluidSynth is also built into programs such as LMMS, MuseScore, ScummVM, and VLC media player to provide SoundFont support within those applications. Unfortunately, its existence as a DAW plugin is currently limited to Linux (Calf Fluidsynth LV2 plugin, FluidSynth DSSI), and may stay that way due to incompatibilities between Steinberg’s VST SDK license and FluidSynth’s GPL v2 license.

FluidSynth actually betters the official Creative/E-MU hardware implementations in a few ways. It has a better-sounding filter (to my ears, anyway), with access to the full range in both cutoff and resonance (the Sound Blaster caps off at a certain point). FluidSynth also ignores the 2.01 spec default modulator for “velocity to filter cutoff”, which is a good thing. You can read why in my test notes and observations.

If you don’t care about 2.01 modulator support, CoolSoft’s VirtualMIDISynth (itself based on the BASS audio library) also makes a strong showing, but this program will only appeal to those looking for a virtual GM device.

The best SoundFont VST/AU plugin for Windows and Mac that I tested is bismark bs-16 (or the single-channel version: bs-1). It doesn’t support modulators, and the filter implementation is not perfect, but instruments generally sound as they should. It is also very flexible, allowing realtime manipulation of the ADSR envelope and filter, among other things. The plugin is not free, but can be demoed as long as you don’t mind the sound of the occasional dog bark. There is a free version, bs-0, but it is extremely limited.

If you’re looking for a free SoundFont VST/AU plugin for Windows or Mac, I’m sorry to report that nothing I have found is very good. Jeskola XS-1 is decent as long as you don’t run more than one instance at a time and don’t mind it badly interpreting instrument layer volume and other parameters. The old rcg:audio sfz plugin has been around for a long time, but it also gets some things very wrong, including a very shallow velocity curve that really messes with the balance of many instrument sounds. Also, you will need to hunt down the multi-core-friendly version if you want to avoid issues on modern PCs. Macs can use Apple’s DLSMusicDevice, but it’s pretty terrible, failing the majority of my tests.

In Conclusion

The purpose of this blog post was to provide a thorough review of the SoundFont technology as it stands in 2016. It is my hope that this information will be useful to others in the field—musicians, virtual instrument designers, synth plugin developers—perhaps leading to better support for the standard moving forward.

What’s still missing at this point in time is a VST/AU virtual instrument with complete support of the SoundFont 2.01 spec, as well as a good, cross-platform SoundFont editor that supports and can audition 2.01 modulators.

I realize that clamoring for change regarding an aging technology might fall upon deaf ears. However, I still see a lot of life in this old format. There is an obscene number of SoundFont instruments available online, and new, SoundFont-compatible software continues to be actively developed. SoundFonts might not be as feature-rich as Kontakt instruments (no round-robin or scripting, for example), but they are perfect for many tasks, and I make use of them frequently in my own music production.

So, you have now heard my very long and technical plea. I have no idea how many others will care about this as much as I do, but I thank all of you who stuck it out to the end! Please let me know your thoughts in the comments, and have a blessed day!

And don’t forget to check out my SoundFonts and music at!