This is awesome, and also awesome is this:

> I originally developed a WASM port of wxWidgets

I had some fun looking at the commits here[1] and I can imagine a lot of classic wxWidgets apps are going to be ported to wasm now. Congrats, that a lot of dedication!

[1] https://github.com/wxWidgets/wxWidgets/compare/master...ahil...

I feel like I should preemptively apologize and I'm really not trying to knock the project in any way, and the achievement is pretty epic, but those who have seen my username on this site before know what's coming, especially in regards to people seriously considering using WX Widgets on the web... This app is inaccessible. Audacity on its own is already a bit difficult to use with a screen reader, but sadly, this port, unsurprisingly, is even worse. I've managed to at least explore some of the UI using OCR, but it was very cumbersome and I could never get it to do what I wanted. Just uttering my careful warning that you should please, please, please think 3, 4, 5 times before deciding to actually use this UI library for serious projects. The benefits of using what the browser already gives you is that, if you're not going too crazy, accessibility comes for free and there's very little you need to do to make sure that we can still use your app. Again, I understand that this is a port of Audacity, and I believe that what we can do in browsers is pretty amazing and my aim is not to discourage anyone from trying out new things. I'm just saying that this app is 100% screen reader inaccessible so please make sure you have a valid reason for keeping out users with disabilities (hint, you almost never do) by using WX widgets drawn directly to a canvas. And if you do, please think hard about what you can do to still keep your app accessible. I'm sure there are ways to add accessibility to a web port of WX, but if you can, sticking with the things the browsers give you is usually the better idea.

I so frequently see this tone with accessibility discussions: "X is not accessible, so don't use it, stop what you're doing, this is bad." I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible", because it presumes the problem is unfixable. I believe you wrote your comment in good faith, and I agree accessibility is important. But I think you should consider focusing on this:

> I'm sure there are ways to add accessibility to a web port of WX

and not

> Just uttering my careful warning that you should please, please, please think 3, 4, 5 times before deciding to actually use this UI library for serious projects.

because, as you acknowledge, this is a hobby project. The goal is to do something cool and fun and push boundaries of what's possible. So if pushing accessibility for all web apps is your goal, why not seize this moment to say "hey let's find ways to make WASM apps more accessible" rather than saying "nobody should use this for serious projects"? Why not try to fix it rather than shutting it down? Doesn't it benefit people more if we find a way to make accessibility easy, rather than discouraging people because it's hard?

There are lots of cool and interesting technical problems in there that somebody who takes the time to make something like this could have interest in: How do OCR or other accessibility tools understand canvasses? How can we communicate with them? What addons to WASM or wxWidgets would achieve this goal?

> I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible", because it presumes the problem is unfixable.

Of course the problem is fixable. But in the meantime, until it's fixed, a disabled person could fail to get a particular job, or even lose a job they already have, due to an inaccessible application. It's important to remember that the stakes are really that high. If we want to prevent that from happening, I think it's worthwhile to try to persuade application developers to not use inaccessible GUI toolkits, particularly for new projects. We can do that at the same time that we work on making more GUIs accessible.

> I think it's worthwhile to try to persuade application developers to not use inaccessible GUI toolkits, particularly for new projects. We can do that at the same time that we work on making more GUIs accessible.

Can we? People don't typically work on tools they don't intend to use. Where are the people doing the fixing going to come from if the conventional wisdom is "even if you use this for a side project, you're harming disabled people?"

Another way of framing your suggestion here is that toolkits with the resources to make themselves accessible without community help will always dominate toolkits that don't have those resources. That stifles progress for anyone.

> But in the meantime, until it's fixed, a disabled person could fail to get a particular job, or even lose a job they already have, due to an inaccessible application.

This kind of stake-raising honestly feels toxic to me, sometimes. You can make the same argument about almost anything. Eventually, you're going to get tuned out, because the knee-jerk reaction expressed to any new project is "well, you didn't do thing X I wanted, so I refuse to care even if the project has merit."

