I never used standard, but I think so... Quintijn

-----Oorspronkelijk bericht-----
Van: VoiceCoder@yahoogroups.com [mailto:VoiceCoder@yahoogroups.com] Namens
Eric S. Johansson
Verzonden: vrijdag 27 november 2009 18:56
Aan: VoiceCoder@yahoogroups.com
Onderwerp: Re: [VoiceCoder] edit Python scripts

Quintijn Hoogenboom wrote:
>
>
> Current Natlink/Vocola/Unimacro version is 3.8

works with standard as well as preferred and professional?

Quintijn Hoogenboom wrote:
>
>
> Current Natlink/Vocola/Unimacro version is 3.8

works with standard as well as preferred and professional?

Thank you, Eric. Chances I fly over to the USA are small, but thanks also
for your invitation...

Quintijn

-----Oorspronkelijk bericht-----
Van: VoiceCoder@yahoogroups.com [mailto:VoiceCoder@yahoogroups.com] Namens
Eric S. Johansson
Verzonden: donderdag 26 november 2009 20:09
Aan: VoiceCoder@yahoogroups.com
Onderwerp: Re: [VoiceCoder] edit Python scripts

Quintijn Hoogenboom wrote:

>
> My aim is to bring Dragonfly also under the combined installer, so all
> developments are working under one installer.

just in case no one ever tells you this, I am incredibly grateful for the
work
you are doing bringing all three tools under one installer.  If you ever
make it
to Boston, let me know so I can get together some people from the Boston
voice
users group and take you and a plus one out to dinner.

--- eric

> Current Natlink/Vocola/Unimacro version is 3.8

     More precisely, the combined installer version is 3.8.  The latest
Vocola version is 2.6.4[I].

- Mark

Quintijn Hoogenboom wrote:

> When you want to code really with speech recognition, the tool is
> VoiceCode, but this is another steep curve to take. And you should work
> with Emacs at present. I am thinking of porting to PythonWin and/or
> Komodo though, but that is not a short term project.

   in this opinion will probably probably be treated as heresy but, I think voice
coder, while an absolute amazing piece of work with a great user interface
showed us a wrong way of solving the problem of programming by voice.

I've had this idea about a different way to aproach programming by voice for
quite a few years and it's been evolving every time it circles around the
intellectual drain.  The most recent time it resurfaced was was pitching an idea
to a certain speech recognition company.  The idea was building a dictation box
that is "always awake" and associated with an application window.  Instead of
dictating into the application using something like natural text, you would
bedictating to the dictation box and then when you transfer the data, it would
be injected into that application.

One thing that came out of this kind of almost on the spur of the moment was the
idea that the dictation box Translation engines on the input and the output to
convert from application-specific data to dictation box format data and vice
versa.  The translators could be used to translate plain text with speech
recognition friendly markup to HTML and vice versa.  Then a while later, the
idea fairy took a really big hammer and planted one on my forehead.

The current version of the idea centers on the ability to translate code into an
English like structure and then translate the same English like structure back
into code.  When the English like structure resides in an expanded dictation
box, we would have full use of the existing Select-and-Say capability within the
enhanced dictation box and only need them relatively small amount of code to as
a conduit to different editors.  In its simplest form, all you would need is the
ability to specify cut and paste.

This insight shows one possible blind spots in using speech recognition and that
is using speech recognition within the context of an application.  It may be
better for usability and adaptability to use speech recognition independent of
the application and only require a conduit to go between the two.

The separation model enables a change to the command-and-control model of
naturally speaking with regards to applications.  You can move all of the
controls into an enhanced dictation box if you focus strictly on the commands
that modify the body of the text.  Page breaks, footnotes etc. in the context of
code, it would be things like block boundaries, like continuations etc. (I
think).  All of the commands for manipulating the application itself would
obviously need to be separate from the enhanced dictation box.

Anyway, I thought about the solution and felt it was too simple so I bounced the
idea off of two professors I know at MIT CSAIL and a Welsh computational
linguist.  I got back three thumbs up.  So, it looks like this would be a good
approach to not just programming by voice but editing code by voice.

Benefits are that it's reasonably editor independent, localizes UI problems to
independent component, and editing and code creation process are almost
identical in terms of user experience and complexity.  the problems are that you
need to create a per-language translation modules and specify the pseudo-English
environment for each language.

anyway, I think it's an interesting concept.  No idea on how to implement it
but, based on feedback, I think it's on sound intellectual ground

