Notes for PROTXR1 Proteus XR Profile: 3/23/90

This version of the Profile closely emulates the way Proteus works.
It uses a single edit buffer for Presets (like Proteus).  The main
Module is the Setup module, which handles all Global and Setup 
parameters (using the same file format as our stand-alone Proteus 
editor).  Following that is the Preset Edit Buffer, the Program
Change Map and the Tuning Table.  

BASIC OPERATION:
We recommend that you open an Internal Bank when using this Profile -
this will improve displays, and allow special features to operate.  To
open an Internal Bank, either Get Bank, or open the Bank File named in
the Instrument Setup window (see V1.1 docs).

In the Setup Patch Edit window, you will use Basic Channel slider to 
change the current channel (this is the Channel in the Proteus' main 
window).  The Proteus switches channels and loads the current channel's
Preset into its edit buffer, which is exactly what this Profile will do,
providing that the Internal Bank is open, and the Preset called for is
not a ROM Preset (in which case, the Preset Module will be marked as 
"out-of-sync").  X-oR's Mouse/Receive Channel is also changed so that 
you can audition the current channel.

  *** Note that, as with the Proteus, you must be sure to save
      any edited Presets before changing the basic channel!

Unlike Proteus, however, we DO attempt to protect the edit buffer's
contents until you actually change the basic channel, which is no small
feat given the Proteus MIDI implementaion.  Occassionally, when you
change Volume, Pan, or Preset Select for a channel other than the current
channel, the Profile will need to retransmit the edit buffer (which takes
a second).  This is only done if necessary; if the current Preset is 
edited, or if it didn't come from the Internal Bank.

The Proteus MIDI Mode affects the way channels are used.  In either Poly
or Omni Mode, only the current channel's Preset can be played.  The
enable/disable parameter for each channel has no effect in these modes.
In Multi or Mono mode, each channel is seperately enabled and disabled.
If the current basic channel is disabled, you will see "off" for the
Preset in the Performance window.

When an Internal Bank is present, several things happen automatically.
This is intended to keep X-oR and Proteus in sync as much as possible:

    1) X-oR automatically loads a RAM Preset from the Internal Bank 
    whenever a Setup is transmitted or received, when the basic channel
    is changed, or when the Preset Select for the current basic channel
    is edited.  If there is no Internal Bank, or the Preset called for
    is a ROM preset, a '?' is shown in X-oR's Performance window.

    2) The Setup is automatically edited when a Preset is loaded from
    or stored (with Bank Updt on) to the Internal Bank.  With Bank Updt
    on, the Preset is also sent to the RAM of the Proteus.  This feature
    is essential for anyone using multi-timbral setups or links.

Like any synth with ROM presets, when you select a ROM preset in the 
multi-timbral setup, X-oR doesn't have the ROM data, so it can't load 
the data into the corresponding edit buffer.  If you have a switcher, 
the Profile could be programmed to get the Preset, although from my
experience, this technique can be quite cumbersome.  It's hard for any
computer editor to totally remain in sync, but as long as you have
the Internal Bank open, and don't use ROM presets, you should be O.K.

FILE FORMATS:
The Bank File format supported is nearly identical to that used in
our stand-alone Proteus editor.  We just tack a couple of 16-char. names 
onto the end of the file (for Pgm. Chg. Map and Tune Tbl.).  One other
minor change: the Setup name is now 16 characters, stored in consecutive
bytes, as opposed to 8 stored in every other byte.

The Tuning Table uses the same format as we used in the Proteus Editor.
However, I plan to switch all microtuning files to a similar, but NOT
compatible standard format in the not-to-distant future.  Some sort of
conversion will be possible, but don't build up a Library just yet, OK?
Note that the fine tuning is in cents, unlike the Proteus display.
Obviously, this is not a fancy microtuning editor - it doesn't even do
ratios.  My big question is: How many X-oR users out there really care? 

LINKS & SETUPS
When a Preset patch uses links, we recommend using E-mu's convention of
naming the patch with an asterisk.  Also, when you store the Preset in
a Library, you should include the name of the Bank File, or perhaps the
names of the linked Presets, in the Library comment field.  Links are
done by reference number only, so the Internal Bank file usually must
be restored along with a linked Preset.

Currently, on the Preset edit screen, links don't show ROM preset names.  
Also, the Program change table switches to a slider when a ROM preset 
is called for.  The ROM Presets (256-383) are shown by name only in the 
Setup Module.  Due to the way a Profile is structured (as of V1.1), all 
names would have to be entered in each Module, which would be quite a 
waste of space (though it can easily be done).

The Setup file also uses the same format as our stand-alone editor,
with the previous exception (name size and storage) noted.  Setups 
(like Links) only store pointers to Presets and not the actual Preset 
data.  When you save a Setup in a Library, you should probably include
the name of the Bank File to be used in the comments.

The Proteus only has one Setup, which is always active.  Therefore, 
when you Send Bank (which sends the Setup), the Setup is automatically 
loaded into the Setup edit buffer.  The same is true with Program 
Change Maps and Tuning Tables.  Be sure you store or save anything you've
edited before Sending a Bank!

PROFILE EXTENSIONS: Emile uses links a lot, and he thinks a Profile
that was made specifically to support easy linking would be desirable.  
This could be done two ways: First, a special X-oR Module could deal 
with 4-Preset group patch format.  X-oR would have to take over the 
Proteus RAM, and send presets directly to bank memory at all times. 
Another idea - and I've allocated 64 extra bytes to a single Preset file
for this possibility - is to store names of linked patches with each
Preset stored individually to disk or in the Library.  That way, at the
very least, you'd be able to see what's SUPPOSED to be linked to the 
Preset.  It may even be possible to do some automatic adjustment when
the Preset is sent, to make sure the links are set up as originally 
intended.  I've also allocated 256 extra bytes to the Setup file for a 
similar possible extension to the Profile.  These are both good ideas, 
which I presently don't have the time to pursue.  Anybody interested?  
I'll be glad to offer technical advice.

PROTOGRIPES:
The Problem with Proteus is that there should be a System Exclusive way
to change Volume, Pan, and Preset Select for channels other than the
current channel, without destroying the edit buffer in the process!  
Another weirdo thing is to store ASCII characters as integers - this 
type of hostility to us MIDI Programmers is definitely not appreciated.
A fast way to send a Preset to the edit buffer, however, would have 
been very much appreciated.  Next time, E-mu, consider consulting with 
Caged Artist about your Sys Ex implementation BEFORE releasing your 
product - you almost got it right, but these few problems would 
have been trivial to correct if they had been caught in time.

We would appreciate hearing about any bugs + we'd like your thoughts 
on the Profile architecture and screen layouts.

Reply via E-Mail to Bob Melvin (in the Dr. T's menu)

Bob Melvin.