Noticed increased accessibility on the Mac

Hi, Martin, I want to say I've upgraded to Hauptwerk 8, and right away, when the dialog came up to load an organ, I noticed that things in Hauptwerk windows, control panels and such are now visible to VoiceOVer. This is great, and definitely a very, very good thing to see. Haven't fully explored the interface to see just how accessible it is yet, but will provide more feedback as I do. This is definitely a great thing, rather than getting, "Hauptwerk has no windows," all the time, as I did with Version 4, through 7. Thanks a lot, Dan.

[mdyde]

Hello Dan,

Thanks very much for upgrading, and glad to hear v8 works better for you with Apple's VoiceOver. (Compared to previous versions, the main relevant difference is that v8 uses a newer version of the Qt multi-platform library, which I understand has improved support for VoiceOver.)

Hi Martin, just wanted to come in here and provide additional feedback, after having had HW 8 a few days now. I can do things like load different combination sets, temperaments and that sort of thing ok, which is very cool. Never was able to do that before. When it comes to screens like the voicing screen for example, or the screens to set up where things are on your console, under organ settings, keyboards, stops, buttons and pistons for this organ, etc, I'm unable to see which control, or rank I've selected to work with. that is not spoken when arrowing through the list of controls, or ranks in the voicing screen for example. I'm unable to tell what control I've selected in those screens. VO just says, Group, rather than the name of what I've selected. Whereas in the window to load a combination set for example, when arrowing through the list of them, the name of the one I'm on, is spoken, so I can just hit return on it and load it. same with loading different temperaments, or even organs, via the load organ window. Those are spoken, when arrowing through my list of organs. Also in the voicing window, there are some buttons, that to VoiceOVer, just say, "Button,", they're unlabeled, so to the screen reader user, a button, that just says, "Button," doesn't give the screenreader user any idea of what the button does. Exploring around a bit with the VoiceOver cursor for example, gives me an idea of what rank I'm working with in the Voicing screen, but I find that's hit and miss to get at that information. IT'd be nice if it was spoken, like names of organs, and combination sets are , when just arrowing through those lists. Also, additionally, a lot of hot keys in Hauptwerk, use the control and option keys, along with other keys . These by default on a Mac, control-option that is, are the VOiceOVer modifier keys. . It might be a good idea to advise somewhere in the user guide, that if using VoiceOVer, it's a good idea to set the VOiceOVer modifier to be caps lock, so they're Aren't conflicts, and that this can be done under the general section of VoiceOver utility. If the things I've outlined above, could be fixed in an update to HW 8, that'd be great. Just thought I'd come in, and add to this thread, to provide additional feedback. Thanks. Dan

[mdyde]

Thanks very much, Dan.

I've added your notes to our request log about potentially improving compatibility with VoiceOver.

Hi Martin,

I emailed Francois after only just hearing about Hauptwerk 8, someone had mentioned a new release and I thought I'd check out if anything had happened to give some usability to VoiceOver, the release notes gave some good hints, so, ok I'm not a hauptwerk owner yet, just evaluating the trial, but I was blown away, absolutely stunned. It felt good running Hauptwerk for the main areas, but the organ library that comes with the trial, I couldn't interact with it at all.

I've created a screen recording and hope it's of help, Francois did say he was passing my email over to devs which is great. I just hope there's a solution to this issue somewhere. I've suggested a couple of ideas, not sure how viable they are to you, but worth a shot.

Thank you for making Hauptwerk blind friendly at stage, it means so much to me. At some point, when I know that there would be a way to make the libraries compatible with VoiceOver navigation, then I'll go and purchase a perpetual license for my ilok.

here's the video...

https://drive.google.com/file/d/1bms8LP ... RhOK9/view

If there's any way I could contact you off list, I'd really appreciate hearing from you. I know you're busy, but you're a miracle worker.

lew

[mdyde]

Hello Lewis,

Thanks very much for the feedback and information, and also for the continued interest in Hauptwerk. Glad to hear that v8 (and especially the newer Qt multi-platform library version it uses) helps to a worthwhile extent with compatibility with compatibility with Apple's VoiceOver.

We're aware that there are some areas of Hauptwerk that still aren't readily accessible to visually-impaired users, particularly sample sets' graphical virtual consoles, and I've added your notes to the existing enhancement request regarding that.

