I still do not understand. WxWidgets should rely on native controls rather then rendering them right? Does it mean that there is a branch of WxWidgets that renders the controls?
Can this somehow be used to edit a file on a system remotely? Say I have some .wav's on a raspberryPi, can I publish them, edit, send them back to that raspberryPi?
Because that seems to me to be a very awesome use-case ..
There was a lot of discussion back when Audacity decided to make some changes. I don't remember what they were specifically, but I do remember a few threads here about forks of the project. I don't remember the name wavvy, so maybe this is another fork. I was thinking the fork discussed here previously also was a play on the "*city" name as well.
Wow, this is incredible! I was not expecting it to work on mobile Safari of all things, but it does! The UI is even usable.
Audacity is an indispensable utility. It’s great to see it and other “real” software on the web. I’m reminded of Photopea[1] which is a web clone of Photoshop.
> Audacity is an indispensable utility. It’s great to see it and other “real” software on the web.
It's been a very long time since I used it, but didn't Audacity turn evil, add a bunch of networking code it never needed before, and start spying on people? (https://fosspost.org/audacity-is-now-a-spyware/). I remember people reverting to older "safe" versions.
I guess that doesn't much matter for this web app since it's collecting your IP and data by design (their privacy policy seems very vague and handwavy), but for the desktop app it seemed like kind of a big deal at the time.
So the stuff available on ubuntu/arch don't have spyware? I never heard about these changes, I did know some company bought it but didn't think much about it at the time as I don't use it a lot, but when I need it, it's quite handy
I haven't kept up with what happened since the original controversy, but at the time it was about telemetry in dev builds (i.e. building from the repo) only. In any case it doesn't have spyware unless you think firefox and various other programs are also spyware.
I'll never understand peoples' obsession with equating telemetry with spyware. As an application developer, I need to know that my application is working appropriately for my users. It's not sufficient to rely on manual bug reports. If someone doesn't like that, then that's perfectly fine in my opinion. Just don't use the product. To accuse an application developer of spying on users is a bit much imo.
Why should a user ignore when a developer has the means to spy? Telemetry is used as a false metric for a lot of bad decisions that make sense for the numbers but don't improve the product itself.
Even A/B testing could be considered an ethical hazard because it disrupts the user's understanding of the software for the sole purpose of decisions that, frankly, devs should have made before telemetry.
Users should be able to trust that their software won't be blabbing over the network about what you're doing. In an age where privacy is attacked from all angles, it's the least a developer could do.
I’m not advocating that users ignore the possibility of spying. All software has the potential to spy on you. But that does not mean you can publicly accuse a developer who wants to add telemetry of spying.
> Users should be able to trust that their software won't be blabbing over the network about what you're doing.
Says who? That’s just your opinion. My opinion is that if an exception happens in my software that makes it harder for me to use, the developer should be aware of the issue and fix it so that the software works correctly in the future. There isn’t anything wrong with your opinion, but there is something wrong of accusing the developer of some type of impropriety just because they want to use telemetry.
Says responsible developers. Good software doesn't need to phone home or report to the dev that they clicked widget X instead of Y.
Telemetry is what happens when lazy or complacent devs move forward in their software but decide to be 'data driven'.
What's wrong with accusing someone of having the ability to spy of maybe spying? The point with technology and humans is, if the ability is there, it's not 'if' it will be abused; it's when.
Software that doesn't phone home or have telemetry never has to worry about that moral hazard. User data doesn't belong to developers, and that includes behavioral data.
“Says responsible developers”. That’s called rationalizing friend.
This conversation can go nowhere because you believe you’re right and others are wrong. You really should accept that you have a specific preference and other people have other preferences. It’s not a question of right or wrong.
I disagree, I consider it a matter of ethics when I'm deciding whether or not to add telemetry to a piece of software. Passing it off as a preference is equating them, when the software with telemetry is less trustworthy and has a broader attack surface due to network connectivity. Maybe doing all that is worth treating your users like a science project, but it's not just a preference to me.
There is too much behind-the-scenes telemetry, analytics, and other intel-gathering happening on websites and in software. The gains are held solely by developers who either cannot figure out how to build their software, or whose management is so incompetent that there's no real connection to the users of the software, so making meaningful and helpful change to the software is less accessible.
I strongly hold that the practice creates less durable software that also primes a user to expect their software to study their behavior and change accordingly. That is supremely creepy, and users deserve better treatment than that. It's our job as developers to respect the resources our software is using on the user's machine, and for them to be 100% informed of anything they may be sharing over the wire.
Maybe that viewpoint isn't in line with VC-backed startups or enterprise, but I also don't expect them to act ethically wrt software, either... Analytics and telemetry created the data brokerage industry. Programmers are responsible for allowing that behemoth to invade and shape lives.
> As an application developer, I need to know that my application is working appropriately for my users.
You don't need telemetry for that. We have several decades of data showing that software can be developed, tested, deployed, used, and valued without ever forcibly collecting a single bit of data from users.
Why on earth should a user trust that their data isn't being used to spy on them just because it's being collecting under the guise of being for something else? Once the data is collected, the user has no control over what a company will do with it and the only sane assumption users can make these days is that if a company can make more money by doing something (like selling or abusing the personal data of their users) they will do that thing.
The practice of collecting telemetry is also highly suspicious because it's often done without the user's consent (opt out at best), and without showing the user exactly what data is collected and sent.
The fact is that companies have betrayed the public's trust so many times, and in such egregious ways, that it's unreasonable for developers to expect people to "just trust them" to do the right thing. If you don't want to be accused to spying, maybe just don't behave like spyware. Do testing, solicit voluntary feedback, and eat your own dog food.
Again, it’s just your preference. No one is forcing you to use such software. It’s not the moral issue you’re framing it as.
We also don’t have “decades of data”. Almost all large scale software systems leverage some form of telemetry/monitoring. Would you run a factory without quality control on the process? A more interesting question to me is which large software systems don’t use telemetry? Linux maybe?
The first computer program was written in the 1840s. FORTRAN was released in the 1950s. I promise that we had many many decades of amazing software that didn't phone home to spy on users. Most software had no telemetry at all until well after the internet became mainstream.
When many people connected to the internet via dial up, phoning home (even just to check for updates) could get your software branded as spyware. The idea that a software company would be collecting data on what dates/times you were online, what your IP address was, and when/how often you used the software you purchased was offensive. Adware (and nagware) were tradeoffs users knowingly made, but data collection was a sin.
As the internet got popular enough more and more programs started spying on users and there were efforts to come up with clear guidelines for what was/wasn't acceptable, for example: https://www.grc.com/oo/cbc.htm
Today most programs collecting telemetry would fail by that standard.
Just because "everybody does it" today that doesn't make it right. Most computer users have no understanding of what the software they run is doing, very little idea of the risks/harms involved with giving up their personal data, and no idea that there was ever a time when things were any different.
It's still not any of your business when your users run their software. Which features they use more often or what tasks they use their software for are also none of your business. You might find that information useful to have, but that doesn't make it yours to take without asking.
You don't need telemetry. If you want it because it lets you be lazier, request permission before collecting anything and make sure users know exactly what is being collected before asking them to opt in. Just having or pointing users to a privacy policy is not enough. Don't collect anything more than you absolutely have to and delete the data quickly once you have it so that it can't be leaked/sold later. Anything less than that is disrespectful and deceptive.
According to that link, all the browsers do implement the non-experimental parts of that API. The other features seem to be ones that Chrome has shipped unilaterally - the links to the standards docs seem to only have Google authors for those bits.
OK. Let me rephrase. If all browsers would support the very useful set of experimental FSA APIs implemented in Chrome/Edge's desktop browsers, then these types of web apps would be even more usable.
There was nothing biased in my comment - even Chrome for Android doesn't support these APIs.
Persistent read/write access to user-defined folders rather than only to private origins.
You know how everyone complains about Flatpak sandboxing until they learn about portals and Bubblewrap because the programs are isolated from the rest of their disk? The web is like that, except without portals and Bubblewrap. You can save stuff and drag files in, but you can't really integrate a webapp with a user's local filesystem -- and it's very hard to keep all of a webapp's data in a user-inspectable format that's easy to transform, open up with native apps, or transfer across browsers or websites.
Now, the problem is that persistent read/write access to user-defined folders is wildly dangerous. And Google's proposal is... not the worst thing in the world? But it's suboptimal and it's a missed opportunity to build something far better, and I kind of understand why Mozilla considers it harmful.
Getting this wrong would have permanent implications for the web. Mozilla is absolutely right to be cautious. However, it's also really holding the web back and in particular holding back PWAs because the only really reliable way as a developer to store data via the web is to sync it to an online account. As a result offline webapps are very limited; you never really trust the storage.
It's an extremely dangerous feature that we really need, but it's not clear who should champion it and I don't really trust Google to be heavily involved in the spec process, let alone to be the people writing the first draft. I don't think Google is good at building nuanced web specs even when there's no conflict of interest at all (see the web audio API, HTML templates, etc...). A lot of Google specs end up being very weird and they end up having strange quirks and very strange limitations that don't need to exist? They're very often kind of orthogonal to what the community needs. I don't know if the problem is that Google doesn't think enough about the spec or that they think too much and over-complicate things, but for low-level important features I prefer other browser-makers to lead the way.
What would be best is if a team with more earned trust picked up the spec and went over it again trying to better address the dangers and trying to make something that better addressed everyone's needs in a cleaner way, but there are not a ton of stakeholders on the web that I trust to do that. As it stands the proposal is... ok-ish? But needs a lot more discussion and could be better. I don't blame anyone for being hesitant about it; the potential for abuse is so unbelievably high.
But... it is a serious limitation that I can't ask for persistent read/write access to a folder from an offline webapp.
It's not just that it makes the web less powerful, it also makes it less private and less user-controllable. There is no effective way to build an offline webapp that handles important data, if you're building a website that handles actually important data -- that data is getting synced to an online account.
As a result there are a number of web-apps that could be entirely account-free and offline that aren't. It also makes it a lot harder for users to move and transform data, although maybe that's less of a consideration nowadays since mobile has kind of standardized data silos even for native apps that would have previously had portable databases or worked directly with files.
Not saying you should want it, I completely understand and am completely sympathetic to anyone who says "the benefits don't outweigh the risks." That is a fine position for someone to take. That being said, this isn't just about trying to make the web more powerful, it's also in a lot of ways about fixing long-time deficiencies in the web that have made it less private and that forcibly shift the majority of even well-intentioned web software into a user-hostile SaaS model. When every webapp is a SaaS business with web accounts, that decreases hobby development in favor of corporate development and encourages users to spread their data in (imo) irresponsible ways.
Well, I find Gimp unusable because I learned PS hotkeys 15 years ago and whenever I press them in Gimp it does random things. Photopea is nearly a 1:1 mapping of PS. Can't comment too much on feature parity, I don't do anything too crazy. Some cropping, expanding canvas size, maybe desaturate or adjust levels, use layers and masking. Magic selection. Maybe some content-aware fill. No artist/painting/fancy brushstroke stuff though.
I agree that it running on mobile safari is incredible - I wouldn’t call the UI ‘usable’ though, it’s a straight duplicate of the desktop UI, which isn’t geared for mobile by any stretch of the imagination, and is actually unusable on my iPhone due to (I assume) far too small a clickable area for most controls.
A UI rework to incorporate mobile-friendly design would be a ton of effort, but it would really take this project to the next level!
Does EVERY desktop application really need to run on mobile? Some apps are just... call me crazy... desktop apps! (NOTE: "native vs. browser-based" is separate distinction from "desktop vs. mobile".)
That's not to say that there can't be mobile audio apps, or mobile whatever. I just think that's a separate app, and should be designed and written as a mobile app from conception.
I realize that a large cohort finds desktop applications uncool today, but I'm just so frustrated with the idea that serious and powerful desktop interfaces need to crippled in order to fit into a "mobile-first" (a.k.a. "lowest-common denominator") paradigm. For audio listening, that's fine. But for serious audio creation and editing? FUCK an iPhone, sheesh.
> I realize that a large cohort finds desktop applications uncool today, but I'm just so frustrated with the idea that serious and powerful desktop interfaces need to crippled in order to fit into a "mobile-first" (a.k.a. "lowest-common denominator") paradigm.
Yeah, my primary issue with this sort of thing is that there is very little personal A/V content I'd feel comfortable uploading to some random server in the first place, but I agree that there are some tools better suited for the desktop and more specifically a keyboard and mouse.
The problem is that a very sizable part of the population doesn't have a desktop. It's not that they think it's uncool exactly but for a lot of people, kids especially, all they have are cell phones and tablets which were designed first and foremost for content consumption. I can't blame developers for wanting to target the needs of that audience to whatever extent they can.
You said it: Designed for content consumption. Hence it’s important to not cripple the UI of content creation tools for platforms that aren’t suitable for that.
You can use GarageBand perfectly fine on an iPhone, no reason Audacity can't do the same. It's literally just a UI issue, easily remedied especially on the web.
The difference is that Apple has a much higher dev budget and a clear economic incentive to promote mobile apps.
I think Audacity devs should instead focus their limited resources on desktop (mouse+keyboard+big screen) use. Also because if you just need some simple audio editing, you can be served by other simple mobile apps.
This is what people like me have been getting at for ages when we talk about decoupling interfaces from application logic. It's also incidentally a really strong argument for decoupling state presentation from visual presentation. I should be able to build a mobile interface for Audacity without rebuilding Audacity both because the audio processing logic should be separate from the interface and because the interface should be separate from the visuals -- I should be able to consume Audacity's interface as an XML tree and pipe it into a separate renderer.
Because if that was the case it wouldn't be that hard to make Audacity mobile friendly (or at least more mobile friendly than it currently is).
As a bonus, if your interface is consumable as an XML tree without rendering anything, it's very likely going to be much easier to make the interface accessible. From what I can see in the documentation, Audacity as a native app on desktop doesn't work with screen readers on Linux.
This is not necessarily anyone's fault beyond GUI toolkit designers, it's not particular to Audacity, but it's a paradigm shift. Some visual controls wouldn't work well on mobile, but for most apps including Audacity there's really no reason (other than lack of existing infrastructure and toolkit support) why people shouldn't be able to just swap out those visual controls with ones that do work on mobile and use Audacity normally otherwise.
Sometimes I don’t need to do “serious audio editing” with audacity. I need to trim a clip or something. I can’t think of a reason why I SHOULDNT be able to do that on my phone that has more processing power than most computers a decade ago
Are you using an old iPhone with a tiny screen or have you not tried turning it sideways? It's extremely usable in landscape. My sausage fingers don't have trouble hitting any buttons.
Wow this is just incredible! Seeing this and software like photopea I can now start to feel that HTML has become powerful enough that almost any desktop app can now be built for the web just as same.
A lot of people/companies tried their best to impede this progress (1) for promoting app stores but I'm so glad we are finally getting there regardless. Better late than never!
Can anyone summarize how this works. Guessing Audacity is some C++ program. How did they take all the dependencies and make them work on browser, using WASM? What about the frontend? Is the UI just completely re-written?
wxWidgets uses native controls, so just compiling to "WebAssembly" (I'm assuming it's compiled to WebAssembly, plus some JavaScript for DOM manipulation) was probably a significant amount of work. I'm actually curious how it was done!
Alright, it's at a kind of uncanny valley situation where we have Windows XP applications running real-time in our browsers. Is the end-game just a universal sandboxed VM that's cross-platform? What do we do next?
For better or for worse, that's what Google is aiming at with ChromeOS. Especially now that the overarching "OS" is really just a Linux shell for multiple VMs.
People often claim that ChromeOS is versatile enough to replace a normal computer because it has these various compatibility layers. They often fail to mention that they work terribly. You wind up with the poor performance and annoying isolation that VMs give, but with an extra helping of instability and incompatibility. Running anything Google hasn't approved is gated behind "developer mode", and even for a developer the pseudo-Debian container "developer mode" unlocks is confusing. I regularly encounter problems (like needing to run Wireshark) that I believe are simply unsolvable.
I don't understand anything about ChromeOS. At one point it was a bad but clear idea: a machine with just a web browser, capable only of running web apps. Then at some point they decided to just make the world's most complicated and confusing Linux distro, with the vestigial browser-centric design kept around just to make things as inconsistent as possible.
You could just as easily construct an arbitrary usability test over interop that the web platform excels at while current desktop apps do terribly. For instance:
* Send a link to a Google Drive document to another person on WeChat: Pass
* Send a link to a Microsoft Word document to another person on Slack: Fail
The web has different paradigms and some of them are an improvement, one being hyperlinks, another being instant delivery just for example (no install time).
> Running anything Google hasn't approved is gated behind "developer mode", and even for a developer the pseudo-Debian container "developer mode" unlocks is confusing.
This is mixed up. "Developer mode" is a firmware mode that allows you to run unsigned images. You use that if you want to hack your ChromeOS image itself. The Linux development environment feature (crostini) runs in a VM on any chromebook, it doesn't require developer mode or any firmware features. Technologically it's basically the same thing as WSL, though integrated much better with the OS UI.
Versatile is the opposite of what ChromeOS has become. I would argue that there was a time (beginning of pandemic) where it looked like Google might strike the perfect balance between web-reliant (PWAs and safer extensions) and legacy-OS supported (Android, Linux, and even some slight Windows compatibility).
Now, it just seems like a bad version of the legacy operating systems. Android, but in a VM, Linux, but in a VM, and Windows delivered via the cloud!
All of this is worse than just running any of those systems alone.
FWIW: native audacity (literally the debian package) runs in ChromeOS as a wayland/somellier client from crostini. Basically everything not tied to particular driver or hardware environments runs great.
The whole OS is really the best "app fusion" desktop environment out there. I've got Android apps for Threads and Tesla running alongside all the web apps you'd expect to find. I've got my personal email via linux Thunderbird. I read my PDFs in Evince (because, let's be honest, both the Chrome and Adobe readers are junk) and it integrates with the native ChromeOS Files app like a normal app. In fact all the Gnome .desktop files in the Crostini personality appear as apps in the OS menu that can be associated with files types or pinned to the shelf, so there's a surprising amount of scriptability to the process. Likewise it makes a great X terminal for shells and emacs windows from development machines.
In fact I've moved (to be fair: for professional reasons, and I resisted for quite a while) to a mid-tier junky old Chromebook for basically all my client activity at this point (windows games being the sole exception). Really it's pretty great. The proverbial year of Linux on the desktop arrived and won while we were all looking elsewhere.
Unfortunately, Fugu is totally seperate from ChromeOS, since many of Fugus capabilities don't work on the platform. Still, on Windows and Mac, Fugu is definitely more impressive than anything ChromeOS is doing.
Obviously yes, there are going to be platform-dependencies with any platform abstraction API, and different platforms support different things. For sure Android is "primary" for most of these and it is doing the best, but the other platforms seem pretty well-supported, with no particular winner that I'm seeing. Is there something specific you're wanting and not getting?
Then it is correct? Many of the Fugu APIs don't work.
I didn't say none.
You can always tell someone hasn't developed consumer apps for ChromeOS when they white knight for it.
If you want to know a specific API that DOESN'T work, but performs splendidly on Windows, then the Eyedropper is a perfect example.
There's an old bug report for it that even has Google Chrome team support, and still no dice.
But yeah, keep rushing to defend the platform that doesn't even get proper support from its creators.
Another example is given in the link you posted. Direct Sockets API is deprecated, but its replacement isn't available yet.
So, if you were a web-dev using "vanilla" ChromeOS to test a site, you better install a full Debian VM on your 4 gb machine, because there's no other way to spin up a server.
No, I think it was correct to say Fugu is NOT for ChromeOS.
> Then it is correct? Many of the Fugu APIs don't work. I didn't say none
You claimed that support was significantly worse than on Mac or Windows, and the chart certainly doesn't bear that out.
And your examples seem... pretty cherry picked? I mean, there's junk that fails everywhere. If color pickers are core to your job, then... OK, I guess. It's a hole. It doesn't seem to remotely justify the kind of bile and hatred you're deploying here.
I gave another example as well. I'm also not spewing any "hate" or "bile" for an inanimate operating system.
To make this easier to understand, please give me an example of what's missing from Mac or Windows and I'll share the way it can easily be accomplished in a native environment. After that, we can try to do the same for ChromeOS and you'll see where the holes appear.
Fugu is about slowly moving Mac and Windows functions to the web, but ChromeOS exists RIGHT NOW. Thus, if it were for that platform, there would be urgency and full support across the board. Because they don't care about filling all those holes, they choose not to support every API.
That was my point. Windows and Mac don't need Fugu to function. ChromeOS does. Still, Windows and Mac needs are prioritized over ChromeOS.
I also noticed you deftly ahem cherry-picked around the lack of server support on a web-first operating system, but that's neither here nor there.
> To make this easier to understand, please give me an example of what's missing from Mac or Windows and I'll share the way it can easily be accomplished in a native environment. After that, we can try to do the same for ChromeOS and you'll see where the holes appear.
Which is kinda what I thought. This isn't about your upthread point about Fugu. You're doing a platform advocacy thing, which I'm not interested in. I jumped in to point out that it's simply not true that Fugu is poorly supported in ChromeOS, because it's not. I'm not trying to have a fight about platforms.
Fun fact: when you don't give a shit about whether your UI looks like what "the OS looks like" (no offense to Tantacrul, but audacity clearly doesn't), you can get a surprising amount of work done. This isn't a Windows XP application, it looked like this well before Windows XP existed.
Audacity is a cross-platform app that runs on (at least) Linux, macOS and windows (I suspect most other *nixes are supported to).
Also, note that most creative apps (music, video, art) do not follow the UI guidelines for any particular OS platform (partly because they tend to be cross-platform, partly because their needs are very different from office productivity and communications apps. This is true even when the apps are nominally made by Apple for Apple (see Logic Pro or FCP for examples).
Finally, Tantacrul has zero responsibility for the UI appearance of the Audacity that Wavacity is based on.
I'm trying to think how you'd even make blender or bitwig look native, but then I remember the DirectShow node graph editor from the windows 98 days and I'm going to stop thinking about this again.
I strongly support using OSS every chance I have, and do what I can as a non-programmer to support OSS projects, but as someone who trained on industry standards for audio editing (since the 1990s, starting with Syntrillium’s Cool Edit Pro) I found Audacity quite difficult to use. I really don’t understand this philosophy that prefers when applications lack any cohesive visual design language. “Designed by engineers” is every bit as problematic to me as “engineering by designers”.
The next step will be the same stack except the browser engine will be running in """The Cloud""" and streamed to your consumption-only device like an OnLive/Stadia/PSNow game. Everything already has dedicated video-decoding hardware so it will probably be sold as better for battery life to rely on that instead of the unpredictable load of your own local OS and browser engine.
Recompile Chromium for webasm. Run Chromium in Chromium in Chromium…
Then add Firefox into the mix.
(Being facetious of course, not wishing to put down managing to get an Audacity port running this way which is cool and even potentially useful (should you find yourself desperately in need of an audio editor in a place where you can't install software packages)).
Fun fact: Unreal was the first real, major piece of software that got ported to run in the browser, in a collaboration between Epic and Mozilla... almost a decade ago
Unreal Engine support is coming back to the browser, and with faster performance and load times than ever before!
My team and I at Wonder Interactive are building a hosting platform and suite of devtools that enable native games and 3D apps in the browser using WebAssembly and WebGPU.
Unreal is the first of many engines we'll support, we started with it because it has historically had subpar (and since the deprecation of HTML5 support in UE4, non-existent support for the web platform!)
Check out a few of our demos below, as well as a roadmap blog post we did last year:
Back in the 80s, when 90% of software development consisted of using a database and the tooling provided by the database supplier, and creating a front end to enter/edit/view the database contents, the results were called "applications".
In the 2020s, when 90% of software development consists of using a database, tooling supplied by various open source projects and some choice of web front- and backends to create a front end to enter/edit/view the database contents, the results are called "apps".
Honestly it's just so hurtful to me how confined & narrow opinions are on what the web should be, on what should be allowed, for what it can be.
This sort of stuff is so prime to me, so excellent.
There's plenty of scary platforms about, less than great sites, sure. But there is no other connected medium available for humanity.
And to let the Fear Uncertainty & Doubt - or to let IMHO pitiful pointless sad grumbling about performance - dog us down is is to miss such huge potential, to grow & expand & improve, in unconstrained & vast greatness. This sort of shit is so excellent. Yes you can. And anyone with any kind of computing device can tune in & try it. Heck yeah!
We need to split the web into documents and apps, in my opinion.
We still don't have a standard HTML text editor, instead relying on hundreds of Incompatible WYSIWYG editors which all produce custom output, or worse (much, much worse) the abomination that is MarkDown. Every browser should be an editor which all produce standardized output.
In 2023, we're still relying on asterisk, hash marks and underscores to format text, while simultaneously being able to run full fledged audio editors. It's ridiculous.
was very excited about this! but recorded my thing and tried to export it and the page went unresponsive. ugh. so sorry but have to go back to real audacity.
https://news.ycombinator.com/item?id=32688646