After my ramblings about the code and discovering how to get the PL-1 working, I thought I ought to document some kind of summary. So here it is.
Setting up the various controls work as before in Px (see previous posts – using “Px” saves me typing its long name). By that I mean that the MIDI setup dialog still works and you get a tab labeled properly as “CMD PL-1,” similar to how it works with the Hercules. The mapping procedure is mostly the same with the Behringer.
The main wheel is big and very smooth turning, great as a main-tuning knob. You can set it to be, for example, a VFO – the most obvious mapping and probably the most useful. If you do, the code makes use of the wheel’s speed sensitivity to change tuning rate in three steps – slow, medium, and fast. It transitions through the speeds gradually as you turn faster. If you give it a good spin you’ll fly across the band, and if you turn it slowly you’ll fine-tune the radio using the step size defined elsewhere (mine is set to 10Hz). I’ve eliminated the wheel’s sensitivity to touching its top surface. It may be useful for something but I haven’t thought of anything yet. And besides, it’s always possible to touch the top surface accidentally while tuning, causing something else to happen inadvertently – so I’m guessing it’s probably not going to be useful for anything.
To program the main wheel, go through MIDI setup as usual, spinning it clockwise and counterclockwise. The max/min numbers won’t matter because to get the speed sensitivity, the code reads the all the reported values anyway and does the right thing. If you plan to use it for both VFOs, first program it for VFOA, then keep reading…
There is a new CAT function I’ve added called “Toggle Wheel to VFOA/VFOB.” You can map this to any of the buttons. It is used to toggle the main wheel’s function between controlling VFOA and VFOB. To set up this function properly you need to do it in a certain order:
- Map VFOA to the main wheel as above.
- Map a button of your choice to the “Toggle Wheel to VFOA/VFOB” function.
- Save and exit MIDI Setup.
- Press the button you just mapped in step #2 once (and only once).
- Go back into MIDI setup.
- Map VFOB to the wheel, which behaves now as a different control than it did in step #1.
- Save and exit setup.
- Have fun.
The knobs on the Behringer CMD PL-1 behave like wheels instead of knobs as Px defines them or is expecting knobs to behave, i.e. with limits and values, like a slider. That’s why Px lumps knobs and sliders together. So when you program a PL-1 knob, you have to choose “Wheel” as the control type in the MIDI setup. You can map any knob to anything in the UI that makes sense. That is, it can be used to control anything that has a value that changes continuously.
In addition, I’ve written code that activates the LEDs around each knob as you rotate them, roughly as a percentage of the specific function’s minimum and maximum values. At the time I’m writing now, this feature works for AF gains, AGC gains, and RIT/XIT. I can add others if needed.
For RIT/XIT there are additional behaviors. First, the center (midpoint) LED lights only when the RIT/XIT is exactly zero. Then the counterclockwise and clockwise ones light depending on how much you turn the knob. Despite the wide range of settings in PowerSDR, I chose to limit the LEDs to only indicate a maximum of plus or minus 2kHz. I found that if I took in a wider range, they changed too slowly to have any meaning. Note: you can still keep cranking the knob and go well beyond 2kHz all you like – but the LEDs will hit their maximum and minimum at 2kHz or slightly less.
For most of the mappings of knobs to UI slider controls, the LEDs also work in the reverse direction. For example, if you map a PL-1 knob to the RX1 AF Gain, then slide the on-screen RX1 AF slider in the user interface, the LEDs will change just like you were turning the PL-1 knob.
The second feature of these knobs is that they act as buttons when you push down on them. So you can map them as buttons. But I’ve implemented code that detects when you push them to zero the RIT/XIT. This seems more useful than on/off, which you can map to any other button you like.
The PL-1 buttons have fairly standard behavior – they produce messages going down and going up. You map them just like with any other controller.
They are capable of changing to one other color than their default orange. So, you can add messages to M0YGG’s already existing MIDI setup dialog to make them do what you want. For the PL-1, you just need to send back the message as received, but change the “value” part of the message to a number, depending on what you want the button’s LED to do. For default orange, send 0 (0x00); for the alternate color, send 1 (0x01), and to have it alternate or flash between the two, send 2 (0x02).
The buttons all have only one alternate color: CUE can be pink/purple, Play/Pause can be green, and all the others can be blue. I added a section in the code to change some of them to their alternate color on startup. I think it looks cooler than all orange. I may make this customizable later. For now, you can use the built-in messaging (as above) to change color however you like.
As an example, I have my “SCRATCH” button mapped to toggle between VFOs. In MIDI setup, I entered a message to turn it blue for VFOA and orange for VFOB.
The PL-1’s slider can be mapped in setup as a “knob or slider.” I had to do some interception of its messages because its control ID changes (something none of the other controls do). Now it works fine and the change in control ID is transparent to the user (although you might notice I chose to use “73” – 0x49 – as the code). When you map it to an existing slider in the UI, the LEDs follow the slider’s movement. The one bit of quirkiness comes about because there is, of course, no way to move that slider under program control. Thus, if you change the slider in the UI, the LEDs will change and become out-of-sync with the actual slider, until you move it yourself. When you do, its value will jump instantly to its actual physical setting.
Notice that the knobs don’t have this problem. Since the knobs have no absolute position (they just freely turn), there is no direct correspondence between knob position and value or UI slider position, and so the qurkiness described above for the PL-1 slider’s LEDs isn’t an issue with the knobs.
M0YGG’s original code nicely handles multiple controllers. The changes I made to handle the PL-1 have their effect only for the PL-1. So programming the Hercules, for example, should be unaffected. In fact, you can use both connected at the same time. This hasn’t been thoroughly tested but W1JA, who has one of each, has verified that both work together.