public inbox for speakup@linux-speakup.org
 help / color / mirror / Atom feed
* Possible work around to the hardware synthesizer problem
@  Shawn Kirkpatrick
   ` covici
  0 siblings, 1 reply; 9+ messages in thread
From: Shawn Kirkpatrick @  UTC (permalink / raw)
  To: speakup

I've written a program that will allow hardware synthesizers to be used with 
speakup even thoe the serial support seems to be currently broken. I wrote 
this program about a year ago when I thought this problem would be only 
temporary. Since it seems like the hardware synthesizer support is still 
broken and isn't going to be fixed anytime soon I thought I'd put it out 
there in case it can be of some use.
The program is called speakupbridge.
speakupbridge is a program which makes it possible for speakup to use
external serial, parallel, or usb synthesizers. It does this by reading
speakup's softsynth device and passing the text to the synthesizer.
speakupbridge has the following features:
* The ability to communicate with any device that can accept a string
of text using a /dev interface.
* The ability to define the commands used by the synthesizer in a
user-editable configuration file.
* Multiple synthesizer definitions in a single configuration file.
* Change the pronunciation of words using a dictionary file (a feature 
speakup
really should do itself).
* Save and reload speakup settings for each defined synthesizer.
For more information or to download the program please visit: 
http://www.shawnk.ca/speakup
I haven't had a lot of time to work on or test this code lately so there's 
likely to be some rough spots. You'll have to compile the code but that 
should be easy enough. I've tested this with my serial Artic transport 
synthesizer and it seems to work. I don't use speakup regularly thoe (too 
many other missing/bbroken features) so this program really hasn't had any 
hard testing.
This solution isn't perfect, you still won't get kernel messages from boot 
up but it least it should be possible to use a hardware synthesizer once the 
system is started and that's probably better than nothing at all.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
   Possible work around to the hardware synthesizer problem Shawn Kirkpatrick
@  ` covici
     ` Shawn Kirkpatrick
     ` John G Heim
  0 siblings, 2 replies; 9+ messages in thread
From: covici @  UTC (permalink / raw)
  To: shawn, Speakup is a screen review system for Linux.

Shawn, maybe it might be easier and more universal to write a speech
dispatcher driver instead?  That way, if you use speechd-up, indexing
would work.  What do you think?

Shawn Kirkpatrick <shawn@shawnk.ca> wrote:

> I've written a program that will allow hardware synthesizers to be
> used with speakup even thoe the serial support seems to be currently
> broken. I wrote this program about a year ago when I thought this
> problem would be only temporary. Since it seems like the hardware
> synthesizer support is still broken and isn't going to be fixed
> anytime soon I thought I'd put it out there in case it can be of some
> use.
> The program is called speakupbridge.
> speakupbridge is a program which makes it possible for speakup to use
> external serial, parallel, or usb synthesizers. It does this by reading
> speakup's softsynth device and passing the text to the synthesizer.
> speakupbridge has the following features:
> * The ability to communicate with any device that can accept a string
> of text using a /dev interface.
> * The ability to define the commands used by the synthesizer in a
> user-editable configuration file.
> * Multiple synthesizer definitions in a single configuration file.
> * Change the pronunciation of words using a dictionary file (a feature
> speakup
> really should do itself).
> * Save and reload speakup settings for each defined synthesizer.
> For more information or to download the program please visit:
> http://www.shawnk.ca/speakup
> I haven't had a lot of time to work on or test this code lately so
> there's likely to be some rough spots. You'll have to compile the code
> but that should be easy enough. I've tested this with my serial Artic
> transport synthesizer and it seems to work. I don't use speakup
> regularly thoe (too many other missing/bbroken features) so this
> program really hasn't had any hard testing.
> This solution isn't perfect, you still won't get kernel messages from
> boot up but it least it should be possible to use a hardware
> synthesizer once the system is started and that's probably better than
> nothing at all.
> 
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
   ` covici
@    ` Shawn Kirkpatrick
       ` covici
     ` John G Heim
  1 sibling, 1 reply; 9+ messages in thread
From: Shawn Kirkpatrick @  UTC (permalink / raw)
  To: covici; +Cc: Speakup is a screen review system for Linux.

