Audacity is a great tool. It's not a DAW and doesn't try to be one; I find myself using it most when I need to do a quick edit on a sound or make a recording and I'll be done before my DAW would even have started up.
I think the point of the original comment was that, no, it's precisely _not_ that. The functionality isn't super deep, broad, nuanced, or customizable - but it is enough to get _most_ jobs done.
> The functionality isn't super deep, broad, nuanced, or customizable
Having used Audacity quite a bit, my impression is the exact opposite. Indeed, those traits are exactly why Audacity's UI is currently as "clunky" as it is: because there's a veritable smörgåsbord of features that need encapsulated.
"Audacity is the GIMP of audio" is perfectly accurate in this regard. But GIMP ain't Inkscape, and Audacity ain't Ardour.
> "Audacity is the GIMP of audio" is perfectly accurate in this regard.
This statement brings back a fond memory for me. I was first introduced to open-source software in the late 90s, when I was in high school. GIMP was one of the best known and most popular pieces of open-source software at the time. At the time there wasn't really an equivalent open-source equivalent for audio that was nearly as feature rich or popular.
I remember coming across some programmers around that time who were trying to write "GIMP for audio" -- they called it GWAMP (Gnu Wave Audio Manipulation Program) -- but it never really took off.
Then a few years later, when I was in college, I came across a programmer named Dominic Mazzoni who was working on this pre-1.0 program he called Audacity. It was still in the early stages, and didn't have anyone else working on it except his PhD advisor who had written a lot of the DSP code. Dominic and I hit it off, and I spent a lot of my college free time hacking on it, as other contributors started joining the effort too. And then it went on to succeed beyond my wildest dreams (thanks mostly to Dominic and others -- I was just in the right place at the right time).
If you had told me in the 90s that I'd have a chance to get in on the ground floor of a program that, 20 years later, was still being called the "GIMP of audio", it would have sounded too good to be true.
I'm pretty sure all of the songs I recorded in high school are gone forever, since I only backed up the Audacity files and not the entire folder. Perhaps this is for the best, but either way I'm glad future emo teens will have an easier time preserving their work.
My wife did the exact same thing in transferring the files between her computer and mine. This is one thing that could definitely be made a lot better.
Thanks Audacity team and contributors! I love to see major releases from tools I've been using for decades. So dependable, always ready to save my bacon when I need it.
Interesting that they decided to change the project format from bag of files to single file. I certainly remember when I was new to computers and I was using some software and brought only the project file with me to a friend and didn’t know I had to bring the source files also. But after the first time of making that mistake I learned from it. Personally I still like the bag of files approach for music and video projects because it keeps the source files accessible and I use a few different pieces of software and don’t want my source files locked into a project files (even when it’s a SQLite based approach like Audacity 3). And for me personally I don’t want to duplicate files on my local storage medium either.
But I can see how it will be helpful to users in general.
macOS has a really interesting feature that allows bag of files to appear like a single file to users but it’s actually just a directory and you can still access the files inside by opening it as a directory. Of course that doesn’t help for cross platform software though, as on other platforms you will still only see it as the bag of files that it really is.
I used to have problems with running out of file descriptors on MacOS, and I recall that the maximum number was 256. I was wondering if this package abstraction could be used to work around it.
But then I checked `ulimit -a` and it looks like on Big Sur the max is now 2560. Progress!
Huh. It looks like "package" is the more general type and "bundle" is a more specific format. Even if "bundle" is what you were thinking of, it looks to me like the high-level description you gave matches "package"!
But I struggle to understand the criteria that a "package" must satisfy to qualify as a "bundle". According to your second link a bundle is "A directory with an internal structure specified by Core Foundation Bundle Services." So there's a finite list of bundle file types, maybe?
Thanks for the validation, and I learned something useful tonight! I'd discovered accidentally how to traverse those pseudo-directories, both in the terminal and the finder. Now I know what's actually going on!
I wonder: Is it like the new Office formats, where it's actually a zipped bundle? In this case, maybe they just zipped up all the files they already had and saved a lot of reimplementation in other parts of the system.
Right, but the individual rows in that SQLite3 database could indeed be entire files, which is what I think the GP was getting at. Basically: using SQLite as if it were an archive format, with file data stored as BLOB-typed columns (and possibly other columns for various metadata).
Whether Audacity is actually doing this, I don't know.
> We also fixed over 160 bugs that had been accumulating over the years.
This is good news indeed. Previous versions of Audacity are so buggy that they're barely usable. Version 2.4.2 crashed more often than not when I used it.
That doesn't seem fair. I used Audacity a lot for all kinds of things over the years, (most recently 2.3.3 on a Mac) and it never crashed or even behaved weirdly.
I've used Audacity from time to time over the past 15 years or so. I've had so many bad experiences with it that I try to use alternatives whenever reasonable. I've used it on Macintosh, Windows, and Linux on different hardware configurations. It's the only piece of software that has ever physically hurt me, to my knowledge (on some platforms it adjusts system volume without warning).
It's been buggy as hell and I've had some profoundly negative experiences using it.
Doesn't seem fair because "Previous versions of Audacity are so buggy that they're barely usable." isn't true. Sounds like it was true for you, but not most other people. Otherwise it wouldn't be so popular, would it. I've never noticed a bug using it. Maybe you're doing particular things with it that I never tried to do, like I never used most of the effects.
I am tired of having people tell me that my criticisms of Audacity are invalid or unfounded. “Audacity is fine, you must be using it wrong,” is what I’m hearing here. I’ve heard it before.
Last time I used Audacity, it was version 2.4.2, which is the previous version before 3.0. It adjusted the system volume against my wishes, worked for about five minutes, and crashed. I gave it another shot—tried running it again, but it crashed again fairly quickly. I have no fucking clue what I could possibly be doing wrong. I was not trying to make it crash, I didn’t think I was doing anything unusual. No esoteric formats, no bizarre hardware configurations, no plugins.
When you make comments like that, I feel like my concerns are just being dismissed as invalid. The argument that Audacity is popular and therefore it must not be buggy makes no sense to me. People will use buggy software if they still get work done.
> I am tired of having people tell me that my criticisms of Audacity are invalid or unfounded.
Firstly, I'm mildly sorry to hear that, but I don't know you, and whether you are tired or not and about what...seems none of my business. Nothing personal: "I am tired of.." doesn't seem a good start to a comment on HN.
"Audacity is popular and therefore it must not be buggy" is not remotely my argument. You talk as if everyone using it experiences bugs very frequently – "so buggy [it's] barely usable" – which isn't at all true, in my experience. (My anecdata seems relevant, when someone talks as if claiming everyone had experience X, and I had the opposite.)
Maybe if you restrain yourself to talking about your experience, instead of talking as if everyone must have that same experience, you wouldn't get "tired of having people tell me that my criticisms of Audacity are invalid".
"Previous versions of Audacity are so buggy that they're barely usable" strikes me as ridiculous. Because it sounds like you are trying to speak on behalf of every user. I'm sorry you had so many problems with Audacity. I hope it's ok for me to say that I never had any, and never heard of any, until reading your words, although I'm not an expert. Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
> You talk as if everyone using it experiences bugs very frequently…
I said that it crashed “when I used it”. I thought that was enough to make it explicit that I was talking about my own experiences—but I don’t think that should be necessary.
Just like when you talk about how Audacity doesn’t crash when you use it, I know you’re talking about your experiences, and not anyone else’s.
> Because it sounds like you are trying to speak on behalf of every user.
That interpretation is incorrect.
> Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
What you said is that my criticisms didn’t seem “fair”. I do a lot of software development—it’s my job—and when a piece of software I write works for user X and crashes for user Y, my conclusion is usually “my software is buggy”. If user Y complains that my software is buggy, I would consider their complaints completely valid and want to fix it—and it looks like the Audacity team has made some great strides fixing bugs that don’t affect everyone equally—which is a very typical experience when fixing bugs.
To quote the release notes for version 3.0, “Some [bugs] though were really juicy high priority bugs that would have mattered a lot to the people affected by them.” It sounds like the Audacity team, at the very least, were aware that some users had very negative experiences with the software and I’m glad that they’re making stability a priority.
I was taking a zoom class and they released some youtube videos in which the vocabulary words were pronounced by a native speaker. I downloaded Audacity, grabbed the youtube video with python's youtube downloader, and was able to splice up the recording into individual vocab words and put them on my Anki cards.
So Audacity helped me to learn a foreign language. Thanks!
Audacity is a great project and I’m very glad it exists.
Personally I only need pretty basic wave editing and am happy with OcenAudio (https://ocenaudio.com - free but closed source), it’s the closest thing I’ve found to Cool Edit 2000 (which I still think is the best wave editor ever!) and has quite a nice UI.
I tried it out a while back and it felt really heavyweight for what I needed (often just trim, normalise, export)... so I’m happy with a lightweight, fast wave editor, then I do anything more involved in a DAW. Thanks for the recommendation though!
Very pleased that Audacity is still actively developed. I said it before but I think this can't be overstated:
Audacity may had some quirks over the years but it's still one of the most (if not the most) accessible tool for audio editing by non-professionals with an adequate feature set. It's used by community radio stations all over the world since it's easy to teach and cross-platform while being free.
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.
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.
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 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.
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).
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.
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.
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'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)
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.
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.
"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.
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!
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.
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'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.
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.
(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 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.
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.)
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.
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!
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.
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.
Well, their changes have to be accepted. A lot of established contributors to (and users of) these open-source projects are belligerent apologists for their shitty UI.
But really, you find that in any forum. People get bent out of shape that you're pointing out flaws in their pet product, and pile on with claims that amount to, essentially, "you're holding it wrong."
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
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.
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.
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.
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.
Audacity has a chapter in the "Architecture of Open Source Applications" book ( https://aosabook.org/en/audacity.html ). It is a nice read to understand the internals of the application and some of the technical challenges the have confronted.
The main lesson I learned from that chapter was the importance of a clear plugin interface. Especially for software used by people with different needs. This avoids a lot of pull requests into the main code that are unlikely to be maintained.
You've used the term plugin interface, but would API be a better fit? Have an API that exposes everything a user would need to see in the UI. Then whatever knob/button/fader/etc can call the same APIs to interact with the data. At that point, you could have a UI on a tablet calling a more powerful laptop/desktop install doing the lifting and connected to monitors/etc.
To me, plugins are something that provides additional functionality to the native abilities of the program.
When speaking about audio software, people saying plugins do usually mean adding native functionality - plugin formats like VST are implemented as shared libraries that can be called by the host application's hot codepaths (because they are often doing latency sensitive things like processing audio streams). Audacity supports VSTs, AU, and several other major formats for audio processing / instruments, as well as its own proprietary module format.
That said, an API around the UI would be great. A lot of commercial audio platforms have moved in this direction, iPad control of commercial mixing consoles and effects processors is common in the industry now. I'd love to see PC-based audio applications go down the same path.
> To me, plugins are something that provides additional functionality to the native abilities of the program.
That's what audacity plugins do? I think the most important distinction of a "plugin" is that it can be created, distributed, and installed with no modification or recompile of the Audacity source. Therefore, plugins are relatively easy to use for non-technical users, and can be mixed together with a low fear of conflict. Two separate programs that consume an API, on the other hand, cannot usually be mixed together if both are needed.
Audacity is up there for me with those open source projects that deserve to go into some form of OSS Hall of Fame.
Audacity, VLC, Blender, KeePass, Inkscape, OBS, etc (there's many more but those are the ones I use regularly). Programs that have been around forever, are used by millions every day, and yet continue to do it (and do it damn well) just because they want to.
Absolutely. I cleaned (removed cursing) more hip hop tracks than I care to remember with the highlight/reverse in Audacity. There is no other program that allowed me to do this so simply and efficiently.
I think audacity might be a good candidate for breaking some "no, that doesn't usually work" rules.
Baby Mode - I know this has a history of sucking, but a lot of audacities UI complaints are from users who need one small thing once in a while.
Less "G" in the GUI. Audacity is a whole bunch of hard to group commands. Maybe they should just bite the bullet, and incorporate some 80s-ish text navigation UI elements. People are googling "how do I X" anyway.
I use it to view time-series data from my homemade ECG logger, to debug whether my heart is beating. All the built in analysis tools are fun to play with, too. It's mildly disappointing that it doesn't really sound like much of anything when played through a speaker.
When I was working in college radio we used to build quick liners and sweeps in Audacity instead of loading up the heavier programs (I can't remember what they were now actually - maybe Nexgen?) for editing and mixing.
You're right. I didn't meant to say that Audacity isn't for professionals. But in my experience most audio professional (like audio engineers) pick (or get picked by their educational institution) a tool early in their career and stick to it. Most of the times this tool is a full-fledged DAW in which they acquire quite a muscle memory. So switching tools later (even for simple tasks, which don't require a DAW) comes with a big "performance hit".
Audacity is a wonderful piece of software - I've used it in a lot of projects for mastering/tweaking sound-effects. And it's come a very long way in terms of stability. Long may it continue to thrive :)
Audacity is an awesome project. I know a LOT of non technical people with no affinity to open source who are using it. I think a UI refresh to something modern looking will help it increase its popularity even more, I hope they find someone to help with this.
Fantastic. Audacity keeps it simple and does it well, if there was ever a hall of fame of applications, Audacity deserves a spot. Heck, if I were to distribute any kind of "creative suite", I would always include Audacity, no matter what operating system I was targeting. It is a near essential tool for working with audio, daily, or every now and then.
The genius of the application is that it does not try to be more than a waveform editor. Oftentimes, no matter if you are new to audio production or a veteran audio technician, you just need to edit some sound, and Audacity lets you get it done in a easy enough way for newbies, and in a complex enough way for veterans.
Maintainers of projects like these should carry themselves with pride. Projects that stand the test of time and continue to deliver exactly what you needed is what makes the IT-world go around.
While I use Logic for making "real" audio, Audacity is great for those other audio tasks. For example, I used Audacity's "Import Raw Data" feature to open a dd image of a USB drive to recover corrupted audio FTW!
Interesting, I guess this only works to recover uncompressed wav files where you know the sample frequency and bit depth? Or does it read the wav headers when it finds them or something?
Yes you are correct! My 12 channel mixer (Behringer X12) allows you to plug in a USB disk and record the output. But somebody turned off the mixer while it was recording, which meant that lots of bits of data were written, but the WAV file header was never updated with the size of the file.
So I did another recording to determine the frequency & bit depth, and then opened the dd disk image with those settings. It was pretty obvious from the waveform image which parts of the drive had the recording, and it was perfect.
Interestingly, I got those settings completely wrong at the start, and I could still tell it was music by listening to it, it was just very corrupted sounding!
Audacity is an example that being good enough is enough. It probably doesn't competes against industry giants, but considering its simplicity and license, it is probably the most used audio editor in use today.
Congrats audaciteam!
Disclaimer: I was a contributor a long time ago to the noise filter effect.
226 comments
[ 3.1 ms ] story [ 251 ms ] threadHaving used Audacity quite a bit, my impression is the exact opposite. Indeed, those traits are exactly why Audacity's UI is currently as "clunky" as it is: because there's a veritable smörgåsbord of features that need encapsulated.
"Audacity is the GIMP of audio" is perfectly accurate in this regard. But GIMP ain't Inkscape, and Audacity ain't Ardour.
This statement brings back a fond memory for me. I was first introduced to open-source software in the late 90s, when I was in high school. GIMP was one of the best known and most popular pieces of open-source software at the time. At the time there wasn't really an equivalent open-source equivalent for audio that was nearly as feature rich or popular.
I remember coming across some programmers around that time who were trying to write "GIMP for audio" -- they called it GWAMP (Gnu Wave Audio Manipulation Program) -- but it never really took off.
Then a few years later, when I was in college, I came across a programmer named Dominic Mazzoni who was working on this pre-1.0 program he called Audacity. It was still in the early stages, and didn't have anyone else working on it except his PhD advisor who had written a lot of the DSP code. Dominic and I hit it off, and I spent a lot of my college free time hacking on it, as other contributors started joining the effort too. And then it went on to succeed beyond my wildest dreams (thanks mostly to Dominic and others -- I was just in the right place at the right time).
If you had told me in the 90s that I'd have a chance to get in on the ground floor of a program that, 20 years later, was still being called the "GIMP of audio", it would have sounded too good to be true.
Thanks Audacity, for an excellent tool!
But I can see how it will be helpful to users in general.
macOS has a really interesting feature that allows bag of files to appear like a single file to users but it’s actually just a directory and you can still access the files inside by opening it as a directory. Of course that doesn’t help for cross platform software though, as on other platforms you will still only see it as the bag of files that it really is.
I think this is what you're referring to:
https://en.wikipedia.org/wiki/Package_(macOS)
I used to have problems with running out of file descriptors on MacOS, and I recall that the maximum number was 256. I was wondering if this package abstraction could be used to work around it.
But then I checked `ulimit -a` and it looks like on Big Sur the max is now 2560. Progress!
E.g.:
Almost. I was actually referring to https://en.wikipedia.org/wiki/Bundle_(macOS) which is the same concept.
See also https://developer.apple.com/library/archive/documentation/Mi...
But I struggle to understand the criteria that a "package" must satisfy to qualify as a "bundle". According to your second link a bundle is "A directory with an internal structure specified by Core Foundation Bundle Services." So there's a finite list of bundle file types, maybe?
No, third party software can define bundles too.
Fine. I tracked down the relevant official documentation:
https://developer.apple.com/library/archive/documentation/Co...
> • A package is any directory that the Finder presents to the user as if it were a single file.
> • A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.
[...]
> The Finder considers a directory to be a package if any of the following conditions are true:
> • The directory has a known filename extension: .app, .bundle, .framework, .plugin, .kext, and so on.
> • The directory has an extension that some other application claims represents a package type; see Document Packages.
> • The directory has its package bit set.
Whether Audacity is actually doing this, I don't know.
This is good news indeed. Previous versions of Audacity are so buggy that they're barely usable. Version 2.4.2 crashed more often than not when I used it.
I've used Audacity from time to time over the past 15 years or so. I've had so many bad experiences with it that I try to use alternatives whenever reasonable. I've used it on Macintosh, Windows, and Linux on different hardware configurations. It's the only piece of software that has ever physically hurt me, to my knowledge (on some platforms it adjusts system volume without warning).
It's been buggy as hell and I've had some profoundly negative experiences using it.
Last time I used Audacity, it was version 2.4.2, which is the previous version before 3.0. It adjusted the system volume against my wishes, worked for about five minutes, and crashed. I gave it another shot—tried running it again, but it crashed again fairly quickly. I have no fucking clue what I could possibly be doing wrong. I was not trying to make it crash, I didn’t think I was doing anything unusual. No esoteric formats, no bizarre hardware configurations, no plugins.
When you make comments like that, I feel like my concerns are just being dismissed as invalid. The argument that Audacity is popular and therefore it must not be buggy makes no sense to me. People will use buggy software if they still get work done.
Firstly, I'm mildly sorry to hear that, but I don't know you, and whether you are tired or not and about what...seems none of my business. Nothing personal: "I am tired of.." doesn't seem a good start to a comment on HN.
"Audacity is popular and therefore it must not be buggy" is not remotely my argument. You talk as if everyone using it experiences bugs very frequently – "so buggy [it's] barely usable" – which isn't at all true, in my experience. (My anecdata seems relevant, when someone talks as if claiming everyone had experience X, and I had the opposite.)
Maybe if you restrain yourself to talking about your experience, instead of talking as if everyone must have that same experience, you wouldn't get "tired of having people tell me that my criticisms of Audacity are invalid".
"Previous versions of Audacity are so buggy that they're barely usable" strikes me as ridiculous. Because it sounds like you are trying to speak on behalf of every user. I'm sorry you had so many problems with Audacity. I hope it's ok for me to say that I never had any, and never heard of any, until reading your words, although I'm not an expert. Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
I said that it crashed “when I used it”. I thought that was enough to make it explicit that I was talking about my own experiences—but I don’t think that should be necessary.
Just like when you talk about how Audacity doesn’t crash when you use it, I know you’re talking about your experiences, and not anyone else’s.
> Because it sounds like you are trying to speak on behalf of every user.
That interpretation is incorrect.
> Maybe it's hard for you to believe I used it for years and never had one problem. It does seem like you can't really hear what I'm saying.
What you said is that my criticisms didn’t seem “fair”. I do a lot of software development—it’s my job—and when a piece of software I write works for user X and crashes for user Y, my conclusion is usually “my software is buggy”. If user Y complains that my software is buggy, I would consider their complaints completely valid and want to fix it—and it looks like the Audacity team has made some great strides fixing bugs that don’t affect everyone equally—which is a very typical experience when fixing bugs.
To quote the release notes for version 3.0, “Some [bugs] though were really juicy high priority bugs that would have mattered a lot to the people affected by them.” It sounds like the Audacity team, at the very least, were aware that some users had very negative experiences with the software and I’m glad that they’re making stability a priority.
So Audacity helped me to learn a foreign language. Thanks!
There's a section that references .aup files, see 2.6. BlockFiles (Audacity 3.0.0 introduces the .aup3 file format)
The most memorable parts of this to me was wXWidgets. Here's ShuttleGUI:
https://github.com/audacity/audacity/blob/master/src/Shuttle...
[0] https://en.flossmanuals.net/audacity/_full/
[1] https://en.flossmanuals.net/audacity/_info/
[PDF] https://flossmanuals.net/pub/audacity-en-2018.02.pdf
[EPub] https://flossmanuals.net/pub/audacity-en-2018.02.epub
Personally I only need pretty basic wave editing and am happy with OcenAudio (https://ocenaudio.com - free but closed source), it’s the closest thing I’ve found to Cool Edit 2000 (which I still think is the best wave editor ever!) and has quite a nice UI.
Audacity may had some quirks over the years but it's still one of the most (if not the most) accessible tool for audio editing by non-professionals with an adequate feature set. It's used by community radio stations all over the world since it's easy to teach and cross-platform while being free.
But hey, UI is hard and audio processing UIs are probably harder than most.
[0] https://git.io/azpainter
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...
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.
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.
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).
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)
Having actually used Audacity and Photoshop, I'd love to learn a bit more about how those design decisions were made.
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.
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.
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 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.
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.
> 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.
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!
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.
But really, you find that in any forum. People get bent out of shape that you're pointing out flaws in their pet product, and pile on with claims that amount to, essentially, "you're holding it wrong."
Maybe a custom config profile that is very easy to tune, import and export would allow redesign to get radical without compromising old users
https://www.ocenaudio.com/
https://www.blackmagicdesign.com/products/davinciresolve/fai...
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, plugins are something that provides additional functionality to the native abilities of the program.
That said, an API around the UI would be great. A lot of commercial audio platforms have moved in this direction, iPad control of commercial mixing consoles and effects processors is common in the industry now. I'd love to see PC-based audio applications go down the same path.
That's what audacity plugins do? I think the most important distinction of a "plugin" is that it can be created, distributed, and installed with no modification or recompile of the Audacity source. Therefore, plugins are relatively easy to use for non-technical users, and can be mixed together with a low fear of conflict. Two separate programs that consume an API, on the other hand, cannot usually be mixed together if both are needed.
https://jspaint.app
(& github: https://github.com/1j01/jspaint )
Audacity, VLC, Blender, KeePass, Inkscape, OBS, etc (there's many more but those are the ones I use regularly). Programs that have been around forever, are used by millions every day, and yet continue to do it (and do it damn well) just because they want to.
For the clients, 2.x uses KDBX files, but is also compatible with the older KDB files, while 1.x can only use the older KDB files.
Baby Mode - I know this has a history of sucking, but a lot of audacities UI complaints are from users who need one small thing once in a while.
Less "G" in the GUI. Audacity is a whole bunch of hard to group commands. Maybe they should just bite the bullet, and incorporate some 80s-ish text navigation UI elements. People are googling "how do I X" anyway.
When I was working in college radio we used to build quick liners and sweeps in Audacity instead of loading up the heavier programs (I can't remember what they were now actually - maybe Nexgen?) for editing and mixing.
> The Blender & Audacity add-on playing both apps in sync - without Jack - so you can edit sound in Audacity and using Blender as video player
[0] https://github.com/tin2tin/audacity_tools_for_blender/
[1] https://twitter.com/tintwotin/status/1371885605735530500
[2] https://www.youtube.com/watch?v=f61Zvb8AipA
It took me some time to remember to avoid it.
I do luvs me Audacity, though.
Good show!
[0] https://twitter.com/FossTorrents/status/1372176177708818433
[1] https://fosstorrents.com/softwares/audio/audacity/
The genius of the application is that it does not try to be more than a waveform editor. Oftentimes, no matter if you are new to audio production or a veteran audio technician, you just need to edit some sound, and Audacity lets you get it done in a easy enough way for newbies, and in a complex enough way for veterans.
Maintainers of projects like these should carry themselves with pride. Projects that stand the test of time and continue to deliver exactly what you needed is what makes the IT-world go around.
Well done.
Its great to have an array of these tools provided for free
[0] https://kdenlive.org/en/
Audacity 2.2.0 Released - https://news.ycombinator.com/item?id=15621681 - Nov 2017 (146 comments)
The Future of Audacity, Interview with the Team - https://news.ycombinator.com/item?id=9392035 - April 2015 (28 comments)
Removing background noise in Audacity by differencing stereo channels - https://news.ycombinator.com/item?id=6158058 - Aug 2013 (13 comments)
Audacity 2.0 Released - https://news.ycombinator.com/item?id=3714766 - March 2012 (63 comments)
Learning a new language with Audacity - https://news.ycombinator.com/item?id=2962284 - Sept 2011 (9 comments)
So I did another recording to determine the frequency & bit depth, and then opened the dd disk image with those settings. It was pretty obvious from the waveform image which parts of the drive had the recording, and it was perfect.
Interestingly, I got those settings completely wrong at the start, and I could still tell it was music by listening to it, it was just very corrupted sounding!
Congrats audaciteam!
Disclaimer: I was a contributor a long time ago to the noise filter effect.