"Learning" a LUSP System

In order for a controlling system to actually control or interface with at LUSP compatable system, it needs to find out some information about it. The first step in the "learning" process is to find out the manufacturer id, the product id and the device id of the LUSP system. The manufacturer id and the product id can be aquired using the Non-Real Time System Exclusive General Information "Device Inquiry" (see page 15). The "device id" can be obtained from the system's user interface or using "all devices" (127). Armed with this information, we are ready to dig into the details of the box.

Building a "Data Type Description" Database

In order for a controlling system to build a control tree and edit data in a LUSP system, it needs to obtain information about "Data Types". The external control system requests the "System Configuration Message" to tell it how many "types" the LUSP system supports, then requests a description of each "Data Type". As each "Data Type" description comes in, the control system builds a database with them. Refer to the Data Type Description (04 hex) on page 29 for additional information about the elements of this database.

Building the Control Tree

Now that the controlling system knows about all the "Data Types" the LUSP system supports, it needs to know where in the control tree they appear (again, the "Data Transfer Message" uses the control address to access data).

Initially, the controlling system doesn't know anything about the control tree of the LUSP system. The only assumption it can make is that there is at least one "Data Type" which lives at the top of the tree. This is a special "Data Type" that contains the name of the product in it's description (in the database we just built) and the number of primary (level 'A') branches the tree contains. The product name appears in the "name" field of the description and the number of branches is the "max_value" field of the data type's description (plus 1).

The next problem is, "How do we find out which "Data Type" is at the top of the tree or for that matter anywhere else in the tree. This is where the "Data Type Message" is used. When you want to find out what "Data Type" is at a particular control address, you "request" the "Data Type Message" using the control address as arguments to the "request". The request for a typical control address looks like this: (note that the "Num Control Levels" and the actual control address (eg - "Level A value") fields are 16 bit values in a nibblized form with the least significant nibble coming first)

request

Num Control Level A Level B

----header---- class levels value value

F0 06 09 00 06 03 00 02 00 00 00 00 00 00 00 01 00 00 00 F7 

"06" is the message class for the request (un-nibblized), "03" is the message class you are requesting ("Data Type Message"), "2" is the number of control levels in the control address, "0" is the value of level 'A' of the control address and "1" is the value of level 'B' of the control address (or A:0, B:1). This would be "Chorus" in the following tree fragment:
 

Control levels ->
 
top A B C D E
0 - Program
0 - Program 0 - pitch
0 - Program 0 - pitch 0 - Detune
0 - Program 0 - pitch 0 - Detune 0 - Mix
A B C D E F G H I
| | | | | | | | |
MPX 1

0 - Program

0 - Pitch

0 - Detune (M)

0 - Mix

0-100%

1 - Level

2 - Tune

...

1 - Chorus

0 - Chorus Algorithm

0 - Mix

1 - Level

2 - EQ

...

1 - System

0 - Audio Config

1 - Setup

...

"But how do you represent the control address for the top of the tree?". The top of the control tree is a sort of "null" control address. It doesn't contain any control levels so it would be requested as follows:

request

Num Control

----header---- class levels
F0 06 09 00 06 03 00 00 00 00 00 F7 

The message indicates 0 control levels but the LUSP system responds with the "Data Type" at the top of the tree. The "Data Types" are represented as numbers in the "Data Type Message" which comes back from the LUSP system. This number is then used as an index into the database of "Data Type" descriptions created earlier. In the case of the MPX 1, this is "Data Type" number 0x0155, the "MPX 1" data type. Building the control tree always starts by requesting the "Data Type" at the top of the tree.

Now that you have access to the description of the "Data Type" at the top of the control tree, you use the description contents to build the tree below it. Each of the descriptions contains a "min" value and a "max" value. For "Data Type"s such as "Mix" that can be edited, these are the maximum mix value (100) and the minimum mix value (0) that the "Data Type" can be set for. When the "Data Type" is not editable, the min and max represent the tree branches below it. A "Data Type" is considered "editable" if the "Control Level" flag in the description "Control Flags" field is NOT set (see Data Type Description (04 hex) on page 29). For these "Data Types" the min value is always 0 and the max value is always the number of branches below it, minus 1. The min and max values are telling you the minimum and maximum branch (level value) that you can access below it. In the case of the top level "Data Type", the max value is the largest level 'A' control address value that is allowed.

