Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

Entire forum ➜ MUSHclient ➜ General ➜ Accessibility in MUSHClient and MUSHClient Help

Accessibility in MUSHClient and MUSHClient Help

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #15 on Thu 20 Sep 2018 06:28 AM (UTC)

Message

Okay, I think I am visualising this.

You point your braille reading device to a certain part of the screen which, in the absence of input from you, is fixed.

It renders what it sees in that part of the screen by raising bumps on the device which your fingers can then read. I presume you only use your eight fingers, and not your thumbs, so you would be able to read 8 characters at a time, and would have to move your fingers to read the whole 40 characters.

I’m guessing that your thumbs would be available to do other activities such as push a button to scroll.

Now, no doubt the annoying part is if the screen scrolls and the text being rendered changes before you have had a chance to read it.

It seems to me the same interface which is used by plug-ins to do text to speech would also be useful in this case. Those plug-ins use a special call back which is simply the incoming text from the output window which it then renders into speech, which it equally well render it into braille.

Ideally it seems to me such a plug-in would render 40 characters at a time, pausing at the end of a word and then wait for you to press a button to tell it to render the next 40 characters.

To speed up rendering, a new line could be rented as a special character, for example a slash, to speed up the output of text.

Does this sound like the sort of solution you are seeking?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #16 on Thu 20 Sep 2018 08:10 AM (UTC)

Amended on Thu 20 Sep 2018 08:17 AM (UTC) by JJTim

Message

Yes - this is pretty much my problem.
I only use 4 fingers (2 at each hand) but that's not that important as I'm, in theory, a very fast reader.
Also, my thumbs are actually pressing buttons to scroll, just as you visualized:
Thumb key 1: Scroll 40 characters back (or a line if braille display is at start of line).
Thumb key 2: Scroll 80 characters back (usually one line up)
Thumkb key 3: Move focus to system focus/caret.
Thumb key 4: Scroll 80 characters forward.
Thumb key 5: Scroll 40 characters forward, or one line down if braille display is at end of line.
The problem here is that if too much text comes in, I don't get a chance to read everything, and get caught up trying to scroll back - that's a bit like trying to walk up a conveyor belt that moves down - you move, but the movement in opposite direction renders your progress near zero, you get what I mean?
There are also 3 settings I can use: Braille display tethered to system focus/caret (I can only see what I type in MUSHclient), tethered to NVDA-focus (can only see output) or automatically tethered (see what I type, then shift to output upon enter).
What you suggest sounds great, but I'm not sure how to do that, tbh.

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #17 on Thu 20 Sep 2018 11:16 AM (UTC)

Message

Okay, so your problem of needing to pause the output, and your other problem of wanting to review old text are really secondary problems caused by the primary problem of your not be able to read the text as quickly as it is arriving, or having a useful way of pausing it.

It seems to me that my proposed solution of having a method of delivering text to the Braille rendering device in a controlled fashion is what you need.

Can you give me the name, webpage, model number, or other information about it so that I might better be able to understand how to interface with it?

If the device can in fact simply read text off the screen, in the same way that it might read text off a book or a newspaper, then a fairly simple solution would be to make a miniwindow, which would have the purpose of delivering the output text to you in a controlled way.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #18 on Thu 20 Sep 2018 12:11 PM (UTC)

Message

The company developing my braille display is called Optelec.
My braille display itself is the ALVA 640 Comfort, Firmware 3.0.2, Bluetooth 1.20
More details here:
https://in.optelec.com/products/alva-640-comfort.html
I haven't used mini windows in MUSHclient yet, but I know blind people who have, so they should be able to help me with learning how to focus them.

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #19 on Thu 20 Sep 2018 02:14 PM (UTC)

Message

I see that model supports JAWS.

Therefore it seems to me that the work is 90 percent done.

If you interface with JAWS and then install the JAWS plug-in into MUSHclient, then the text from the MUD will be sent to JAWS, it will be “spoken” and then your device will render it in sequence.

The only problem might be the rate of delivery, however JAWS already has the option to slow the speech down. You should conceivably be able to choose a speed that suits your reading rate.

Failing that, the plug-in could be modified to pause indefinitely until it receives a certain keystroke which could be generated by one of the buttons on the device.

In fact, from memory, the JAWS plug-in already has an option to pause the output.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #20 on Thu 20 Sep 2018 02:28 PM (UTC)

Message

I'll try this, of course.
However, please keep in mind that braille and speech are two entirely different things.
It's not like I see everything which gets spoken on my braille display. Likewise, not everything I read is spoken.
I'll get back to you after the testing.

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #21 on Thu 20 Sep 2018 02:47 PM (UTC)

Message

Surely whatever adjustments it makes, in reading from the screen, it could also make from the output of a screen reader?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #22 on Thu 20 Sep 2018 03:16 PM (UTC)

Message

I'm no expert...
Come to think about it, the interface for voice and braille should be rather similar, but there are also differences.
Hm, which JAWS plugin were you talking about? The sapi one on the plugin page?

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #23 on Fri 21 Sep 2018 04:31 AM (UTC)

