Deleting Objects; Dependent Objects; Memory Banks - Kurzweil K2600 Musician's Manual

Editing Conventions

Deleting Objects

Deleting Objects
Within most editors, there are soft buttons for deleting objects. When you want to delete an
object, press the Delete soft button, and the K2600 will ask you if you want to delete the object.
(At this point in the dialog, you can select another object with any of the data entry methods.)
Press OK if you want to delete it, or press Cancel if you donÕt. Although it seems that you can
delete ROM objects, you canÕt actually do it. The K2600 will behave as if itÕs deleting the ROM
object, but it will still be there the next time you select it. (What actually happens is that the
ROM object is copied to RAM as soon as you press Edit, and when you ÒdeleteÓ the ROM object,
youÕre actually deleting the RAM copy. The original ROM object remains in memory.)
RAM objects, on the other hand, are gone when you delete them! If youÕve ÒreplacedÓ a ROM
object by saving a RAM object with the same ID, the ROM object is invisible, but still there.
Deleting the RAM object stored at the same ID will restore the ROM object.
YouÕll often delete objects to gain RAM space, or to organize the memory banks before saving
objects to disk. To delete multiple objects, use the Delete Objects utility available in Master
mode. ItÕs described on page 11-17.

Dependent Objects

A dependent object is an object thatÕs linked in memory with at least one other object. For
example, if you create a setup that uses a program that you also created, that program is a
dependent object of the setup.
When you start to delete an object that has dependent objects, the Delete dialog gives you a
choice: Delete dependent objects? If you press Yes, the K2600 will delete the object and all its
dependent objects when you execute the Delete function. In our example, if you were deleting
the setup you created, and you chose to delete dependent objects, the dependent program
would get deleted as well. If you press No at the Delete dependent objects? prompt, the K2600
deletes only the object, but keeps the dependent objects. In our example, the setup would get
deleted, but the dependent program would remain.
When deleting objects and their dependents, the K2600 deletes only those dependent objects
that arenÕt dependent on other objects that youÕre not deleting. For example, suppose you have
two setups that contain the same program. If you delete one of the setups, and delete dependent
objects with it, the setup gets deleted, but the program thatÕs contained in the other setup
remains in memory.

Memory Banks

To help organize the storage of your edited objects, the K2600Õs memory is divided into ten
banks, each of which stores objects having IDs within a certain range. Objects within the same
range of IDs are stored in the same memory bank, regardless of their types. The banks are in
increments of 100, that is, objects with IDs from 1 through 99 are stored in the Þrst bank, IDs
from 100 to 199 in the second bank, and so on. We refer to them simply as the ÒZeros bank,Ó
Ò100s bank,Ó Ò200s bank,Ó etc. If you save an object as ID 203, for example, itÕs in the 200s bank.
You can store up to 100 objects of each type in each memory bank, The number of objects of a
given type that can be saved in a memory bank depends on its type. For example, you can store
20 Quick Access banks in each memory bank. As you begin to save objects that youÕve edited,
youÕll notice that the IDs suggested by the K2600 sometimes increase in large chunksÑfrom 219
to 300, for example. This is due to the limit to the number of objects of a given type that can be
stored in a single memory bank. This limit can be important in terms of organizing your objects
for storing to disk. Check out the section called Storing Objects in the Memory Banks on page 13-36
for lists of how many objects of each type can Þt into each memory bank.
5-6