[DECtalk] DECtalk TTS licensing

[Don]

On 8/30/2021 9:04 AM, Devin Prater wrote:
> Exactly! And yeah, Emacspeak has to be taught about all that, but shoot,
> it's better than what *all* other screen readers do.

Sorry to beat a dead (?) horse, but you're still not opening your
mind, enough.

The problem isn't the speech synthesizer.  The problem is the
*applications*.

Run through this same discussion substituting "brailler" for
"speech synthesizer".

There's a reason that applications are heavily into graphics,
menus, etc. -- because there are prebuilt TOOLKITS that make
it easy for the developer to deploy these sorts of interfaces!

Where's the interface that facilitates speech output?  Or, braille
output?  Or *input* from a paraplegic?

"D'uh..."

What is needed is to refocus on how "interfaces" are defined.

As I mentioned upthread, when a program needs to possibly "talk"
to another program, the design of the interface *facilitates*
that.  ("404 page not found").

Until there's a "group rethink" of interfaces, anyone (or
anyTHING) that is not a "mainstream consumer" will be
disadvantaged and have to deal with some form of "bolt on"
adapter.

When I started my current project, I interviewed dozens of folks
with different "I/O capabilities".  I posed simple applications
so they wouldn't get side-tracked into thinking about the
application, instead of the *interface*.

When discussing a hypothetical "address book" with one blind
gentleman, he casually mentioned that he needed to be able to
handle 5,000 contacts.  At first, I was wondering if his "5000"
was merely a typo intended to be "500".

When I asked for clarification -- it really *was* 5000! -- our
discussion took on an entirely different character.

Designing an address book that will likely not hold more than
500 entries (even if it could store 5,000,000!) is very
different than one that is *expected* to hold 5,000!  How
would he, a blind user, search through 5000 contacts for the
contact sought?  Imagine, also, if his "input" device was
a mouth stick!!