The Role of LUSP
I should point out that LUSP is intended to provide an interface layer between equipment of all kinds. As such, all references to specific
kinds of equipment have been moved to the "Data Type" area which by definition
is product specific. A typical LUSP compatible product would have a SYSEX/MIDI
document which would provide details about that product's particular implementation.
Audio effects products, for instance, might contain a "Data Type" to specify
number of algorithms but a foot controller wouldn't. The document would
describe unique "Data Type"s with, perhaps, structure "typedefs" supplied
to simplify parsing the "Data Type" contents.
Dumps
All of the MIDI compatible systems that Lexicon makes move
large quantities of data in a single message packets defined as "dumps".
In the MPX 1 there are "Program Dumps", "Patch Dumps", "MIDI Map" dumps,
etc.. All of these specialized dumps present a major inconsistency for
a truly "generic" SYSEX implementation. There's no telling how many types
of "dumps" a particular system may require. LUSP avoids this entirely by
folding "dumps" into the "Data Message". The "Data Message" supports "Data
Type"s up to 65535 (0xFFFF) bytes wide. Special "dumps" simply become a
unique data type that can be mapped into the system's control tree.
Note that this has not been implemented in the MPX 1 yet
due to time constraints. Again, I hope to implement it before the product
ships.
Displays/LEDs
Dumps to and from the system's display and LEDs are another
specialty case that can be cleanly folded into the existing "Data Message".
All that is required is some special handling of the data message to route
the data to a display or LED buffer (most Lexicon systems already deal
with special handling in the form of change mechs). Typically, the MIDI
document for the product would provide details of this and any other specialized
"Data Type"s.
It may make sense to define a particular "Control Address" for the contents of the display and/or front panel LEDs that would be common
across all products but it is NOT a requirement.
Buttons
Again, button messages to and from the system are typically
handled by special SYSEX message but can be folded into the "Data Message".
Typically, the MIDI document for the product would provide details of this
and any other specialized "Data Type"s.
It may make sense to define a particular "Control Address"
for the "buttons" that would be common across all products but it is NOT
a requirement.
Program Selection
And again, program selection, normally a unique SYSEX message,
can be folded into the "Data Message". Typically, the MIDI document for
the product would provide details of this and any other specialized "Data
Type"s.
It may make sense to define a particular "Control Address" for SYSEX program change that would be common across all products but it
is NOT a requirement.
Number of Programs
In the past we have included a field in the System Configuration
Message to indicate the number of programs/user registers/banks in the
product. Because LUSP is defined to be a generic protocol, the term "program"
may mean different things on different products. Some products may have
more than one kind of "program". For this reason, the "number of programs" would show up at a unique System Control Address as a "Data Type".
Typically, the MIDI document for the product would provide details of this
and any other specialized "Data Type"s.
Product Name
The name of the product is contained in the description of
the "Data Type" at the top of the tree. It has been suggested that we may
want to put a redundant version of this string in the System Configuration
Message.
Count of Algorithms/Effects On-line
Being product specific, things like "count of algorithms"
and "number of effects on-line" would show up at a unique System Control
Address as a "Data Type". Typically, the MIDI document for the product
would provide details of this and any other specialized "Data Type"s.