13-28
Disk Mode
Saving Files
This can be a quick way to edit the sample without having to edit a program and a
keymap.
Keymaps are reproduced accurately, and are played according to the parameters in Program
199 Default Program. This default program in ROM is set up to have a 0% effects
level (dry). Therefore, auditioning keymaps can be a very convenient way to hear
them isolated from the effects.
Programs play exactly as they would if they were selected from the Program-mode page.
Songs start playing when either the Left or Right cursor button is pressed, and stop
playing when either cursor is pressed while the song is playing. The most recent
song that is auditioned from this page become the current song (as seen on the
Song-mode page).
Setups play exactly as they would if they were selected from the Setup-mode page.
Once auditioned, the above object types remain active on the keyboard until another object is
auditioned, or until Cancel is pressed. If a song is being auditioned, no other objects are
auditioned until the song audition is stopped (by pressing one of the Left or Right cursor
buttons).
Saving Dependent Objects
When you save a file, you may see a prompt as part of the Save dialog that asks you whether
you want to save dependent objects. A dependent object is simply an object that’s associated
with another object. The dependent object can be stored in a different memory bank—for
example, a RAM sample with ID 301 that’s used in a program with ID 402, or in the same bank
as the file being saved. Rather than forcing you to save dependent objects separately and to keep
track of them yourself, the K2661 gives you the option of automatically saving the dependent
objects as part of the file you save. When you load the file again, the dependent objects will be
loaded along with the objects to which they’re attached.
While the K2661 makes it easy for you to keep track of your dependent objects, you need to keep
aware of what happens with dependent objects when saving to disk and reloading. First of all,
make sure you have enough space available (on card or disk) to hold whatever RAM samples
you are saving. Consider this example. Suppose you create 30 new programs, each of which
uses a keymap containing four different RAM samples. If you save these programs to a disk file,
and save dependent objects with them, you’ve created a file containing 30 programs and 120
dependent RAM samples. So far, so good. Suppose you then load that file into the 300s bank.
The K2661 will load the 30 programs into the 300s bank just fine, but it will be able to load (at
most) only the first 100 dependent objects to the 300s bank (each memory bank can hold a
maximum of 100 objects of a given type). The remaining 20 dependent objects will be loaded
into the 400s bank. If there are no objects of the same type in the 400s bank, there’s no problem.
But if there are objects of the same type in the 400s bank, some or all of them will be replaced by
the newly loaded dependent objects.
The easiest way to prevent this is to make sure that you don’t create more than 100 dependent
objects attached to the other objects in a given memory bank. The easiest way to do this is to
avoid creating dependent objects when possible, by saving objects with IDs in the same memory
bank as the objects to which they’re related. For example, if you create a program that uses RAM
samples, and you save the program with ID 201, resaving the RAM samples used by that
program with IDs in the 200s will prevent dependent objects from being created for that
program. If you do this, you’ll minimize the number of dependent objects you create, and you’ll
be unlikely to force dependent objects to be loaded into a higher-numbered memory bank when
you load files.
To Next Page
Loading...