I thought of writing a speechdispatcher driver but there were some problems. 
When I've tried speechdispatcher with software speech there were lags and 
little glitches. I'm not sure if these were being introduced by 
speechdispatcher, speechd-up, or some combination of the two. Also, my 
version of speechdispatcher has a nasty habbit of segfaulting, not sure why.
I don't think this would solve the indexing problem anyway, as far as I
know speechd-up uses speakup's software synth driver and that doesn't 
support indexing, or has this changed? I also think the less layers you have 
between speakup and the synth the better, one program is probably better 
than two.
What I'd really like to do, if I ever have the time, is write a speach 
daemon to replace this whole mess. Something like speechdispatcher but with 
more modularity. There could be modules for output, allowing hardware and 
software synth support. Modules for input, for various forms of input like 
speechdispatcher compatibility, speakup, fifo, or anything else that might 
be needed. Modules for conversion, allowing things like a word dictionary, 
number processing, etc. The main goal of the program would be to get fast, 
responsive speech from whatever synth the user chooses to use.
I think this would be a worthwhile project it would just require time to 
write.

On Fri, 26 Feb 2016, covici@ccs.covici.com wrote:

> Shawn, maybe it might be easier and more universal to write a speech
> dispatcher driver instead?  That way, if you use speechd-up, indexing
> would work.  What do you think?
>
> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
>
>> I've written a program that will allow hardware synthesizers to be
>> used with speakup even thoe the serial support seems to be currently
>> broken. I wrote this program about a year ago when I thought this
>> problem would be only temporary. Since it seems like the hardware
>> synthesizer support is still broken and isn't going to be fixed
>> anytime soon I thought I'd put it out there in case it can be of some
>> use.
>> The program is called speakupbridge.
>> speakupbridge is a program which makes it possible for speakup to use
>> external serial, parallel, or usb synthesizers. It does this by reading
>> speakup's softsynth device and passing the text to the synthesizer.
>> speakupbridge has the following features:
>> * The ability to communicate with any device that can accept a string
>> of text using a /dev interface.
>> * The ability to define the commands used by the synthesizer in a
>> user-editable configuration file.
>> * Multiple synthesizer definitions in a single configuration file.
>> * Change the pronunciation of words using a dictionary file (a feature
>> speakup
>> really should do itself).
>> * Save and reload speakup settings for each defined synthesizer.
>> For more information or to download the program please visit:
>> http://www.shawnk.ca/speakup
>> I haven't had a lot of time to work on or test this code lately so
>> there's likely to be some rough spots. You'll have to compile the code
>> but that should be easy enough. I've tested this with my serial Artic
>> transport synthesizer and it seems to work. I don't use speakup
>> regularly thoe (too many other missing/bbroken features) so this
>> program really hasn't had any hard testing.
>> This solution isn't perfect, you still won't get kernel messages from
>> boot up but it least it should be possible to use a hardware
>> synthesizer once the system is started and that's probably better than
>> nothing at all.
>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
>
> -- 
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>         John Covici
>         covici@ccs.covici.com
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
     ` Shawn Kirkpatrick
@      ` covici
         ` Shawn Kirkpatrick
  0 siblings, 1 reply; 9+ messages in thread
From: covici @  UTC (permalink / raw)
  To: shawn; +Cc: Speakup is a screen review system for Linux.

hmmm, I am using  0.8.3 of speech dispatcher  and not seeing any
segfaults or any such and indexing works fine -- although my speechd-up
was compiled from a source which maybe you don't have, I am not sure
where this came from.  I was thinking that the output module for a
hardware synth would not be too hard to write and that is why I
suggested it.  Your ideais nice, but remember we would want this to work
with orca as well as a client, otherwise for those who use both speakup
and orca, it would be a mess.

I can send you my source for speechd-up, if you would like.

Shawn Kirkpatrick <shawn@shawnk.ca> wrote:

> I thought of writing a speechdispatcher driver but there were some
> problems. When I've tried speechdispatcher with software speech there
> were lags and little glitches. I'm not sure if these were being
> introduced by speechdispatcher, speechd-up, or some combination of the
> two. Also, my version of speechdispatcher has a nasty habbit of
> segfaulting, not sure why.
> I don't think this would solve the indexing problem anyway, as far as I
> know speechd-up uses speakup's software synth driver and that doesn't
> support indexing, or has this changed? I also think the less layers
> you have between speakup and the synth the better, one program is
> probably better than two.
> What I'd really like to do, if I ever have the time, is write a speach
> daemon to replace this whole mess. Something like speechdispatcher but
> with more modularity. There could be modules for output, allowing
> hardware and software synth support. Modules for input, for various
> forms of input like speechdispatcher compatibility, speakup, fifo, or
> anything else that might be needed. Modules for conversion, allowing
> things like a word dictionary, number processing, etc. The main goal
> of the program would be to get fast, responsive speech from whatever
> synth the user chooses to use.
> I think this would be a worthwhile project it would just require time
> to write.
> 
> On Fri, 26 Feb 2016, covici@ccs.covici.com wrote:
> 
> > Shawn, maybe it might be easier and more universal to write a speech
> > dispatcher driver instead?  That way, if you use speechd-up, indexing
> > would work.  What do you think?
> >
> > Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
> >
> >> I've written a program that will allow hardware synthesizers to be
> >> used with speakup even thoe the serial support seems to be currently
> >> broken. I wrote this program about a year ago when I thought this
> >> problem would be only temporary. Since it seems like the hardware
> >> synthesizer support is still broken and isn't going to be fixed
> >> anytime soon I thought I'd put it out there in case it can be of some
> >> use.
> >> The program is called speakupbridge.
> >> speakupbridge is a program which makes it possible for speakup to use
> >> external serial, parallel, or usb synthesizers. It does this by reading
> >> speakup's softsynth device and passing the text to the synthesizer.
> >> speakupbridge has the following features:
> >> * The ability to communicate with any device that can accept a string
> >> of text using a /dev interface.
> >> * The ability to define the commands used by the synthesizer in a
> >> user-editable configuration file.
> >> * Multiple synthesizer definitions in a single configuration file.
> >> * Change the pronunciation of words using a dictionary file (a feature
> >> speakup
> >> really should do itself).
> >> * Save and reload speakup settings for each defined synthesizer.
> >> For more information or to download the program please visit:
> >> http://www.shawnk.ca/speakup
> >> I haven't had a lot of time to work on or test this code lately so
> >> there's likely to be some rough spots. You'll have to compile the code
> >> but that should be easy enough. I've tested this with my serial Artic
> >> transport synthesizer and it seems to work. I don't use speakup
> >> regularly thoe (too many other missing/bbroken features) so this
> >> program really hasn't had any hard testing.
> >> This solution isn't perfect, you still won't get kernel messages from
> >> boot up but it least it should be possible to use a hardware
> >> synthesizer once the system is started and that's probably better than
> >> nothing at all.
> >>
> >> _______________________________________________
> >> Speakup mailing list
> >> Speakup@linux-speakup.org
> >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>
> >
> > -- 
> > Your life is like a penny.  You're going to lose it.  The question is:
> > How do
> > you spend it?
> >
> >         John Covici
> >         covici@ccs.covici.com
> >
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
       ` covici
