dictation-toolbox / aenea-grammars

Grammars pulled out of aenea as preparation for merging all grammars.

dictation-toolbox

Meta-repository for tracking and providing information about the organization itself.

Summary

dictation-toolbox is a loose organization intended to organize projects for users of voice recognition software, with a focus on customizability, flexibility, and programming/system administration/etc. We hope to help fill in the gap between commercially available solutions for common workflows and other workflows which require customization.

We also intend to provide a contingency plan for projects to be "adopted" by new maintainers if their current maintainers leave without transferring control of the project. Each repository in dictation-toolbox has one or more owners responsible for it, and admins of dictation-toolbox agree not to use their admin privileges on repositories where they are not an owner, except in the case of all owners dropping out of all contact for four months.

We are open to including other projects under these terms to better serve the needs of the dictation community. Please open an issue in this repository if you are interested. Historically, we have made all owners of all repositories in dictation-toolbox admins of the organization.

Projects

The listed owners of each project, rather than the admins of dictation-toolbox, retain full control and responsibility for all aspects of their project.

aenea

Owners: @calmofthestorm

Client-server library for using voice macros from Dragon NaturallySpeaking and Dragonfly on remote/non-windows hosts using NatLink and Dragonfly.

aenea-grammars

Owners: @calmofthestorm

A collection of grammars written for use with Aenea, with an eye toward programming and use on Linux.

dragonfly-scripts

Owners: @nirvdrum

This repository contains a collection of Dragonfly Python-scripts, that can be used with Dragon NaturallySpeaking Professional.

aenea-resources

Owners: @calmofthestorm

Miscellaneous resources (cheatsheets, etc) for working with aenea and aenea-grammars.

aenea-grammars's Issues

What's up with the git grammar?

https://github.com/dictation-toolbox/aenea-grammars/tree/master/_git

there is a json file with stuff that looks duplicated from the py file. what's going on?

i came across this as i wanted to make an easier way to add new git commands/options. i don't like json because yu are restricted to the json strucutre. i wanted to generate python classes so this sort of api would work within the git grammar:

add_git_command('stash', options=[
        sub_command('add'),
        sub_command('save'),
        # ...
        option('verbose'),
        option('patch'),
        # ...
])

The verbal Emacs name is confusing

When I first looked at this, I assumed that verbal Emacs meant that it provided Emacs support but of course, it is actually a VIM grammar. This could become especially confusing if a grammar for Emacs is added later. For these reasons, I propose that it be renamed to "verbal vim".

Fix uppercase letters not working

I have these vim grammars

        'open': Key('o'),
        'big open': Key('O'),

but whether I say open or big open (these are understood correctly by Dragon), only a lower case o is pressed.

It appears you have to use s-o instead of O

Support for common editors

How about trying to flesh this repository out with a few more grammars that support common editors? Having a few solid grammars for common editors in this repository might help aenea/dragonly newbies ease into development.

I hacked up an Intellij IDEA grammar this week and am open to tidying it up if we think it's worth the effort.

https://github.com/mzizzi/aenea-grammars/blob/mzizzi/_idea/_idea.py

Thoughts on Aenea reimplementation

There still needs to be a Aenea reimplementation. Some might say that Aenea has outlived its use case with Dragonfly implementing cross-platform support and Draconity for DNS.

I don't believe that to be the case. We are now bridging into using more open source technology for speech recognition. Aenea has some advantages yet to offer. Primarily separating the backend (speech recognition engine) from the frontend client over a network.

• Larger models for speech recognition
• Dictation on low power devices
• Easier deployment
• More...

Anyone who is used Aenea knows that it's hard to set up and difficult to maintain. So what would be the path of least resistance? Why not to allow two instances of Dragonfly to communicate proxied with audio streaming. The thought is for whatever speech recognition engine is available through dragonfly would be compatible including DNS.

Dragonfly cross-platform and implements much of what was in Aenea to provide Linux. Testing can be done on Dragonfly 'text' engine which does not require a backend to perform manual and unit tests.

I primarily wanted to share this thought with the community to gauge interest. While I recognize I do not have the technical skills to build this from the ground up, I'm willing to contribute.

Support for accentuated letters is lacking

/!\ POSTED ON THE WRONG PLACE, SORRY

Hello there.
Current setup with Dragon 14 with a french profile, natlink Uniform, and the last version of dragonFly patched to accept accentuated letters
(made possible by the manual application of the patch given by chep in this thread)

All is working fine , even in french, as long as I don't use words with accentuated letters, ("être", "coupé", "lève", ...)

In my setup Natlink and dragonfly handles it well, but not aena.

