Here are some comments about the LED lights in the Behringer CMD, PL-1 based on what I’ve learned in the past two weeks or so of playing with the PowerSDR source code to make it work with the PL-1. This info may be of some use or interest, at least in understanding how this thing works.

The PL-1’s controls behave differently from, say, the Hercules (I don’t have one of those so I’m making some assumptions here).

Its LED lights can be manipulated by sending messages back to the PL-1 – usually the same message it sends the computer for a given control, but changing the “value” field in the message. But there are some exceptions.

The little knobs aren’t knobs in the usual sense, they are more like wheels.  By this I mean they don’t have stops – they just keep turning forever. They don’t report a value according to their position in rotation, and they aren’t speed sensitive, so they send a 63 for CCW and 65 for CW rotation. Each knob can also be pressed down like a button. Those actions put out 127 or 0 (down and up), just like the big wheel’s touch/untouch. They each have 15 amber LED segments around their circumference and one red round one at the bottom.  One amber LED can be lit at a time by sending the PL-1 a message with status=B0, ctrlID=00 through 07 depending on which knob you’re selecting, and a value of 00 for no LEDs lit, 01 to light the first (most CCW) LED, 02 for the next, and so forth up to 0F for the fifteenth LED. The round red LED can be lit by sending status=90, ctlID same as the knob, and a value of 00=off, 01=on, or 02=blinking.

The PL-1’s buttons work similarly to buttons on other controllers – one event for press (down), and one for un-press (up). Their lights can be changed as follows:  Send a value of 00 for default color of orange, 01 for alternate color (each button has a single alternate color), and 02 for continuous alternating between the two. The alternate colors are CUE/pinkish-purple, PlayPause/green, and all the others blue. The one exception seems to be the DECK button, which I haven’t completely figured out yet except it seems to change only the status bytes of the messages the other controls send, but not all of them.  As far as I can tell, there is no way to turn a button light off completely (other than unplugging the controller 😉

Finally, the slider is the weirdest one of all.  It sends a stream of different control-IDs that seem to be 00, 10, 20, 30, 40, 50, 60, 70, in no apparent pattern. This has two nasty effects: (1) you can’t simply catch a single control-ID to handle it in code, and (2) it conflicts with the IDs for knob1 (00), button1 (10), and SYNC (20). So if you have one of those other controls mapped to an action, the slider will randomly execute that other control’s function.

The method I use to deal with these problems goes like this: The slider puts out a status value of 0xE0, which seems to be unique – so I catch all messages with E0 and change their controlID number to something unused (I picked 73 or 0x49), before passing it on. That works fine.

The LEDs along the left edge of the single slider was the final one to tackle.  Since I wasn’t able to find any documentation on the codes the PL-1 uses, I had to experiment.  But after trying several combinations along the lines of the methods I used to figure out the small knobs, I failed to find the right combination.

So I wrote a routine to cycle through all combinations of messages to figure out which combination lights the PL-1 slider LEDs.  I discovered that the following message combination works:

• Control ID: 10 (0x0A) – This doesn’t interfere with button #1 which uses the same ID, as long as status is set correctly.
• Value: 0-15 (0x00-0x0F) – 0 turns all off, 1-15 lights LED numbers 1 through 15, starting at the bottom.

de W2PA