@        ` Shawn Kirkpatrick
           ` covici
           ` covici
  0 siblings, 2 replies; 9+ messages in thread
From: Shawn Kirkpatrick @  UTC (permalink / raw)
  To: covici; +Cc: Speakup is a screen review system for Linux.

I assume you're talking about indexing working with speakup and not orca? 
What version of speakup are you using? I don't see how indexing could be 
working since the soft synth driver doesn't seem to send any codes that 
would allow it to work. Unless things have changed pretty recently. In that 
case writing indexing support in to my program probably wouldn't be that 
hard. Of course not all hardware synths will do indexing anyway.

On Mon, 29 Feb 2016, covici@ccs.covici.com wrote:

> hmmm, I am using  0.8.3 of speech dispatcher  and not seeing any
> segfaults or any such and indexing works fine -- although my speechd-up
> was compiled from a source which maybe you don't have, I am not sure
> where this came from.  I was thinking that the output module for a
> hardware synth would not be too hard to write and that is why I
> suggested it.  Your ideais nice, but remember we would want this to work
> with orca as well as a client, otherwise for those who use both speakup
> and orca, it would be a mess.
>
> I can send you my source for speechd-up, if you would like.
>
> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
>
>> I thought of writing a speechdispatcher driver but there were some
>> problems. When I've tried speechdispatcher with software speech there
>> were lags and little glitches. I'm not sure if these were being
>> introduced by speechdispatcher, speechd-up, or some combination of the
>> two. Also, my version of speechdispatcher has a nasty habbit of
>> segfaulting, not sure why.
>> I don't think this would solve the indexing problem anyway, as far as I
>> know speechd-up uses speakup's software synth driver and that doesn't
>> support indexing, or has this changed? I also think the less layers
>> you have between speakup and the synth the better, one program is
>> probably better than two.
>> What I'd really like to do, if I ever have the time, is write a speach
>> daemon to replace this whole mess. Something like speechdispatcher but
>> with more modularity. There could be modules for output, allowing
>> hardware and software synth support. Modules for input, for various
>> forms of input like speechdispatcher compatibility, speakup, fifo, or
>> anything else that might be needed. Modules for conversion, allowing
>> things like a word dictionary, number processing, etc. The main goal
>> of the program would be to get fast, responsive speech from whatever
>> synth the user chooses to use.
>> I think this would be a worthwhile project it would just require time
>> to write.
>>
>> On Fri, 26 Feb 2016, covici@ccs.covici.com wrote:
>>
>>> Shawn, maybe it might be easier and more universal to write a speech
>>> dispatcher driver instead?  That way, if you use speechd-up, indexing
>>> would work.  What do you think?
>>>
>>> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
>>>
>>>> I've written a program that will allow hardware synthesizers to be
>>>> used with speakup even thoe the serial support seems to be currently
>>>> broken. I wrote this program about a year ago when I thought this
>>>> problem would be only temporary. Since it seems like the hardware
>>>> synthesizer support is still broken and isn't going to be fixed
>>>> anytime soon I thought I'd put it out there in case it can be of some
>>>> use.
>>>> The program is called speakupbridge.
>>>> speakupbridge is a program which makes it possible for speakup to use
>>>> external serial, parallel, or usb synthesizers. It does this by reading
>>>> speakup's softsynth device and passing the text to the synthesizer.
>>>> speakupbridge has the following features:
>>>> * The ability to communicate with any device that can accept a string
>>>> of text using a /dev interface.
>>>> * The ability to define the commands used by the synthesizer in a
>>>> user-editable configuration file.
>>>> * Multiple synthesizer definitions in a single configuration file.
>>>> * Change the pronunciation of words using a dictionary file (a feature
>>>> speakup
>>>> really should do itself).
>>>> * Save and reload speakup settings for each defined synthesizer.
>>>> For more information or to download the program please visit:
>>>> http://www.shawnk.ca/speakup
>>>> I haven't had a lot of time to work on or test this code lately so
>>>> there's likely to be some rough spots. You'll have to compile the code
>>>> but that should be easy enough. I've tested this with my serial Artic
>>>> transport synthesizer and it seems to work. I don't use speakup
>>>> regularly thoe (too many other missing/bbroken features) so this
>>>> program really hasn't had any hard testing.
>>>> This solution isn't perfect, you still won't get kernel messages from
>>>> boot up but it least it should be possible to use a hardware
>>>> synthesizer once the system is started and that's probably better than
>>>> nothing at all.
>>>>
>>>> _______________________________________________
>>>> Speakup mailing list
>>>> Speakup@linux-speakup.org
>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>>
>>>
>>> --
>>> Your life is like a penny.  You're going to lose it.  The question is:
>>> How do
>>> you spend it?
>>>
>>>         John Covici
>>>         covici@ccs.covici.com
>>>
>>
>
> -- 
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>         John Covici
>         covici@ccs.covici.com
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
         ` Shawn Kirkpatrick
