CWKeyerShield Library

[softerhardware]

Hi All,

This is a discussion about the CWKeyerShield Library which is currently used by the TeensyWinkeyEmulator and eventually with the K3NG keyer. I made another round of updates to this library today:

• On/Off MIDI controls now follow the standard of 0-63 is off and 64-127 is on.
• The constructor now has default values for all settings and is independent of any user such as TeensyWinkeyEmulator.
• Key down and PTT messages received from software are now notes, not control changes, to match what is sent.
• The default key down and PTT notes can be changed via NRPN messages.
• The response flag now controls all CC messages sent back to the host, not just half. Currently volume, speed, tone frequency and tone volume are sent back. Software can ignore reponses if not needed or turn them off. They are on by default for backwards compatibility.
• Roger added more NRPN functionality to save state in the same way that hasak does. This will enable better future compatibility.

The code is the best current documentation:

• For the accepted MIDI CC messages, see the midi_control_selection enumeration around line 53 of CWKeyerShield.h, and then the handler CWKeyerShield::midi around line 300 of CWKeyerShield.cpp. See the end of the handler for the accepted MIDI notes.
• For the accepted MIDI NRPN messages, see the midi_nrpn_selection in CWKeyerShield.h and CWKeyerShield::process_nrpn in CWKeyerShield.cpp.
• For the default channel and note assignments, see the constructor defaults around line 127 in CWKeyerShield.h.

There was some discussion that the way this midi handler is done puts it in an interrupt handler context. I don't think that is the case, and the alternate way of doing midi event handling is in the same category as this. See the documentation and the line "The callback functions are only called when you use read." This is when CWKeyerShield process MIDI data and is the same as when hasak will.

There has been some back and forth regarding responses. I'd like all responses to be turned on or off. For some reason this causes problems with piHPSDR and TeensyWinkeyEmulator? Please check, and if there are problems, let us discuss here before changing code.

Note that in this library I am focusing on MIDI and Audio related settings since most keyer functionality can be changed via a WinKey interface. (The keyer-specific support for hang and leadin times was added by Christoph.) I am starting to be satisfied with this library. My next steps are to finish up a few audio related settings such as balance, pan and input level, complete the Python test interface, and work on issue #5

Please add any requests for this library and bug reports for this library to this discussion thread.

73,

Steve
kf7o

[dl1ycf]

Is is really logical to set midi_ptt_note, midi_keydown_note and midi_channel via the constructor argument list? For these "volatile" parameters there should be interfaces, as already the case for midi_channel, where we have

void set_midi_channel(int v) { midi_channel = v; }

In my view it is more logical to restrict the constructor argument list to reflect the hard-wired things. Whatever software uses this class can then, at any time, do a set_midi_channel() call.

[softerhardware]

It is nice to have everything with default values in the constructor as it makes it easier to read and understand. Initial "volatile" values can be set in the constructor. Volatile values may also have accessor functions so that they can be changed later if desired.