Quintijn Hoogenboom wrote:

>
> My aim is to bring Dragonfly also under the combined installer, so all
> developments are working under one installer.

just in case no one ever tells you this, I am incredibly grateful for the work
you are doing bringing all three tools under one installer.  If you ever make it
to Boston, let me know so I can get together some people from the Boston voice
users group and take you and a plus one out to dinner.

--- eric

That is too short a question to answer.

Dragonfly is more "modern" than Unimacro, but Unimacro also has a lot of
things already done, from which you can profit.

Installing Dragonfly may present problems if you use the combined
Natlink/Unimacro/Vocola installer. I did not manage to get Dragonfly at work
on my system. Regrettably.

My aim is to bring Dragonfly also under the combined installer, so all
developments are working under one installer.

Quintijn

-----Oorspronkelijk bericht-----
Van: VoiceCoder@yahoogroups.com [mailto:VoiceCoder@yahoogroups.com] Namens
frankolafs
Verzonden: donderdag 26 november 2009 13:44
Aan: VoiceCoder@yahoogroups.com
Onderwerp: [VoiceCoder] edit Python scripts

Hi,

what is the best tool/combination of tools to write Python scripts with
Dragon NaturallySpeaking? On the outset I will be focusing on modules for
dragonfly.

Thanks,
Frank

Hi,

what is the best tool/combination of tools to write Python scripts with Dragon
NaturallySpeaking? On the outset I will be focusing on modules for dragonfly.

Thanks,
Frank

On 11/4/2009 10:51 AM, shane_3m wrote:
> --- In VoiceCoder@yahoogroups.com, Deepak Subburam<deepak@...>  wrote:
>>
>> I can now report that I have vrmode_r011 working with Emacs 22.3 and
>> NaturallySpeaking 10.1. I have not noticed any issues such as the below
>> with it so far.
>>
>> More confidently, I can assert that vrmode_r011 works with Emacs 22.1 and
>> NaturallySpeaking 9.0, a setup I've been using for a couple of years (I'm
>> currently in the process of migrating to NaturallySpeaking 10.1).
>>
>> Deepak
>
> Hi everyone,
>
> I just checked in on the list and saw this. I'm happy to see that VR Mode
> still works for people! Certainly I haven't gotten any recent reports about
> failures, but I never know if that's because noone uses it anymore. ;-) It's
> just Eric's mysterious problem that we never managed to track down, but I
> think his installation is pretty "special".

That's right, I put the "special" into special education.  :-) I've moved on to
Windows 7 and Emacs 23.  vr-mode still didn't work the last time I tried it and
if you're willing, I'll even give you remote access to the desktop so you can
see exactly how it fails.
>
> Have anyone tried it with Win7 and the latest DNS? I'm thinking of upgrading,
> as I'm still using v6 and for one it won't install on XP x64 (it says I don't
> have enough RAM or some such nonsense...) but I don't really want to spend
> money if it's not going to work.

I'm running 9.5 on Windows 7.  It works relativel I still have odd recognition
problemsoblems as well as natural text problems as you can see.  All in all
though I think 7 is a vast improvement over all the other Microsoft releases.
Now if it just wasn't such a horrible experience maintaining UNIX filesystem
semantics from the NT side, I could live with this environment for a very long
time.


>
> cheers,
>
> /Patrik
>
>
>
>
> ------------------------------------
>
> Community email addresses: Post message: VoiceCoder@onelist.com Subscribe:
> VoiceCoder-subscribe@onelist.com Unsubscribe:
> VoiceCoder-unsubscribe@onelist.com List owner:
> VoiceCoder-owner@onelist.com
>
> Shortcut URL to this page: http://www.onelist.com/community/VoiceCoderYahoo!
> Groups Links
>

--- In VoiceCoder@yahoogroups.com, Deepak Subburam <deepak@...> wrote:
>
> I can now report that I have vrmode_r011 working with Emacs 22.3 and
> NaturallySpeaking 10.1. I have not noticed any issues such as the below with
> it so far.
>
> More confidently, I can assert that vrmode_r011 works with Emacs 22.1 and
> NaturallySpeaking 9.0, a setup I've been using for a couple of years (I'm
> currently in the process of migrating to NaturallySpeaking 10.1).
>
> Deepak

Hi everyone,

I just checked in on the list and saw this. I'm happy to see that VR Mode still
works for people! Certainly I haven't gotten any recent reports about failures,
but I never know if that's because noone uses it anymore. ;-) It's just Eric's
mysterious problem that we never managed to track down, but I think his
installation is pretty "special".

