Notes; Keyswitching & Other Non-Proteus X Features - E-Mu ProteusX Operation Manual

10 - Appendix
The Proteus X File Converter

Notes...

Keyswitching & Other Non-Proteus X Features
GigaStudio, EXS-24, and HALion have some particular features that the Proteus X
Converter attempts to recreate in some innovative ways. Below is a list of the major
ones.
Key Switching: This is a newly-found feature where the user hits a non-sounding key on
the music keyboard, and that tells the sampler to change sample references to point to
(usually) a different set of samples. The Proteus X does not support this, so the Proteus
X Converter splits each keyswitching section into separate Presets, followed by the
phrase "KSW x" (where x is the split number).
Controller Switching: This is just like the above, only the references are changed upon
receipt of a controller message. For example, the mod wheel can be set up to reference
one sample in the down position, when it hits value 40 the sample reference changes to
another sample, etc. The Proteus X Converter translates this by including all the samples
and changing the amplitude where the sample comes in per the controller. This is not
exactly what is done with the source file. The Proteus X is forced to use up polyphony
whereas Giga/EXS/Halion actually turns the samples on and off, saving polyphony.
Release Triggering: This is when a sample is programmed to play when the engine
receives a note-off message, rather than the normal note-on. This is not possible with
the Proteus X, and such references are ignored.
Locating Referenced Samples
In any multisample format, such as the Proteus X's, there are two elements: the Program
and the Sample.
The Program is defined as the information that determines what sample will be played
when a certain MIDI note is triggering the engine. Programs are called many things on
different platforms - on the Emu they are Presets, on the Ensoniq they are called Instru-
ments, and so on.
The Sample is...well, the sample data and maybe a couple of immediate parameters,
such as the loop points and the sample rate.
Some formats store all this information in one file; this is called the Monolithic
Method. A good example of this is a GigaStudio .gig file. A .gig file can be huge if it
contains long samples or a large quantity of samples.
Other formats store the Program information in a small file, sometimes called the
control file. In that file, there are file references that instruct the sampler engine to load a
sample from another file. These sample references can be broken by deleting or moving
a sample file, or in certain instances, by moving the control file. This organizational
method is called the Separate File For Samples Method. (Or, it should be called that.)
In this method, the built-in mechanism for finding the sample that is inherent in the
Monolithic Method is gone. The Separate File For Samples Method needs a method to
find where the separate file is in order to load it. Below are the ways this is accomplished
by the supported formats.
Absolute Paths
Formats Who Use this Method: EXS-24, HALion
These control files store a complete absolute path to the sample. An absolute path looks
something like this: c:\Program Files\My Kazoo Samples\hohner.wav.
166 Proteus X Operation Manual