@          ` covici
           ` covici
  1 sibling, 0 replies; 9+ messages in thread
From: covici @  UTC (permalink / raw)
  To: shawn; +Cc: Speakup is a screen review system for Linux.

Well, the combination of speakup soft synth, speechd-up, speech
dispatcher and the espeakup driver does work, as far as using speakup-r
goes.  I am not sure if its really using indexing, but it has that
effect.

Shawn Kirkpatrick <shawn@shawnk.ca> wrote:

> I assume you're talking about indexing working with speakup and not
> orca? What version of speakup are you using? I don't see how indexing
> could be working since the soft synth driver doesn't seem to send any
> codes that would allow it to work. Unless things have changed pretty
> recently. In that case writing indexing support in to my program
> probably wouldn't be that hard. Of course not all hardware synths will
> do indexing anyway.
> 
> On Mon, 29 Feb 2016, covici@ccs.covici.com wrote:
> 
> > hmmm, I am using  0.8.3 of speech dispatcher  and not seeing any
> > segfaults or any such and indexing works fine -- although my speechd-up
> > was compiled from a source which maybe you don't have, I am not sure
> > where this came from.  I was thinking that the output module for a
> > hardware synth would not be too hard to write and that is why I
> > suggested it.  Your ideais nice, but remember we would want this to work
> > with orca as well as a client, otherwise for those who use both speakup
> > and orca, it would be a mess.
> >
> > I can send you my source for speechd-up, if you would like.
> >
> > Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
> >
> >> I thought of writing a speechdispatcher driver but there were some
> >> problems. When I've tried speechdispatcher with software speech there
> >> were lags and little glitches. I'm not sure if these were being
> >> introduced by speechdispatcher, speechd-up, or some combination of the
> >> two. Also, my version of speechdispatcher has a nasty habbit of
> >> segfaulting, not sure why.
> >> I don't think this would solve the indexing problem anyway, as far as I
> >> know speechd-up uses speakup's software synth driver and that doesn't
> >> support indexing, or has this changed? I also think the less layers
> >> you have between speakup and the synth the better, one program is
> >> probably better than two.
> >> What I'd really like to do, if I ever have the time, is write a speach
> >> daemon to replace this whole mess. Something like speechdispatcher but
> >> with more modularity. There could be modules for output, allowing
> >> hardware and software synth support. Modules for input, for various
> >> forms of input like speechdispatcher compatibility, speakup, fifo, or
> >> anything else that might be needed. Modules for conversion, allowing
> >> things like a word dictionary, number processing, etc. The main goal
> >> of the program would be to get fast, responsive speech from whatever
> >> synth the user chooses to use.
> >> I think this would be a worthwhile project it would just require time
> >> to write.
> >>
> >> On Fri, 26 Feb 2016, covici@ccs.covici.com wrote:
> >>
> >>> Shawn, maybe it might be easier and more universal to write a speech
> >>> dispatcher driver instead?  That way, if you use speechd-up, indexing
> >>> would work.  What do you think?
> >>>
> >>> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
> >>>
> >>>> I've written a program that will allow hardware synthesizers to be
> >>>> used with speakup even thoe the serial support seems to be currently
> >>>> broken. I wrote this program about a year ago when I thought this
> >>>> problem would be only temporary. Since it seems like the hardware
> >>>> synthesizer support is still broken and isn't going to be fixed
> >>>> anytime soon I thought I'd put it out there in case it can be of some
> >>>> use.
> >>>> The program is called speakupbridge.
> >>>> speakupbridge is a program which makes it possible for speakup to use
> >>>> external serial, parallel, or usb synthesizers. It does this by reading
> >>>> speakup's softsynth device and passing the text to the synthesizer.
> >>>> speakupbridge has the following features:
> >>>> * The ability to communicate with any device that can accept a string
> >>>> of text using a /dev interface.
> >>>> * The ability to define the commands used by the synthesizer in a
> >>>> user-editable configuration file.
> >>>> * Multiple synthesizer definitions in a single configuration file.
> >>>> * Change the pronunciation of words using a dictionary file (a feature
> >>>> speakup
> >>>> really should do itself).
> >>>> * Save and reload speakup settings for each defined synthesizer.
> >>>> For more information or to download the program please visit:
> >>>> http://www.shawnk.ca/speakup
> >>>> I haven't had a lot of time to work on or test this code lately so
> >>>> there's likely to be some rough spots. You'll have to compile the code
> >>>> but that should be easy enough. I've tested this with my serial Artic
> >>>> transport synthesizer and it seems to work. I don't use speakup
> >>>> regularly thoe (too many other missing/bbroken features) so this
> >>>> program really hasn't had any hard testing.
> >>>> This solution isn't perfect, you still won't get kernel messages from
> >>>> boot up but it least it should be possible to use a hardware
> >>>> synthesizer once the system is started and that's probably better than
> >>>> nothing at all.
> >>>>
> >>>> _______________________________________________
> >>>> Speakup mailing list
> >>>> Speakup@linux-speakup.org
> >>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>>>
> >>>
> >>> --
> >>> Your life is like a penny.  You're going to lose it.  The question is:
> >>> How do
> >>> you spend it?
> >>>
> >>>         John Covici
> >>>         covici@ccs.covici.com
> >>>
> >>
> >
> > -- 
> > Your life is like a penny.  You're going to lose it.  The question is:
> > How do
> > you spend it?
> >
> >         John Covici
> >         covici@ccs.covici.com
> >
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
         ` Shawn Kirkpatrick
           ` covici