As a work-around, although the virtual organ console is graphical, if you have plenty of MIDI pistons/stops/buttons, or something like a Novation Launchpad X (which has lots of MIDI buttons), you could conceivably auto-detect the virtual stops/pistons to MIDI stops/pistons/buttons via the "Organ settings | Stops/couplers//... switches ..." settings screen, and MIDI keyboards via "Organ settings | Keyboards" settings screen. However, I do appreciate that wouldn't be ideal, in that you would need to remember which virtual stops were assigned to which MIDI stops/pistons/buttons and, unless those MIDI stops were solenoid-actuated or some other type of physically bi-state MIDI switches, there might not be any way of telling whether they were drawn or not (aside from sound).

Once controls have been auto-detected (e.g. via the settings screens), Hauptwerk is designed to be fully usable 'headless' via MIDI -- without any computer monitor, mouse, or computer keyboard, e.g. from a a solenoid-actuated MIDI organ console.

Hi Martin,

Thanks for the amazing reply.

How would the autodetect function work for a custom console build, I.E: a non standard build / known console make? I ask as my console is hand built (still tweaking it's design a touch) so it's based on a 20 stop per division, 4 manual + pedal, couplers are on the manual boards as well as pistons, etc same for trems which are at the top of the console above the solo manual, etc as well as master functions such as the sequencer. it's a console that's taken me 3 years including experimental software before I started working with a company making one of their organ systems blind friendly before official release but I'd rather have hauptwerk for a 4 manual setup and the cathedral organs I'm used to working with.

Does the autodetect function walk you through pressing each stop, coupler, piston, etc so that you can map out a console?

Based on the GUI for the organ libraries, could the QT library extend to interaction with the graphical side of the libraries, or is the design of the interface based on something else? I don't know the design method. Is there a way with the custom organ designer to embed accessibility resources in to each library, so that stops, couplers, pistons, trems, other functions, etc can be recognised and navigated / interacted with through VoiceOver / other screen readers?

One solution I thought about was based on a GUI description by a friend and Hauptwerk owner who described one of the libraries he uses where instead of the console view, it showed as a dual jamb view, but with that dual jamb view which would be ideal for touch screens, it would also extend to adding the necessary functions like general pistons, divisional pistons, couplers, trems, etc, the vitals basically of a 4 manual console, so you could have to the left of the panel the pedal as column 1, Choir as column 2, Great as column 3, Swell as column 4, solo as column 5, from there to the bottom of the page you could have couplers, trems and sequencer buttons and furthest right to the columns for divisions, the divisional pistons and general pistons to top. the screen reader can easily navigate this as I've worked with someone on a concept for another system a while back and it worked quite nicely, but wasn't designed for hauptwerk, but could be.

I want to at some point purchase hauptwerk, but it does concern me about setting up a console and being able to work around the environment. the bottom toolbar descriptions are somewhat confusing and it would be a help to have a bit clearer descriptions of the buttons and button states (on / off)

Here's a question for you...

would it be possible, without voiceover, but by using either macOS or Windows speech synthesis engine, to have stops, pistons, etc spoken out from a midi event, say you engage a stop for an 8' flute, the midi event would trigger the speech server to announce "Great - 8' flute ON"

lew

Hi Martin, just a quick addition to my reply to you. this might help...

regarding my suggestion about an option which could be turned on and off in preferences for hauptwerk for spoken announcements, I don't know if you know much about a developer called Native Instruments, a good company, they develop the Komplete Kontrol series hardware controllers and the software called Komplete Kontrol. Part of the software's support includes spoken announcements for the blind, it doesn't use a screen reader, it relies on either the microsoft or macOS speech synthesis server / engine to announce events. With the komplete kontrol setup, you're relying on the software with the function enabled, so that any button press is spoken, control knob change is spoken, etc, the problem with the software is that a screen reader doesn't actually work with it due to the way it's been developed, so it has a bit of an aronic method. I used to use their software and hardware but became so fed up of the fact the software itself couldn't be navigated by a screen reader either in Windows or MacOS, yet they expected blind users to set up the software using "sighted help" just to achieve the spoken UI, yet the laugh of it was that the Native Instruments software installer and manager is blind friendly, odd but ah well.

so, is there a series of components or resources as part of QT or other tools in your box of tricks which could call upon the speech server to announce events based on midi event triggers? if so, that would provide a blind person with a unique opportunity.

One challenge I face at times as an organist is when I work at a location with a console I don't know it's layout or it's stops, so either sighted help from the senior or assistant organist to the site, or if my ORCAM MyEYE Pro can handle it or just feeling my way around and learning the environment, it's a challenge. This is why I started researching and trying to develop an environment for blind organists where a console can speak out functions through either the system audio or dedicated audio interface to an ear bud while the main console audio goes through it's own interfaces.

Is this something you think you could achieve? if so, I'm up for helping you achieve it and test it.

lew

hi va3ets, I completely agree, yes there are some buttons lacking descriptions, there are also buttons with vague / puzzling descriptions and help references, so it's certainly a bit of a puzzle.

Testing VoiceOver on MacOS 13.6 with the demo of hauptwerk 8.1 on a 2020 16" Macbook Pro, there's definitely a few things to fix including as said, unlabelled and poorly described buttons, but as mentioned to Martin, looking at ways to make the libraries accessible to voiceover, and also a method of using the speech synthesis server to announce midi events assigned for stops, pistons, trems, couplers, sequencer, etc to be announced to the system audio as with voiceover so that the main audio for hauptwerk isn't contaminated, that's what I recommend as an audio engineer / developer.

We're getting there, aren't we? feels exciting to know that we're closer to an accessible organ environment.

How are you working with hauptwerk? are you using a custom or manufactured organ console? if so, how did you find setting it up to engage with stops, etc? I'd love to know your experience with this before I decide to bite and purchase a license.

lew

[mdyde]

Hello Lewis,

How would the autodetect function work for a custom console build, I.E: a non standard build / known console make? I ask as my console is hand built (still tweaking it's design a touch) so it's based on a 20 stop per division, 4 manual + pedal, couplers are on the manual boards as well as pistons, etc same for trems which are at the top of the console above the solo manual, etc as well as master functions such as the sequencer. it's a console that's taken me 3 years including experimental software before I started working with a company making one of their organ systems blind friendly before official release but I'd rather have hauptwerk for a 4 manual setup and the cathedral organs I'm used to working with.

Any given virtual controls (stop, piston, keyboard, expression pedal, etc.) is auto-detected via a wizard (separately, for each control), which can be invoked by either:

1. If it's a native control within the sample set (e.g. stop), by right-clicking on the virtual control on the graphical virtual console, . Without sight, presumably you won't be able to know where to click to do that, since sample sets' graphical consoles aren't navigable by keyboard shortcuts.

2. Or if it's a Hauptwerk menu function (e.g. master general combination), by right-clicking on it on an applicable control panel (or on the Touch Menu). Those controls may be navigable from keyboard shortcuts, and thus feasible without sight.

3. Alternatively, you can use the relevant settings screen on the "General settings" or "Organ settings" menu, such as "Organ settings | Keyboards". For those settings screens you need to select the relevant item (e.g. the virtual keyboard) in the item list, then press the "Auto-detect settings" button.

However, I've checked, and the item lists on the real-time MIDI settings screens that you would need to use for 3 (e.g. "Organ settings | Keyboards") don't appear currently to be readable from screen-reader software, so unfortunately I don't think you would be able to configure MIDI to a sample set's virtual controls currently after all. The next version of Hauptwerk should fix that, so I would recommend waiting until whenever that's released, and then trying Hauptwerk again to see whether it would be usable for you.

With regard to a MIDI implementations to use for MIDI stops/couplers/tremulants/pistons if building/commissioning a MIDI organ console, here is the relevant text from the Hauptwerk user guide:

If you are building a new MIDI organ console or new MIDI hardware for Hauptwerk then we recommend that MIDI switches and pistons use MIDI NRPN-on/off messages (on value=127, off value=0) and that if a MIDI switch supports MIDI output (for example, if it is solenoid-actuated or illuminated) then we recommend that it should receive identical MIDI messages to those it sends (thus making it possible for Hauptwerk to configure MIDI output to it automatically during auto-detection).

If you are building a new MIDI organ console for Hauptwerk using MIDI encoder circuitry that doesn't support NRPNs, then we recommend instead using MIDI note-on/off messages for switches and pistons, again ensuring that each MIDI switch receives identical MIDI messages to those it sends (if the MIDI switch supports MIDI output)

If you were to make your console's stops solenoid-actuated (using a suitable MIDI implementation, as above) then you would in principle be able to feel whether any given MIDI stop was on or off.

Does the autodetect function walk you through pressing each stop, coupler, piston, etc so that you can map out a console?

No -- you need to auto-detect each one individually.

Based on the GUI for the organ libraries, could the QT library extend to interaction with the graphical side of the libraries, or is the design of the interface based on something else? I don't know the design method. Is there a way with the custom organ designer to embed accessibility resources in to each library, so that stops, couplers, pistons, trems, other functions, etc can be recognised and navigated / interacted with through VoiceOver / other screen readers?

Sample sets' virtual consoles are entirely graphical (they don't use Qt buttons, or operating system buttons, for example), so you wouldn't currently be able to navigate them with keyboard shortcuts, or use them from screen reader software, I'm afraid. In order for them to be usable we would need to develop an alternative mechanism (e.g. a new window containing standard text-based Qt/operating system buttons for the stops and pistons). We do have that logged as an enhancement request (but I can't promise when, or even whether, it will be implemented).

Hence at the moment, the only way that I think you might be able to use it is if you auto-detected them to physical solenoid-actuated MIDI stop switches and MIDI pistons (and in order to auto-detect them you would either need help from a sighted person, or to wait for the the next version of Hauptwerk so that you could auto-detect via their settings screens from screen reader software).

One solution I thought about was based on a GUI description by a friend and Hauptwerk owner who described one of the libraries he uses where instead of the console view, it showed as a dual jamb view, but with that dual jamb view which would be ideal for touch screens, it would also extend to adding the necessary functions like general pistons, divisional pistons, couplers, trems, etc, the vitals basically of a 4 manual console, so you could have to the left of the panel the pedal as column 1, Choir as column 2, Great as column 3, Swell as column 4, solo as column 5, from there to the bottom of the page you could have couplers, trems and sequencer buttons and furthest right to the columns for divisions, the divisional pistons and general pistons to top. the screen reader can easily navigate this as I've worked with someone on a concept for another system a while back and it worked quite nicely, but wasn't designed for hauptwerk, but could be.
...
would it be possible, without voiceover, but by using either macOS or Windows speech synthesis engine, to have stops, pistons, etc spoken out from a midi event, say you engage a stop for an 8' flute, the midi event would trigger the speech server to announce "Great - 8' flute ON"
...
regarding my suggestion about an option which could be turned on and off in preferences for hauptwerk for spoken announcements, I don't know if you know much about a developer called Native Instruments, a good company, they develop the Komplete Kontrol series hardware controllers and the software called Komplete Kontrol. Part of the software's support includes spoken announcements for the blind, it doesn't use a screen reader, it relies on either the microsoft or macOS speech synthesis server / engine to announce events. With the komplete kontrol setup, you're relying on the software with the function enabled, so that any button press is spoken, control knob change is spoken, etc, the problem with the software is that a screen reader doesn't actually work with it due to the way it's been developed, so it has a bit of an aronic method. I used to use their software and hardware but became so fed up of the fact the software itself couldn't be navigated by a screen reader either in Windows or MacOS, yet they expected blind users to set up the software using "sighted help" just to achieve the spoken UI, yet the laugh of it was that the Native Instruments software installer and manager is blind friendly, odd but ah well.

so, is there a series of components or resources as part of QT or other tools in your box of tricks which could call upon the speech server to announce events based on midi event triggers? if so, that would provide a blind person with a unique opportunity.

One challenge I face at times as an organist is when I work at a location with a console I don't know it's layout or it's stops, so either sighted help from the senior or assistant organist to the site, or if my ORCAM MyEYE Pro can handle it or just feeling my way around and learning the environment, it's a challenge. This is why I started researching and trying to develop an environment for blind organists where a console can speak out functions through either the system audio or dedicated audio interface to an ear bud while the main console audio goes through it's own interfaces.

Is this something you think you could achieve? if so, I'm up for helping you achieve it and test it.

Thanks very much for the suggestions, and offer. I've added your notes to our enhancement request log for reference. It isn't something that I can be involved with at the moment, I'm afraid, and we can't make any promises about when (or even whether) any given enhancement request would be implemented, but it's logged so that it won't be forgotten and can be considered for the future, and we do of course consider it desirable for Hauptwerk to be as usable as possible by visually-impaired users.

As above, I'd recommend waiting until the next version is released, then re-testing it, and seeing whether using it via solenoid-actuated MIDI stops and MIDI pistons would be viable for you at that time.

Cheers for the info on this,

a bit of sad news then, ok, it's showing that the main interface is mostly accessible to VoiceOver, but urgan libraries because of their design and structure would require a new method of building libraries, this would be an issue as it would affect library creators who would have to recompile each library, etc.

my console isn't solenoid based, I wish I was that posh, instead it's just SPST standardised switches set in cabinet frames with controller boards sending out midi messages the usual way, so really, other than positional memory alone, there's no actual mechanical registration or physical difference for a switch on or off as solenoid switches for this build would set me back a few grand at least, this build has been sponsored by a few interested parties.

I'll keep my ears open on this for the future, but I guess for the moment, although there's positive movement to hauptwerk itself, I can't set this up independently and that's an important factor for me as I don't have people around me I can either rely on or who don't need teaching every 5 minutes.

Thank you for your time and patience with me, I really appreciate it.

What if you could make the automated midi mapping so that you could have a wizard which could allow you to work on lists of midi elements and build the console that way, say as an example, wizard section 1: Stops... where the library would provide information on the stops to a library and populate columns, the autodetect could tell you to press a midi trigger for that particular stop and move on, then by the time you've mapped your stop jambs for each division, it can move to tremulants, couplers, divisional pistons, general pistons, toe pistons and expression shoes as further wizard pages. To me, that would make sense to have a wizard setup, whether it was a known or unknown console spec.

If a different library contained further stops, couplers or had changes, it could use the initially created preference file for that midi mapping, create a 2nd or further versions of it associated with the other libraries.

How would that sound to you as a concept?

Regarding creating integrated windows for the various libraries available using QT components and system buttons, I'm sure that could be doable, a single page as a console view but without manuals and pedals, just giving the divisions, couplers, trems, pistons, etc in a double jamb view as a single page would make good sense. It's been described to me that the salisbury stop view page could make a good example of this, but rather than as graphical as it is, instead as a purely QT or system button based environment. I can understand that the coding would take some time to play with, but wouldn't it be worth it to try out on some of your own libraries first and then offer that format to other developers who might be interested in this?

This particular mode could be set up as a setting in preferences to use an accessible mode by default for those with sight impairment / loss.

I hope this all works out. We as blind organists / sight impaired organists on here would like to, want to and need to see this happen, I know it's taken you a long time and as the developer of this, everything you throw at this makes a difference to users, this time, it would be an amazing achievement to bring hauptwerk in to the accessible domain, just think what it can do for your company, brand, image, etc? sales would increase, you'd have experienced organists like us here who can offer consultancy and training, online setup and configurations for assistive builds, etc.

keep on with the amazing work you're doing. What harm would it do to play with how organ libraries are built? you might find something interesting that would change how things work for the better.

lew

[mdyde]

Hello Lewis,

Thanks for the additional thoughts. Briefly:

What if you could make the automated midi mapping so that you could have a wizard which could allow you to work on lists of midi elements and build the console that way, say as an example, wizard section 1: Stops... where the library would provide information on the stops to a library and populate columns, the autodetect could tell you to press a midi trigger for that particular stop and move on, then by the time you've mapped your stop jambs for each division, it can move to tremulants, couplers, divisional pistons, general pistons, toe pistons and expression shoes as further wizard pages. To me, that would make sense to have a wizard setup, whether it was a known or unknown console spec.

If a different library contained further stops, couplers or had changes, it could use the initially created preference file for that midi mapping, create a 2nd or further versions of it associated with the other libraries.

How would that sound to you as a concept?

Auto-detection is intentionally handled separately on a per-control basis in Hauptwerk (as opposed to as a batch for all controls), because there are many more virtual controls and Hauptwerk virtual functions/buttons than most people have MIDI controls to map them to. Also, different sample sets often have significantly different sets of controls, and people are likely to want to map different sub-sets of them. That isn't something that we'd want to change, but, in itself, that shouldn't be a significant issue for accessibility (because in the next Hauptwerk version you should be able to auto-detect any desired virtual controls fairly quickly via their settings screens using a screen-reader).

t's showing that the main interface is mostly accessible to VoiceOver, but urgan libraries because of their design and structure would require a new method of building libraries, this would be an issue as it would affect library creators who would have to recompile each library, etc.

...

Regarding creating integrated windows for the various libraries available using QT components and system buttons, I'm sure that could be doable, a single page as a console view but without manuals and pedals, just giving the divisions, couplers, trems, pistons, etc in a double jamb view as a single page would make good sense. It's been described to me that the salisbury stop view page could make a good example of this, but rather than as graphical as it is, instead as a purely QT or system button based environment. I can understand that the coding would take some time to play with, but wouldn't it be worth it to try out on some of your own libraries first and then offer that format to other developers who might be interested in this?

This particular mode could be set up as a setting in preferences to use an accessible mode by default for those with sight impairment / loss.

The enhancement request that we have logged would be for adding a new window to Hauptwerk which visually-impaired people could use, instead of the existing graphical virtual consoles. It would have automatically-generated standard Qt/operating system buttons and sliders on it for all of the sample set's stops, pistons, expression pedals, etc., so that they should be accessible via screen readers. Hauptwerk could, in principle, generate those controls automatically based on information that sample sets already contain, so it wouldn't be necessary for sample set producers (or any third-parties) to do anything additional for each sample set.

Hence if that change were to be implemented in the future I think you would have a means by which you could operate the virtual stops, etc., and determine their states, from a screen-reader, without needing to use solenoid-actuated MIDI stops.

As mentioned, it isn't something that I can be involved with at the moment, but it's logged as an enhancement, and we do appreciate that it would be very helpful for visually-impaired people, and therefore very desirable.