Audacity 3.0(audacityteam.org)
audacityteam.org
Audacity 3.0
https://www.audacityteam.org/audacity-3-0-0-released/
226 comments
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.
But hey, UI is hard and audio processing UIs are probably harder than most.
I’m working with the Audacity dev team on a redesign of the UI/UX. More on this soon!
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 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
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
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.
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.
> 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.
You can directly reply by clicking the timestamp ("1 hour ago") on the comment you want to reply to.
Yes, it's poor UI.
Yes, it's poor UI.
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.
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.
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.)
Where did you find an OpenGL render backend in GTK2/3?
https://www.cairographics.org/backends/
GTK -> GDK -> Cairo -> OpenGL
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.
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.
Over a cliff?
> 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!
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!
Ha, that one has been bugging me for ages but I never realized it was due to HiDPI! Suddenly it all makes sense.
Correction: I turned off HiDPI and it still happens... wow this is worse than I expected.
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
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.
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.
Material Design .NET applications okay?
Wow, that's awesome news!
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'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've been designing a complex desktop application.. there's not that much info out there. I found these helpful:
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.
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.
Thanks for sharing those links. The win95 design was a great read, a proper data driven approach to user experience.
"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.
That's not innovation. It's pathetic.
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.
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.
>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.
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 feel like changing an array to a linked list couldn't be that hard, but I don't know the particular complications.
Exactly, and neither do I, I have mostly worked on Java and and with IDEs that would tell me in a nice way if what I did didn't make sense.
You could volunteer ...
Even a short design rationale would be fascinating.
[deleted]
I think you should check out Tentacruel’s videos on YouTube about the UX of music composing suites!
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.
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.
*Tantacrul
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.
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.
Preferences -> Keyboard -> Assign keybind to "Export as WAV"
It's still called an export, but it's basically doing exactly what you're asking for.
It's still called an export, but it's basically doing exactly what you're asking for.
Please be gentle for those of us who've grown accustomed to the UI thus far along the journey.
Exactly, a lot of pro users depend on this swiss army knife and they had to get used to work around it's peculiar UI.
Maybe a custom config profile that is very easy to tune, import and export would allow redesign to get radical without compromising old users
Maybe a custom config profile that is very easy to tune, import and export would allow redesign to get radical without compromising old users
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!
I also really like how intuitive looping is in Logic. They’ve done many things right - been a happy user since the Emagic days
This is fantastic news!
That's really exciting
Please get them to add MMC sync, it would make recording much better
Please consider web first!
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.
And then when there's no internet in the studio you're stuck? Ehh
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.
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.
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 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).
[deleted]
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.
An ultrafast, pipe-able, set of Unix philosophy audio tools with a CLI interface would be great
Like... sox?
If sox could show you the waveform you're cutting.
Sox is beautiful and way faster than GUIs (first comment ever!)
Same workflow for that operation as "CoolEdit Pro" before it.
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.
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 feel as though early 2000s was the peak of UI, they took peak performance and made it look good enough
What about AzPainter[0] UI?
[0] https://git.io/azpainter
[0] https://git.io/azpainter
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
The AzPainter screenshot is meant to showcase as many tools as possible. For real usage, most of them would be folded away or completely hidden.
Looks similar to the Corel interfaces, which were nigh-unusable if you were used to Adobe.
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, ...
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, ...
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.
[deleted]
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 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).
> but man the UI is really really clunky.
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.
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.
https://www.blackmagicdesign.com/products/davinciresolve/fai...
https://www.blackmagicdesign.com/products/davinciresolve/fai...
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.
Last time I checked, Audacity Portable had a better UI than the regular version, so you might want to try that.
For most of the things Audacity does, Ocenaudio does them in a less clunky way:
https://www.ocenaudio.com/
https://www.ocenaudio.com/
Doesn't seem to be open source, though.
maybe the hardest, but audio softwares tend to have the most innovative designs I've ever seen. (Ableton, Fruity Loops, etc)
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.
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.
With keepass, I always get confused in all the versions and how much are they compatible :(
Basically there's 2 versions of the database file, the old (KDB) and the new (KDBX) which has more features/fields/etc.
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.
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.
I'm just here to say thank you for Audacity. It's a fantastic tool.
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.
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.
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.
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.
"MS Paint for sound"
I'll agree the day MS Paint becomes multiplatform and FLOSS.
[deleted]
I agree, but that wouldn't be so pithy would it? :)
Does this count?
https://jspaint.app
(& github: https://github.com/1j01/jspaint )
https://jspaint.app
(& github: https://github.com/1j01/jspaint )
If we should compare it to any other successful FLOSS project it should be good ol' GIMP
[deleted]
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.
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.
Key combos rock. Not sexy, but are fast, easy to learn, and given a search index, fairly discoverable.
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.
Not just non-professionals, but pros too.
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.
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".
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.
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.
yup, vscode, blender, audacity, gimp, inkscape and openshot running on linux can get you very far for basically 0 software cost.
Its great to have an array of these tools provided for free
Its great to have an array of these tools provided for free
While I'm not using linux it really is amazing how far FOSS can take you. I haven't used openshot but can definitely vouch for kdenlive[0]
[0] https://kdenlive.org/en/
[0] https://kdenlive.org/en/
Entirely seconded. What people really need is there, works, is just not a big deal to get done.
Well done.
Well done.
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.
Maximum emo-ness: the darkness in these songs is so irredeemable that even the project file couldn't save them.
I have to commend Audacity for making a tool so easy to use that regular (but technical) folks can use it with no prior recording experience. It being cross platform and runnable on so many devices due to low hardware requirements is a big perk too.
I've recorded 70+ episodes of the Running in Production podcast[0] and to get the highest quality audio I can for the show I ask guests to locally record their side of the conversation with Audacity while I do the same on my end. Then we talk in real-time over Zoom to have the actual conversation.
Out of 70+ episodes there hasn't been a single case where something went wrong due to Audacity. These are shows where we're continuously recording for 60-90 minutes too.
All I ended up doing was write up a quick guide. Basically how to download it, making sure your "good" mic is selected and doing a test recording. No one has ever complained that the process was too involved or hard to follow. Most folks get set up in less than 2 minutes with no assistance and most guests have never recorded audio before.
[0]: https://runninginproduction.com/
I've recorded 70+ episodes of the Running in Production podcast[0] and to get the highest quality audio I can for the show I ask guests to locally record their side of the conversation with Audacity while I do the same on my end. Then we talk in real-time over Zoom to have the actual conversation.
Out of 70+ episodes there hasn't been a single case where something went wrong due to Audacity. These are shows where we're continuously recording for 60-90 minutes too.
All I ended up doing was write up a quick guide. Basically how to download it, making sure your "good" mic is selected and doing a test recording. No one has ever complained that the process was too involved or hard to follow. Most folks get set up in less than 2 minutes with no assistance and most guests have never recorded audio before.
[0]: https://runninginproduction.com/
> I ask guests to locally record their side of the conversation with Audacity while I do the same on my end.
That's so simple and so obvious that I'll punish myself 1000 years for not having thought about it :-)
That's so simple and so obvious that I'll punish myself 1000 years for not having thought about it :-)
Hah, what were you doing before?
I thought about using 1 of many online services for this but they all came with very big warnings and potential issues like audio drift (tracks get more and more out of sync as time goes on), garbled quality or worse. It ultimately boiled down to not feeling like I could trust any of these services.
I thought about using 1 of many online services for this but they all came with very big warnings and potential issues like audio drift (tracks get more and more out of sync as time goes on), garbled quality or worse. It ultimately boiled down to not feeling like I could trust any of these services.
Would you be able to share a copy of the guide?
Sure, it's all text based that I send in an email. The Audacity specific part of the guide is:
---
3. Locally recording our own individual audio tracks
Programs like Zoom and Google Hangouts are great for talking in real-time but their audio quality is extremely low for a podcast.
So we'll be recording our own individual audio tracks. Basically that means you'll want to download a tool so that you can press record on your own computer, record your side of things and then be in a position to send me the exported result of that. Then I'll combine our tracks together in the end.
Don't worry, we'll do an audio test and double check things together on the call to make sure things are set up properly before we hit record.
If you're not already familiar with tools to locally record your own audio track you can try using https://www.audacityteam.org/. It's free, open source and works on all major platforms. It's a fantastic tool.
After starting Audacity there will be a drop down box near the top of the toolbar where you can select your microphone. If you have multiple microphones please make sure your best microphone is selected.
macOS and Linux users can use the defaults for everything else. If you're on Windows there is a drop down box that says MME to the left of where you pick your microphone. You should change that to Windows WASAPI to ensure you get good quality audio.
Next up you can try recording yourself a few times to get the hang of the program. You can do that by pressing the big red button. After doing so when you speak into your microphone you should see a bunch of blue bars and lines scroll across your screen. That's good! It means your microphone is picking up your voice.
You can confirm if things recorded properly by pressing stop and then playing back your recording. You should hear yourself loud and clear. If you can't then make sure your headphones or speakers are selected in the drop down box to the right of your mic.
If you want to send me a sample that would be fine, but you don't have to.
After we finish our call, it will be very important to stop the recording, save the project and then export it to both wav and mp3 files (just to be safe). You can do that by going to the File menu and then picking Save Project -> Save Project. You can save it anywhere you want.
That will ensure your recording gets saved in case something catastrophic happens while exporting the files, such as the power going out or Audacity crashing for whatever reason.
Lastly, you'll want to do a File -> Export and then choose wav. Once that finishes you'll want to do the same thing for mp3. The default settings are fine.
Keep in mind the recording will be roughly 60 minutes long when we do it for real which will take up about 400-500 MB of disk space, so make sure you have at least 1 GB of space to be safe before recording.
---
3. Locally recording our own individual audio tracks
Programs like Zoom and Google Hangouts are great for talking in real-time but their audio quality is extremely low for a podcast.
So we'll be recording our own individual audio tracks. Basically that means you'll want to download a tool so that you can press record on your own computer, record your side of things and then be in a position to send me the exported result of that. Then I'll combine our tracks together in the end.
Don't worry, we'll do an audio test and double check things together on the call to make sure things are set up properly before we hit record.
If you're not already familiar with tools to locally record your own audio track you can try using https://www.audacityteam.org/. It's free, open source and works on all major platforms. It's a fantastic tool.
After starting Audacity there will be a drop down box near the top of the toolbar where you can select your microphone. If you have multiple microphones please make sure your best microphone is selected.
macOS and Linux users can use the defaults for everything else. If you're on Windows there is a drop down box that says MME to the left of where you pick your microphone. You should change that to Windows WASAPI to ensure you get good quality audio.
Next up you can try recording yourself a few times to get the hang of the program. You can do that by pressing the big red button. After doing so when you speak into your microphone you should see a bunch of blue bars and lines scroll across your screen. That's good! It means your microphone is picking up your voice.
You can confirm if things recorded properly by pressing stop and then playing back your recording. You should hear yourself loud and clear. If you can't then make sure your headphones or speakers are selected in the drop down box to the right of your mic.
If you want to send me a sample that would be fine, but you don't have to.
After we finish our call, it will be very important to stop the recording, save the project and then export it to both wav and mp3 files (just to be safe). You can do that by going to the File menu and then picking Save Project -> Save Project. You can save it anywhere you want.
That will ensure your recording gets saved in case something catastrophic happens while exporting the files, such as the power going out or Audacity crashing for whatever reason.
Lastly, you'll want to do a File -> Export and then choose wav. Once that finishes you'll want to do the same thing for mp3. The default settings are fine.
Keep in mind the recording will be roughly 60 minutes long when we do it for real which will take up about 400-500 MB of disk space, so make sure you have at least 1 GB of space to be safe before recording.
Have you considered using Jamulus[0] for both talking in realtime and recording high quality audio? Jamulus server supports recording separate tracks to Reaper and Audacity projects. I suspect it will be easier for your guests to set up. Using Audacity is probably a better option unless something goes wrong for any of the guests. Using Jamulus will minimize the room for error.
I've also written an extensive guide for getting the best possible results with recording speech: "Voice recording and processing for talks, streaming and conferencing"[1]. Hope it can be of use.
0. https://jamulus.io
1. https://indiscipline.github.io/post/voice-sound-reference/
I've also written an extensive guide for getting the best possible results with recording speech: "Voice recording and processing for talks, streaming and conferencing"[1]. Hope it can be of use.
0. https://jamulus.io
1. https://indiscipline.github.io/post/voice-sound-reference/
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!
So Audacity helped me to learn a foreign language. Thanks!
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.
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.
> macOS has a really interesting feature that allows bag of files to appear like a single file
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!
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!
> I think this is what you're referring to
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...
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...
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?
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?
> So there's a finite list of bundle file types, maybe?
No, third party software can define bundles too.
No, third party software can define bundles too.
LOL. "Wrong!" "Wrong again!" "Still wrong!"
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.
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.
Ah, you were right and it was actually packages I was thinking of after all. Thank you and sorry.
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!
The wikipedia article does not mention the most common example -- .app "files"/bundles.
E.g.:
E.g.:
zsh% ls Applications/Firefox.app/Contents
CodeResources Library PkgInfo _CodeSignature
Info.plist MacOS ResourcesI 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.
No, they're using SQLite3 as the repository.
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.
Whether Audacity is actually doing this, I don't know.
Audacity almost certainly isn't doing this, but you can use SQLite to treat an archive as a database:
$ echo "select name, sz from zip" | sqlite3 -table mb.zip
+---------+--------+
| name | sz |
+---------+--------+
| MB.EXE | 125952 |
| MB.DOC | 1225 |
| MB2.DOC | 9158 |
+---------+--------+
$ sqlite3 new_archive.db -A --create log.txt
$ sqlite3 new_archive.db -A --list
log.txtThis is insane, SQLite can open ZIP files? :-))
All file formats are now zip files or sqlite files it seems
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.
It's like the Microsoft Paint of audio editing.
More like the GIMP of audio editing.
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.
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.
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 guess everyone should know what a DAW is.
For those interested Audacity's underlying design, it's featured in The Architecture of Open Source Applications: https://www.aosabook.org/en/audacity.html
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...
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...
Also may recommend to read FLOSS Manuals' book on Audacity[0]
[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
[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
If curious, past threads:
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)
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)
JFTR, There is already a project[0,1,2] on adding Audacity into Blender:
> 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
> 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
Nice to see sqlite3 as the file format of choice. It is known to be quite a bit faster than the file system for large number of small files .. though I'm not sure Audacity's case aligns with that. The file system is expected to be slightly faster for larger blobs, but sqlite3 can be like 10x faster than the file system in windows10 for blobs in the 100s of kB range.
Overall, it looks like it might be a great performance boost when working with highly edited fragments and at worst a slight performance degradation for large unedited tracks.
https://www.sqlite.org/fasterthanfs.html
Overall, it looks like it might be a great performance boost when working with highly edited fragments and at worst a slight performance degradation for large unedited tracks.
https://www.sqlite.org/fasterthanfs.html
I have relied on Audacity for audio editing for 15 years and challenge all HN readers to join me in giving value for value to this project. In those 15 years I've used a few different paid products but I keep coming back to Audacity because it's power and simplicity allows me to speed through editing projects in less time than it would take me to learn other products... and it's good enough that I don't feel like I'm missing anything. My donation to the project is so long overdue!!!
I'm happy to hear about the new file format. The prior "piles of files" were a problem when saving to folders watched by Dropbox / OneDrive.
Thanks Audacity, for an excellent tool!
Thanks Audacity, for an excellent tool!
> Nevertheless, this was a huge change, and we decided it was too risky to include many other changes we wanted to make at the same time – so 3.0.0 is almost entirely about this big format change.
I just absolutely love this sentiment! It gives me so much faith in their organisation.
I just absolutely love this sentiment! It gives me so much faith in their organisation.
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!
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 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.
Last week, my son had to make a podcast for school. He created a series of small sequences with his mobile and I told him I would make a big mp3 out of it.
I had never used a sound manipulation software before, but within 2h (including downloading and installing the software) I was able to import all the files (It was not intuitive, I had to search a bit), cut stuff, put a bit of a piano stuff he played with fade in/out effect and create a nice 2 minute mp3.
I was blown away by the final quality for so little work.
I had never used a sound manipulation software before, but within 2h (including downloading and installing the software) I was able to import all the files (It was not intuitive, I had to search a bit), cut stuff, put a bit of a piano stuff he played with fade in/out effect and create a nice 2 minute mp3.
I was blown away by the final quality for so little work.
Audacity, OBS. Let's hear it for open source! True hero's of the creative space of tech.
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.
I love Audacity, particularly after discovering the "Enable Cut Lines" feature [0], which is a nice solution for poor man's non-destructive editing.
Eric S. Raymond considered Audacity a great example of Linux UI design in "The Art of Unix Programming" [1].
I do, however, think mhwaveedit [2] deserves more attention. A really well thought out UI; excellent for small edits on Linux. It was also a direct inspiration for the writer of the mtpaint graphics editor [3].
0: https://forum.audacityteam.org/viewtopic.php?t=39688#p102880
1: http://www.catb.org/esr/writings/taoup/html/ch06s01.html#aud...
2: https://github.com/magnush/mhwaveedit
3: https://en.wikipedia.org/wiki/MtPaint
Eric S. Raymond considered Audacity a great example of Linux UI design in "The Art of Unix Programming" [1].
I do, however, think mhwaveedit [2] deserves more attention. A really well thought out UI; excellent for small edits on Linux. It was also a direct inspiration for the writer of the mtpaint graphics editor [3].
0: https://forum.audacityteam.org/viewtopic.php?t=39688#p102880
1: http://www.catb.org/esr/writings/taoup/html/ch06s01.html#aud...
2: https://github.com/magnush/mhwaveedit
3: https://en.wikipedia.org/wiki/MtPaint
> A really well thought out UI; excellent for small edits on Linux. It was also a direct inspiration for the writer of the mtPaint graphics editor.
I prefer AzPainter[0] instead of mtPaint.
[0] https://git.io/azpainter
I prefer AzPainter[0] instead of mtPaint.
[0] https://git.io/azpainter
Audacity is one of the best open source software products out there. Grats on the release!!!!
I've digitized 60 year old reel-to-reel tapes and made adjustments for 60Hz/50Hz differences solely with Audacity. Its value can't be overstated.
Glad to see progress made on Audacity! Regrettably, performance on Mac is still very poor.
These performance issues motivated me to build https://wavtool.com. It's faster for basic recording and navigation, and runs entirely in the browser. It also has a code editor built in, and a bunch of community-made audio effects written in JS.
These performance issues motivated me to build https://wavtool.com. It's faster for basic recording and navigation, and runs entirely in the browser. It also has a code editor built in, and a bunch of community-made audio effects written in JS.
One small thing that bothered me in Audacity last time I checked was that it showed "stairstep" style zero order hold when you zoom in enough for samples to be shown as one more than one horizontal pixel - rather than the reality of a sinusoidal curve for the waveform.
25 years ago it was reasonable to argue that you just couldn't afford the performance cost of calculating and displaying even a halfway accurate approximation, but that's a pretty weak argument today.
Stairstep displays reinforce a bunch of erroneous beliefs about digital audio. There are of course some great material like https://wiki.xiph.org/Videos/Digital_Show_and_Tell to debunk those beliefs, but they'd be less likely to arise if all the tooling people used didn't implicitly reinforce them.
Did they fix that any time since? Sadly I would guess not.
25 years ago it was reasonable to argue that you just couldn't afford the performance cost of calculating and displaying even a halfway accurate approximation, but that's a pretty weak argument today.
Stairstep displays reinforce a bunch of erroneous beliefs about digital audio. There are of course some great material like https://wiki.xiph.org/Videos/Digital_Show_and_Tell to debunk those beliefs, but they'd be less likely to arise if all the tooling people used didn't implicitly reinforce them.
Did they fix that any time since? Sadly I would guess not.
Audacity defaults to rendering audio as stem plots now, when zoomed in.
I found https://thewelltemperedcomputer.com/KB/SRC.htm to be interesting. Near the bottom, it has sinc-interpolated visualizations of discrete-time signals (though saying that resampling is bad, because of a Nyquist-frequency signal not surviving an upsample and downsample, is misleading). What program is that?
I found https://thewelltemperedcomputer.com/KB/SRC.htm to be interesting. Near the bottom, it has sinc-interpolated visualizations of discrete-time signals (though saying that resampling is bad, because of a Nyquist-frequency signal not surviving an upsample and downsample, is misleading). What program is that?
Now I woke back up and actually checked. You're correct, this display (I would call these "Lollipops" not stems but I get what you mean) is no longer misleading, so that's great.
Isn't it better to show the actual data, not what its analog product is?
Frankly, that approximation would be wrong in many cases, and would very significantly complicate the visual presentation as well as impact UX.
There is a lot of work here. Actual gains are marginal, risks quite high.
Those steps are the data being manipulated.
Displaying the product of the data only would be confusing in another direction.
So, both would be required.
That is where all the work is, and in terms of priority the case for this kind of thing is super weak, IMHO.
Seems to me you are framing this as a fix when it is not actually a problem.
It is an enhancement request.
While I agree with you, and learned about these things myself! I felt much better about a lot of concerns, but I must also say I find very little utility in a computed visualization of this kind.
It would be spiffy, but would add almost no real value.
Frankly, that approximation would be wrong in many cases, and would very significantly complicate the visual presentation as well as impact UX.
There is a lot of work here. Actual gains are marginal, risks quite high.
Those steps are the data being manipulated.
Displaying the product of the data only would be confusing in another direction.
So, both would be required.
That is where all the work is, and in terms of priority the case for this kind of thing is super weak, IMHO.
Seems to me you are framing this as a fix when it is not actually a problem.
It is an enhancement request.
While I agree with you, and learned about these things myself! I felt much better about a lot of concerns, but I must also say I find very little utility in a computed visualization of this kind.
It would be spiffy, but would add almost no real value.
> Isn't it better to show the actual data, not what its analog product is?
A stairstep isn't "the actual data". The actual data is a series of impulses. While it is possible that somewhere inside a component of your hardware there's a DAC which is creating zero order hold signals to feed into a reconstruction filter as one cheap way to make the PCM data into analogue audio, Audacity has no way to know that and there's no reason either Audacity or its user should care.
> Frankly, that approximation would be wrong in many cases
You could easily plot a curve that's more accurate than the user's display. You can't see inaccuracies that are smaller than a pixel. There's already suitable code for this calculation (it's called a resampler) inside Audacity.
> Those steps are the data being manipulated.
Again nope, you're manipulating PCM data, an Excel-style view of lists of signed integers would be much closer to "the data being manipulated" in this sense but you presumably don't think that's a good idea.
Your apparent confusion as to what's real here despite having "learned about these things" is exactly why I was pleased to see in the other reply that Audacity now shows lollipop sticks illustrating the actual impulses once you zoom in far enough to see them.
If lollipops are the thing we're showing most users for the next twenty years I have my hopes that conversations like this will become no more necessary than arguing with Flat Earthers.
A stairstep isn't "the actual data". The actual data is a series of impulses. While it is possible that somewhere inside a component of your hardware there's a DAC which is creating zero order hold signals to feed into a reconstruction filter as one cheap way to make the PCM data into analogue audio, Audacity has no way to know that and there's no reason either Audacity or its user should care.
> Frankly, that approximation would be wrong in many cases
You could easily plot a curve that's more accurate than the user's display. You can't see inaccuracies that are smaller than a pixel. There's already suitable code for this calculation (it's called a resampler) inside Audacity.
> Those steps are the data being manipulated.
Again nope, you're manipulating PCM data, an Excel-style view of lists of signed integers would be much closer to "the data being manipulated" in this sense but you presumably don't think that's a good idea.
Your apparent confusion as to what's real here despite having "learned about these things" is exactly why I was pleased to see in the other reply that Audacity now shows lollipop sticks illustrating the actual impulses once you zoom in far enough to see them.
If lollipops are the thing we're showing most users for the next twenty years I have my hopes that conversations like this will become no more necessary than arguing with Flat Earthers.
"More accurate" is not real
Which is it?
There was an input signal. Those samples will reproduce it. (Assuming an input matched to the sampling capability under discussion.)
That is what the video you linked tells people.
I am definitely one of the people, and have shared that exact one many times.
Showing people the input waveform makes sense. Overlaying it with the data captured also makes sense.
An approximation does not make sense.
Can we show them the input signal that generated the data easily? If so, great. Let us do that.
What I meant by "real data" is that list of integers. That is what is in the machine.
We both know that is not what comes out, nor what came in, nor what people hear.
Personally, I have always evaluated that by actually listening, or using my scope, same way that engineer did in the pretty great video you linked.
Which is it?
There was an input signal. Those samples will reproduce it. (Assuming an input matched to the sampling capability under discussion.)
That is what the video you linked tells people.
I am definitely one of the people, and have shared that exact one many times.
Showing people the input waveform makes sense. Overlaying it with the data captured also makes sense.
An approximation does not make sense.
Can we show them the input signal that generated the data easily? If so, great. Let us do that.
What I meant by "real data" is that list of integers. That is what is in the machine.
We both know that is not what comes out, nor what came in, nor what people hear.
Personally, I have always evaluated that by actually listening, or using my scope, same way that engineer did in the pretty great video you linked.
> "More accurate" is not real / Which is it?
We'd be trying to draw a curve (a band limited audio signal is a smooth curve, although I guess in the very degenerate case that it's completely silent that curve is also a perfectly flat line), on a display made of rectangular pixels, so, that is always going to be an approximation, but that's really neither here nor there.
> Can we show them the input signal that generated the data easily? If so, great. Let us do that.
Yes, this is very easy to do, in the video you say you've shared many times it shows this (among many other things) because it isn't hard, unless your idea of a fast computer is a 20MHz 80386 or something, in which case, yeah, that's not easy and maybe isn't worth your time.
Or what they have chosen to do now (lollipop graph) is also fine, if you zoom into the lollipop graph on your 44.1kHz recording of a Mariah Carey vocal it's still fine, it only starts to get a bit confusing (making the smooth curve valuable to see what's actually happening) at really high frequencies say, 15-20kHz.
We'd be trying to draw a curve (a band limited audio signal is a smooth curve, although I guess in the very degenerate case that it's completely silent that curve is also a perfectly flat line), on a display made of rectangular pixels, so, that is always going to be an approximation, but that's really neither here nor there.
> Can we show them the input signal that generated the data easily? If so, great. Let us do that.
Yes, this is very easy to do, in the video you say you've shared many times it shows this (among many other things) because it isn't hard, unless your idea of a fast computer is a 20MHz 80386 or something, in which case, yeah, that's not easy and maybe isn't worth your time.
Or what they have chosen to do now (lollipop graph) is also fine, if you zoom into the lollipop graph on your 44.1kHz recording of a Mariah Carey vocal it's still fine, it only starts to get a bit confusing (making the smooth curve valuable to see what's actually happening) at really high frequencies say, 15-20kHz.
I like the lollypop graph personally.
Well, in that video he is reproducing inputs with only modest frequency complexity.
And by approximation, I do not mean pixels. I do mean a reconstruction of the input. That drawn as pixels is fine.
Won't the compute burden depend on the frequency domain complexity of the input signal?
And if that is approximated, I maintain the existing UI representation is just fine, as it is functional.
Well, in that video he is reproducing inputs with only modest frequency complexity.
And by approximation, I do not mean pixels. I do mean a reconstruction of the input. That drawn as pixels is fine.
Won't the compute burden depend on the frequency domain complexity of the input signal?
And if that is approximated, I maintain the existing UI representation is just fine, as it is functional.
> Well, in that video he is reproducing inputs with only modest frequency complexity.
Monty is making them with a signal generator, so that you can easily see what's going on and (if you have suitable gear) you can reproduce the results. The exact same phenomenon would happen for some hypothetical complicated analogue signal. Notice that Monty also demonstrates a square wave, which is in fact the maximum possible "frequency complexity" because of how audio is defined, even though chances are you're still thinking about it as very simple.
> Won't the compute burden depend on the frequency domain complexity of the input signal?
No, it's just resampling, the same way you would to go from say 44.1kHz (from a CD) to 48kHz (typical modern fixed rate DAC in a cheap PC), except you're maybe going from 40 samples to 1000 pixels if you've zoomed in that far. It'd use a windowed sinc function.
Monty is making them with a signal generator, so that you can easily see what's going on and (if you have suitable gear) you can reproduce the results. The exact same phenomenon would happen for some hypothetical complicated analogue signal. Notice that Monty also demonstrates a square wave, which is in fact the maximum possible "frequency complexity" because of how audio is defined, even though chances are you're still thinking about it as very simple.
> Won't the compute burden depend on the frequency domain complexity of the input signal?
No, it's just resampling, the same way you would to go from say 44.1kHz (from a CD) to 48kHz (typical modern fixed rate DAC in a cheap PC), except you're maybe going from 40 samples to 1000 pixels if you've zoomed in that far. It'd use a windowed sinc function.
Lets simplify this discussion.
If the software renders the output shown on the scope, fine! That is what people will get.
How useful is that?
The case you made, which is to beat back misconceptions about what the output will be, is a good one. I do not disagree. Then again, just sharing that video does a very similar thing.
I do however think that display and UX would / could be more complex and would not actually get anyone anything new.
In my case, after learning the things presented in that video, I first used my scope, which is actually very similar, if not identical to the one in the video, to play with some signals and explore performance on various devices,circuits and code I found of interest.
Then what?
From an audio editing POV?
Nothing, other than I understand where seeing sample data breaks down in terms of what will be output and heard. That is nice, and seeing it would be nice too, but unnecessary.
Now, when building my own stuff, knowing what to expect is just as nice. I can hook up a scope and validate it.
It does make me wonder about the inverse questions! My square wave is a mess!
Despite fancy rendering and interpolation we may well be back to sharing the video.
If the software renders the output shown on the scope, fine! That is what people will get.
How useful is that?
The case you made, which is to beat back misconceptions about what the output will be, is a good one. I do not disagree. Then again, just sharing that video does a very similar thing.
I do however think that display and UX would / could be more complex and would not actually get anyone anything new.
In my case, after learning the things presented in that video, I first used my scope, which is actually very similar, if not identical to the one in the video, to play with some signals and explore performance on various devices,circuits and code I found of interest.
Then what?
From an audio editing POV?
Nothing, other than I understand where seeing sample data breaks down in terms of what will be output and heard. That is nice, and seeing it would be nice too, but unnecessary.
Now, when building my own stuff, knowing what to expect is just as nice. I can hook up a scope and validate it.
It does make me wonder about the inverse questions! My square wave is a mess!
Despite fancy rendering and interpolation we may well be back to sharing the video.
[deleted]
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.
Congrats audaciteam!
Disclaimer: I was a contributor a long time ago to the noise filter effect.
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 :)
I wish developers would merge the XDG Base Directory support patches.
I wish there was a similar equivalent for video editing. I tried vinci but it crashed the first time I tried it.
Avidemux is nice, but I can hardly add text or do simple effect with it, maybe with some scripting?
The new windows video editor is pretty good too, but features are quite limited.
I have some nice ideas for /r/highqualitygifs but I really don't want to use a professional video editor.
There are libraries to decode and render video with sfml and sdl, and i guess I could easily build a tailored editor myself with adequate ffmpeg commands...
Avidemux is nice, but I can hardly add text or do simple effect with it, maybe with some scripting?
The new windows video editor is pretty good too, but features are quite limited.
I have some nice ideas for /r/highqualitygifs but I really don't want to use a professional video editor.
There are libraries to decode and render video with sfml and sdl, and i guess I could easily build a tailored editor myself with adequate ffmpeg commands...
I use the free Davinci Resolve regularly (not sure which OS you're on) and it is stable on both Mac and Windows. Haven't tried on Linux since install on non-Centos is a little complex. If not using Davinci Resolve, I recommend Shotcut, which is a very capable, easy-to-use, cross-platform, open-source, and probably the most stable free open source editor out of others (ie Kdenlive, Openshot, etc).
I've found Shotcut[1] to be pretty good. It's not quite professional, but not at all hard to learn as an amateur. It is also open source, and works on Windows, Linux and macOS.
[1] https://shotcut.org
[1] https://shotcut.org
Love to see audacity still going strong, was one of the first audio tools I used for music production back in the day and is a great piece of software
* labeled silences!
* bugs i've never run into; fixed
* the pile of files -> a single .aup3
--> Thanks to all involved!
Audacity is a great audio editor.
Very intuitive GUI and easy to learn and to teach to others.
I was able to teach a musician friend of mine to be able to lay tracks, edit and splice in about 20 minutes even though had very little technical abilities.
Sometimes too much is a bad thing.
Trying to learn something like Pro Tools as a beginner is enough to scare someone away from digital recording/editing
Very intuitive GUI and easy to learn and to teach to others.
I was able to teach a musician friend of mine to be able to lay tracks, edit and splice in about 20 minutes even though had very little technical abilities.
Sometimes too much is a bad thing.
Trying to learn something like Pro Tools as a beginner is enough to scare someone away from digital recording/editing
Did they fix the macOS issue(s)? You had to run Audacity from the command line for whatever reason from macOS Catalina.
Love Audacity !
It's such a great tool for editing bits of audio fast. I think the UI is fine for what it does to be honest .
It's such a great tool for editing bits of audio fast. I think the UI is fine for what it does to be honest .
I use a Mac, which has GarageBand installed, and Audacity is still my go-to choice for any audio editing. I just used it to split a stereo track into two mono tracks, something I'm not sure I can do in GarageBand (TBH I didn't look since I had Audacity).
No way to donate any money? I am using it a lot but do not have the time to contribute otherwise.
If there anything that Audactity can do which blender can not ? I plan to learn video editing using blender and don't want to learn another tool if blender can do everything Audactiy does.
Thanks for the great work, Audacity is my to-go audio maker for multiple years. It's like gimp for graphics, vlc for video playing, what a god send.
On windows for me to add .m4a access I must install an .exe with the warning that the publisher cannot be verified.
Is there not a "safer" way in 2021?
Is there not a "safer" way in 2021?
I remember seeing this project launched at CodeCon way way back in the day and I'm happy its been cruising along ever since.
Somehow I'm not surprised to learn that the inimitable SQLite is powering this seismic shift in this venerable package.
If ever we needed to archive timeless bits is software to rebuild society with, Audacity would definitely be on that list.
One of the best and most consistent open source projects over the years. You should be proud, well done.
Thank you Audacity for an absolutely indispensable piece of software for anyone who works with audio.
Anyone else remember using Goldwave in the pre-Audacity days, or its multi-track cousin Multiquence?
Wow, never would have remembered Goldwave had you not brought it up.
My turn: Creative WaveStudio (came with some of the original Sound Blaster cards back in the Win3.1 days) and n-Track Studio
My turn: Creative WaveStudio (came with some of the original Sound Blaster cards back in the Win3.1 days) and n-Track Studio
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.
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.
Cool Edit became Adobe Audition and is still very nice to work with.
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!
Ugh. FOSSHub. That enormous VPN downloader at the top.
It took me some time to remember to avoid it.
I do luvs me Audacity, though.
Good show!
It took me some time to remember to avoid it.
I do luvs me Audacity, though.
Good show!
FOSS Torrents team already provided `.torrent` downloads for Audacity 3.0.0.[0,1]
[0] https://twitter.com/FossTorrents/status/1372176177708818433
[1] https://fosstorrents.com/softwares/audio/audacity/
[0] https://twitter.com/FossTorrents/status/1372176177708818433
[1] https://fosstorrents.com/softwares/audio/audacity/
Congrats to the Audacity team. This project is legendary.
this is six
> 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.
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.
Why doesn't it seem fair?
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.
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.
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.
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 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.
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.