Have anyone tried it with Win7 and the latest DNS? I'm thinking of upgrading, as
I'm still using v6 and for one it won't install on XP x64 (it says I don't have
enough RAM or some such nonsense...) but I don't really want to spend money if
it's not going to work.

cheers,

/Patrik

Well... RTFM - A glance in the vista help screens set me straight - Project
works fine in Vista and XP with no modifications needed.

Life is Good.

joe

--- In VoiceCoder@yahoogroups.com, Joe Reynolds <spamgactus1@...> wrote:
>
> I am writing a VB6 speech-controlled app. I first wrote the program while
using Win2K, now I'm using XP. The program at this point uses SAPI 5.1.
>  
> What kind of hoops will I have to jump through to make the program Vista/SAPI
5.3 compatible? I have already tried to just run the program in Vista without
any modifications, and everything works, except of course the SR.
>  
> I have gathered from other sources on the web that SAPI 5.1 apps won't work in
Vista, and SAPI 5.3 apps won't work in XP/2K, etc. Is that truely the case? If
so, what do I do to plug SAPI 5.3 into the project? Can I use both SAPI
versions, and switch from one to the other depending on which OS is detected?
>  
> Thanks,
>  
> joe
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

--- In VoiceCoder@yahoogroups.com, "Eric S. Johansson" <esj@...> wrote:
> What reasons would you give for switching

* Frustrations with Nuance.
* Vocola 3


> What reason would you give for not switching?

* Text Services Framework (TSF).
* Applications that support TSF:

   Microsoft Word
   Microsoft Outlook

* Applications that don't support TSF:

   Everything not listed above.

> Then I got talking with Susan about some of the things I had been
> noticing when trying to piece together a Python-based application
> environment.  Most of the people that had worked on the core pieces
> like natlink have moved on to Windows speech recognition.  I wasn't
> sure why this was happening.  I have some conjectures but I'd like to
> hear from folks who have made the transition to Windows speech
> recognition.

     Neither Quintijn nor I have moved on to WSR.  Understandably, power
users like to hedge their bets.  At this point I have some hedges
against DNS/NatLink failures:

   * Rick's WSR version of Vocola 3
   * Dragonfly, which also supports WSR, as a possible Vocola 2 target
   * if just NatLink dies, it's not very hard to retarget Vocola 2 to
     directly generate advanced scripting commands for DNS
     (Downsides: need prof. version of DNS, no command sequences,
      no  _anything, time-consuming load step)
   * Vocola's core is simple enough that it should be able to target
     pretty much any decent voice-based macro system

     As Rick says, it's looking like WSR isn't going to reach its
potential as a DNS killer anytime soon.  :-(

- Mark

> Most of the
> people that had worked on the core pieces like natlink have moved on to
> Windows speech recognition.

What makes you say that? I'm not sure it's true. I have switched, but by far
most of the traffic on this list and Speech Computing is from dragon users.

> Microsoft has, in the past, had an active developer soliciting or input.

That was true, but I think it has changed. Since WSR is part of the operating
system the opportunities for fixes / enhancements are few and far between. There
were relatively few changes for windows 7, and I suspect that what's left of the
WSR team is focused on mobile and server-based speech applications where there's
more payoff than on the desktop. (I only have circumstantial evidence for this,
perhaps Rob Chambers is still paying attention and can correct me.)

> nuance's inability or unwillingness to fix long-standing bugs that
> seriously hurt developers (natural text, grammar parser, etc.

This is sad and frustrating. But while WSR doesn't have these particular
problems, it does have other problems which I'm not optimistic about fixes for.
(Like: no support for vocabulary words with spacing properties, overzealous
capturing of phrases like "Caps Hello" and "No Caps That" in non-WSR-dictation
contexts, and API deficiencies which cause Vocola command sequences to sometimes
be misrecognized as dictation.)

> Microsoft has provided a more accessible/higher function API for
> third-party applications.

True, and great.

> What reasons would you give for switching what reason would you give for
> not switching?

My reasons for switching:
1) NatLink could be desupported without warning in any NatSpeak release.
2) The WSR API.

Why I might switch back: Nuance at least has a team actively dedicated to
NatSpeak and regular releases, and might wise up with any release.

Maybe in a few years when smart phones offer sophisticated voice control,
desktop environments will belatedly catch up.

-Rick