What's wrong with saying "hey, this is cool, but be aware if you wanna use wxWidgets for production app, know it's inaccessible and so you'll have more work to do to make your app accessible, which I assume you want to do, because it's the right (and often profitable!) thing to do"?

Why do we have to escalate it to "If you make side projects with wxWidgets, you're encouraging people to use them for production apps and therefore causing disabled people to lose their jobs"? It's purposefully taking everything in the most negative way possible.

Put another way, how is your argument distinct from the following: "Working on Audacity, a project for audio, privileges hearing people over Deaf people, and therefore could deprive Deaf people of programming jobs would go to text-based projects if there were fewer commercial audio engineering products helping people to replace text resources (blogs, etc.) with audio (podcasts, etc.). Therefore, Audacity is harmful and one should not work on it."

> I so frequently see this tone with accessibility discussions: "X is not accessible, so don't use it, stop what you're doing, this is bad."

'Don't use X for reasons ABC' is a great advice! Why use unusable X if some other thing Y works?

Have you tried using Wavvy on a smartphone? Guess what: it's effectively unusable on smartphones: - touch events aren't leveraged. - hover and right click aren't available, and keyboard shortcuts don't have an appropriate substitute; therefore core audio editing tasks cannot be accomplished in any acceptable manner.

If you are accustomed as I am to use Audacity on a desktop PC - clicking, cutting, shortcutting your sound files effortlessly - but then use Wavvy for the first time, you gonna feel...

disabled.

And that's only a glimpse into what the experience must be for a blind person using Wavvy. Here is an experiment: Close your eyes, use Wavvy. Only OCR allowed...

Being an awesome POC, the accessibility issues aren't Wavvy's "fault", but wxwidget's (and Audacity's by depending on wxwidget).

Considering audio is especially valuable for visually impaired people, having a usable audio editor is very valuable.

Now imagine, as it's so often the case in IT, everybody jumps on the latest bandwagon ("Docker all the things!", "Electron all the things!"), and suddenly everybody "WASM-canvases all the things!".

Now imagine Audacity decides "WASM-canvas" is the way to go for Audacity distribution; no more separate builds for Windows, Linux, macOS, just one WASM-canvas build.

And so do other software projects. And so does your company with its IT department software contribution... more and more, you cannot do your tasks the way you used to...

Back to the comment: constructive critique is always helpful:

- It helps Wavvy to consider using an alternative audio editor. - It helps Audacity to improve their usability and accessibility and consider another widget provider. - It helps wxwidget to fix their accessibility shortcomings.

We discuss problematic tools, libraries, websites, and services all the time at HN - be it for privacy concerns, performance issues and whatnot. We all learn from that why e.g. having a slice of privacy is also a good thing for us personally. So is accessibility, even when it's just the slices involving good layouts, readable fonts, unconfusing button naming, logical tabbing order, consistent shortcuts across applications, big-enough advertising close buttons, unfrustating timepickers... , ..., ...

> I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible"...

ClawsOnPaws is neither scolding, nor is it coming off as it for me. They apologize upfront, says "please, please, please", says "my aim is not to discourage anyone from trying out new things".

If there was one polite, constructive comment at HN it be it.

> ...because it presumes the problem is unfixable.

I don't understand how you came to the conclusion that this was even remotely implied.

> But I think you should consider focusing on this: "I'm sure there are ways to add accessibility to a web port of WX"

I think you should consider focusing on this: "I'm sure wxwidgets could follow basic accessibility best practices and leverage accessibility APIs which are provided by operating systems already for years."

> why not seize this moment to say "hey let's find ways to make WASM apps more accessible"

