Mini - Midi - Maxi

I've been busy over the past ten days or so defining the characteristics of different styles of controller and thinking about the software implications. The overriding requirement is that a single executable should be able to work in any physical layout.

This is not as easy as it might seem!

Controller definitions
Tempting though it might be to have a complete free-for-all common sense dictates that we need to define some standardised configurations. After quite a lot of thought I have concluded that these are they:

• Mini controller. One physical VFO, up to four encoders and 16 switches.
• Midi controller. Up to two physical VFOs, up to six encoders and 32 switches.
• Maxi controller. Two physical VFOs, eight encoders and 32 switches.

Each controller type is able to manage up to two slices, so all controllers are effectively dual VFO rigs. The maxi controller is effectively the Mk I controller physical specification and I can't see that there is a need for anything larger. An interesting thought is that there should be no particular reason why one couldn't have more than one controller per radio, with each controller taking its own, unique pair of slices. A sort of grown-up version of little knob/big knob operating!

Software considerations
Until a few days ago all my development work had been on the basis of what we now know as the Maxi controller. Thinking about the Midi and, especially the Mini controllers made me realise that there was a need for a new class of encoder and switch controls.

The Mini controller and, potentially the Midi controller have only one physical VFO. As we wish to control two slices, we need a switch to select which slice the VFO knob is controlling at any one time. I soon realised that this is also true for encoders and switches. For example, I have a switch definition that allows the user to lock VFO-A and another switch to lock VFO-B. In a maxi controller this makes complete sense but less so in the Mini controller, where we may feel that we can ill-afford the space for two physically separate switches.

The answer, of course, is to use the VFO switch to also switch all these other switches to operate on VFO-A or VFO-B, whichever is currently selected. The same logic applies to the encoder functions.

So, using the VFO lock as an example, we actually have three potential functions:

• Lock VFO-A
• Lock VFO-B
• Lock selected VFO

The same applies for encoders. Using filter width control as an example we have the following functions

• Filter width for VFO-A
• Filter width for VFO-B
• Filter width for selected VFO

By having three functions defined for each control type we have total freedom to implement separate controls or common controls for the two logical VFOs as required. 

Which VFO have I selected?
So we now have a switch function that permits the user to map the physical VFO to either VFO-A or VFO-B. It's obviously rather important to know which VFO is selected and I've spent some time thinking about that too.

A single VFO system operating in split mode,
with the VFO controlling VFO-A

In the end, I've decided that the best way to show the current VFO is to highlight the VFO frequency display by underlining it. This immediately grabs the attention. Of course the underline is only needed in a single physical VFO configuration and even then only when both VFO-A and VFO-B are active. It seems to work very well.

Profiles
Finally, and in a related development area, I've now implemented user selectable profiles. This lets the user change the layout of his controller at will. In fact it is the way I tested the mini controller controls - switching between a maxi controller and mini controller configuration simply by loading a different profile.

Of course the profile manager also had to be updated to know about the new class of switched VFO controls. That too seems to be working well.

All in all a lot of progress along the way to a single Host Controller code set that can support any controller configuration.