Alesis K2661 specifications Working with Relink-by-Name, 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.

13-30