Message

I actually I was thinking of this one :

https://github.com/nickgammon/mushclient/blob/master/plugins/Text_To_Speech.xml

It should be in the plugins folder of the download you would’ve got. I’m not absolutely certain that it’s compatible with Jaws, perhaps Fiendish could comment.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Fiendish USA (2,541 posts) Bio Global Moderator

Date

Reply #24 on Sun 23 Sep 2018 02:49 PM (UTC)

Amended on Sun 23 Sep 2018 03:19 PM (UTC) by Fiendish

Message

Not that plugin. That plugin sends directly to the Microsoft speech api instead of going through any screen reader's input interface. Essentially it bypasses the screen reader entirely and I have no idea what degree of first-party support Windows has baked in for braille displays.

Plugins that I know of for interfacing with JAWS and also NVDA are the mushReader plugin from https://www.allinaccess.com/mc/ or my own "Universal Text To Speech" plugin that I include in the Aardwolf MUSHclient package. Because I only really write plugins for Aardwolf, my plugin also depends on LuaJIT which I also include in the Aardwolf package in place of PUC-Rio Lua. But I can (and will) bundle it into its own portable package. Just know that I didn't write my own because of any known deficiency in mushReader except that I just found its code to be harder to read than necessary. So using mushReader should work fine.

But I suspect that these plugins won't solve the problem without some modification.

To recap the description of the thread so far...

The major difference as I understand it between braille output and speech output is that there's an insurmountable latency between when the braille display shows some text and when the fingers are able to finish reading it. This is because speech output doesn't interrupt itself before it finishes speaking a line, so the ears always get the chance to receive every spoken word, but the braille display will happily switch to showing a new line before your fingers have finished scanning to the end of the first line.

I'm not sure if using either of the above plugins will directly solve this, since the only solution I can think of is, as you suggest Nick, to slow down how quickly lines get pulled out of the screen reader's text buffer onto the display. And while you can slow down a speech rate, you can't really slow down a braille display rate because I imagine that it would always display instantly (since it can show the whole line all at once instead of vocalizing phonemes).

I think the plugins would need to be modified to add a second layer of buffering inside of the plugin and then a coroutine to gradually pull things off the buffer before sending them to be displayed with some delay between each line. That way the player could control the inter-line delay. None of the plugins I know currently does this. but it should be easy enough to add.

Nick, I should be able to look at the MUSHclient code tonight to rig up a toggle option for disabling the auto-unpause when scrolling hits the bottom. If I did, would you merge it? I'll also look at adding a line delay setting to the plugins.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #25 on Mon 24 Sep 2018 04:29 AM (UTC)

Message

Fiendish said:

If I did, would you merge it? I'll also look at adding a line delay setting to the plugins.

Yes, I think I can access GitHub at present.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #26 on Mon 24 Sep 2018 07:46 AM (UTC)

Message

Thanks you guys!
Yes, you have got the problem now - I'll test the suggested plugins now and get back to you with the results.

Posted by

Fiendish USA (2,541 posts) Bio Global Moderator

Date

Reply #27 on Tue 25 Sep 2018 12:33 PM (UTC)

Amended on Tue 25 Sep 2018 12:35 PM (UTC) by Fiendish

Message

JJTim, there's a new pre-release build of MUSHclient with the ability to disable the part of auto-pause that also automatically unpauses when scrolled to the end of the output.

First you need to replace your MUSHclient.exe file with the one from
https://github.com/nickgammon/mushclient/releases/download/latest_commit/MUSHclient.exe

You can then activate the option by going to the immediate window (Control+I or the Immediate option in the Game menu) and then typing the following:

SetOption("keep_pause_at_bottom", 1)

You can turn it back off by replacing the 1 with a 0.

For this to have a meaningful effect, the auto-pause option must be enabled too, which will pause automatically when you scroll back.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #28 on Tue 25 Sep 2018 05:42 PM (UTC)

Message

Note that capitalisation is important in the command Fiendish showed you.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

JJTim Germany (21 posts) Bio

Date

Reply #29 on Sun 30 Sep 2018 10:15 PM (UTC)

Message

And the next round.
First thanks SO MUCH for putting up with all of this. Without your help, I'd probably quit playing one of the more fast paced MUDs, because I couldn't hope to get all this working.
First, Fiendish, the function you made is very good, thanks. Sadly, a NVDA AddOn for MUSHclient that automatically fixed my screenreader focus to the output no longer works with the new exe file. I have no clue why, have already messaged NV Access AddOns about this - no response so far. So now I'm on Jaws. I could try to make such an AddOn for Jaws, but I'd need to learn the scripting language of Jaws first, so that takes time. In the meanwhile, I downloaded output_functions, a plugin, which pastes all output to a notepad. That's not perfect, but it would've sufficed for now. Sadly, when there's a lot of spam, the writing to the notepad completely disables the client for a few seconds. There's just so much in the quue, and the client is just busy with other stuff - I can't read during that time, type commands etc.
Do you think Lua-JIT would solve that? Or do you think there's some other method I could use?

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

98,890 views.

This is page 2, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.