@          ` covici
  1 sibling, 0 replies; 9+ messages in thread
From: covici @  UTC (permalink / raw)
  To: shawn; +Cc: Speakup is a screen review system for Linux.

Also, orca's read to end or whatever they call it works as well, just to
let you know.

Shawn Kirkpatrick <shawn@shawnk.ca> wrote:

> I assume you're talking about indexing working with speakup and not
> orca? What version of speakup are you using? I don't see how indexing
> could be working since the soft synth driver doesn't seem to send any
> codes that would allow it to work. Unless things have changed pretty
> recently. In that case writing indexing support in to my program
> probably wouldn't be that hard. Of course not all hardware synths will
> do indexing anyway.
> 
> On Mon, 29 Feb 2016, covici@ccs.covici.com wrote:
> 
> > hmmm, I am using  0.8.3 of speech dispatcher  and not seeing any
> > segfaults or any such and indexing works fine -- although my speechd-up
> > was compiled from a source which maybe you don't have, I am not sure
> > where this came from.  I was thinking that the output module for a
> > hardware synth would not be too hard to write and that is why I
> > suggested it.  Your ideais nice, but remember we would want this to work
> > with orca as well as a client, otherwise for those who use both speakup
> > and orca, it would be a mess.
> >
> > I can send you my source for speechd-up, if you would like.
> >
> > Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
> >
> >> I thought of writing a speechdispatcher driver but there were some
> >> problems. When I've tried speechdispatcher with software speech there
> >> were lags and little glitches. I'm not sure if these were being
> >> introduced by speechdispatcher, speechd-up, or some combination of the
> >> two. Also, my version of speechdispatcher has a nasty habbit of
> >> segfaulting, not sure why.
> >> I don't think this would solve the indexing problem anyway, as far as I
> >> know speechd-up uses speakup's software synth driver and that doesn't
> >> support indexing, or has this changed? I also think the less layers
> >> you have between speakup and the synth the better, one program is
> >> probably better than two.
> >> What I'd really like to do, if I ever have the time, is write a speach
> >> daemon to replace this whole mess. Something like speechdispatcher but
> >> with more modularity. There could be modules for output, allowing
> >> hardware and software synth support. Modules for input, for various
> >> forms of input like speechdispatcher compatibility, speakup, fifo, or
> >> anything else that might be needed. Modules for conversion, allowing
> >> things like a word dictionary, number processing, etc. The main goal
> >> of the program would be to get fast, responsive speech from whatever
> >> synth the user chooses to use.
> >> I think this would be a worthwhile project it would just require time
> >> to write.
> >>
> >> On Fri, 26 Feb 2016, covici@ccs.covici.com wrote:
> >>
> >>> Shawn, maybe it might be easier and more universal to write a speech
> >>> dispatcher driver instead?  That way, if you use speechd-up, indexing
> >>> would work.  What do you think?
> >>>
> >>> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
> >>>
> >>>> I've written a program that will allow hardware synthesizers to be
> >>>> used with speakup even thoe the serial support seems to be currently
> >>>> broken. I wrote this program about a year ago when I thought this
> >>>> problem would be only temporary. Since it seems like the hardware
> >>>> synthesizer support is still broken and isn't going to be fixed
> >>>> anytime soon I thought I'd put it out there in case it can be of some
> >>>> use.
> >>>> The program is called speakupbridge.
> >>>> speakupbridge is a program which makes it possible for speakup to use
> >>>> external serial, parallel, or usb synthesizers. It does this by reading
> >>>> speakup's softsynth device and passing the text to the synthesizer.
> >>>> speakupbridge has the following features:
> >>>> * The ability to communicate with any device that can accept a string
> >>>> of text using a /dev interface.
> >>>> * The ability to define the commands used by the synthesizer in a
> >>>> user-editable configuration file.
> >>>> * Multiple synthesizer definitions in a single configuration file.
> >>>> * Change the pronunciation of words using a dictionary file (a feature
> >>>> speakup
> >>>> really should do itself).
> >>>> * Save and reload speakup settings for each defined synthesizer.
> >>>> For more information or to download the program please visit:
> >>>> http://www.shawnk.ca/speakup
> >>>> I haven't had a lot of time to work on or test this code lately so
> >>>> there's likely to be some rough spots. You'll have to compile the code
> >>>> but that should be easy enough. I've tested this with my serial Artic
> >>>> transport synthesizer and it seems to work. I don't use speakup
> >>>> regularly thoe (too many other missing/bbroken features) so this
> >>>> program really hasn't had any hard testing.
> >>>> This solution isn't perfect, you still won't get kernel messages from
> >>>> boot up but it least it should be possible to use a hardware
> >>>> synthesizer once the system is started and that's probably better than
> >>>> nothing at all.
> >>>>
> >>>> _______________________________________________
> >>>> Speakup mailing list
> >>>> Speakup@linux-speakup.org
> >>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>>>
> >>>
> >>> --
> >>> Your life is like a penny.  You're going to lose it.  The question is:
> >>> How do
> >>> you spend it?
> >>>
> >>>         John Covici
> >>>         covici@ccs.covici.com
> >>>
> >>
> >
> > -- 
> > Your life is like a penny.  You're going to lose it.  The question is:
> > How do
> > you spend it?
> >
> >         John Covici
> >         covici@ccs.covici.com
> >
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
   ` covici
     ` Shawn Kirkpatrick
@    ` John G Heim
       ` Gregory Nowak
  1 sibling, 1 reply; 9+ messages in thread
From: John G Heim @  UTC (permalink / raw)
  To: Speakup is a screen review system for Linux., shawn


WWhat is indexing?


On 02/26/2016 06:26 PM, covici@ccs.covici.com wrote:
> Shawn, maybe it might be easier and more universal to write a speech
> dispatcher driver instead?  That way, if you use speechd-up, indexing
> would work.  What do you think?
>
> Shawn Kirkpatrick <shawn@shawnk.ca> wrote:
>
>> I've written a program that will allow hardware synthesizers to be
>> used with speakup even thoe the serial support seems to be currently
>> broken. I wrote this program about a year ago when I thought this
>> problem would be only temporary. Since it seems like the hardware
>> synthesizer support is still broken and isn't going to be fixed
>> anytime soon I thought I'd put it out there in case it can be of some
>> use.
>> The program is called speakupbridge.
>> speakupbridge is a program which makes it possible for speakup to use
>> external serial, parallel, or usb synthesizers. It does this by reading
>> speakup's softsynth device and passing the text to the synthesizer.
>> speakupbridge has the following features:
>> * The ability to communicate with any device that can accept a string
>> of text using a /dev interface.
>> * The ability to define the commands used by the synthesizer in a
>> user-editable configuration file.
>> * Multiple synthesizer definitions in a single configuration file.
>> * Change the pronunciation of words using a dictionary file (a feature
>> speakup
>> really should do itself).
>> * Save and reload speakup settings for each defined synthesizer.
>> For more information or to download the program please visit:
>> http://www.shawnk.ca/speakup
>> I haven't had a lot of time to work on or test this code lately so
>> there's likely to be some rough spots. You'll have to compile the code
>> but that should be easy enough. I've tested this with my serial Artic
>> transport synthesizer and it seems to work. I don't use speakup
>> regularly thoe (too many other missing/bbroken features) so this
>> program really hasn't had any hard testing.
>> This solution isn't perfect, you still won't get kernel messages from
>> boot up but it least it should be possible to use a hardware
>> synthesizer once the system is started and that's probably better than
>> nothing at all.
>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup@linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>

-- 
--
John G. Heim; jheim@math.wisc.edu; sip://jheim@sip.linphone.org


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Possible work around to the hardware synthesizer problem
     ` John G Heim
@      ` Gregory Nowak
  0 siblings, 0 replies; 9+ messages in thread
From: Gregory Nowak @  UTC (permalink / raw)
  To: speakup

Indexing is where the speech cursor follows what is being spoken by
the synthesizer. So, if the last thing spoken was "indexing" and you
interrupted speech, the speech cursor would be just after the g of
indexing, or very close to it if both the synthesizer and screen
reader support indexing.

Greg


On Mon, Feb 29, 2016 at 10:20:08AM -0600, John G Heim wrote:
> 
> WWhat is indexing?
> 


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-manager@EU.org

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~ UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
 Possible work around to the hardware synthesizer problem Shawn Kirkpatrick
 ` covici
   ` Shawn Kirkpatrick
     ` covici
       ` Shawn Kirkpatrick
         ` covici
         ` covici
   ` John G Heim
     ` Gregory Nowak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).