I was talking with Susan Cragin about doing our annual update about naturally
speaking on wine sometime soon we realized we didn't have a whole lot to say.
Naturally speaking on wine getting more stable and there is some bugs that need
to be fixed but the effort seems to be running out of steam/Money.  The
conversation turned to why I moved back to Windows and NaturallySpeaking and the
answer was simple, I need to get work done.  Windows 7 is almost as good as
Linux in many ways.  The only pain in the ass is the conceptual mismatch between
Windows and Linux for doing cross boundary development

Then I got talking with Susan about some of the things I had been noticing when
trying to piece together a Python-based application environment.  Most of the
people that had worked on the core pieces like natlink have moved on to Windows
speech recognition.  I wasn't sure why this was happening.  I have some
conjectures but I'd like to hear from folks who have made the transition to
Windows speech recognition.

If I was going to make the transition, for me it would be because

Microsoft has, in the past, had an active developer soliciting or input.

The cost of Windows 7 is about the same as the cost of Linux plus
NaturallySpeaking preferred and even lower if Windows delivered with your
machine.

nuances inability or unwillingness to fix long-standing bugs that seriously hurt
developers (natural text, grammar parser, etc.

Microsoft has provided a more accessible/higher function API for third-party
applications.



What reasons would you give for switching what reason would you give for not
switching?

Eric S. Johansson wrote:
> after a fm day of trying to fix a vm networking problem I broke NatSpeak. 
when
> I try to run it, I get  "The class is configured to run as a security id
> different from the caller"  any ideas?

   ran a repair and audio setup Wizard.  Seems to have restored NaturallySpeaking
to normal function.  I still would like to know what the hell I did to break
natspeak but, it's running and that's all I care about right now.

after a fm day of trying to fix a vm networking problem I broke NatSpeak.  when
I try to run it, I get  "The class is configured to run as a security id
different from the caller"  any ideas?

--------------------------------------------------
From: "Eric S. Johansson" <esj@...>
Sent: Sunday, August 02, 2009 3:46 PM
To: <VoiceCoder@yahoogroups.com>
Subject: Re: [VoiceCoder] Installation directory for NatLink

> LuDean Marvin wrote:
>
>> It follows then that the immutable must go in the programs directory and
>> the
>> mutable data in a users directory.  As far as whether mutable should be
>> under All Users on an Individual User, the DNS user should be given the
>> option to select which one.  Even though DNS can only be used by one
>> person
>> per license requirements, that one person may wish to have two or more
>> windows profiles for a host of reasons (most of them too obscure for me,
>> but
>> we're all an obscure bunch anyway ;-) .  Besides (now I'm really being
>> off
>> the wall) some of us might even have multiple personality disorder!
>
> :-)
> it is a use case that may or may not be useful for others.  I install
> NaturallySpeaking for all users because I sometimes use it as my user
> account,
> and other times I use it as an administrator account.  Same person, two
> accounts
> on two machines.
>
> now if only I could use it to control a remote machine with the same ease,
> well... someday
>
> --- eric
>

Good point!  That's a use I had not thought of when I jested about the All
Users directory, but not just a few of us would have need for that option.

LuDean

LuDean Marvin wrote:

> It follows then that the immutable must go in the programs directory and the
> mutable data in a users directory.  As far as whether mutable should be
> under All Users on an Individual User, the DNS user should be given the
> option to select which one.  Even though DNS can only be used by one person
> per license requirements, that one person may wish to have two or more
> windows profiles for a host of reasons (most of them too obscure for me, but
> we're all an obscure bunch anyway ;-) .  Besides (now I'm really being off
> the wall) some of us might even have multiple personality disorder!

:-)
it is a use case that may or may not be useful for others.  I install
NaturallySpeaking for all users because I sometimes use it as my user account,
and other times I use it as an administrator account.  Same person, two accounts
on two machines.

now if only I could use it to control a remote machine with the same ease,
well... someday

--- eric

--------------------------------------------------
From: "Mark Lillibridge" <mark.lillibridge@...>
Sent: Saturday, August 01, 2009 11:35 AM
To: <natpython@...>
Cc: <q.hoogenboom@...>; <VoiceCoder@yahoogroups.com>
Subject: [VoiceCoder] Installation directory for NatLink