I'm not an WASM expert, but I'm versed in accessibility features specified by W3C and implemented in browsers. As WASM can interact with Javascript, and Javascript allows all kinds of web accessibility standards interactions, this part is solved. What's required then is a mapping from OS accessibility calls (wxwidgets' duty) to browserland (WASM's side). I don't know about WASM's status here, but wxwidgets will have to make its own first step. ...

ClawsOnPaws' comment is a tangent comment on an important aspect of any application: usability. It gives awesome insights about why Wavvy is unusable for visually-impaired users.

- I learned that Audacity has its own problems with accessibility; - I learned that Audacity uses wxWidgets, which especially is bad when it comes to accessibility. That already is great to know, as I'm now informed to avoid it in my projects - with bad accessibility always comes a generally bad usability. - Now port this to the web as in the currently presented Wavvy form and you get a hilarious clusterfuck of inaccessibility. I learned from the comment that usability by default and without explicit consideration just degrates with each layer added and each porting. - useful information that there exists some OCR software for what's currently shown on the screen.

In essence, ClawsOnPaws' comment has everything in it for why I come to Hacker News.

I don't have time now to reply to everything in here; there's a lot. But I did want to mention that I posted some thoughts about WASM accessibility here: https://news.ycombinator.com/context?id=32697514 which are hopefully valuable in terms of how the problem could be solved without rewriting a given target application.

With regards to the rest, suffice it to say that I don't find the slippery slope argument persuasive. Given, though, that we're mostly arguing about how to approach doing the thing we both agree should be done, figured I might try and think about things that actually achieve the goal instead.

Unless you have a legal requirement to provide accessibility, I encourage everyone to ignore this advice. It is basically letting perfect be the enemy of good. Especially if your project is opensource. Someone that cares, which may even be you at a later date when other things on the to-do list are done, can submit patches to address accessibility later.

Brace yourself: the "European accessibility act" will soon make accessibility a legal requirement to the private sector, including computers, operating systems, smartphones, and e-commerce.

https://ec.europa.eu/social/main.jsp?catId=1202

Have your popcorn ready to watch how this will freak out plenty of big corporations, rushing to fix their products, services, and websites from their accessibility "short-sightedness" of times past.

Depending on circumstances, failing to comply may cause heavy fines and having the product removed from market.

My guess is this show will peak in 2025.

I just read it and the requirement for computers applies to hardware and operating systems. Ecommerce sites are covered but website and mobile app requirements beyond that apply to communication, transportation and public sector systems. The vast majority of private sector systems will still not have a legal accessibility requirement.

> ... can submit patches to address accessibility later.

I'm not experienced with accessibility, but I pay attention to it whenever I can to increase my own awareness. A very common feedback when it fails (e.g. in software, online conferences, ...) is: "Accessibility must be part of the plan from early on. Trying to add it afterwards basically always fails."

> I feel like I should preemptively apologize

You should not. A mentor once told me that we disabled people tend to apologize too much. You are right to point out the problem of accessibility in this context, despite the negative responses you've received.

Of all the GUI toolkits with wasm ports, IMO wx is the most amenable to using native HTML controls rather than doing everything with canvas. I'm sure that kind of port would take more work though.

I've seen this discussion happen before and the same problem be pointed out re: WASM and canvas[1]. (I'm sure there are more examples than just that.) The trouble is that Canvas exists for a good reason: It is much more time-intensive to re-implement something like Audacity in the DOM than it is to render Audacity to a canvas.

So if we wanted to spend the time, could we be over-focusing on "just manipulate the DOM" as a solution? WASM conceives of the web browser as the "OS", or at least as hardware, and JavaScript as a means to manipulate that "hardware" (ask the browser to do things). Most operating systems expose APIs that let you do accessible things (read the screen, automate UI actions, etc.). Then frameworks like QT, for example, hook into those APIs from their own code to provide generic accessibility regardless of OS.[2]

So, maybe one half of the solution here is that to try to develop a neutral API WASM can use to emit accessibility information which can then be read by JavaScript running in the browser, and transformed into objects in the DOM? Then you could write an interface to that from your framework (something like QT would be a better starting point than wxWidgets, though, admittedly) and you'd get what you need.

Not that any of that is easy. But it would be fun, and naively, seems not too much harder than "rewrite app X in WASM to use the DOM" for much broader impact.

