But hey, UI is hard and audio processing UIs are probably harder than most.
I'm hoping this is something that improved in 3.0.0, because using Audacity is becoming increasingly impractical. I was just trying to listen to 10 tracks one by one yesterday and even just muting/soloing a track would take about a second; it was horrible. Shrinking the window helps, but it's silly to have a tiny window and scroll around when you have a 4K display.
I kind of suspect this to be a windowing toolkit issue, and originally I thought it was macOS-specific (since I first noticed when I tried to recommend it to friends who use that), but ever since I moved to a 4K screen on Linux I noticed it's bad here too...
The Mac story is here: https://forum.audacityteam.org/viewtopic.php?f=47&t=111105
The workaround is, well, not using HiDPI mode which is silly. But Audacity doesn't even seem to support HiDPI mode on Linux properly to begin with (the entire UI is small), so that's not it per se... I guess wxGTK just struggles when it has to draw 4x as many pixels?
Apparently it's bad on Windows too: https://forum.audacityteam.org/viewtopic.php?t=111857
This is because the state machine that drives the draw context is synchronous. Every line, pixels (or anything, really) takes some CPU cycles.
Newer toolkits (QtQuick2, GTK4, Skia-based-ones) are hardware accelerated. They are slower of standard DPI, but much faster on HiDPI.
So, yes, they cannot be as snappy on HiDPI, the number of pixel gets bottlenecked by the single thread performance of the CPU. Those barely grow year-over-year, while the number of pixel went up a cliff overnight.
> which tells me this isn't a simple pixel pushing problem but rather something more profound in Audacity.
That's probably because of the cursor animation (when you play). Audacity has to redraw the entire track widget each time the needle moves unless they implement special double buffering + special damage area slices. By default, Qt/GTK/wx are too dumb to understand layers properly. They will redraw the entire rectangle if you try to stack things with any transparency or non-rectangle clips. Even with proper double buffering, combining both frame buffers is still done on the CPU. That's 2x4x{width}x{height}x{fps} bytes up load to the GPU per second. for a 4k ARGB8888 video frame @ 60fps, that's like 4GB/s of raw transfer if you rasterize each frames in the CPU.
(disclaimer: former KDE dev)
edit: If you run KWin, you can enable the redraw compositor plugin and see for yourself which area of the window are repainted.
Yes, it's poor UI.
I've noticed that the Audacity issue seems proportional to the number of tracks (not how much of the screen they take up) and improves when I zoom in a lot (to the sample level), which tells me this isn't a simple pixel pushing problem but rather something more profound in Audacity. There is obviously something horribly inefficient about how waveforms are being drawn at lower zoom levels.
For comparison, I can run full-screen Ardour with an order of magnitude more tracks and complexity than Audacity and it still performs much better, even if it isn't perfectly smooth.
It's a potential project killer, but it can be done. The trick is to wrap all your objects in QObject classes. You keep the old UI code as-is as long as possible.
The first Jedi mind trick is to reverse the event loop. Qt supports GLib2 loops, but only as long as they are created by Qt. So you create a dummy QCoreApplication, start the event loop. Then you coerce GTK into using the glib event loop Qt created.
After that, you populate your QObjects I mentionned above. The `Q_PROPERTY` stuff is the important part. It *has* to be fully implemented for QML to ever work. For Qt5, you need to use Qt containers. This means porting your lists and other C++ types (or glib types) to Qt. For Qt6, I think you can get away with some of that, but not Qt5.
Then, make all the signals work. It is important that all properties have signals. The signals must be reliable. QML heavily relies on events for literally everything. Without events, your UX gets out of sync and crash.
The next part is models. Turn all list with selections to models. Don't try to render stuff using for-loops in QML, this is a terrible idea and will explode in your face. Qt Models are annoying to write (and get repetitive very fast), but reliable list models really greatly simplify the QML code.
When you have all those QObject to reflect your current codebase, you make a companion app. This is a small window (or LAN/Network smartphone UI using QtRemoteObjects).
Now you are ready for the UI. Add little features, one by one. Don't try to do everything at once. Again, as long as you can, keep the wx/GTK window alive and fully functional. Your app will look wierd with 1 wx window and 1 QtQuick window. However, having the fully functional old UI let you press buttons there and see the results being updated in QML. That let you polish/debug your signal/q_property code step by step.
Once you are "done" with your port, strip the UI code from the old codebase. Then refactor/clean the logic and turn it into a library. Then start merging your QObject shims and logic classes into a single class.
If you get there, congradulation, your port is complete. Time to annoy your users with a bunch of changes.
With Qt 4/5, there is an environment variable, to play with. It sill runs like crap and is now deprecated.
edit: Of course, GTK4 have "real" backends for both Vulkan and OpenGL. They implement scene graphs like QtQuick rather than building a big bitmap like GTK2, GTK3 and QtWidgets.
On KDE HiDPI, the audio input/output device selector positions the dropdown boxes according to 100% scaling, but they're sized according to 125% scaling, so they overlap!
Or you get ancient looking Ui
Or you get platform spesific stuff!
Actually Java applications are kinda reasonable compromise
As are .NET applications. Yeah, most .NET desktop apps in the wild are technically chock full of Windowsisms, I've found that said apps more often than not Just Work(TM) on e.g. Linux w/ Mono, and alternative toolkits like Avalonia help further.
I'm super interested in the UI design of really complex applications (like Audacity, or Photoshop, etc.). I would adore some kind of writeup on y'all's design process whenever you towards the end!
(Obviously a big ask for someone already doing a bunch of work for free, pls feel free to ignore me; just saying that I'd be interested :D)
Designing the Win95: https://socket3.wordpress.com/2018/02/03/designing-windows-9...
Also the final design guides: https://www.ics.uci.edu/~kobsa/courses/ICS104/course-notes/M...
A (really old) book: https://www.amazon.com/About-Face-Essentials-Interaction-Des...
Another book: https://www.amazon.com/Designing-Interfaces-Patterns-Effecti...
Oddly enough these are all ancient. There hasn't been much innovation in that space though. (apart from High Dpi and Dark Mode)
Blender recently did a redesign of their UI, they have lot's of discussions about their rationale.
Computers used to show light characters on a dark background. 8-bit platforms often defaulted to white text on a dark-blue background, which until just a few years ago was still available in Word as a checkbox option.
Then the "desktop publishing" craze came along, and brought the analogy of a computer screen to a piece of paper. But this inverse (black text on a white background) scheme ignored the fact that paper doesn't EMIT light. Using these systems was akin to reading the label on the surface of a lit light bulb all day.
But for two decades, Windows let you set up a system-wide color scheme whose colors would be inherited by (nearly) all applications. It was great; you could (and I did, in the early '90s) replace the dumb inverse default color scheme with a "charcoal" scheme... essentially exactly what most "dark modes" are today.
I think Unix GUIs allowed you to set up color schemes too, leaving only the vaunted Mac GUI as the hard-coded,glaring eyeball-strainer of the era.
But now that people are finally realizing that inverse color schemes suck, what did Microsoft do? REMOVE the color-scheme editor from Windows. So now we're being dribbled out "dark mode" one OS, Web page, and application at a time. And it's still hard-coded.
That's not innovation. It's pathetic.
>paper doesn't EMIT light
Your retina doesn't care if the photons it receives are emitted (as with CRTs) or reflected (as with paper). If you feel like you're staring into a lightbulb, your monitor's brightness is set too high. Set it properly, and, in a well lit environment, your monitor's white should match that of the wall behind it, or that of a piece of paper on your desk.
The only thing I think I can remember clearly however was the question about the biggest regret which I think was one particular core datastructure that was an array but which they later wished they had used a linked list for instead.
Having actually used Audacity and Photoshop, I'd love to learn a bit more about how those design decisions were made.
It's still called an export, but it's basically doing exactly what you're asking for.
It's because the format you want (regardless of it being the same format you started with) can't store quite as much metadata about your changes as the app's native format.
Maybe a custom config profile that is very easy to tune, import and export would allow redesign to get radical without compromising old users
To give a concrete example: suppose I want to apply noise cancellation (something very few free audio tools provide I must add, and a really cool feature of Audacity):
- You select your track
- You go in Effect, you skim through the long (alphabetized) list to find "Noise reduction"
- You realize that you forgot to generate your noise profile, so you close the pop up because you can't reselect when the pop up is active
- You select your noise reference
- You return to Effect, skim through the long (alphabetized) list again, find noise reduction again
- You tell it to use the selected audio as noise reference.
- You close the window
- You select the entire audio again
- You return to Effect, skim through the long (alphabetized) list again, find noise reduction again
- You can tweak the various reduction parameters, then you can click "preview" again which pops a 2nd window up with a rudimentary audio player that doesn't let you do anything besides listening to the selected audio from the start. You can't focus on a particular zone or anything. If you want to do that you have to apply the noise reduction, close the module, return to the main window, listen to your track on the proper timeline then undo the reduction and return to Effects, skim through the long (alphabetized) list etc...
If there's a better way to do any of this I haven't found it.
I don't want to really to be too hard on Audacity, I'm genuinely thankful for its existence, but it's not a good example of UI done right IMO.
I like minimalism in UI, but I think it works best when it's flexible and composable (like Vim commands for instance). Audacity UI's is neither, it's just a long series of ad-hoc modules.
Not rocket surgery, but a very deep UI redesign compared to a dialog box.
I blame the traditional prevalence of highly self-contained plugins and little scripts (for example, Audacity has Nyquist scripts) that entail generic host applications that only really care about the subset of features that cannot be delegated to plugins (for example, Audacity has the waveform view).
TBF default groupings are often based on the function baked into a VST/AU by the designer, and some of those groupings are more useful than others.
But given that Audacity's plugins are largely homebrewed, I don't there's a good reason not to get this right.
I find these kinds of problems baffling. And it's not that they're exclusive to open source, because they really aren't. (I'm looking at you, Adobe...)
Some designers just don't seem to get UI concepts like making common workflows as streamlined and effortless as possible, minimising clicks and scrolling, efficient presentation of options with useful grouping, and watching non-dev users interacting with the software to find out what feels clunky and excessively complex to them.
It's not pretty and looks cluttered, but those are just looks. Those aside, it's probably perfectly serviceable for getting work done. I like UIs where everything is just there (or even where you put it), and you don't need to dig in submenus that may even make you wait for animations. You can build effective muscle memory for this. It also appears it will let you make use of multiple monitors easily.
It just doesn't look great because font sizes and spacing is really inconsistent across types of UI elements: buttons get lots of space to breathe with big paddings and margins for some reason, any bar has very little space and gets a tiny font, lists have fonts way larger than everything else, ...
SoundForge was fantastic. Now I just do everything in Reaper. Both non-free of course, but Reaper is really cheap and works everywhere and does so much more than just audio editing.
Edit: the love Audacity is getting in the comments inspires respect! There is obviously something that I missed...
I gave up every time I tried to use it because the UI was fugly to the point of being distracting.
> If I was a rich philanthropist I'd throw them some money to gut the core of the software and rebuild a decent user interface around it.
Unless I’m misremembering the software, years ago (a decade?) I planned on doing the next best thing and work on a new icon and UI for them, but soon found an official page which said they weren’t interested in such contributions. The page existed because people kept offering.
There’s another commenter on this thread who’s working with them on a redesign, so I’m glad they changed their minds.
https://www.blackmagicdesign.com/products/davinciresolve/fai...