Helps to have some helping hands around…
She’s missing out on the drawbar indicator lights on this pipe organ .
(It’s a case where nice hot to the touch light bulbs would have it over LEDs)
1 Like
I’ve actually spoken with her on a few occasions, a breath of fresh air and puts a smile on my face, she goes through similar tech challenges as I do and yes, you’re right about the stops to consoles like these, they’re non motorised LED centre lit momentaries and a real headache on different consoles.
the modular moog you mentioned is accessible as it’s primarily tactile, it’s a question of memory lol.
lew
1 Like
You can’t help but root for her succeeding. Here mom could use a break from tending after her. It’s a lot more tricky for musicians make money, ever since digital drove piracy to new heights. Perhaps she can improve the pop star appeal (without an agent’s total image makeover) perhaps producing a duets album with original pieces written for the partners, would be be a useful exercise, a partnership with someone providing complimentary skills might make an attractive pop act. Good to see she has experimented in genres and developed other instrument skills instead of doing a Child Music Prodigies tour (she’s 28 now)
Her newest Tiny Desk Contest Entry, June 2021 shows some development of her vocal instrument. Perhaps some pop music hook coaching, like contestants in the Songland TV show got from industry pros, might help one make it big. (they make the refinement of a song seem so easy)
Pianoteq 7.4.0 (2021/06/29) has added, “Accessibility for blind users: VoiceOver (macOS) and Narrator (Windows 10) support added”. I am not sure if this is of particular benefit to Zynthian (where we are implementing accessibility at a core level) but interesting to see another manufacturer considering accessibility in their products.
it’s possible, bare in mind that orca is the primary screen reader and it can be very buggy
lew
The MIDI Association held a seminar on plans for a Music Accessibility Standard. The recording is available here. It is seventy minutes long and pretty interesting to see the association trying to make progress in this field.
2 Likes
I’ve discovered this tool, maybe accurate :
It combines Vosk for voice recognition and svox-pico for vocal synthesis and has got a Qt interface for its configuration.
source code available here
Hi, wow I thought this thread had departed in peace a while ago lol. oh well.
Good find…. but…. not on the right track :). This is more about either voice input or voice synthesis input rather than what we refer to as Text To Speech (TTS). Accessibility in this case is about having spoken feedback using a speech synthesis server and client, the client being a screen reader which allows someone with sight loss to navigate the OS and apps directly either with keyboard only or keyboard and mouse, or touch screen feedback, like we see on apple iphone / ipod / ipad / watch and of course, the macOS platform itself. sale could be said for windows but under third party level where this gets expensive and annoying.
Sadly, linux accessibility is extremely poor regardless of the porting and distro of linux, ORCA and other tools are just unstable and there’s no actual resources available for custom object layers and functions, so really, linux for blind users is like a fart in a shoebox lol.
I like the thought you’ve put in to this and it could be a great musical tool as part of this platform, it’d be like bringing back the speak and spell, etc into 80’s pop 
lew
Hi @lewisalexander2020 , to be honest, I recognize I should have re-read the thread 
I think, for controlling Zynthian’s UI with CUIA, it could be useful, but yes, for giving feedback to the impaired sight user it’s certainly not that accurate.
yep, don’t be afraid of using the word “blind”, after all I’m the author of this and am blind, so don’t worry. political correctness and me, we don’t go together well lol
I spent a good few years on linux distros, testing, reporting, etc to find stable screen reader solutions, it started because of an organ build project, sadly 3 months back I closed the entire project down due to a number of factors, but in that time, Aeolus as an organ engine became fairly interesting, but completely inaccessible and nothing I could do to change it’s behaviours at all, orca was just a total nightmare also, so I stepped away from it all and took a posting with Modartt, so now we do have a blind friendly 3 manual, voiceable pipe organ system and Hauptwerk started making some changes including basic screen reader compatibility but it’s still not fit for use for blind organists because the organ libraries use GUI’s based on image files and no actual way of embedding the right resources to make the libraries navigatable and spoken.
that’s what my background is based on, that and being a former developer behind VoiceOver amongst well over 100 others worldwide doing this to this day.
lew
We continue to consider how best to improve zynthian to improve accessibility. This includes blind and partially sighted users and those with other differences to their eyesight like reduced contrast perception. Visual is not the only area where we can improve accessibilty to zynthian but it is the topic of this thread so I will talk within that scope.
I have explained many times that zynthian, although having a computer at its core, should not be considered as a computer but instead an embedded device. Screen readers are of little use with our interface although the webconf should be accessible to all web browser users and any issues should be reported so that we can improve it.
The link provided by @le51 relates mostly to desktop computing so, although there may be elements of the project that can inform or benefit zynthian, I doubt it is a direct solution for any of our requirements.
The main area we have been considering is the ability to give audible feedback of UI operation, e.g. describing what each hardware control does and what state it is currently has. An example of this may be during engine selection where the type and name of each engine may be spoken. We do not intend to provide a screen reader because we have direct control of the core zynthian functionality so it makes little sense to describe to a blind user what is written on a screen when we can just tell them what they need to know without any reference to graphics.
To implement this feature we ideally need a dedicated audio output to carry this information separate to the production audio that the user is attempting to create. Until now, the default zynthian hardware has just two audio outputs configured nominally as a stereo pair. Recent development has put in place the building blocks for this to possibly change in the future.
As @lewisalexander2020 has described, Linux has struggled to provide robust support for its desktop users who require tools such as screen readers. This is almost certainly due to the cost to implement (it takes a lot of effort to make these things work) across such a diverse platform. In many ways it is far easier for Apple to provide a consistent interface due to their total control of the hardware and OS. Zynthian also benefits from that to a lesser degree but we have a tiny fraction of the effort than Apple or Microsoft or even the Linux distibutions have, so our progress is painfully slow.
@lewisalexander2020 and I have had many detailed discussions and his assistance in furthering our understanding of blind organists’ requirements is invaluable. We are very grateful for his input on this subject. I must remind him that we are still separated on our views about the use of screenreader within zynthian. My experience of providing access to embedded systems for blind and visually impared users has been in the area of providing direct access to the core API and not having to interface through the GUI which is often quite unsuitable for users without good eyesight.
We also have a couple of other users who have joined us recently with vested interest in this subject whose views are equally important. I am working with the MIDI Association’s Special Interest Group for Accessibility which shares resources that may prove beneficial to zynthian’s development. Much of their concentration also gravitates towards using commodity software and hence screen readers but there is also work in physical interfaces, etc.
This subject is regularly in my thoughts. This thread is far from forgotten, although domant for a while. Thanks for reigniting the discussion.
An area that could be considered further is spoken command recognition and the use of machine learning to assist with such interfaces… “Alexa, add a C minor triad at beat 3”.
ey up, long time no hear, how are you? Sorry it’s been quiet. other projects on, a complete wind down and being in and out of hospital with a fight for my life, but hey, I’m here.
I’m not actually concerned about having a native screen reader within an interface / OS like this, if it can be done at base level so that if an encoder is changed based on assigned parameters, say if you’re editing ADSR envelopes as an example, it’d be useful to have the values for each control announced when changed, it’s doable if a speechsynthesisserver element or module is part of the base system and can be integrated in to controls, maybe even the touch screen and any other associated buttons. As I understand it though, this is a flexible software / hardware product, so pages based on whatever plugin / instrument is running, would change display state and control assignments.
A thought on this, now I don’t know the physical hardware here because I don’t have access to one, never got around to ordering one, etc. If there was a USB connection available free, a single stereo audio interface module could be connected and assigned as a speech synthesis output, or if the standard stereo output of the host board be assigned to speech output and any audio beeps, etc, then the synth itself would use another interface, ideally so that one doesn’t steal the other’s data path.
If you think of it from both Windows and MacOS as an example, this is my background from the mac anyway…
MacOS can route the system audio wherever you want it to go, so say if your internal audio interface isn’t good enough or fails, The CoreAudio engine through the Audio/Midi setup can route system audio out, this also includes the speechsynthesisServer and client modules to the system audio to whatever audio interface you use, this can be assigned to channels also. VoiceOver as an example can bypass the system audio completely and be sent to another audio interface, but I always advise the following as a setup for a good reason…
Say you’re running a recording studio, or like me, developed the organ system with accessibility in mind, You’d do this:
1: System Audio = assign to internal audio interface (system speakers / headphone port by autodetect)
Studio Audio = assigned to dedicated audio interfaces.
Why is this done? well, regardless of whether assistive technology is used, you don’t want the system audio bleed in to the pro audio setup. In a studio setting which I’ve done for years, I use an earbud connected to the mac’s system audio headphone out, this gives me VoiceOver feedback when needed, take that out of my ear and I’m mixing a project purely with the pro audio setup and no bleed. I regularly endorse this method whether it’s building a pro audio system if asked to do so or installing a setup and training.
Not knowing what the main board being used has, then what interfaces it’s using as part of it’s proprietry connections, I can’t give positive suggestions, only my experience.
this being said, a screen reader itself wouldn’t actually be needed, just a speechsynthesis server and client side installed and a means of action association and announcements of what objects are on display or assigned to controls to edit, that’d be the primary level and it could be done at a low level without the GUI level.
all the best.
lew
Why not on another device? I mean, you can easily add an omnipresent Python module with a function to send the needed feedback (like logging does), and that function would send the message to an Android device (or, if we use a webserver with SSE, it could be whatever OS). The user only needs to open the webapp, and she/he would just hear the feedback (web technologies does have support for TTS).
Of course, you still need to define what to say and when, but at least you know that you can.