Dragon freezes when natlink.natConnect() used

[Jason Veldicott]

An example grammar from the Dragonfly site, shown below, was tried with natlink.natConnect() prepended to try to 'attach' a grammar to the natlink system without having to include it in the MacroSystem directory.  This is the code:

from dragonfly.all import Grammar, CompoundRule

from dragonfly.engines.engine import get_engine

from dragonfly.engines.engine_natlink import natlink

natlink.natConnect()   # <<<<<<<<< ADDED CONNECT

try:   

    # Voice command rule combining spoken form and recognition processing.

    class ExampleRule(CompoundRule):

        spec = "do something computer"                  # Spoken form of command.

        def _process_recognition(self, node, extras):   # Callback when command is spoken.

            print "Voice command spoken."

    

    # Create a grammar which contains and loads the command rule.

    grammar = Grammar("example grammar")                # Create a grammar to contain the command rule.

    grammar.add_rule(ExampleRule())                     # Add the command rule to the grammar.

    grammar.load()

except:

    natlink.natDisconnect()

    raise

But the result is that Dragon's speech recognition (v11.5) locks up.

Maybe the only way for a grammar to be recognized is for it to be placed in the MacroSystem directory, even though natConnect() is provided.

Can this be confirmed?

Thanks

Jason

[Jason Veldicott]

After further consideration, this could be due to the working of natlinkmain.py, which apparently is responsible for loading and unloading of grammar modules in the MacroSystem directory.  If Dragon callbacks are somehow funnelled through this component, then perhaps even once a grammar is added, if it needs to access the grammar file again and it is not accessible in the MacroSystem directory, the grammar wont work.  If this is the case, one wonders if it is a necessary limitation.

Jason

[Charlie Tango]

Hello Jason,

The code in your first message makes me think that you are trying to
run the Python file as a "script" as opposed to a "macro" loaded by
natlink running inside DNS. That is possible, although you need to
take care of some additional processing yourself instead of letting
natlink do it for you. For example, you must run your own "message
loop" to drive the script.

An example of an application that loads Dragonfly command modules
itself, i.e. in a standalone application instead of in the natlink
that is running inside of DNS, is Bumblebee. Source code available
here:

https://bitbucket.org/t4ngo/bumblebee

Specifically note the following code within Bumblebee:
- bumblebee/system/dragonfly.py: DragonflySystemParticipant.startup()
and .shutdown() -- these connect and disconnect from a speech
recognition engine
- bumblebee/command/legacy_loader.py: LegacyDirectoryLoader.update()
-- command modules are loaded and unloaded here

Kind regards,
Charlie

[Jason Veldicott]

Hi Charlie,

Thanks for your reply.  Yes, I'm using scripts to fiddle around with the Dragonfly system and perhaps Natlink if needed.  I'd like to be able to control stuff from my environment, with an active dialogue with Natlink, rather than the more rigid 'place your files here' approach. But given the workings of Dragon and its fixed protocols for voice recognition and the grammar system of Natlink, it may be the case that simply providing Natlink a set of grammar files to load is convenient enough and sufficient.

Running a message loop doesn't sound to be ideally what I was after - it was more calling natlink to add a grammar using objects rather than relying on the grammar file repository (already done by Dragonfly using GramObj in natlink_engine.py, but it seems more is required beyond natConnect()) - but I will have a look at the BumbleBee code, the mention of which is appreciated.

Thanks

Jason

[Charlie Tango]

Hello Jason,

Have you had any success with this? What do you think of the Bumblebee code?

The challenge you're facing here is due to DNS's architecture (and
Windows in general). When you connect to the recognition engine, and
it sends you a recognition event, you must run some kind of an event
loop, otherwise the recognition engine will block waiting for you.
That's just the way Windows applications talk to each other. Writing
such an event loop can be slightly tedious, so I hope that Bumblebee
can serve as an example to help you dare.

Best regards,
Charlie

[Jason Veldicott]

I much prefer the move evolved events kind of architecture to loops, so I must confess I gave this a miss.  For now at any rate.

But I will probably get around to looking at Bumblebee, even though it may not be necessary to hook grammars in dynamically from the Dragonfly side, but to gain a little more understanding of how the systems work.  

Wondering whether or not it may be possible, more out of curiosity at this point rather than any committed resolve, to efficiently hook into DNS without Natlink, at least as it is, and without DNS registered grammars even.  ie interface with DNS only at the most basic level and handle all the grammar stuff with complete flexibility externally. 

Jason