Show HN: Wavvy – web-based audio editor (Audacity port)

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...

ClawsOnPaws · 3 years ago

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.

ivraatiems · 3 years ago

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?

tssva · 3 years ago

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.

mwcampbell · 3 years ago

> 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.

lukasb · 3 years ago

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?

antoineMoPa · 3 years ago

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?

greggman3 · 3 years ago

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.

melony · 3 years ago

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.

suby · 3 years ago

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.

naet · 3 years ago

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.

itsagavin · 3 years ago

Accessibility is great but its hardly humanity's goal. In most instances your burden is no one else's unless we are talking life or death.

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?

samwillis · 3 years ago

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.

ahilss · 3 years ago

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...

tobsterius · 3 years ago

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