[fasterdom]

Funny how there are a few domains where the same problem is solved over and over again. Probably an indication that a good solution is truly missing.

A long time ago I wrote a tiny audio synth. And yep, I wrote my own minimal GUI which had stuff like sliders, and most importantly knobs which general GUIs typically don't provide.

Now I'm working on a non-audio webapp, and I have a problem where a knob would be the ideal solution. Searched far and wide for a Vue knob, and what I found was not usable. It worked if you "rotated" it circularly, but it didn't work if you pulled it up/down like a slider. You might say "use a slider then if you want to pull it up/down". True, but a slider takes a lot of UI space which sometimes is very precious. More importantly, the slider resolution is limited to it's height, while a knob could for example use the whole screen height for a full turn.

[extra88]

> minimal GUI which had stuff like sliders, and most importantly knobs which general GUIs typically don't provide.

They don't provide knobs because they're a bad idea for input. Holding mousedown while drawing an invisible arc with the cursor is an awkward way to change a value. Sliders are generally better but still not great on interfaces with cursors (they're better on touchscreens). Skeuomorphism can be a useful visual design cue but it needs to be secondary to the input capabilities of the device.

Up and down arrow buttons(or plus/minus, or whatever makes sense for the value) are very compact and operable with a variety of input methods. Buttons need a way display the value but there are many options including putting them in the center of a ring of numbers like a knob would use.

[vbsteven]

In a good knob it’s not an arc but just clicking and dragging straight up or down that makes it move. A lot of VST audio plugins work like this and they get a lot of controls into a small area like this.

[extra88]

But then the gesture doesn't correspond to the interface at all. You could get the compactness plus a visual that corresponds by having something like a vertical slider that appears when you mousedown on the spot.

[jcelerier]

> But then the gesture doesn't correspond to the interface at all.

I remember learning soft synths when I was 11 - 12 years old and back then it maybe took me a few minutes to get it. Come on.

[bch]

> They don't provide knobs because they're a bad idea for input

I like knobs because the distance from the center of that control (radius of your arc movement) can be a “fineness” or “coarseness” control. I think sliders don’t usually offer this.

[rickbutton]

Some iPhone apps provide this for the time slider (I believe via the native media player control, although I could be wrong). It is very nice.

[bch]

I’ve seen this too, and yes, it’s nice. I don’t know where in the stack this feature lives.

[holy_city]

That's why you don't use circular dragging for a knob, you use vertical/horizontal drags (or a combination of both, JUCE supports those for reference, I forget what it defaults to). I've only seen rotary dragging in a handful of products and it always sucks.

Arrow buttons are pointless when you're trying to dial in a value - which is the whole point of using knobs in audio software. They don't give you adjustable granularity or an easy way to continuously adjust - and if you do give it those functions, you've made a knob without the visual feedback of knob position. Or like you say, put it in the center of a ring of numbers, but again, you've just made a knob!

[extra88]

Yes, if you have to click up, then down, then up again, and down to nail down a "just right" value, those buttons would be more difficult but their operation would be apparent. You might be able to get to a "just right" value if mousedown can be held while the cursor is moved between the buttons but a slider is probably better.

The knob behavior you're describing is essentially an invisible slider. An invisible line is better than an invisible arc but it's still not good. Why not make it visible? A visible slider could appear on mousedown so there's something that corresponds to the gesture.

[holy_city]

It's not non-intuitive. The most acclaimed UIs for audio software are littered with knobs, and they have to be. You're talking about dozens to hundreds of continuous parameters that need to be dialed in by hand in conjunction with the user's ears. It's also common practice to have a hotkey like ctrl to swap between coarse/fine tuning of the parameters, so you can dial it in without changing controls or letting go of the mouse - which is often done in real time during playback.

In your first example, you've just made a knob that doesn't look like a knob.

In your second example, you're confusing mouse position and gesture. Linear sliders map mouse position to state changes, rotaries map gesture. Another way of looking at it is that a rotary slider's state is decoupled from the input, and in doing so, is a much more responsive control. Not to mention, you have an infinite 2D area to traverse to change the knob value with respect to the widget itself, not a finite, defined path.

And the huge reason that linear sliders (at least off the shelf ones) are impossible to use for audio UIs is that 99% of your user's time is spent adjusting from the previous position, not resetting it to a new one. That means any behavior where a click resets the position (like clicking just past the current position) is broken. Not just because it's trash UX for the application, but because in audio systems jumping parameter values can cause artifacts, and mitigating them is not without cost in performance and fidelity.

[extra88]

> It's not non-intuitive. The most acclaimed UIs for audio software are littered with knobs

That doesn't make them intuitive, they're merely familiar to people already familiar with such audio software.

> hotkey like ctrl to swap between coarse/fine tuning of the parameters

Image editors and video editors have keys like that too, they're not related to knobs.

> In your first example, you've just made a knob that doesn't look like a knob

That's great! I preserved the functionality while making the action more apparent.

> a rotary slider's state is decoupled from the input

That's what I'm criticizing.

> Not to mention, you have an infinite 2D area to traverse to change the knob value with respect to the widget itself, not a finite, defined path.

The visual feedback of both sliders and knobs are both restricted to finite, defined paths. Whether the control of the input is restricted to that path depends on how it was designed. With some sliders, you can only move the control when the cursor remains without the bounds of the slider the iTunes volume control for example. With other sliders, once you've clicked on the control, the cursor can be outside the slider, I think this is the "infinite 2D area" you're talking about. The macOS menu bar volume and Sound Preferences sliders are examples of this latter behavior, I also found this example (you need to click the play button for the code to run).

https://editor.p5js.org/Joemckay/sketches/rk2edzTIb

> That means any behavior where a click resets the position (like clicking just past the current position) is broken

Yes, for what knobs are used for, you wouldn't want a slider control to jump to whatever point on its line was clicked on. This is another behavior that is found on some sliders (both iTunes and macOS Sound volume controls) but not others (the P5 example above).

[fasterdom]

In the space of that slider you linked to, and audio app would have 5 knobs:

https://soundquest.jp/files/uploads/2018/10/massivex-replica...

On a more meta level, a whole industry decided after 30 years of iterations that knobs that work like invisible sliders are the best controls, and you - who by the looks never had any extensive use of audio software - are claiming that they are all wrong, because of some philosophic argument. You might be true, you might be the rare visionary who sees a better way of doing things where other cannot, but the burden of proof is on you.

[amelius]

> You might say "use a slider then if you want to pull it up/down". True, but a slider takes a lot of UI space which sometimes is very precious. More importantly, the slider resolution is limited to it's height, while a knob could for example use the whole screen height for a full turn.

Perhaps the solution is to make the slider pop up if you press a button?

[djowel64]

Not a bad idea, actually.

[kitotik]

In the early days of the iOS App Store I worked on a music iPad app. Through many hours of user testing and researching prior art, the best solution we came up with was detecting the trajectory of the user input and supporting both vertical dragging and dial-like rotation. It took a shitload of trial and error fine tuning, but it eventually turned out pretty well.

I think many music apps these days give you the option buried somewhere in settings.

[scrumper]

> option somewhere buried

That’s what I did. Made it slide by default (because I hate trying to twist a virtual knob). I briefly had a translucent rectangle popup when the control was in slider mode but it turned out not to be helpful as linear dragging seemed to make sense to everyone and I only had like eight options in total.

The one nice innovation I had was automatically detecting horizontal or vertical drags - useful for things like pan controls where a horizontal motion makes more sense.

[jcelerier]

> Probably an indication that a good solution is truly missing.

I don't think so. It's a pretty standard exercise to try to create an ui framework so of course we're bound to see tons of them.

[yoz-y]

Is it better to write one own's GUI in this case? I believe most toolkits have a way to add new controls, so it should be less work to add a knob to GtK, Qt or any other toolkit.

[fasterdom]

True, you could write a new Qt control.

Then you hit the second requirement: complete bitmap theming, many times of a skeuomorphic kind. This is extremely difficult to do in something like Gtk/Qt.

[torarnv]

Behold, in all its skeuomorphic glory, the Qt styles example:

https://doc.qt.io/qt-5/qtwidgets-widgets-styles-example.html

[kazinator]

That looks almost exactly like Motif from 1991, but superimposed with a wood grain pattern.

[Narishma]

Looks more like Windows 9x than Motif to me.

[kazinator]

1. Motif came first. Among people who knew what Motif is, the look of Windows 95 was widely recognized as being very similar to Motif to the point of being a knock-off.

2. See the diamond-shaped radio buttons in the second example. :)

3. 3D embossed arrows on scroll bars.

[jcelerier]

Qt has the following style that you can use, where you just have to ship the bitmaps for your controls in a predefined naming scheme : https://doc.qt.io/qt-5/qtquickcontrols2-imagine.html