3 ms·

You make good points. And I do think miki123211 is conflating memory safety with GC. But the concerns about Handmade software lacking important user-facing thi

You make good points. And I do think miki123211 is conflating memory safety with GC. But the concerns about Handmade software lacking important user-facing things like accessibility and internationalization are real. TO take one particularly ironic example, lots of tools in the field of audio production roll their own GUIs, and invariably, these UIs are completely inaccessible to screen reader users. I say this is ironic because "blind musician" is such a stereotype. To dispense with a straw man, it's true that Electron would not be a good fit for these tools. But maybe their developers could accept the size of something like Qt in exchange for a GUI that works for all users without having to roll it themselves. You say that engineers should be aware of trade-offs, but in my experience, way too many, even very talented engineers, seem to ignore this one.

ratww 6y ago
A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible. On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech. The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool and different from everyone else without taking a couple weeks (or maybe not even that much) to iron out accessibility issues. By the way, at least for plugins, another option is not doing any GUI at all and just exposing all parameters to the host, like the AirWindows guy does [1]. Or using native OS controls. This is both very accessible and EXTREMELY cheap. [1] http://www.airwindows.com http://www.airwindows.com
- mwcampbell 6y ago
  No disagreement there. Still, there are also developers who go out of their way to make their software both cool-looking and lean and mean by rolling their own GUI toolkit... and now it would take them way longer to implement accessibility.
  - deleted 6y ago
    [deleted]
  - ratww 6y ago
    I agree, but it sounds to me that the issue then is not with lean and mean code per se. Both AirWindows and people using native interfaces in plugins are leaner, meaner and more accessible than your example. And by the way, to keep on topic, "handmade" audio software people are not really creating their own GUI toolkit. That's the big boys at Waves, Native Instruments, IK Multimedia, etc. The problem to me is that people are trying to make things that look exactly the same everywhere with complete disregard for both the user and the particularities of each platform. And by platform I don't just mean the OS: one of my pet peeves with audio software are plugins that skip the DAW's preset saving and implement their own. The walked an extra mile only to give me a shitty interface when I wish I could just use Logic presets or whatever.
PaulDavisThe1st 6y ago
There are much deeper and more sophisticated reasons why inaccessibility to screen readers is not really the core of why we should consider audio production software to be inaccessible. This is a debate/discussion I've been having for 20+ years now (as the original author of Ardour). The GUI of a typical DAW (or even a moderately sophisticated plugin) serves as memory aide for sighted users. 48 tracks? Which ones did I mute? A sighted user doesn't have to remember - they can just look. Sight-impaired/blind users of older hardware mixing consoles use the tactile experience of those devices to partially fulfill the same role, which is why modern full digital consoles with tap-only-LED-lit buttons are so much harder for them to use: they have to either remember or investigate which features are enabled and which are not. In addition, most DAW and many plugin GUIs present information in ways that are more or less inconceivable for screen reader presentation. Waveforms are the obvious example, although here perhaps sight-impaired users have what some would consider an advantage, in that they are forced to work entirely by ear, rather than use on-screen representations that have only a debatable relationship with the sound. But routing presents another area where it can be very difficult to present the current state in a way that could ever be rendered meaningful by a screen reader. Please don't think that I don't view accessibility or i18n as of critical importance - I absolutely do. But I also think that when application niches (like audio production) evolve their own highly-developed visual language to supplement and assist (sighted) users, that the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation. This is one area in which Linux is far ahead of Windows and macOS: there are numerous command line applications available for audio production which would strike utter fear into the hearts of most sighted users, but that turn out to be incredibly great for sight-impaired users. Ecasound, I'm looking at you (among others).
- mwcampbell 6y ago
  You obviously know way more about this field than I do. I'm a dilettante when it comes to recording in general, never mind developing a DAW. Thanks for sharing your thoughtful insights. > the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation. This cuts to the heart of a long-standing debate among accessibility advocates and blind techies. It's true that tools tailored specifically for blind people can be more productive and easier to use. But they can also isolate the blind community from the sighted mainstream. For example, would a DAW developed specifically for blind people enable them to collaborate with sighted peers, or to use one-of-a-kind plugins that are developed for mainstream DAWs with a visual interface? This is why, while retrofitting accessibility onto a GUI is often suboptimal, it's necessary.
