A plea for consistent scroll wheel behavior in music software

Perhaps I’m just picky. Perhaps my neuroplasticity isn’t what it used to be. Either way, I find myself getting quite frustrated with the inconsistent scroll wheel behavior between music applications, in particular, digital audio workstations (or DAWs). This wouldn’t be such a problem if the behavior could be customized in “settings”, but this seems to be quite rarely allowed.

Muscle memory is key to an efficient workflow. Years of using a mouse and keyboard in largely consistent ways enables me to perform many computing tasks with great speed. Most software has settled on conventions for keyboard and mouse shortcuts, such as Ctrl-C to copy, Ctrl-V to paste (Command-C, Command-V on Mac), etc., meaning one doesn’t need to relearn common shortcuts on a per-application basis. The same is also true for navigating a view via mouse wheel, at least for most software, according to the following rules:

• Scroll wheel: pan the view vertically
• Shift + scroll wheel: pan the view horizontally
• Ctrl (Command) + scroll wheel: zoom (wheel up = zoom in, wheel down = zoom out)

The vast majority of software I use on a daily basis functions this way, including Audacity, MuseScore, GIMP, Inkscape, LibreOffice, Firefox, Google Chrome, and Polyphone, just to name a few. Over 90% of my computer time is spent reinforcing these shortcuts into my muscle memory.

And then I try working with almost any DAW, and it all goes to hell. My muscle memory kicks in to scroll down in REAPER, and I end up zooming, or I try to zoom in Cakewalk and end up panning horizontally instead. A good percentage of my navigation attempts initially fail as everything that is built into my muscle memory is now wrong.

Perhaps a good comparison for this experience would be video game controller buttons. Anybody who has played platform-style games knows that jump is always the A button and attack is always X (assuming an Xbox style controller layout). If you make one game that swaps the functionality of these buttons with no option for configuration, you will have gamers up in arms, as muscle memory is key for gaming prowess. Some early games did have the jump and attack buttons swapped, but the industry has since standardized on the configuration we use today.

I believe we are at a similar juncture here in 2020. Most software has settled on the aforementioned scroll wheel conventions, so I believe software developers should strive to use these conventions whenever possible.

Scroll wheel behavior in popular DAWs

I tested the mouse scroll wheel (MW) behavior in a number of DAWs in Windows and Linux and charted their behavior in this Google spreadsheet. Here are a few notes on reading the spreadsheet:

• Behaviors not in accordance with the aforementioned conventions are highlighted in red.
• DAWs that have the desired scroll wheel modifiers out-of-the box are highlighted in green.
• DAWs that have alternate scroll wheel modifiers but allow full modifier customization are highlighted in yellow.
• The zoom shortcut (Ctrl+MW) should be used for horizontal zoom, as this is by far the most common zoom operation used in a DAW.

As you can see in the spreadsheet, the scroll wheel behaviors are all over the place. Of the 13 DAWs I tested, only 4 featured the desired scroll wheel behavior by default. Interestingly, all four are open-source DAWs (Ardour, Audacity, LMMS, Qtractor). A further four DAWS (Ableton Live, Pro Tools, Reason, Studio One) at least have vertical and horizontal scrolling correct, but miss on the zoom controls.

Only two DAWs (Mixcraft and REAPER) allowed me to fully customize the scroll wheel behavior, at least as far as I could find within the application’s settings. So, counting these two, that brings the number of DAWs that can be used with the desired scroll wheel behavior to 6.

I must give Tracktion Waveform 11 special mention for doing something truly awful: completely different controls between the track and piano roll views:

	Track view	Piano Roll
Vertical pan	none	MW
Horizontal pan	Shift+MW	none
Horizontal zoom	MW	Alt+MW
Vertical zoom	Ctrl+MW	Shift+MW / Ctrl+MW

Tracktion Waveform 11 scroll wheel shortcuts

I can’t see this as anything other than terrible UX design. How is anyone supposed to develop muscle memory when there isn’t even consistency within the same application?

Conclusion

The purpose of this blog post is not just to vent, but to make a case for the standardization of the aforementioned scroll wheel conventions. We’re already part way there, with very strong adoption already in the open source community. If you are a software developer and wish to use a different control scheme, please at least provide an option to fully configure the scroll wheel modifier behavior, as Mixcraft so simply does in its preferences:

From a programming perspective, this is one of the easiest things to implement, so I am astonished it is so rare to find.

I am curious to hear opinions from both users and software developers on this matter. Do you share a similar experience to mine or something completely different? Are there types of music software where a different control scheme makes more sense? Please let me know in the comments.

Advertisement

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.

Replicating the Blade Runner Theme

Although I am a bit late to the party, the arrival of the new Blade Runner movie inspired me to try to replicate the title music from the original 1982 Blade Runner using Mixcraft 8 Pro Studio. As most of you synth aficionados already know, the Blade Runner soundtrack was composed by Vangelis using the beastly-yet-expressive Yamaha CS-80. The Pro Studio version of Mixcraft just so happens to come bundled with the ME80 VST instrument, which very nicely models the sound of the Yamaha CS-80.

It turns out that I was able to replicate a good deal of the instruments in the main title music using only VST plugins that are included with Mixcraft, so I made a tutorial video showing how it’s done:

Of course, the techniques I use in the video aren’t just limited to imitating existing music, but can be used to create your own Blade Runner style tunes as well. Here is a little track I wrote a few years back attempting to recreate that iconic sound:

Hopefully some of you fellow synth-heads will find this tutorial to be useful. I will soon be posting an update to my previous article, “Using SoundFonts in 2016”. Spoiler: there is some really good news on the SoundFont front. Stay tuned 🙂

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 hotmail.com”. 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 www.schristiancollins.com!

The Start of a New Thing

So, I have decided to start a blog. I have wanted to do this for a long time, not because I have a tremendous amount to say, but rather I felt it would be the best format for sharing some of the music and tech-related articles I am planning to write. I will also use this blog to announce new and updated virtual instruments I have created. I will not use this blog as an advertising space for my musical endeavors (performances, compositions, etc.), unless there is major news in this area. If you would like to follow me as a musician, please follow me on Facebook.

So, with this groundwork laid, I hope you will find this blog informative. Until next time…

Cheers!