Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cprichard

Pages: [1]
1
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 04:00:52 am »
I see,, looks like the HAL application uses the VBSCRIPT BRAIN as the dynamic, user-configurable aspect of the product. From VBSCRIPT there are calls to the HalBrain.DLL

I see no reason why I can't simply create my own COMMAND processing DLL that will accept input from HAL and pass COMMAND verbage to HAL-enabled applications.

It will even be possible to PREFACE keywords to help build application interfaces. When a command is issued to open an application, HAL first looks to see if a PREFACE file exists for it. If found, HAL reads the script and a number of KEYWORDS are prefaced with logic needed to build the interface.

Processing uses something like this:

CMD = HalBrain.TopicSearch(UserSentence, WorkingDir & "CMD.brn")

to illicit a response from HAL that is suited for the application to process the UserSentence content returned in COMMAND.

Then the CMD string is passed to the COMMAND.DLL which sends it to the opened HAL-enabled application. Ideally COMMAND.DLL is generic and suited for use by any developer who wants to use a HAL chatter-bot to optionally interface users to their application.

COMMAND.AUTHENTICATE(CMD) ;Validates HAL's user to the application
COMMAND.DO(CMD) ;Issues the command to the application
COMMAND.ABORT(CMD) ;Terminates processes
COMMAND.CLOSE() ;To require re-authentication.


ETC.

 




2
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 02:54:17 am »
One thing to try might be to SHELL to an application without opening a window. That application would simply be capable of passing the associated command verbage along to the desired HAL-enabled application in COMMAND exchanges.

3
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 02:44:45 am »
Okay,, I just caught the flow of the BRAIN editor. IT IS POSSIBLE to parse input looking for specific phrases such as PREFACED keywords. PREFACING them is not dynamic, it is done manually to setup particular responses from HAL. Its possible to then PARSE HAL's responses to get application input and when appropriate, add further processing before passing HAL's response to the application. In taking dictation, HAL would have his BRAIN programmed (prefaced) to handle input by responding with a line for the application. The application then feeds HAL with a response that is actually used to generate HAL's response to the user who was dictating the message. He perceives what HAL is told by the application to do in completing an exchange between the user and the HAL-enabled application. Only problem here is getting something in place to parse HAL's output before making it visible or audible to the user.

The BRAIN EDITOR allows HAL to be VERY customized.

It seems there has to be a way to call a Windows API function to pass input to my application.

-C


4
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 02:20:51 am »
OK,, now I have a disassembled copy of the DLL. Not to VB source, but useable for my analysis to see what's going on in HAL's BRAIN.

Looks like he is a real criminal just bluffing us about having some kind of personality. But he is allot more interesting than some of the people I know.

Anyway, I need to get a handle on the parsing logic that is used to determine a response. Looks like parsing could be added right in the BRAIN editor to put PREFACED keywords ahead of all current parsing to see if buffer content passes as focused application input. Then add a function to implement dynamic calls to any opened application's exposed control methods.

-C

 


5
MSSCRIPT.ocx is the MISROSOFT script control.

You download it from MICROSOFT. You also need MSAGENT installed.

There is README info with links somewhere in the ZABAWARE readout on this.

-

6
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 01:05:34 am »
Ahaa,, all processing is done by the HalBrain.DLL

I have a nifty program somewhere that will give me all the external HalBrain functions. Most of them will be used in the editor.

I also have IDA disassembler to really take it appart.

The HalBrain.DLL is what parses all input. The BRAIN needs to be enhanced to allow application keywords to be created dynamically so that commands and their verbages can be passed from HAL to the application. Even to process HAL's responses to recognize them somehow as readied application input will require some special enhancements. The BRAIN EDITOR might make such a thing possible. with enough coaxing, HAL would begin to recognize COMMANDS and issue responses that are suitable as application input. This seems like a backdoor-like unscientific approach, even to HACKING a solution.

-C

7
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 08, 2003, 12:38:10 am »
So,, thus far I've determined that I want to have HAL open my application and PREFACE a list of keywords with contextual designations or meaning. In initializing, HAL then interrogates my application to get the protocol for each prefaced application function name. Simple command like SEND and CIPHER are easy because there is no added verbage as input or output except to indicate that the message was sent. Then HAL can parse the dialog looking for complete commands in the input buffer, checking against the structures given by the application when initialized. Hal does not presently do this.

Then HAL must send a parsed command to my application as expected input. Windows handles this.

