Existing Bugs

The present state of the Talking Face implementation of the DIVA project still contains a few errors. The issues, and some hints at resolution, are described below:

1. When launched from MAX, the KuraFace becomes unresponsive to input after about 45 seconds

The KuraFace model is launched via the StartAS class, in the package artisynth.core.driver. This class, in turn, is run from the Artisynth jar file, located in the DIVA project in the ArtisynthTools folder. StartAS can be edited from the Eclipse Java development environment ( located on Brahms at BrahmsOSX:/Eric/eclipse/ ), and the jar file can be built from source by typing ant jar while in the BrahmsOSX:/Users/diva/Documents/workspace/artisynth_2_0 folder.

The Artisynth jar file is run using the following command, in the directory where the jar file is located:
java -cp Artisynth-2.0.jar artisynth.core.driver.StartAS
When this command is sent from a terminal window, Artisynth loads the KuraFace model, waits for a socket connection, and the face can be stretched by sending values through the socket connection, for any length of time. However, when the command is sent from within MAX, the KuraFace model only responds to values through the socket for about 45 seconds, and then becomes unresponsive.

It is clear that this error has something to do with MAX. What is not clear is the specific error occuring -- since the Artisynth jar is launched as a process from the ArtisynthManager MXJ code, the error output is not printed back to the MAX window. In order to determine the problem, the first step is to obtain this error output somehow.

2. A stack overflow occurs in CreateVizemeMap when clicking on "new map"

A bug occurs when performing the following behaviour:

i) From the Main Window, select CreateVizemeMap from the Vizeme Tools menu
ii) In the CreateVizemeMap interface, select a dictionary, and click "Choose Dictionary"
iii) Click on "new map"

At this point, MAX notifies the user that a stack overflow has occured, caused by a message object in the "newMap" patcher, located in the Vizemes/CreateVizemeMap/getMap/ folder of the DIVA project. It is suspected that the "iter" object is causing too much data to be sent to the message object in succession, so that if this data flow is slowed down somehow, the overflow might not occur.

3. In the CreateVizemeDictionary and CreateVizemeMap interfaces, "Load Dictionary" or "Load Map" will occasionally not work properly

The conditions which cause a dictionary or map to be improperly loaded have not been precisely determined -- the occurence is not specific to certain files, and does not appear to follow any particular commands. What is known, however, is that when a dictionary loads properly, the send/receive variables (see MAX help for explanation of send & receive) i_newDict, dictPath, dictName, dictOwner, s_dictStatus are all properly set. When a dictionary does not load properly, only the variables i_newDict, dictPath, and s_dictStatus are set. The case is similar for the map interface, except with "map" rather than "dict". Open the VizemeTroubleshoot patcher for a printout of these variables, when they are set.

The problem is likely to be somewhere in the "loadDictionary" and "loadMap" patchers, in the Vizemes/CreateVizeme(Map|Dictionary)/get(Map|Dictionary)/ folder. TextToLists is suspected as a potential cause, since it is beyond this object that dictOwner and dictName are set, and these are the variables which are not set when the dictionary does not load.