4-26
Disk Mode Enhancements in Version 3
Saving Files
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. Until
Version 3, it was necessary in most cases to re-save all sample data after any change to a
program that uses the sample data. It is now possible to 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 resaved.
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 relinking 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 relinked properly. This will create problems
such as keymap ranges that don't play as they are supposed to.
2. The dependents to be relinked must already be loaded. Otherwise they will not be found
and relinked 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.
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.
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 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 400s bank, and the file
includes a name table that lists the layer's keymap by name, then the K2000 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
Not|found as the value for its
Keymap parameter. this value includes the ID of the unfound object.
The search is done in this “circular” manner 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 re-link to.
Note that this can only be taken so far, since it would be impossible for the K2000 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.
To Next Page
Loading...
Need help?
General
