6 ms·

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 utilit

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. [1]: https://www.photopea.com/ https://www.photopea.com/

russellbeattie 3y ago
If all the browsers, including mobile ones, would implement all of the the FileSystem Access APIs, these types of apps would be even more usable. https://developer.mozilla.org/en-US/docs/Web/API/File_System_API https://developer.mozilla.org/en-US/docs/Web/API/File_System...
- meepmorp 3y ago
  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.
  - russellbeattie 3y ago
    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.
    - tambourine_man 3y ago
      What useful features aren’t implemented in other browsers?
      - danShumway 3y ago
        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.
        3y ago
mock-possum 3y ago
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!
- StevePerkins 3y ago
  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.
  - gochi 3y ago
    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.
    - whyoh 3y ago
      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.
  - autoexec 3y ago
    > 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.
autoexec 3y ago
> 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/ 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.
- asddubs 3y ago
  IMHO the spyware angle was overblown. they added telemetry to the dev builds. the real thing I took issue with was adding a CLA after the fact
  - lost_tourist 3y ago
    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
    - asddubs 3y ago
      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.
- rcme 3y ago
  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.
8n4vidtmkvmk 3y ago
Yeah I didn't expect Photopea to be any good but now I use it all the time. Perfect Photoshop replacement for light editing.
- lost_tourist 3y ago
  better than gimp?
  - erhaetherth 3y ago
    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.

russellbeattie 3y ago

If all the browsers, including mobile ones, would implement all of the the FileSystem Access APIs, these types of apps would be even more usable. https://developer.mozilla.org/en-US/docs/Web/API/File_System_API https://developer.mozilla.org/en-US/docs/Web/API/File_System...

meepmorp 3y ago
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.
- russellbeattie 3y ago
  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.
  - tambourine_man 3y ago
    What useful features aren’t implemented in other browsers?
    - danShumway 3y ago
      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.
      - 3y ago

mock-possum 3y ago

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!

StevePerkins 3y ago
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.
- gochi 3y ago
  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.
  - whyoh 3y ago
    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.
- autoexec 3y ago
  > 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.

autoexec 3y ago

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

asddubs 3y ago
IMHO the spyware angle was overblown. they added telemetry to the dev builds. the real thing I took issue with was adding a CLA after the fact
- lost_tourist 3y ago
  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
  - asddubs 3y ago
    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.
rcme 3y ago
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.

8n4vidtmkvmk 3y ago

Yeah I didn't expect Photopea to be any good but now I use it all the time. Perfect Photoshop replacement for light editing.

lost_tourist 3y ago
better than gimp?
- erhaetherth 3y ago
  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.