Compressor Plugin GUI

Sampo Savolainen asked me to design an audio compressor plugin GUI. This triggered a thought process with a first result that is guaranteed to be far way from what he had in mind, but before I may head in a more conventional direction, I just have to explore this ;)

Background info on dynamic range compression.

I wondered how one could express what each control of a compressor as the one written by Sampo does. Giving an idea of the signal path and relations between controls. Ideally without labels, even.

Full size

The controls provided are:

  • High-pass filter on/off for the analyzed signal. Left side. Here I neglected that the signal is split in 2, one for measurement, the other to apply the effect on.
  • Treshold. Green line in the graph. Should be draggable from the whole grap area.
  • Ratio. Blue fader with round knob, synchronized with the blue line/dot in the graph.
  • Markup gain. Fader with red arrow. The graphics show the relation to the first graph.
  • Attack and Release time. Below the stop watch icon. I’m worried that the chart below the faders is rather hard to get, so it might be best to drop it and to add labels.
  • Dry/wet amount. Right side. The output touching the right corner and the fader handle for this are one.

High-pass switched off:

Experimental Theme Mockup

There are complaints about Ubuntu’s theming again and again. While I don’t think the default in Feisty is horrible, I don’t think it’s good, either. Colour perspective is an important reason for the prevalence of blue backgrounds. Orange jumps to the front, making Ubuntu look “full” and even “loud”.

So I played with warm but rather subtle tones, textures and various ideas in the details.

The shadows are not the same size for every window, but stepped according to z-order for a stronger sense of depth. This means the top window casts a larger shadow on the desktop.

Making no distinction between title and menu / tool bar means that any empty space there should act like the title bar does now. This is the reason why I clearly show the menu are on the browser window.

The size column of the browser has bars representing file size, where the full width is mapped to the largest file. With a very large file and several much smaller files, the only info this would provide is the distinction large / small, but even then it might be useful. It should work best in folders filled with similar files, like image or music collections.

Regarding some other details, please see:
HD Icons
List View Columns
Scrollbars with Popups
Options (check boxes and radio buttons)

Click on the thumbnails for full size images (1280 x 1024)

Experimental Theme Mockup

The Feisty screenshot this is based on:
Ubuntu Feisty
The only changes from the defaults that affect the visuals were turning on “Desktop Effects” and adding workspaces, I think.

EDIT: Since this still gets many hits, I would like to point to more recent work ;)
Experimental Theme Mockup 5

Ardour Latency Dialog

Paul Davis asked me for advice on the Latency dialog he is implementing. This is the state of things:

Latency current

The underlying logic above is to go from minus to plus and from large to small and back to large. With “Use natural latency” in the neutral center. The result looks rather chaotic :)

Latency A

“Use natural Latency” -> Automatic. Under the assumption this is the default, I put it on the left as the thing to start from. It should be a toggle button to inform the user if it is on or not (clicking the other buttons should disable it) . Adding the value it will result in as part of the label in parenthesis or as tooltip would be good, but I’ve been told that value is not readily available.

Using 2 rows allows to split step size and direction. Same size buttons avoid an overly busy layout.

Latency B

If custom widgets are an option.

Note that I treated this mainly on the layout level and did not put to question the elements, as I currently do not have much insight into the underlying needs. So I just trust Paul here ;)

Save Changes Integrated 3

Save Changes Integrated 1
Save Changes Integrated 2

Due to the various concerns that have been raised, here’s another approach, targeted at the WM alone.

I also played a bit with WM button styles and suddenly had the idea of using a colour change on the close button instead of a * in the document window title to indicate unsaved changes. But as that doesn’t show up in task bar items, perhaps both should be used.

The warning colour of the button could extent to the titlebar that serves for both document window and dialog. The window title changes to that of the dialog, as that makes more sense in the task bar, I think.

The dialog is meant to be a movable relative to the document window , just in case the user wants a free view on the canvas, but is placed so as to emphasize the connection. It’s taken right from GIMP; the wording, icon and button labels shall be of no concern, here.

Save Changes 3 Title Bars

Save Changes 3
(Click to enlarge)

Save Changes Integrated 2

After some discussion with Peter Sikking, I decided to modify the design from my previous post.

Before, I placed the dialog part at the bottom, to keep the buttons in the usual place (if you think of the whole window as dialog). This time I aim at a stronger visual separation, more like the dialog appearing right on top of the image window, but precisely aligned and glued to it. The canvas part could either slide down, or the message / button part could appear above it for not having to resize the window.

Note the disappearance of the close button. Close buttons were the user has to wonder if they equal cancel and close or do-whatever and close are a well known problem. For GNOME/GTK, it has been argued that the presence of a Close button on dialogs is an accessibility feature for the blind. Well, I don’t quite get that.

Save Changes 2
(Click to enlarge)

Save Changes Integrated

Applied to GIMP, as that’s where I stumble over the Save Changes dialog most frequently. That dialog appears centered over the image window, so you have to move it out of the way if you want to take a second look on the image you are about to either discard or to overwrite another version with. At least with GIMP 2.3.x and Metacity, the dialog can’t be focused separately, already making it a part of the image window in a way.

After the user issues a Close command, the canvas part of the image window should move up as the menu bar disappears. The window is expanded downwards as needed. The zoom combo box in the status bar of image windows would still be useful, but I decided to go for a clean layout. Zoom options could be given in a context menu on the canvas. Experienced users prefer shortcuts, anyway ;)

The List Changes button is optional. It came to my mind because the text mentioning changes from the last x minutes is nice, even helpful in cases, but vague (well, it points the user to his own memory and time perception, so to speak). Also, the GIMP already has a history panel and the changes dialog would be similar. I wondered if the button label should end with and ellipsis (…), but the HIG tells us that it should only be used if the brought up dialog requires user input.

I tried to shorten the message text a bit. The original reads: “Save the changes to image ‘Untitled’ before closing? If you don’t save the image, changes from the last 5 minutes will be lost.”

Save Changes

(Click to enlarge)