Maybe this discussion already happened and there are very good reasons not to do this - but I couldn't find anything about it in previous arguments.

[1] https://news.ycombinator.com/item?id=17349170 [2] https://doc.qt.io/qt-6/accessible.html

I'm surprised at the pushback against ClawsOnPaws here. Why would you not want to make your apps usable by as many people as possible?

I'd be interested to see the man-hours-needed : people-helped ratio when it comes to user accessibility. There's certainly a threshold where it simply doesn't make sense to put in a man year's worth of work to cater to a proportionally very small percentage of the population.

I'd like to politely challenge your assumption that accessibility concerns are relevant only to a "proportionally very small percentage of the population". It's a common myth in this space.

Disabled people represent between 10% and 20% of the world population, and that's not even including those who don't identify as disabled but would nevertheless benefit from more accessible technology. If you've ever adjusted the text size in your browser or enabled captions while watching media, this group includes you.

With this same argument, could we please also stop catering to the "special needs" of the LGBTQ+ community? That also affects only a tiny fraction of the population, yet everyone has to live with huge dropdown lists for 25 genders, web forms that ask for "pronouns", and (e.g. in Germany) the "gendering" of every single word?

/S

Actually, that's a good thing to keep in mind. I would not use this for anything serious right now, unless for some reason it perfectly fits all requirements one might have. I see this as useful more for fun side projects and as another commenter said, it's possible to improve accessibility later. Maybe text could be rendered as actual text over the canvas?

It's not just accessabilty, nothing but English works. Even the keyboard doesn't work as it's hardcoded to keycodes so click the top of the track and click "Name..." and try to enter é and nope let alone 音

I'm not trying to knock the app or the work put into wxWidgets. But, we need to not regress in supporting the entire world and not just the English speaking subset. I don't really want to go back to the 80s/90s. I like that in general, with HTML, international text input/editing just works.

Other wxWidgets apps don't have this problem.

other wxWidget apps running in the browser?

You meant wxWidgets-wasm?

Why don't you spend some time harangueing browser and other big tech engineers instead of blaming application developers at every turn? The tools we use are ultimately determined by the companies that make them. Complete GUI toolkits are some of the most expensive software to build. We are limited by whatever's out there. The fact that HTML is a poor framework for rich application development is no fault of your average software engineer. If you want to blame someone, blame upstream and the product managers who run the browser engineering projects.

I feel like it should be possible to build a universal accessibility tool using machine learning that relies on vision rather than native framework UI/toolkit support. The problem seems much more tractable than other AI projects like self-driving cars, and also more in the realm of existing successes that we've already seen with machine learning. The problem of inaccessible apps will only get worse as wasm becomes more mature, I feel like the only way to win is to sidestep the problem.

This may sound insensitive, but accessibility isn't usually the #1 concern when developing new projects. It is usually tacked on later in an update because it isn't a core feature and it affects only a small subset of users.

Rather than encourage everyone to never use WX widgets for any reason in a website, maybe you should be encouraging people (or working yourself) to add this accessibility feature.

". It is usually tacked on later in an update because it isn't a core feature and it affects only a small subset of users"

But thats not optimal, right? But most do not care, as long as they are not part if that subset.

I mean, I find it hard to care too much either, when my main concern are all the missing and buggy features, that needs fixing first..

Accessibility, like globalization, expands your market, and should be part of a long term strategy. But when building out new projects, its severely slows down feature development. Both should be seen as tech debt, but tech debt is not evil, just like debt is not even. You are borrowing from the future for present day benefits. Used wisely and you can create a successful project that can afford to spend time on accessibility. Waste too much time on accessibility to start and you may burn through all your resources before seeing any success.

I mainly agree, but does the numbers of blind people really justify it economic wise?

I allmost see accessibility as charity. I want to add it to my apps, mainly because it is not nice to ignore people needs(and who know, with bad luck I might end up in that group one day), but not because I expect great monetary returns.

"Allowing people to participate in society is great but hardly humanity's goal."

