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 specified for loading the parent file. 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
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 "400's" bank, and the
file includes a Name Table that lists the layer's keymap by name, then the K2500 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 have an "object id Not found"
indication in 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 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 file into
a specific 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 K2500 to
differentiate between objects with the same name within the same bank.
The re-linking process happens in the background, without any notification 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 K2500'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 file, and the Program in
another file. So, from the Save Object dialog you could first select all the Samples 300-310, and
Keymap 300, for saving into a file, let's say STWAVE1.KRZ.
You would then return to the Save Object dialog and save just Program 317 in a separate file 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 file 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
To Next Page
Loading...
