Kurzweil KSP8 TM - Manual (Page 101)

Storage Mode
Saving Files
Preliminary - Subject to Change 13-11
The Name Table
A file’s name table is a list of any dependent objects that were not explicitly selected for saving
in the file. Each entry in the name table contains the object type, object ID, and the name of a
dependent object.
A file’s name table is used by the PC3 at only one time: when the file is loaded. At that time, the
PC3 will search for dependent objects that were not saved in the file originally. The search
matches dependent objects by name with objects that are already in RAM, and links them to the
“parent” object. The name-table data are then discarded when the file load is finished. This
search feature is referred to as Relink-by-Name.
Relink-by-Name allows you to save objects and their dependent objects separately (in multiple
files) and be able to link them up later on by loading the files in the correct order. This can be a
very efficient way of working with the PC3’s many levels of dependent objects.
When loading a file that contains a name table, the following rules should be observed in order
for correct relinking to occur.
1. Use unique names for dependent objects at every level.
2. The dependents to be relinked must already be loaded. Otherwise they will not be found and
relinked when the file containing the parent objects is loaded. You can save the dependent
and parent files in the same directory with similar filenames such that they will appear
consecutively in the alphabetized file list. Once you have done this, it is easy to select both
files for loading in the correct order.
These rules may appear complicated at first, but they will seem natural once you have worked
out a few examples with your own files.
The search algorithm used for relinking dependent objects to their parent objects during loading
is as follows:
The search for a dependent object (whose name matches that of an entry in the name table) begins at the
beginning of the bank that is specified for loading the parent file. All possible IDs are then
consecutively searched. When the last ID of the 900s bank has been searched (typically 999), the
search will wrap around to ID 1 up until the end of the bank just before the specified bank. The
search stops once a dependent with a matching name has been found and relinked.
For example, if a file containing a one-layer program is loaded into the 400s bank, and the file
includes a name table that lists the layer’s keymap by name, then the PC3 will begin to look
through all possible keymap IDs starting at 400, until ID 999. The search then continues from
ID 1, stopping at ID 399. If the search does not successfully find a match, the dependent will be
unresolved, and in this example the program would show a value of “Object id not found” for
its Keymap parameter, where the object id is the value that was stored in the file.
The search is done in this “circular” manner so as to allow you to direct which dependent
objects get relinked. This may be necessary if you end up with multiple copies of dependent
objects with the same name; you can differentiate between them by loading the parent file into a
specific bank that is the same bank or “before” the bank containing the objects you wish to relink
to. Note that this can only be taken so far, since it would be impossible for the PC3 to
differentiate between objects with the same name within the same bank.
The relinking process happens in the background, without any notification or error messages if
items cannot be relinked.