Not only does your comment show ignorance of a significant percentage of humans, it also shows you have zero idea of the fact that good accessibility provides service to everyone.

Have you ever struggled to use your smartphone while driving (temporary blindness, because your eyes are focused on the street),

or pressed the wrong button while sitting in a bumpy, shaking bus, because the button you actually wanted to press was way too small (temporary hand coordination disability)?

Accessibility's best practices also exist for everyone to enjoy a great usability.

Lol what? No you are right struggling to use your smart phone while driving and simultaneously being blinded by the sun are one of humanities great struggles. Let's get real accessibility has and will always take a back seat to innovation unless the innovator is in some way also disabled. You can always circle back around but no disabled person has any right to talk down to someone else because they weren't a first consideration.

Nice! Is it possible to merge this WASM port back into the wxWidgets main project? It just seems like a valuable target addition and could breathe some life back into wxWidgets.

> Audacity seemed like the obvious choice

Tangential question, but why did Audacity seem like the obvious choice? Not a knock on the product - I use it often - but I'm just curious about why it was chosen.

Audacity is one of the largest (if not the largest?) still active projects using wxWidgets, it seems like fairly obvious if you are somewhat aware of that.

Why did wxWidgets fell out of favor?

I don't think it did, the world just moved to mobile and web based apps, then backward towards the desktop with Electron.

I would say wxWidget and QT are probably still the most used cross platform desktop GUI toolkits.

I think there were some problems with wxWidgets and generally people moved to Qt, if they were still making cross-platform desktop apps, and if they haven’t migrated to Electron.

It's probably the most visible project using the wxWidgets framework and in the audio domain which fits well with my experience building the DJ app.

I recently needed a crop component that allowed my users to record something and trim it to their desired size. I ended up using wavesurfer.js with the regions plugin. It seems like there are very few components that meet this type of requirement.

This is awesome! Bookmarking this for sure!

I really dig your dj.app, it looks a lot like an app I sometime I use called Mixxx[1], which is open source[2]. But I think it's built using QT instead of wxWidgets. Anyways, now that I know there's a similar web-app available I might start trying dj.app out! thanks!

1. https://mixxx.org/ 2. https://github.com/mixxxdj/mixxx

I'm generally against web apps, but have to admit this one is really cool; it also loads surprisingly fast. So far the only difference with the original seems the waveform display which uses a smaller resolution, probably not to slow down too much the UI.

This seems like a really impressive technical work. Well done! I'd be interested in a write up of the process

Me too. Maybe just a blog post with the big details and some lessons learned. I tried a Qt app once to wasm. and it was just painfully slow and so buggy when I got done (mostly just unexplained crashes). I'm no pro though, it was just a weekend project.

Cool! The UI even works on iPhone (alas, playback doesn’t work, so my dreams of multitrack audio editing with just my thumbs are dashed /s)

I’m curious what porting wxwidgets involved — are you rendering them with the 2D canvas API, WebGL, or is all the rendering done by WxWidgets and you just have to send a framebuffer into a canvas?

Not the OP, but taking a look at the DOM, it's rendering each "window" as a canvas. So you have a main window canvas, then canvases for popup menus, message boxes etc. All canvases are using a 2d context, and there are many offscreen canvases created for each interaction for each widget which I assume are then composited to the window canvases.

It's an amazing project! If the OP is here, do you have any plans for accessibility to screen readers? I suppose it's a similar problem to that with Flutter.

I also wander if there is a possibility to combine your wxWidget port with the work going into WASM Python...

Edit:

Taking a closer looks at how the wxWidget port works, wxWidgets has multiple backends using native widgets on each platform. They also have wxUniversal which draws each widget itself to a frame buffer, this port uses that as a base to draw the ui to html canvases.

It is rendering using the 2D canvas API. There's a device context class (wxDC) for each wxWidgets port that implements primitive drawing ops (DrawLine, DrawText, etc). For the WASM port, I created a glue library in javascript [1] that wxDC calls into for each primitive.