If the source code of HAL is available or a DLL has been developed for HAL that returns TEXT, then its much like the ancient problem of putting a wedge into the Commodore 64 keyboard input routine. Except that its not DOS anymore. Its Windows receiving keyboard input to HAL, or more preferably returning TEXT that has been recognized by a speech-recognition application working with HAL.

I like to think it would be good to establish a kind of protocol that will allow HAL to interface with all HAL-enabled Windows applications. The GOOD PROTOCOL would permit all developers to use the same object in HAL to extend capabillities for passing commands to opened applications.

What is needed is a dynamic feature to permit definition of PREFACED KEYWORDS for HAL enabled applications. HAL will need to aquire the list of prefaced words (easy) and the set of expected parameters with each application COMMAND or ARGUMENT. A protocol is needed for passing the information to HAL in each instance so that HAL can dynamically acquire the set of definitions.

HAL first reads the set of prefaced words.

It then processes those words that have been prefaced as commands by inquiring to the application whether there is associated other verbage and what kind of interaction is initiated with each command. I need to categorize the possible different COMMAND exchanges and determine a pattern to see if its possible to just articulate in some manner the information in a delimited script of lines.

Studying HAL to see about DLL's and controls.

-C


8
Programming using the Ultra Hal Brain Editor / Drawing a Line
« on: January 07, 2003, 11:29:15 pm »
The statement:

PREFACE <phrase of meaning> AS <application name if other than Windows> <context>.

Is like an SQL statement.

The phrases of meaning are reserved in tables of HAL enabled applications complete with protocol and keywords that implement each needed application input function and its error conditions.

The <context> value has only been introduced as "COMMAND" but other contexts are possible.

Contexts like INPUT, ARGUMENT, PARAMETER could be implemented in HAL to permit developers to interface applications with input from HAL like:

PREFACE 'Now is the time for every good man to come to the aid of his country' AS NOTEPAD INPUT.

PREFACE 'BACKGROUND EQUALS GREEN' AS <application name> ARGUMENT.

PREFACE MILES AS <APPLICATION> PARAMETER <parameter name>. (To assert context to the number of miles given to HAL using the keyword PARAMETER ro preface the use of the actual name of a parameter such as a KEY in an encryption application.)

HAL then looks for the keyword "PREFACE" which could be enabled and disabled with simple phrases. "ENABLE KEYWORD PREFACE" would be required to develop a custom interface when initializing HAL. Then in a script HAL reads the necessary PREFACE statements and is ready for application input. The PREFACE keyword can then be disabled if desired so that no more commands can be created by the user. When given the command to close the application. Hal wipes the PREFACED words.

In theory, the list of PREFACED words has to be minimized to maintain HAL's throughput because each word is tested against a list of prefaced values. This shouldn't be too much of a problem though.

In computer languages all the dialog is CODE,, with HAL it doesn't necessarily need to be executable but it is ALL parsed when there are PREFACED words in the database.


-C




9
Programming using the Ultra Hal Brain Editor / Drawing a Line
« on: January 07, 2003, 10:29:19 pm »
The logicians could descend, dropping ideas in an endless rain of torment.

However,, I think a neat approach would be to give the operator (human) the abillity to use a phrase like:

"PREFACE OPEN as XXX COMMAND" (if XXX is missing then HAL inserts WINDOWS to the logic, otherwise a word can be inserted to give additional context to the command when issued.)

The keyword "PREFACE" then is used with HAL to over-ride the brain or cause it to go by-the-book in passing words as specially instructed or PREFACED. The approach gives users allot of flexibility in creating their own custom language for application commands.

"PREFACE TAKE A MESSAGE AS XXX COMMAND" has the keywords PREFACE, AS, and COMMAND. PREFACE AS COMMAND is a common phrase that passes the phrase between PREFACE and AS the meaning to be construed as a XXX COMMAND.

Then in actual use, HAL then passes the "TAKE A MESSAGE" command to the XXX application which would in this case assert to HAL what is expected.

HAL would then be ready to receive input in the form of a MESSAGE that is to be passed to XXX as input. The protocol would stipulate that when the PHRASE "END MESSAGE" is received, the input to XXX is complete. Determining an error condition might require that the user uses "PAUSE MESSAGE" to reinitiate a timer with the default condition that the timeout counter is re-initiated at each iteration. The user would be able to dictate long messages with interruptions.

-C