>
>    I'm looking for opinions on what the default installation directory
> for NatLink should be / where NatLink data should live.
>
>    Normal Windows conventions apparently say that the program immutable
> part should live in Program Files[ (x86)]\NatLink and the mutable data
> should live in %AllUsersProfile% or %AppData% depending on whether the
> application is installed for one user or all users.
>
>    We have been cheating because we have kept mutable data (e.g.,
> macrosystem\*.py[c]) in Program Files.  This was tolerated under Windows
> XP, but Vista tries hard to prohibit this for security reasons.
>
>    Accordingly, we either need to switch to the Windows scheme (I
> assume it should be installed for all users) or we need to choose
> another install directory location like C:\NatLink.
>
>    Opinions?  Any Windows developers out there who know more about
> these issues?
>
> - Mark
>
>

I'm of the opinion that Natlink should be kept in the Programs directory
where it is now.  I would really like to see Python there, too, though I
think that is out of Natlink developers hands.

It follows then that the immutable must go in the programs directory and the
mutable data in a users directory.  As far as whether mutable should be
under All Users on an Individual User, the DNS user should be given the
option to select which one.  Even though DNS can only be used by one person
per license requirements, that one person may wish to have two or more
windows profiles for a host of reasons (most of them too obscure for me, but
we're all an obscure bunch anyway ;-) .  Besides (now I'm really being off
the wall) some of us might even have multiple personality disorder!

LuDean

Mark Lillibridge wrote:
>     I'm looking for opinions on what the default installation directory
> for NatLink should be / where NatLink data should live.
>
>     Normal Windows conventions apparently say that the program immutable
> part should live in Program Files[ (x86)]\NatLink and the mutable data
> should live in %AllUsersProfile% or %AppData% depending on whether the
> application is installed for one user or all users.
>
>     We have been cheating because we have kept mutable data (e.g.,
> macrosystem\*.py[c]) in Program Files.  This was tolerated under Windows
> XP, but Vista tries hard to prohibit this for security reasons.
>
>     Accordingly, we either need to switch to the Windows scheme (I
> assume it should be installed for all users) or we need to choose
> another install directory location like C:\NatLink.
>
>     Opinions?  Any Windows developers out there who know more about
> these issues?

well, having backed away from Linux as a speech recognition platform (much to my
great sadness and hopefully only briefly)  I've taken a renewed interest in this
type of problem.  From what I've seen, if you don't  give the user the choice
offall users or a single user, you choose the all users profile.  Like you, I'm
leaning towards install for everyone *but* we will need to make it very clear
where the data is located because the all user profile is not on the tip of the
literate person's tongue.

If you do this, I would suggest adding a program files menu option to open the
configuration directory for editing

Mark Lillibridge wrote:
> natpython@... is bouncing...

I sent out a notice of possible termination about a year or more ago because the
list had zero activity.  Got no response about keeping the list so I terminated
it.  I figured if we want to talk about it, it would happen on this list.

Hi Mark,

It is best to follow the Windows convention. Also, you can give the user the
option to choose where they want different components of natLink to reside.
Pranav

natpython@... is bouncing...

- Thanks,
   Mark

I'm looking for opinions on what the default installation directory
for NatLink should be / where NatLink data should live.

     Normal Windows conventions apparently say that the program immutable
part should live in Program Files[ (x86)]\NatLink and the mutable data
should live in %AllUsersProfile% or %AppData% depending on whether the
application is installed for one user or all users.

     We have been cheating because we have kept mutable data (e.g.,
macrosystem\*.py[c]) in Program Files.  This was tolerated under Windows
XP, but Vista tries hard to prohibit this for security reasons.

     Accordingly, we either need to switch to the Windows scheme (I
assume it should be installed for all users) or we need to choose
another install directory location like C:\NatLink.

     Opinions?  Any Windows developers out there who know more about
these issues?

- Mark

http://brainstorm.ubuntu.com/idea/20263/

I put in #3 because I believe the other solutions do not solve the right
problem.

"""It is unrealistic to expect all machines a user uses to have accessibility
software. There may be multiple reasons for this ranging from administrative
overhead to licensing issues to interference with normal operation. By adopting
the perspective that the user interface moves with the user and not the machine
opens up new possibilities for widely available accessibility. By associating
the user interface software (speech recognition, text-to-speech, various dog and
pony tricks, etc.), the impact on the general machine is lessened, and
administrative costs are lowered, licensing issues are reduced or eliminated,
and the user has increased control over the software they need to function.

This can be implemented today using virtual machine technology and relatively
minimal bridge software making the accessibility software interface visible on
the host and enabling interaction between the application and the accessibility
software.
"""

if you can support the concept of user associated ui, please vote for it