Filter
Top Products
13-30
Basic Disk Mode
Saving Files
later). You can construct a macro file to automatically load 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 filenames 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.
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 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 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 400s bank, and the file
includes a name table that lists the layer’s keymap by name, then the K2661 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 show a value of “Object id not found” for
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 relinked. 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 relink
to. Note that this can only be taken so far, since it would be impossible for the K2661 to
differentiate between objects with the same name within the same bank.
The relinking 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 K2661’s RAM contains the following one-layer program and also its
dependent keymap and samples (the technique used in this example could well apply to any
programs with any number of layers):
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 from 300-310,
and Keymap 300, for saving into a file, let’s say STWAVE1.K26.
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.K26…only this time, you will be asked the “Save
dependent objects” question pictured above. Answer this by pressing Names.