Now that the controlling system knows how many level 'A' "Data Type"s are allowed, it can work with those branches. In the MPX 1, it the max value under to top level "Data Type" is 1. This means that level "A" can be 0 or 1. The controller would then request the "Data Type" at control address A:0 (A = 0) as follows:

request 

Num Control 

----header---- class levels level A

F0 06 09 00 06 03 00 01 00 00 00 00 00 00 00 F7

The LUSP system would send back the "Data Type" at that control address. In the MPX 1, this is the "Data Type" number 0x0153, the "Program" "Data Type". In the MPX 1, this "Data Type" has a max value of 19. This means that control addresses A:0 B:0 through A:0 B:19 are legal so you can request Data Types" for these addresses. In the next request you would go one level deeper:

request 

Num Control 

----header---- class levels level A level B

F0 06 09 00 06 03 00 02 00 00 00 00 00 00 00 00 00 00 00 F7

The LUSP system would send back the "Data Type" at that control address. In the MPX 1, this is the "Data Type" number 0x014D, the "Pitch" "Data Type". In the MPX 1, this "Data Type" has a max value of 10. This means that control addresses A:0 B:0 C:0 through A:0 B:0 C:10 are legal so you can request "Data Types" for these addresses.

This continues deeper and deeper into the control levels (letters) until you reach an actual editable "Data Type" (the leave at the end of the branch so to speak). At this point you have reached the end of the branch so you go to the next value of the that level. In the MPX 1, the entire first branch looks as follows:

Control level 

A B C D E F G H I

| | | | | | | | |

MPX 1

0 - Program

0 - Pitch

0 - no effect

0 - Mix
 
 

When you hit the "Mix" "Data Type", you are at the end of the branch so you would go to the next address under "no effect" which is "Level".

Control level 

A B C D E F G H I

| | | | | | | | |

MPX 1

0 - Program

0 - Pitch

0 - no effect

0 - Mix

1 - Level

The "no effect" "Data Type" has a maximum value of 1 so you would back up to the next value of "Pitch" which is "Detune (M)" (A:0, B:0, C:1).

Control level 

A B C D E F G H I 

| | | | | | | | |

MPX 1

0 - Program

0 - Pitch

0 - no effect

1 - Detune (M) 

Looking at it's description you would find that it has a maximum value of 3 meaning that control addresses A:0 B:0 C:1 D:0 through A:0 B:0 C:1 D:2 were legal.

This procedure continues until you hit the bottom of the tree.

"But how do I know when I am at the end of a branch?". In each "Data Type"'s description, there is a field called "control flags". This is a bit mapped (each bit represents a different thing) value that, among other things, tells you if a "Data Type" is a "branch" or an editable "Data Type". If the "Branch" bit is set, there are more "Data Type"s beneath it(*-see note below). If the bit is 0, the "Data Type" is editable and there are no "Data Type"s beneath it.

* - Note that, after the initial release of the MPX 1 (V1.00), an error was found in the control tree where a branch ended with a control level ("type" 0x015B at control address A:1 B:2 C:0). The suggested "work around" for this bug is compare the "Data Type" of two adjacent levels (A:B, B:C, C:D). It was found that the MPX 1 again returned the "type" 0x015B when queried for the "Data Type" at control address A:1 B:2 C:0 D:0.

Note that all of the numbers in these requests except the message class must be 16 bit values so they must each be sent as 4 nibblized bytes.

Using the information

While it is nice to know this much about a system you are trying to control, what is perhaps more important is how to use it. In many ways, the implementation of the LUSP will differ depending on the system in which it is implemented. A personal computer, for instance, can present more information at one time to the user than a hand held remote control. The personal computer also has a much larger memory capacity (for holding onto databases, etc..) than the remote. On the other hand, a program running on a personal computer may not want to tie up lots of it's memory with information about the connected equipment or provide more than a simple interface to the box. All of these issues effect how a particular program will use LUSP to control a system.

Please note that these are hypothetical implementations only.