[DECtalk] It's time to bust some DECtalk myths

[Don]

Nick, resending the settings periodically is a hack that avoids trying to
identify the real problem -- if settings are being lost.

Would you resend the dictionary at the same time?  Just in case it was
also getting corrupted?

Would you reinvoke the self-test just to make sure something hasn't
broken since the last time you told it to do so?

The protocol to talk to the DECtalk was developed at a time when machines
did less and people expected less from them.  No one has thought to redefine
the interface to be more robust.

You don't have to type a URL twice just to ensure you get the correct
web page.  You don't have to send each email message twice just to be
sure it actually got sent.

Those protocols have been designed to address the possibility of
data or messages being lost without requiring the user to deal with
that possibility.

DECtalk tried to just sit on an existing communication line to a user
terminal without altering anything in the host machine or in the user's
expectations.

There are different sets of settings in the DECtalk.  There are
factory defaults, settings stored in nonvolatile memory inside the
DECtalk and the settings currently in play at this instant (which
can change from word to word).

These are in addition to whatever the SpeakUp software thinks the
settings should be.

So, the question is, what are the specific settings being changed to
(this can be determined by asking the DECtalk for a report; but, I
don't know how the various software is plumbed in order to know
how I can be assured a clean, direct path to the DECtalk without
SpeakUp being involved).  Then, see if there is some correlation
to one of these sets of settings that I've mentioned; is it
reverting to factory defaults, nonvolatile memory defaults, speakup
initialization defaults, etc.  And, finally, why are they being changed.

Then, you can start thinking about how to avoid this situation in
the first place!

As to what the developers or support staff should and shouldn't do...
they are likely volunteering their labor so you can't expect them
to make time for your specific request.  They determine their own
priorities and time budgets.

When I do a job for a client, I have a contractual obligation to
support him.  Today, not three weeks from Thursday.  Because he
is incurring costs as a result of something I may have done
incorrectly.

On the other hand, if he wants me to make some enhancement to
a project -- or start another one entirely -- that's not covered
in our prior contract.  I may simply decline to do the work as
I may have other obligations, at that time.  But, we both know
that to be the case; if you wanted me to be available for future
work, we'd have to negotiate a contract to cover that availability
and my legal responsibilities to you thereunder.

This is why "free" has such a high, hidden cost.  I can wait for
someone to develop a free program that does something that I need.
And, hope it actually works!  Or, I can purchase a program that
does what I need, today.  In the first case, I don't spend any
money -- but may have to wait forever!  In the second case, I spend
money and have something today.  (And, if it doesn't work properly,
I have leverage over the seller as I can demand my money back)

On 9/19/2022 4:25 AM, Nick Gawronski wrote:
> Hi, I read somewhere that screen readers would send the strings of rate and
> pitch to the dectalk every several lines to make sure that the device was at
> the correct settings.  I was using my dectalk express with speakup a lot and
> would often change the rate but when I set it the settings never went back to
> what the default was when the device was turned on.  I also would say that
> perhaps the dectalk is not remembering the settings that it was first given
> when speakup first loads and sends the string to the device.  I agree that the
> speakup developers should have test devices as this way they can fix bugs when
> they find an issue or just make sure there are no major bugs in a driver that
> they say to support.  Nick Gawronski