The Name Table - Kurzweil K2600 Musician's Manual

The Name Table

A ÞleÕs name table is a list of any dependent objects that were not explicitly selected for saving
in the Þle. Each entry in the name table contains the object type, object ID, and the name of a
dependent object.
A ÞleÕs name table is used by the K2600 at only one time: when the Þle is loaded. At that time,
the K2600 will search for dependent objects that were not saved in the Þle 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 Þle load is Þnished. This
search feature is referred to as Relink-by-Name.
Relink-by-name can help you work efÞciently with K2600 objects and disk Þles. Careful use of
this feature can save you many megabytes of disk storage. It can also free up time for working
on music and production instead of waiting for sample data to be resaved.
Relink-by-Name allows you to save objects and their dependent objects separately (in multiple
Þles) and be able to link them up later on by loading the Þles in the correct order. This can be a
very efÞcient way of working with the K2600Õs many levels of dependent objects. The most
common way in which Relink-by-Name speeds up development of sounds is when making
small adjustments to a program that has as its dependents a large amount of sample data. You
can separate the program and sample data, so that after changing a program parameter, only a
Þle containing the program and a name table need be resaved.
When loading a Þle 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. For example, if you were going to be
relinking several samples from one Þle with a program and a keymap from another Þle,
each sample should have a different name. Otherwise, the dependent objects (the
samples) will not get relinked properly. This will create problems such as keymap ranges
that donÕt play as they are supposed to.
2. The dependents to be relinked must already be loaded. Otherwise they will not be found and
relinked when the Þle containing the parent objects is loaded. This constraint on the order
of Þle loading can be made easier to work with by using the macro Þle feature (described
later). You can construct a macro Þle to automatically load the dependents Þles and the
parent Þles in the correct order, making sure that any Þles containing dependents are
loaded Þrst. An alternative to loading the Þles with a macro would be to save the
dependent and parent Þles in the same disk directory with similar Þlenames such that
they will appear consecutively in the alphabetized Þle list. Once you have done this, it is
easy to select both Þles for loading in the correct order.
These rules may appear complicated at Þrst, but they will seem natural once you have worked
out a few examples with your own Þles.
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 speciÞed for loading the parent Þle. 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 speciÞed bank. The
search stops once a dependent with a matching name has been found and relinked.
For example, if a Þle containing a one-layer program is loaded into the 400s bank, and the Þle
includes a name table that lists the layerÕs keymap by name, then the K2600 will begin to look
through all possible keymap IDs starting at 400, until ID 999. The search then continues from
Disk Mode
Saving Files
13-31