LUSP Introduction
This document defines a general purpose "Universal" MIDI system exclusive (SYSEX) protocol which was implemented in the Lexicon MPX 1, MPX G2, MPX R1, MPX100 and other products.

The acronym LUSP is, perhaps, a misnomer. On the face of it, LUSP ("Lexicon Universal SysEx Protocol") is "a single MIDI System Exclusive protocol that can be used for all Lexicon products". While this description is accurate, it only scratches the surface of what LUSP is really all about. Being "Universal" is certainly an important element of LUSP because it implies reuse of code/work and therefor saves the developers money. But LUSP also addresses the difficult and important issue of system discovery as well; "How do I interface with, and control a system that I know almost nothing about?".

LUSP uses a tree based method similar to those used in computer disks and elsewhere to organize the control structure of a system.
LUSP Tree
The nodes on the tree provide either storage of other nodes (folders) or actual parameters and larger data objects (file). Though the "tree" may look different from product to product, the same basic organizational rules always apply:
    1. There is always a single entry point at the top of the "inverted" tree.
    2. Each "object" on the tree can only be connected to a single object above it but many below it.

One of the reasons this approach to organizing things is so popular is the ease with which a computer can find it's way around it. The computer checks the entry point at the top of the tree and finds that there are 2 branches below it. It goes to first branch and finds that there 2 branches below it. If the branches are named and grouped logically, the computer (or the person operating it) can find out quite a lot about the system by just looking around.

To simplify discussions about the our system, we'll take the take the "tree" analogy one step further adding "leaves" to the end of the branches. The leaves represent the actual parameters, functions or objects which constitute the underlying system (Mix, Size, MIDI Channel, etc..) while the branches provide a path to them from the root. Like a real tree, a branch can't spring out of a leave and though a branch can break out into smaller branches, it is connected to rest of the tree at a single point. If you are an insect (albeit, a very hansom and brave insect), you can get to any leaf on the tree by walking along it's branches.
 
Now that we've conceptually organized our system in a hiarchal tree, we need to be able to represent the position of these leaves (parameters, functions, objects, etc..)  on the tree in a format that will be easily understandable by computers. In LUSP we've done this by thinking about the tree in terms of levels. At the top level is the product itself (product root). The next level in the example above contains 2 branches: "Active Program" and "System". The next level down on the "Active Program" branch contains "Reverb" and "Delay". The next level down under "Reverb" contains "Hall" and "Chamber", and so on. In LUSP we assign each of these levels a letter:
"Active Program" and "System" are at level A 
"Reverb" and "Delay" are at level B 
"Hall" and "Chamber" are at level C
In LUSP, we refer to these as control levels.

Then we assign numbers to the objects that live on a particular branch at a particular level.
    "Active Program" = 0 and  "System" = 1 
    "Reverb" = 0              and  "Delay" = 1 
    "Hall" = 0                   and  "Chamber" = 1
The resulting structure looks like this:

Now we can describe the position of a particular parameter/object/etc.. by indicating the control levels that led to it. The Chamber "Mix" parameter for example, could be described as being at location A:0 B:0 C:1 D:1 in the tree. The "Input Type" parameter would be at location A:1 B:1 C:0. These series of numbers are refered to as the path of the parameters. When communicating with the system, the path is used to indicate exactly which parameter you are dealing with. If you think of the product as a disk drive, the path would be the path to a file (parameter). By replacing the numbers in the path with their names, you'll see that the path really is just a path to a parameter: "MPX1/System/IO Config/Input Type" or "A:1 B:1 C:0".
 
As it turns out, pathes are also useful for accessing parameters within the system itself (in the software for the system). This provides a common interface into the system (debug/code once, etc...). 
Another way of thinking about the hiarchy, is of objects which are contained within other objects. Heres another look at the previous hiarchy:

 

Leafs (Objects)

It's important to understand that "leafs" in a LUSP system can represent a wide variety of things. Though we typically associate them with "parameters", it's more useful to think of them as objects with the following general defintion:. entities that represent data and an associated set of actions that act on the data. In addition to "parameters", leafs can be program dumps, or simple state changes (Bypass, etc..).

Message Types

While the path tells us where in the control structure of the system to find parameters and other objects, it doesn't tell us how big they are, what their name is, or what their legal values are. To deal with this problem, LUSP allows parameters and other data objects to be defined as "types". types templates that define a particular type of parameter/object/function on the tree.