Kurzweil K2500RS, Руководство музыканта

Страница: 214 / 530

Disk Mode
Saving Files
13-28
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 900's bank has been searched
(typically 999), the search will wrap around to ID 1 up until the end of previous bank to 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 "400's" bank, and the
Þle includes a Name Table that lists the layer's keymap by name, then the K2vx 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 Þnd a match, the dependent
will be unresolved, and in this example the program would have an "
object id Not found"
indication in its Keymap parameter, where the object id is the value that was stored in the Þle.
The search is done in this "circular" manner so as to allow you to direct which dependent
objects get re-linked. 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 Þle into
a speciÞc bank that is the same bank or "before" the bank containing the objects you wish to re-
link to. Note that this can only be taken so far, since it would be impossible for the K2vx to
differentiate between objects with the same name within the
same bank.
The re-linking process happens in the background, without any notiÞcation or error messages if
items cannot be relinked.
Working with Relink-by-Name
Here are a couple of more in-depth examples that can show how Relink-by-Name works in a
practical situation.
Consider that your K2vx's RAM contains the following one-layer program and also its
dependent keymap and samples (the techniques used in this example could well apply no
matter how many programs with any number of layers you want to save):
Program: Program 317 Steinwave Piano
Keymap: Keymap 300 Steinwave Piano
Samples: Sample 300 StwaveG1 .......... Sample 310 StwaveC7
In this case you might wish to save the samples and the keymap in one Þle, and the Program in
another Þle. So, from the Save Object dialog you could Þrst select all the Samples 300-310, and
Keymap 300, for saving into a Þle, let's say
STWAVE1.KRZ .
You would then return to the Save Object dialog and save just Program 317 in a separate Þle in
the same directory, let's say
STWAVE2.KRZ ....only this time, you will be asked the "Save
dependent objects" question pictured above. Answer this by pressing Names .
After saving, the Þle STWAVE2.KRZ will contain two objects in it, Program 317 and a Name
Table. You can easily verify this by going to the Load function (or any other disk function) and