The Name Table - Kurzweil K2000 - MUSICIANS GUIDE Musician's Manual

||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
Save|dependent|objects?|||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
|||||||||||||||||||||Names|||Yes||||No||
Choosing Yes will cause any dependent objects to be saved in the Þle together with the selected
objects. Choosing No means that unselected dependents will not be saved. The Names
button creates a new kind of object to be stored in the Þle, called the Name Table.

The Name Table

The 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 K2vx at only one time, when the Þle is loaded in. At that
time, the K2vx 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 is then discarded when the Þle load is
Þnished. This search feature is referred to as Relink-by-Name.
Relink-by-name offers new and very efÞcient ways of working with K2vx objects and disk Þles.
Careful use of this feature can save you many megabytes of disk storage, as well as a lot of time
spent 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 K2vx'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 re-saved.
When loading in 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. As an example, this would
mean that if you were going to be re-linking several samples from one Þle with a program
and a keymap from another Þle, that each sample should have a different name.
Otherwise, the dependent objects (the samples) will not get re-linked properly. This will
create problems such as keymap ranges that don't play as they are supposed to.
2. The dependents to be re-linked must already be loaded. Otherwise they will not be
found and re-linked when the Þle containing the parent objects is loaded in. 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 in 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
Þle names 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.
Disk Mode
Saving Files
13-27