Please, please, please don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones, when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing. Unless someone puts in all the extra effort to implement platform-specific accessibility APIs for said toolkit. Inaccessible DAW plugins are a problem for blind musicians and audio engineers because of GUI toolkits like this one. Maybe screen readers will eventually use some kind of machine learning to provide access to otherwise inaccessible GUIs, but that’s probably still a long way off. So for now, we need application developers to do their part.
I don’t actually know what the best cross-platform solution is. Is wxWidgets fully functional in a context where it doesn’t own the event loop? I suspect not on Windows in particular. Yes, yes, I know it’s ugly 90s C++, but really, what’s more important, code aesthetics or usability?
> Please, please, please don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones, when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing.
Um, I have normal but aging sight, and I still can't get a DAW that actually scales its widget to something other than 200% (or 150% if I'm reaaaaally lucky).
I have no GUI that renders at useful speeds using OpenGL or Vulkan.
The Photon author didn't just create this to be contrary. Modern OS GUIs don't work very well for things like DAWs because DAWs often operate much more like a game wherein the screen is animated and has 60fps of stuff going on.
Rather than complaining, write us all an open source GUI that doesn't suck and people will happily use that and then people will write the accessibility hooks for it.
> DAWs often operate much more like a game wherein the screen is animated and has 60fps of stuff going on.
This is puzzling to me. Do sighted DAW users really rely on such a high-bandwidth, continuous flow of visual information? What kind of information? Mainly volume meters, or other things as well?
FWIW, I'm just starting to dabble with a DAW myself. But I know that blind people have successfully done all stages of music and other audio production using a DAW. From what I understand, they do it by concentrating solely on the audio itself during real-time playback and recording. But the UI does need to be accessible for non-real-time work, e.g. plugin configuration, switching tracks, switching instruments, or making precise edits.
At least VST allows you to switch to and from using basic controls and the full plugin UI. Actually, if your plugin does not provide a UI, the DAW host will provide a generic one for you, with basic controls like sliders, drop-down menus, etc. that map to the parameters that your plugin use. You should probably just use those if you are blind, again assuming that the host provides all the accessibility features you need (I am not sure if all VST hosts do, you should check).
First of all, I doubt that writing yet another toolkit of my own would be the solution. How could I know that anyone would adopt it? And as for spending time contributing to an existing toolkit, which toolkit? I read about several per year here on HN. That's why I've been pleading with developers to use platform widgets, or cross-platform toolkits that wrap those widgets (like wxWidgets), wherever I can. But the replies on this thread have convinced me that sometimes, the platform widgets really do leave a lot to be desired. So, I don't know what to do instead.
You don't. But if it's better, people will actually use it. This is currently a glaring hole in the software development landscape screaming for a better solution.
I'm currently in a similar boat as the Photon author and I have a much more prosaic application. But I have a lot of interaction with OpenGL and the GUI system, and none of the GUI toolkits like that.
Photon is simply doing the same thing that GTK did originally--GTK was written specifically for the GIMP and only later did it become general purpose.
> And as for spending time contributing to an existing toolkit, which toolkit?
That's your choice to make. And your efforts help make those decisions. The toolkit that attracts motivated people and improves starts gaining momentum and attracts more people. Even a single motivated individual can tip the balance when things are unsettled.
Unfortunately, this is not a well-trod and settled area. Part of being on the bleeding edge is that you get cut.
FWIW, Photon scales well. One issue is that DAWs may or may not allow scalable UIs. VST2 for example, is not designed to be scalable, but VST3 is. I'm very open to addressing accessibility if anyone wants to do some work on it.
It isn’t really a problem of being cross platform: I don’t think platform UIs have enough richness to handle such applications without a lot of non standard components. You can only do so much with sliders.
Likewise, accessibility capabilities rely on very standard generic UI capabilities. Once you go beyond that with professional tooling, accessibility will have to be custom as well.
I'm not convinced that standard controls are insufficient for a DAW plugin UI. Can you please explain why? Is it all about looks, or are there actually usability problems for sighted users?
Let me flip that question around: given what the plugin UI does, how would the interface actually look using LCD UI components and would the experience even be meaningful for unsighted users?
Real time scrubbing and mixing with...a screen reader...how does that even work? I’m sure it could work, but you would still wind up with something as custom as seen here, perhaps even more so. Accessibility isn’t a free lunch except in very generic limited use contexts.
Hi I'm Joel, the the author of Photon. Just wondering, do you know any significant (or perhaps even insignificant) VST or AU plugin that uses standard platform widgets? I wonder how that would look like.
The closest ones I can think of are not VST or AU, but the Audacity LADSPA plugins. They are not platform native either, but rather GTK+. They are fairly simple with just buttons/sliders. It's the best example I can think of.
Same here. And for that matter, all DAWs I know also do not use standard platform widgets. Logic Pro, Reaper, Ableton, Pro Tools, Cubase etc. all use their own custom UI elements.
You're right about the DAWs, though last time I checked, REAPER on Windows uses some standard Win32 controls in its dialogs, which helps. Also, REAPER has rich enough plugin support that a couple of plugins have been written to hack screen reader support into REAPER. In particular, check out the open-source OSARA [1] project. This work-around isn't feasible for making plugins accessible, since those plugins are generally not as hackable as REAPER itself. I don't know about other DAWs.
You spend a minuscule amount of time with Dialogs. You spend Most of the time in the project window itself, the mixer, transport, and all the plugins. None of those use standard controls. If they did, they would've pleased all blind users (assuming they do implement the accessibility features you mention), but turned off everyone else because of the bland, ugly and difficult to use UI, not to mention that there are only a very limited set of standard controls. I doubt Reaper would be the success it is now, if it were so.
Having said that, hey, this is Open Source! Like Reaper, I am willing to support accessibility if you, or anyone else is willing to do the extra effort.
> And noone asked me for accessibility, zero people.
It's possible that blind DAW users have just gotten tired of trying to advocate for accessibility in plugins. I thought I had a chance on this thread, since I would potentially be reaching several developers, including future plugin developers who haven't yet chosen a toolkit, instead of having to write to one at a time.
I'm pretty sure that there is enough incompatible design between the platforms to make a cross-platform UI using native widgets infeasible. Between Windows, macOS, and X Windows, I'll guess that one of them picks a different meaning of (x,y)--is it the center of the pixel or the upper left? I'm guessing that Cocoa/UIKit's constraints are incompatible with Android's gravity, and what do you do on Windows, which has nothing at all (at least for Win32). Do you re-implement Apple's constraints for Android? Vice-versa? What do you do if you have limited space and you can't fit Windows' large edit boxes but macOS's svelte edit boxes fit snugly? Windows' control expand into their frame, but macOS's controls frequently have padding, which means that for Windows you need to add padding between the controls, but on macOS you put the controls next to each other and the internal padding does it all for you. And for some platforms, it's not even clear what the native widgets are: is Win32, WinForms, WPF, or UWP the native widget set for Windows? Is Gtk or Qt/KDE the native widget set for Linux?
> but really, what’s more important, code aesthetics or usability?
Well, if you want software developers to write using it, code aesthetics is pretty important. Code aesthetics is usability to software developers. End-user usability does tend to trump code aesthetics if you want to get money out of the software you write, but even then, code aesthetics is still a consideration.
> what’s more important, code aesthetics or usability?
My guess is that the answer to this is similar to "what is more important, developer friendliness or minding resource use for users with less capable computers?" that gave rise to Electron.
And i'll also bet that there are way more users that have low end computers than users who rely on OS-supplied usability features.
I don’t actually know what the best cross-platform solution is. Is wxWidgets fully functional in a context where it doesn’t own the event loop? I suspect not on Windows in particular. Yes, yes, I know it’s ugly 90s C++, but really, what’s more important, code aesthetics or usability?