Table of Contents
Advertisement
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
Save|dependent|objects?|||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
|||||||||||||||||||||Names|||Yes||||No||
Choosing Yes will cause any dependent objects to be saved in the file 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 file, 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 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 K2500 at only one time, when the file is loaded in. At that
time, the K2500 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 is then discarded when the file load is
finished. This search feature is referred to as Relink-by-Name.
Relink-by-name offers new and very efficient ways of working with K2500 objects and disk
files. 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
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 K2500'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
file containing the program and a Name Table need be re-saved.
When loading in 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. As an example, this would
mean that if you were going to be re-linking several samples from one file with a program
and a keymap from another file, 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 file containing the parent objects is loaded in. This
constraint on the order of file loading can be made easier to work with by using the Macro
file feature (described later). You can construct a Macro file to automatically load in the
dependents files and the parent files in the correct order, making sure that any files
containing dependents are loaded first. An alternative to loading the files with a Macro
would be to save the dependent and parent files in the same disk directory with similar
file names 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.
Disk Mode
Saving Files
13-27
Advertisement
Table of Contents
