Traditionally, GUIs for VST/AU plugins have been created using pre-rendered graphic images, typically in the form of a large background image and any number of smaller image files used for knobs and the like. Allowing these image files to be loaded at run-time made it possible for users to substitute their own images, thus changing the GUI's appearance. This process (also widely used for games) has come to be known as “skinning”, with each collection of files called a “skin”. (See also Skin_(computing) and Theme_(computing).)

The present version of SARAH provides for a minimalist skinning approach—just a single background image—the technique, limitations, and philosophy of which are discussed below. For details about how to create your own SARAH skin, go to https://github.com/getdunne/SARAH/tree/master/Skinning, and look in the Skinning folder in the source code.

Using pre-rendered images has only one real drawback: Because computer displays have different pixel densities, the GUI may appear too small on the higher-density displays. Standard LCD screens have about 100 pixels per inch (ppi, aka dpi or “dots per inch”). Apple's famous “retina displays” are about 220 ppi—approximately double the standard density. Dell's newest 8K “ultrasharp” screens are 280 ppi, and the newest phones and tablets are pushing into the 300-400 ppi range and beyond.

The advent of high-ppi displays, together with the more prosaic problem of aging users requiring larger GUIs just so they can see them clearly, has led to tremendous interest in so-called “vector graphics”, where all elements of the GUI are rendered at run-time, at whatever scale is desired. JUCE's Component graphics classes are all vector-based, and mostly seem to work well on Macs with both standard and Retina displays, but it appears that support for GUI scaling on Windows has been problematic—see e.g. https://forum.juce.com/t/ui-scaling-on-windows-4k/21342/11. I think it's fair to say that vector GUI scaling remains at least semi-problematic in JUCE.

The traditional raster GUI approach, however old-fashioned it may seem, has a number of advantages:

1. It supports skeuomorphic GUIs, where the GUI's appearance may be a near-photographic representation of the traditional hardware device a given plugin replaces.
2. It supports skinning without coding—end-users or any interested people can create alternate skins for a plugin with simple image-editing tools, without needing access to the plugin source-code or indeed any coding skills.
3. More generally, the ability to develop GUI designs using image-editing tools allows for highly detailed GUIs and a good (efficient, appropriate) division of labour between programmers and designers.
4. CPU usage may be lower, as rendering the GUI reduces to simply blitting pre-rendered images.

A lot of people like to hate on skeuomorphic GUI designs, but I happen to think they work quite well for audio plugins, for two reasons:

1. While some people decry the visual cacophony of different-looking plugins, having a distinct look for every plugin helps users find the one they are looking for, when several are on-screen and possibly overlapping.
2. Within each plugin GUI, users engaged in musical work tend to find their way around by memory—both visual and muscle-memory. Nicely detailed GUI designs facilitate visual memory.

This is not to say that there are not good, bad, and downright ugly GUI designs around. But imagine if you will, a large screen full of plugin GUIs that all look like Windows apps from the 1980s. How would you find your way around? How could you tell one from another?

Building GUIs out of pre-rendered raster graphic images supports an efficient and sensible division of labour between programmers, whose primary concern is making software work, and designers, whose primary concern is making it look good. Taking the extra step to allow such images to be found and loaded at run-time makes a program or plugin skinnable, allowing ordinary users to further develop the GUI design. This is particularly beneficial in open-source and community-developed software, where the original developer's resources may be very limited, and enthusiastic users can contribute design ideas which the developer might never have thought of.