10
Programming using the Ultra Hal Brain Editor / Drawing a Line
« on: January 07, 2003, 09:53:58 pm »
I haven't actually tested HAL yet but I'm guessing that ZABAWARE has given HAL the abillity to determine the context of the keyword "OPEN" to determine its function. If "OPEN" is not given in the context of a "COMMAND" then the word is interpreted as language. Otherwise it is a Windows system command word.

I was wrong.

With this dialog:

Teri says good evening, tells me the time and asks how my energy level is.

I say I'm OK but am open to ideas.

Teri replies that "to ideas" does not exist in the database.

So Zabaware has not prefaced the word "OPEN" with contextual meaning.

The easiest way to do this is to create another keyword such as COMMAND so that HAL will look to see if OPEN is to be interpreted as a COMMAND.

There is lots of work to do. We know that HAL checks a database of application names to see if it can OPEN something. It should also look to see if the context is "COMMAND" to preface the logic of the interpretation of "OPEN" when issued as a command.

Using this method to PREFACE application commands is necessary to broaden the number of allowable commands. The danger is that inadvertent keyword will cause problems,, but then the user (human) is supposed to sense that its time to be careful about using certain keywords.

-C


11
Programming using the Ultra Hal Brain Editor / Drawing a Line
« on: January 07, 2003, 09:24:39 pm »
ZABAWARE has created a template for giving the Windows system commands issued by HAL. OPEN is a keyword that initiates the opening of an application if its name matches the text of what HAL has interpreted as an application name. I think that is as far as ZABAWARE has gone. To get HAL to issue commands to assert tasking within applications requires more.

To do it,, it might be possible (at least initially) to intercept the OPEN task and look to see if the accompanying verbage contains coded information that can be passed to a designated application. First it would be necessary to abbreviate the ammount of verbage required with each command to get the driver interface to LISTEN for subsequent commands until issued a STOP.

Then with each OPEN statement the driver will pick up the next asserted application task and pass it to the application using a HACKED interface to get it working.

Ultimately, it would be nice to actually create a structure of commands that the HAL application would recognize as a command that is to be passed to Windows to see if it is qualified as an opened application's command. This will require some logic and a protocol,, but when we get this far it becomes interesting.

I'm personally interested in any FREEWARE type of source code for VB, ASM or VC (in that order) that implements the basics of such a Windows driver. (I've heard that Microsoft Outlook was developed with exposed methods that make it possible to externally articulate application tasks for exactly voice recognition development...) There are probably some examples of code that shows the necessary structures in VB,, but the other part of it is that the Outlook application was written to make the structures work. I've heard that it is done with Active-X creating an application control object with the needed exposed or external methods. Examples of this would also be nice.

My thinking is to FIRST instantiate the very basic functionality needed to pass a command from HAL to Windows that can be examined by my own custom interpreter. If someone knows of existing code to implement and/or undocumented HAL features that support development of custom parsing of HAL's issued Windows verbage,, well then please pass it along.

Thanks!

-C

12
Programming using the Ultra Hal Brain Editor / VB6 applications
« on: January 07, 2003, 08:50:11 pm »
I'd like to see if anyone has developed sourcecode to expose methods in a VB6 application to HAL, and successfully achieved results with giving the application commands using HAL.

I just ordered Microsoft's SDK 5.1 for speech recognition which has VB6 examples. It will be a few days before I get into it.

Part of doing it is planning the application so that an Active-X component can be made to expose methods to other applications such as HAL. A specifically HAL-enabled application would then be developed for users willing to pay the extra charge for putting HAL on their system. Microsoft is supporting development without HAL, but it seems that HAL might already possess all desired capabillities except the actual interface.

Going toward using the Microsoft SDK I'm guessing there is much to learn from the logic employed in HAL's brain.

At this stage I'm shaping my effort, doing research to get a perspective necessary for development. I have an E-mail application that will benefit from speech recognition. It would be great if users would find it more fun to chat a little with their computers in addition to using HAL to render my application useful. Developing the objects will be a template for further use of HAL.

Right now it looks like I need to study the SDK to determine what is needed to adapt HAL to giving my application commands via Active-X or OLE. It might be possible to create a driver in Windows to intercept HAL's system commands. This would require that each command given to an application contain a keyword, or be prefaced with a vebal command that tells HAL to listen for MY APPLICATION directives.

In a month I hope to have the necessary information. All help is appreciated.

-C


Pages: [1]