suyjuris 6y ago
What do you think about the following trade-off? (a) make a software accessible to 99.9% of the population with base-level quality-of-life (b) only be accessible to 98% but increase quality-of-life by 5% for the rest (I am not trying to make a point, just curious.)

ratww 6y ago

A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible. On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech. The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool and different from everyone else without taking a couple weeks (or maybe not even that much) to iron out accessibility issues. By the way, at least for plugins, another option is not doing any GUI at all and just exposing all parameters to the host, like the AirWindows guy does [1]. Or using native OS controls. This is both very accessible and EXTREMELY cheap. [1] http://www.airwindows.com http://www.airwindows.com

mwcampbell 6y ago
No disagreement there. Still, there are also developers who go out of their way to make their software both cool-looking and lean and mean by rolling their own GUI toolkit... and now it would take them way longer to implement accessibility.
- deleted 6y ago
  [deleted]
- ratww 6y ago
  I agree, but it sounds to me that the issue then is not with lean and mean code per se. Both AirWindows and people using native interfaces in plugins are leaner, meaner and more accessible than your example. And by the way, to keep on topic, "handmade" audio software people are not really creating their own GUI toolkit. That's the big boys at Waves, Native Instruments, IK Multimedia, etc. The problem to me is that people are trying to make things that look exactly the same everywhere with complete disregard for both the user and the particularities of each platform. And by platform I don't just mean the OS: one of my pet peeves with audio software are plugins that skip the DAW's preset saving and implement their own. The walked an extra mile only to give me a shitty interface when I wish I could just use Logic presets or whatever.

PaulDavisThe1st 6y ago

There are much deeper and more sophisticated reasons why inaccessibility to screen readers is not really the core of why we should consider audio production software to be inaccessible. This is a debate/discussion I've been having for 20+ years now (as the original author of Ardour). The GUI of a typical DAW (or even a moderately sophisticated plugin) serves as memory aide for sighted users. 48 tracks? Which ones did I mute? A sighted user doesn't have to remember - they can just look. Sight-impaired/blind users of older hardware mixing consoles use the tactile experience of those devices to partially fulfill the same role, which is why modern full digital consoles with tap-only-LED-lit buttons are so much harder for them to use: they have to either remember or investigate which features are enabled and which are not. In addition, most DAW and many plugin GUIs present information in ways that are more or less inconceivable for screen reader presentation. Waveforms are the obvious example, although here perhaps sight-impaired users have what some would consider an advantage, in that they are forced to work entirely by ear, rather than use on-screen representations that have only a debatable relationship with the sound. But routing presents another area where it can be very difficult to present the current state in a way that could ever be rendered meaningful by a screen reader. Please don't think that I don't view accessibility or i18n as of critical importance - I absolutely do. But I also think that when application niches (like audio production) evolve their own highly-developed visual language to supplement and assist (sighted) users, that the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation. This is one area in which Linux is far ahead of Windows and macOS: there are numerous command line applications available for audio production which would strike utter fear into the hearts of most sighted users, but that turn out to be incredibly great for sight-impaired users. Ecasound, I'm looking at you (among others).

mwcampbell 6y ago
You obviously know way more about this field than I do. I'm a dilettante when it comes to recording in general, never mind developing a DAW. Thanks for sharing your thoughtful insights. > the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation. This cuts to the heart of a long-standing debate among accessibility advocates and blind techies. It's true that tools tailored specifically for blind people can be more productive and easier to use. But they can also isolate the blind community from the sighted mainstream. For example, would a DAW developed specifically for blind people enable them to collaborate with sighted peers, or to use one-of-a-kind plugins that are developed for mainstream DAWs with a visual interface? This is why, while retrofitting accessibility onto a GUI is often suboptimal, it's necessary.

suyjuris 6y ago

What do you think about the following trade-off? (a) make a software accessible to 99.9% of the population with base-level quality-of-life (b) only be accessible to 98% but increase quality-of-life by 5% for the rest (I am not trying to make a point, just curious.)