13-30
Disk Mode
Saving Files
Þles that wonÕt Þt onto a 720K or 1.4M ßoppy disk. Since the K2600 canÕt format ßoppy disks in
the middle of a save operation, you should have spare formatted disks ready to go before you
start saving. See the section called
Split Files
on page 13-25.
While the K2600 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. 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 Þle, and save dependent
objects with them, youÕve created a Þle containing 30 programs and 120 dependent RAM
samples. So far, so good. Suppose you then load that Þle into the 300s bank. The K2600 will load
the 30 programs into the 300s bank just Þne, but it will be able to load (at most) only the Þrst 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 Þles.
Once you have selected objects for saving (either individually as just described or by bank
selection), the K2600 will determine if any of the items chosen to save have any dependent
objects in RAM that were not chosen. For example, if you select a program to be saved and
nothing else (using the Save Object feature), the program may have dependent effects, keymaps,
and samples that are in RAM. Dependent objects that are in ROM (for example, ROM samples
or keymaps) do not get saved to disk.
You will see the following dialog displayed if there are any dependent objects in RAM of any
objects that were selected for saving:
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
Save|dependent|objects?|||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||||
|||||||||||||||||||||
||||||
|
||||||
|
|||||
|||||||||||||||||||||
Names|
|
|Yes||
|
|No||
Choosing
Yes
will cause any dependent objects to be saved in the Þle together with the selected
objects. Choosing
No
means that unselected dependents will not be saved. The
Names
button
creates a new kind of object to be stored in the Þle, called the name table.
Summary of Contents for K2600 BEST OF VAST - REV A
Page 76: ......