HyperScribe is a module for organising parameters and data arising from computational experiments, visualization sequences, real-world observations and so on. Using a visual management tool, HyperScribe allows sets of data to be linked together in a way which reflects their inter-relationship, providing a useful `aide memoire' to the series of events leading to their creation.
HyperScribe itself is not designed to hold the actual data, but is written to manipulate and store text strings, typically file names, which define where the data are to be found. Herein lies the module's power and flexibility since, with no internal reference to any particular data type, it can handle all IRIS Explorer structures equally well. Other modules already exist to read and write Geometry, Lattices, Pyramids and so forth and it is not necessary to duplicate these functions within HyperScribe. All that is required is to feed to or from an existing module the relevant file name and let those modules do the work. A further advantage of this approach is its ability to organise data which is not part of IRIS Explorer's data model, such as a file of notes created by a word processor or text editor.
The design of the visual management tool draws upon the results of the GRASPARC project, where associated items of data are grouped together into a `snapshot' and (here) represented by a sphere. Relationships between snapshots (for example, a sequence of images developing in time) can be denoted by links between the spheres, drawn as cylinders. Using a point-and-click interface, the user is able to draw a picture of how the data sets are related, adding snapshots as the data are generated and retrieving the information at any time.
The provided map `dataman' is an example of how to wire up HyperScribe for data retrieval and `dataman2' shows how to do data capture. Both functions can be accomplished simultaneously by one HyperScribe module.
Optional: This port is optional.
HyperScribe works in a loop with a downstream Render by receiving Picks from that module; Render must be in `User Pick Mode' to generate the required data for HyperScribe. Both keyboard and mouse events are used:
A(a) - pressing the `a' key whilst the mouse pointer is over the Canvas results in the addition of a sphere representing a snapshot at the specified point. Strings are applied to the snapshot using the current contents of the InPar and InComp text widgets (see below). Pressing this key over an existing snapshot results in an error message.
I(i) - pressing the `i' key whilst over a snapshot conveys information about that snapshot. The InPar and InComp text widgets are used to display whatever strings are found. Pressing this key over the Canvas results in an error message.
R(r) - pressing the `r' key whilst over a snapshot also conveys information about that snapshot. However the OutPar and OutComp text widgets are used to display whatever strings are found and, since these widgets are typically connected to downstream modules, the net result is to relay information to the Map, rather than just to display it. Pressing this key over the Canvas results in an error message.
BtnDown - pressing the left mouse button whilst over a snapshot indicates the start point of a link.
BtnUp - releasing the left mouse button whilst over a snapshot indicates the end point for a link. The BtnUp event must follow the BtnDown event directly, so the combined operation of making a link is to press, slide and release over the snapshots to be linked. A snapshot cannot link to itself.
Use a snapshot to represent a collection of associated data, for example, the values of a field at some time together with notes on the parameters used to generate the data. Use links to denote related snapshots, for example, four fields generated for increasing times could be drawn as four spheres in a row with three links between. A fifth field with a time intermediate between that of the second and third could be drawn as an additional sphere on a link dependant from the second. In this way, tree-like descriptions can be built up, with the progress of an experiment recorded as a series of branches. In the GRASPARC project, this structure was called a `History Tree'. In HyperScribe, descriptions need not form trees, but this structure will very often suffice.
Although the Pick port is optional, it must be connected in order to view any of the stored information. Its optional status merely simplifies the usage sequence (see `Known Problems').
Port: Activate Tags
Optional: This port is optional.
Connecting to this port causes HyperScribe to check that the Pick it receives comes from its own geometry. This is useful when the map includes other modules which generate Pick data (e.g. QueryLat) or when using more than one HyperScribe module. The data on the port is never read, so it is sufficient to connect anything which delivers a parameter value, e.g. one of the "Widgets<type>" modules.
Port: Input File
This is the first widget to appear when HyperScribe launches. It is available only during the Problem Description phase. Pressing <return> (i.e. a null file name) puts the Problem Description process into `interactive mode'. In this mode, the InPar and InComp widgets appear in turn (see below) until all the items of data to be organised have been described. When HyperScribe is destroyed, a file `tree.pyr' results, containing a template of the information being organised, the strings associated with snapshots and the links joining them.
Typing the name of a file previously created by HyperScribe causes that file to be read and puts the Problem Description process into `automatic mode', with the widget parameter and component labels updated according to the experiment template in the file. All of the strings and structure of the description are preserved and can be added to, so a single experiment can span several IRIS Explorer sessions. When the module is destroyed the file is updated with the new information included, but the original file *must* be writable for this to work. If HyperScribe is loaded within a map, only automatic mode is available and the Input File slot must therefore have a valid filename present when the map is saved.
Port: InPar<1-5>, InComp<1-5>
During the Problem Description phase the widgets are labelled with their generic names. They appear one at a time in turn and the user types into the text slot the label by which this item is subsequently to be known. Names indicating the future contents are preferable, such as "Velocity", "Time Now", "Comment" and so on. On pressing <return>, the current widget is relabelled with the new name, it is disabled and the next (if any) is shown.
Widgets to organise parameters and components are handled separately by HyperScribe but, at present, in the same way. Component widgets hold the data and parameter widgets hold data about the data. If just <return> is typed in any slot during the Problem Description phase, this indicates that descriptions have finished for parameters or components. Once all parameters and components have been labelled, the input widgets are enabled and their output counterparts, also appropriately labelled, are shown. The Problem Description phase is now completed and HyperScribe begins the Problem Capture phase.
During the Problem Capture phase, snapshots are added to the overall data structure using strings present in the input widget slots. Parameter values can be file names or, more usually, scalar values or a short comment. Component widgets generally hold file names where Lattices, Pyramids, Geometry or other data are stored. It is the responsibility of the application being supported to generate these files. Since HyperScribe plays no part in storing the actual data, any files should continue to exist for as long as a HyperScribe description refers to them. Widget values can be typed in, or wired in from an upstream module, or a combination of both. Note that if they are wired in, then the firing of the upstream module does not result automatically in the addition of a snapshot: although the parameter value might change, a snapshot is ONLY added when an appropriate Pick is received.
Input widgets are also used to display information about snapshots. Since the output side of an (input) widget is not usually wired to other modules, this allows browsing of the recorded information without sending it to the remainder of the map.
Port: OutPar<1-5>, OutComp<1-5>
The Output counterparts of the input widgets are set up automatically during the Problem Description phase. They are used solely to retrieve information and convey it to the remainder of the map, on receipt of an appropriate Pick. (See above). It is inadvisable (but possible) to type in to the OutPar and OutComp widgets.
This port delivers the drawing area for adding snapshots to the tree. Use the transform sliders and scale facility in the Render module to move the Canvas or make it bigger as necessary. The Canvas can also be made translucent in Render to facilitate drawing 3D trees.
This port delivers the spheres and cylinders needed to represent the data structure. It should be wired to the Render module to realise the drawing. Once the construction of the tree has begun, it should not be translated or scaled in Render. Instead, the Canvas can be moved or scaled to extend the tree, and a change of camera position used to view from a different angle.
Translating, rotating or scaling the tree during construction causes the snapshots to be added at the wrong place because the transforms are not unravelled by HyperScribe. Move or scale the Canvas instead if wanting to extend the tree, or manipulate the camera to obtain a different view.
Confusion can arise when connecting the parameter and component widgets into the map. This is because all of them, whether In* or Out* type, appear on both the input and output port menus (respectively the left and right hand port pad pop-ups). Mostly (though not exclusively) you connect to the In* type on their input side (left hand pad) and from the Out* type on their output side (right hand pad). Only connect them at all once the Problem Description phase is completed.