Audacity is a godsend for amateur audio makers, but man the UI is really really clunky. 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.
But hey, UI is hard and audio processing UIs are probably harder than most.
Another happy Audacity user here, great to hear it's going to get a refresh. My only request is that performance is kept top-of-mind - using Audacity is snappy and responsive even on ancient hardware, which makes it just a pleasure to use. UI interactions feel instant. The contrast to a slow Electron app like Slack is night and day.
I've found the exact opposite - Audacity used to be instant, but these days its UI is dog slow. It seems to struggle badly on high-DPI displays: it is almost unusable maximized on both macOS and Linux (X11) if you have a 4K or so display. It feels like it's actively gotten worse on this front.
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 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?
Those "classic" UI toolkit as raster engines. Both GTK/2/3 and QtWidgets 4/5/6 have OpenGL backends, but they are slower than the raster.
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.
(sorry, can't reply directly,
marcan_42 comment is too deep in the tree)
> 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.
It's not comment depth that keeps the reply link from appearing. I think it's intentional rate-limiting of replies, but only applied to the thread view, not the comment view.
Audacity is the only app that is this bad (I run KDE; my entire desktop is Qt5 so clearly that is not comparable).
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.
Audacity uses wxWidgets right now. We've been talking about migration to Qt 6 (and possibly QML for some things) but that would be a big re-platforming effort, still debating. Not sure if we can continue with wxWidgets and do a major UI/UX upgrade though
I have done it several time professionally (Motif, Qt3, GTK, etc, but not wx) to QtWidgets or QtQuick. It's been a while and I pivoted to other industries.
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.
Thanks for the write-up! This is great, good to hear war stories. I've sent it to the devs - if they have any questions about the above, would it be possible to reach out for quick thoughts?
Same username on GitHub (public email there) and Reddit. I admit I am slowly losing the battle with my indox, so better ping on both. I would be glad to provide help where I can.
Love this! Although I will almost certainly never have reason to apply it. (Still good inspiration for any big rewrite, and I'm starting one pretty soon.)
Did anyone actually try to make that run in practice? I don't think GTK supports that. You can't just magically hot-swap Cairo backends externally. Using the GL backend means you provide GL surfaces to Cairo instead of memory.
It runs like crap, that's why it isn't supported. But if really, really want to make it work, you can have your app make a surface, put a cairo surface in it, then render GTK there. I suggest you don't waste any time on this. Mozilla, Google and Samsung had many people _each_ assigned to fix it at some point. The Google gave up, bought Skia. Then Mozilla also gave up and used the now Open Source Skia. Samsung somehow kept poking at it for a few more years until they dissolved their Open Source division and scaled down Tizen. At some point Samsung make a Vulkan backend for unknown reasons.
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.
> 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...
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!
Agreed, but thats the tragedy of desktop ui development. Either you get pretty but electron app where loading a few hundred messages grinds it to a halt
Or you get ancient looking Ui
Or you get platform spesific stuff!
Actually Java applications are kinda reasonable compromise
> 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)
"Dark mode" is not an innovation. It's a half-assed reversal of a regression.
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.
I fully agree that customization regressed, and it's a pity. However...
>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.
Even more interesting to me, at least, would be a writeup on how the project came to be in the first place. Long-running open-source projects have a (perhaps unfair) reputation for being somewhere between ambivalent and hostile toward proposals for sweeping UX improvements, and it could be instructive to learn how this initiative got off the ground.
There was an interview many years ago, back when I was a student maybe, but I cannot remember where I read it (best guess is Sourceforge "Project of the Month" which used to be a thing back then at least.
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.
I found that video fascinating even though I couldn't really related to any of the tools he was talking about since I've never composed music in the past.
Having actually used Audacity and Photoshop, I'd love to learn a bit more about how those design decisions were made.
I've never composed either, but most of his complaints are not about the specifics of the programmes but about how they fail at communicating them. Repetition, omission, modality, hiding, or over-highlighting, are problems that can crop up in any software, and he's teaching you how those are perceived by users.
Maybe this already happens, but I wish more designers contributed to open source. There are a a lot open source projects that are UX polish away from being viable alternatives to commercial products.
My biggest pet peeve - just allow me to save a .wav file without having me make a project or 'export' it! It would be a huge time saver as I am usually just editing one file at a time, not mixing.
I get it, but on the other hand isn't that a bit like saying "why do I need to print to PDF instead of just save as PDF?" The UI isn't ideal but the feature isn't terribly buried.
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.
im sure youve heard it before, but priority 1 for me is get the playhead scrubbing reset and looping all sorted. something like logic is very intuitive imo. cheers!
There's enough web-only stuff as it is. I'm thankful for everything that does not require a constant internet connection. For instance, I have already used Audacity to edit a radio show while on a train.
Well, take a look at eg theia-ide.org. you can begin use on web and then run locally, either as docker or built from git source project. Web is portable, even offline
I completely understand that people find the UI offputting. But the UI is effective. Or maybe I should say the UX is effective? Either way, an effective UI/UX is more than what a lot of "newer and fancier" UIs have going for them. And since the application is meant as a tool for creators, and not a product facing consumers (as a website might be), personally I can completely forgive a "clunky ui", as long as it is logically laid out and with normal workflows.
Let me be clear, when I say clunky, I mean clunky, not old-fashioned or anything like that. I live in Vim and the terminal. I know perl. I can handle un-shiny UI.
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.
The ideal workflow for that would be keeping open, until dismissed, a noise reduction GUI widget (like the ribbon in Microsoft Office or the side panels in Blender), guaranteeing that you only dig through the menu once per session; then selecting audio (or using an existing audio selection) and stating that it is the source or the noise reference; then apply and undo noise reduction after seeing that both mandatory inputs have been set.
Not rocket surgery, but a very deep UI redesign compared to a dialog box.
Indeed. I think I like Inkscape approach for that: you can just stack whatever you want in panes to the sides of the work area, this way you can keep the often used tools handy and easily swap them in and out as needed. It's fairly intuitive and rather flexible.
It's a traditional approach in image editors (other notable examples include Photoshop, CorelDraw, GIMP, Krita, Pixia, and as remarked in other comments AzPainter) but not in audio editors.
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).
I tend to agree, in a commercial sound control program like IzotopeRX one can set settings on a modal window while keeping the ability to control the main window. Also one can playback all previous states on the fly by clicking on a list of states, because it treats the process as a graph of Fourier states just like Gimp wants to create with GEGL. It is very important as a creator of a program with a complicated flow of tasks to let people feel that solutions are easy to accomplish. Now is Izotope easier as one imports only one track, but even Ardour in many ways is easier to handle than Audacity, and don't get me wrong, I love Audacity for what it does.
I downloaded Audacity for a project to do exactly what you described and it was very clunky. The method I ended up using was cutting the start of the track so the first few seconds were what I wanted to preview, then went through the process to ascertain parameters, remembered them, went back out to revert to the original audio track, then applied noise reduction with the parameters I'd settled on. Did not enjoy, but as you said, hard to pile on too much when you're getting a free ride.
Most audio apps - including CEP - group plugins by function.
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.
IMHO alphabetical is much better if you already know what you want to do. I want to do Noise Reduction, I open the Effects menu and click on Noise Reduction, which I can find very quickly because it's alphabetical and I know the name. If it were sorted by category then I would have to know beforehand not just the name of the effect but also the category it's in, and from experience with other programs it can be pretty arbitrary/subjective/confusing to have to remember the plugin -> category mapping for every plugin I ever use. Otherwise I have to parse a bunch of categories and think "hmm, I wonder if they would put Noise Reduction in here..". Either way it's slower and more of a hassle.
I use and like Audacity, but it really is clunky. Having to use separate "tools" to edit envelopes, move events, etc. is pretty clunky compared to, say, a DAW like ACID or a commercial audio editor like Soundforge. The active regions for hovers, clicks, and drags (e.g. to resize tracks) really need tweaking as well, and the horizontal scroll after a zoom change is also really hard to predict or control.
First impression: I don't know that software, never used it, not sure how it relates to the GP's post. I just felt like commenting.
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, ...
Perfect, exactly what I was thinking, also was reminded of some of the old erp systems that were fast as lightning and supported thousands of users without breaking, a little on the busy side but refreshing to have all the features accessible
I have tried a few times to use it and man is it bizarre and hostile.
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...
SoundForge was quite capable back in the day. It was probably one of my first chances to "remix" works and probably helped shape my worldview (as weird as that sounds. Making music from music was a pleasure and not a 'bad' thing).
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.
To me it looks like the bigger problem is the lack of decent GTK controls for multimedia/music production. A lot of Linux/FOSS software suffers from that limitation, Audacity being just one of them.
To be honest, most Windows based plugins also historically came with their own interface because the stock UI wasn't good/fast/pretty enough for some uses (knobs, waveform display and manipulation, etc) although I believe today it shouldn't be too hard to start the development of a FOSS generic multiplatform widgets kit that doesn't suck for that purpose.
I loved audacity, don't get me wrong, but I don't know why people don't switch to the Fairlight editor embedded in davinci resolve for this. The UI is so much easier to grok.
Thing is, audio editors all have pretty much the same feature set, making the UI the differentiator. For instance, I started using Audacity after Sony ruined SoundForge. If I'm going to need a new set of muscle-memories, might as well change canoes into free software.
But hey, UI is hard and audio processing UIs are probably harder than most.