It is currently Sun May 12, 2024 8:30 pm
Jump to: Board index » Hauptwerk » Technical support
LewisAlexander23 wrote: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.
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)
LewisAlexander23 wrote:Does the autodetect function walk you through pressing each stop, coupler, piston, etc so that you can map out a console?
LewisAlexander23 wrote: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?
LewisAlexander23 wrote: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.
LewisAlexander23 wrote: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?
LewisAlexander23 wrote: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.
Users browsing this forum: No registered users and 13 guests
© 2020 Milan Digital Audio LLC
Powered by phpBB