The error brought back by natlink is (this is only the last line for clarity, full error at the end of post):
jsonrpclib.jsonrpc.ProtocolError: (-32603, u'Server error: File "/home/remi/aenea-master/server/linux_x11/x11_xdotool.py", line 178, in write_command | UnicodeEncodeError: \'ascii\' codec can\'t encode character u\'\\xe9\' in position 3: ordinal not in range(128)')

this corresponds to this piece of code from aenea-master/server/linux_x11/x11_xdotool.py :

    def write_command(self, message, arguments='type --file -',
                      executable=None):
        executable = executable or self.xdotool
        self.logger.debug(
                'echo \'%s\' | %s %s' % (message, executable, arguments))
        with os.popen('%s %s' % (executable, arguments), 'w') as fd:
            fd.write(message) # THIS IS LINE 186

The debug line puts properly the accentuated letters on my terminal :
echo 'coupé' | xdotool type --file - --delay 0
But doesn't then execute anything

Of course, if I copy-paste this very line into a terminal, is executes properly and without any problem.
It seems the execution environment launched from python somehow doesn't support utf-8.
Anybody as a clue as how to get to the next step ?

Rewrite multiedit and verbal_emacs to use Function

Now that I understand how Dragonfly functions work, I realize the process_recognition and value hacks are unnecessary. I suspect this will correct several bugs in verbal_emacs.

OSX - Vim grammar system events (applescript) error

This error shows up in the Natlink console on the VM when I am speaking with the vim grammar.

Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\dragonfly\engines\engine_natlink.py", line 225, in begin_callback
    self.grammar.process_begin(executable, title, handle)
  File "C:\Python27\lib\site-packages\dragonfly\grammar\grammar_base.py", line 361, in process_begin
    r.process_begin(executable, title, handle)
  File "C:\Python27\lib\site-packages\dragonfly\grammar\rule_base.py", line 183, in process_begin
    self._process_begin()
  File "C:\NatLink\NatLink\MacroSystem\_vocabulary.py", line 51, in _process_begin
    aenea.vocabulary.refresh_vocabulary()
  File "C:\NatLink\NatLink\MacroSystem\aenea\vocabulary.py", line 131, in refresh_vocabulary
    _rebuild_lists('dynamic')
  File "C:\NatLink\NatLink\MacroSystem\aenea\vocabulary.py", line 175, in _rebuild_lists
    for (c, _) in _vocabulary_inhibitions.get(tag, [])):
  File "C:\NatLink\NatLink\MacroSystem\aenea\vocabulary.py", line 175, in <genexpr>
    for (c, _) in _vocabulary_inhibitions.get(tag, [])):
  File "C:\NatLink\NatLink\MacroSystem\aenea\wrappers.py", line 212, in matches
    return context.matches(executable, title, handle)
  File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 146, in matches
    return self._reduce_matches(self._check_properties())
  File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 107, in _check_properties
    properties = _get_context()
  File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 76, in _get_context
    _refresh_server()
  File "C:\NatLink\NatLink\MacroSystem\aenea\proxy_contexts.py", line 63, in _refresh_server
    _last_context = aenea.communications.server.get_context()
  File "C:\NatLink\NatLink\MacroSystem\aenea\communications.py", line 108, in call
    return self._execute_batch([(meth, a, kw)])
  File "C:\NatLink\NatLink\MacroSystem\aenea\communications.py", line 87, in _execute_batch
    batch[0][0])(*batch[0][1], **batch[0][2])
  File "C:\Python27\lib\site-packages\jsonrpclib\jsonrpc.py", line 290, in __call__
    return self.__send(self.__name, kwargs)
  File "C:\Python27\lib\site-packages\jsonrpclib\jsonrpc.py", line 238, in _request
    check_for_errors(response)
  File "C:\Python27\lib\site-packages\jsonrpclib\jsonrpc.py", line 567, in check_for_errors
    raise ProtocolError((code, message))
jsonrpclib.jsonrpc.ProtocolError: (-32603, u'Server error:   File "/usr/local/lib/python2.7/site-packages/applescript/__init__.py", line 65, in _unpackresult | ScriptError: System Events got an error: Can?t get window 1 of process "iTerm2" whose value of attribute "AXMain" = true. Invalid index. (-1719) app=u\'System Events\' range=404-409')

In case I haven't set things up right, after setting up aenea according to the instructions I copied the _vim.py and vocabulary_config into my C:\NatLink\NatLink\MacroSystem folder on the VM, then restarted Dragon.

multiedit should use disable config

Update multiedit to use dictation-toolbox/aenea#75.