MIDI controller numbers

["Christoph v. Wüllen"]

Roger,

do you think this assignment is OK? Look at the comment
at the top, the rest follows automatically

//
// avoid certain "continuous controllers"
//
// No. 0, 32 (Bank select)
// No. 6, 38, 98--101 (Registered and non-Registered Parameters)
// No. 88 (High-resolution velocity prefix)
// No. 96, 97 (Increment/Decrement)
// No. 120-127 (Channel mode messages)
//
//
enum midi_control_selection {
MIDI_SET_A = 1, // Set 7-bit accumulator A
MIDI_SET_B = 2, // Set 7-bit accumulator B
MIDI_SET_C = 3, // Set 7-bit accumulator C

MIDI_MASTER_VOLUME = 4, // set master volume
MIDI_SIDETONE_VOLUME = 5, // set sidetone volume
MIDI_SIDETONE_FREQUENCY = 7, // set sidetone frequency
MIDI_CW_SPEED = 8, // set CW speed
MIDI_ENABLE_POTS = 9, // enable/disable potentiometers
MIDI_KEYER_AUTOPTT = 10, // enable/disable auto-PTT from CW keyer
MIDI_KEYER_LEADIN = 11, // set Keyer lead-in time (if auto-PTT active)
MIDI_KEYER_HANG = 12, // set Keyer hang time (if auto-PTT active)
MIDI_RESPONSE = 13, // enable/disable reporting back to MIDI controller
MIDI_MUTE_CWPTT = 14, // enable/disable muting of RX audio during auto-PTT
MIDI_MICPTT_HWPTT = 15, // enable/disable that MICIN triggers the hardware PTT output
MIDI_CWPTT_HWPTT = 16, // enable/disable that CWPTT triggers the hardware PTT output

MIDI_SET_CHANNEL = 17, // set MIDI channel to/from controller

MIDI_KEYDOWN_NOTE = 18, // MIDI note for key-down
MIDI_PTT_NOTE = 19, // MIDI note for PTT activation

MIDI_WM8960_ENABLE = 20,
MIDI_WM8960_INPUT_LEVEL = 21,
MIDI_WM8960_INPUT_SELECT = 22,
MIDI_WM8960_VOLUME = 23,
MIDI_WM8960_HEADPHONE_VOLUME = 24,
MIDI_WM8960_HEADPHONE_POWER = 25,
MIDI_WM8960_SPEAKER_VOLUME = 26,
MIDI_WM8960_SPEAKER_POWER = 27,
MIDI_WM8960_DISABLE_ADCHPF = 28,
MIDI_WM8960_ENABLE_MICBIAS = 29,
MIDI_WM8960_ENABLE_ALC = 30,
MIDI_WM8960_MIC_POWER = 31,
MIDI_WM8960_LINEIN_POWER = 33,
MIDI_WM8960_RAW_WRITE = 34
};

[Roger Critchlow]

Christoph --

That looks fine to me.

But I would comment the taboo controller numbers inline in the enumeration.  Even allocate them and note that the allocation is non-negotiable so no one will be tempted into grabbing the first free slot for their absolutely essential extension and breaking everything else by accident.

I would also add a short description of units and ranges for each control, whether they use other control values, etc.  This information is essential to using the control or emulating its action and you should not have to search the rest of the source code to figure it out.

-- 73 -- rec -- ad5dz --

[Alan Hopper]

Hi Roger and Christoph,

this all sounds good, I'm just making the config ui in spark driven from a json file for each keyer so it can be changed in the field.  Having this as Roger describes makes it simpler to create the config files, maybe they will be useful to others.

73 Alan M0NNB

[Roger Critchlow]

Christoph --

I see all the bitwise PTT configuration controls, it seems like you could use one control to set a pttMode that will cover all your cases.

I'll look at the sidetone smoother, I got some comments about it, too, and about the master volume range.

I was puzzled by your comment about the master volume resolution, when I looked at the master volume in the driver source, it said it was using a 7 bit value in half dB steps from +6 dB down, but it certainly seems to pack more oomph than that.  Is there another amp being kicked on to extend the high end response?

Wrapping an eight bit serial line in MIDI is fine, but I would specify an endpoint for the connection, too, since other capabilities could use a wrapped serial protocol, too.  So another control to specify the target serial endpoint.  You could actually send 14 bits very efficiently by using one of the MSB/LSB control pairs.  Once the MSB is set to 0, you can send repeated 7 bit characters by sending LSB, and once the MSB is set to 1, you can send repeated 0x80|LSB by sending LSB.

Hmm, I guess you could put the endpoint identifier in the high bits of MSB and you won't need another control to specify the endpoint.  6 bits of endpoint should be enough.

On directly keying, are you ignoring the pttMode setting?  I put the tune switch into the keying arbitrator so it gets the same PTT treatment as any other key signal.  It should also get pre-empted if the operator touches the straight key or paddle, but that's still to be tested.  If you're going to allow remotely switched keyout and pttout, it seems that you should have to set a pttMode that specifies that's what you're doing.  Otherwise you have PTT settings which are true, except when they're ignored, and there's no way to tell by looking at the PTT settings that being ignored is an option.

 

I don't understand  "For this I simply use the NOTE values of the outgoing messages

as CONTROLLER numbers for the incoming ones."  Could you explain that some more?

-- 73 -- rec -- ad5dz --

On Fri, Feb 11, 2022 at 10:58 AM "Christoph v. Wüllen" <DL1...@darc.de> wrote:

I have integrated this in the CWKeyerShield library both on my and Steve's github.

Pse look also at the "side tone volume change smoother", this I have in response
to some "complaints" I received, and to two additional messages that are processed,
so that you can direcly key and ptt from the MIDI controlle (in case you want
a "Tune" button). For this I simply use the NOTE values of the outgoing messages
as CONTROLLER numbers for the incoming ones.

What is your opinion on "wrapping" the WinKey protocol in a certain MIDI
message? I got positive responses and this save us from a lot of future
"feature requests".