[1] https://github.com/ahilss/wxWidgets-wasm/blob/master/build/w...

Doesn't the iOS version of GarageBand allow for multi-track editing?

Wow. How much work was the porting of audicity? It seems there's no commit history for wavvy.

OMG, finally a audacity version that won't crash my Wayland window manager. Unfortunately the recorded audio is really weird. Basically it tunes down the audio once I'm speaking, maybe some weird autogain racecondition between PulseAudio/Pipewire and Firefox?

Sounds a lot more like playing 44.1kHz audio through a 48kHz device

You are right, that might be it. I've tried setting all the preferences I could find to 44.1kHz though it's still the same.

Very impressive work! I tried to play some loops and add some effects. They all went well. Did you manually handle the audio or is it wrapped in the portaudio-wasm?

One thing I can learn from your work is to how the canvas is rendered. For my project Glicol (https://glicol.org) I use the Web Audio Analyser Node for visualisation but I am considering to use SAB to send even non-audio channels and render the canvas in real-time. It would be great to explore the process if you can write more on your GH repo.

What other options exist for "complex native-ish browser interfaces" in this style? E.g. if you wanted to develop a new app which is a traditional desktop GUI app with tons of menus and buttons that need to be custom rendered (so wasm/canvases presumably, rather than html), what options exist aside from this effort with wxWidgets?

For example, say you wanted to make a 3D editor/CAD program or full-featured DAW from scratch - what would you use?

Not a popular language/RAD these days, but I wouldn't rule out Lazarus/FPC.

https://github.com/zamtmn/zcad https://wiki.freepascal.org/Projects_using_Free_Pascal

Note that Lazarus isn't (yet) able to do web-based GUIs. Free Pascal only just added wasm support (not in a release yet, but it is part of the main branch), so all is needed (which TBH is kind of a big "all" :-P) is someone to make an LCL backend for it, so it might happen at some point.

I will use rust egui

I like this very much, especially because I love Audacity, but lately Audacity seems to be somewhat buggy as a native app on (Arch) Linux. With some versions I had rendering problems and buttons that didn't work (probably related to the widgets), with other version the whole sound system didn't work.

Can you comment on how difficult this was? and how much time it took?

I've thought about doing something similar with some open source games but have just never had the time.

The work is fantastic! I hope you enjoyed making it!

Bravo! This is fantastic!

I was excited to see Dr. Jeep's Hardcore mix of Dissociate in the default library for dj.app - that's been my jam lately, really niche track to come across in the wild :)

I feel so productive with this 90s type UI, and crisp mouse pointer

Awesome work, I love these kinds of ports! As someone working on a desktop environment in the browser, it's great seeing more apps coming to the browser.

Feels very similar to the real app. Zooming in with key macros isn't as accurate for some reason. Blown away by wasm. Truly the next frontier.

It leaks HTML elements (div + canvas) for every dialog (or maybe just About?), but I have to say, it is fucking impressive. Good work!

It's really impressive. Playback seems not to work in Firefox Nightly on Android but Chrome on Android works great.

Is there a way to record the output audio? Audacity on windows has the WASAPI option, which my wife has to use a lot.

Is File > Export not suitable? And if WASAPI can be used with your browser, won't it work for this? I don't really understand the use case though.

I mean record system output audio. E.g. audio streamed to speakers. Desktop Audacity can capture this audio directly on Windows. The specific use case is extracting the audio from long videos, to upload to a transcription service.

It’s an edge case for sure. Since the video is hosted weirdly and no video downloaders I’ve tried can get the video downloaded with the audio.

So we simply stream the video normally in the browser, and capture the audio output directly into Audacity.

Oh, I see, WASAPI as Audacity's input not output. Setting up a virtual microphone with something like VoiceMeeter might do it, since the browser would just see it as a microphone.

Oh, that looks promising! Thank you.

Are there terminal based keyboard first audio/video editors? Sort of like vim but for multimedia.

probably not what you're looking for but you might enjoy reading about Snd if you're not familiar [0].

side note, such a fun list of abandoned projects here [1] and here [2] to browse through.. many sadly broken links but i remember checking some of them out back in the day. there was so much activity in the open source audio sphere back in the early 2000s.

[0]: https://ccrma.stanford.edu/software/snd/snd/snd.html

[1]: http://www.linux-sound.org/one-page.html

[2]: https://wiki.linuxaudio.org/apps/daw_apps

This is amazing. I’m sure many HN would appreciate an in depth exploration of the porting process.

I bow my head to you sir... You have done what I've dreamed of many times. Thank you.

Wow! It feels like the native app.

Thank you for this. I've been looking for something like this for quick audio editing.

For me it plays back audio during recording, causing audio feedback screeches

i use Audacity -daily- for my podcast mixtape. its a bit buggy, occasionally crashes, and i have to reboot it everytime i plug in/out a different mic. hoping this solves my problems!

This is amazing work. Very well done. Congrats on the launch!

Very well done! Thanks!

Wow, it loads so quickly for me.

its crazy how this works better in my browser than on my macbook air M1

This is so awesome :)

impressive.

everything looks very smooth.

did you manually manage the sharedarraybuffer?

Excellent work!

woah dude

very nice

Now we just need to wrap this in Electron so we can run it on desktop! ;)

Relevant talk: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Thanks for the link, very good talk.

Nah, we ll just run it remotely through Mighty app

The OP mentioned this is a part of Audacity, so hopefully you were being sarcastic, but you can already do apt install audacity if you want a desktop app, as it already exists in the form of Audacity

you missed that it was a joke, it seems. a sad, realistic joke that makes me weep, instead of laugh.

This can't be better, another level

No, Tauri!

I think this was tongue-in-cheek. Nobody would actually want to take a native C/C++ Audacity, port it to WASM, and then wrap it in Electron to make it a "desktop app" again.

On the M1 Mac I actually measured lower CPU usage during audio playback on WASM compared to the native desktop version which uses Rosetta. I'm not sure if the slowness is due to Rosetta or a performance bug on the Mac port.

Supposedly[1], Audacity 3.2.0 will be available as an M1 native app.

Guess we’ll see then :)

[1]: https://forum.audacityteam.org/viewtopic.php?f=47&t=114242&s...

Niche hardware popular in the US alone? Mild shock.

It would give you safety properties that native Audacity doesn't have. It would also make distribution much easier.

> It would give you safety properties that native Audacity doesn't have. It would also make distribution much easier.

Has Audacity ever had safety issues in the past?

Because it sounds like you'll be going to a lot of effort to prevent a problem that had never surfaced in over a decade of use.

Not the sort of safety issues I think you mean, but there have been some rather questionable behaviours from the current owners in the last year or so. A quick search for Audacity here or elsewhere will find the details.

I'll save everyone the quick search. They added really basic opt-in telemetry, and then removed it after an out-of-proportion outcry.

Good write-up here: https://arstechnica.com/gadgets/2021/07/no-open-source-audac...

It wasn’t clear it was opt-in (although maybe the code was clear?).

Either way, adding telemetry (especially to open source) is obviously going to cause a ruckus, so they obviously mishandled the situation.

i dont understand privacy maniacs. have telemetry in from the start, nobody bats an eye. add it later, everyone freaks.

Simple, privacy "maniacs" do not install something with telemetry integrated by default.

So of course they freak, when it is suddenly creeping in, in something they trusted.

In the first case, intentions are clear from the start, so user trust can be built.

In the second case, intentions have been hidden or they have changed, which obviously erodes user trust.

especially if it's opt-in (which is provable since the project is entirely open-source) -- can people simply _not_ opt-in if they disagree with telemetry?

Audacity segfaults all the time when I use it. Don’t make it sound like it is more stable than it really is. Security bugs are a subset of bugs, of which Audacity has many.

also it would let you have a common target (wasm) for plugins so it doesn't matter if you're running on ARM/x86