-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Letter-by-Letter Voice Keying #316
Comments
The voice keyer functionality supports only playing Fn messages configured by VKMn/VKSPM/VKCQM parameters. One option could be to expand the configured value as a message text (as if it'd be sent to the CW keyer in CW mode) before passing it to the script. Example:
Then it'd be up to the script to interpret its input and there would be also no interference with the CW keying setup. Expanding currently used wav file names has normally no effect on them. |
Yes, and I think as long as the voice keyer function feeds the VKM strings as expanded text, Onno's
which would then trigger playing individual letter files such as E.wav, A.wav, etc., followed by EXC.wav, which would be the recording of the outgoing exchange. |
A rough prototype is available in https://github.com/zcsahok/tlf/tree/ssb_keyer_prototype
Here is a matching
|
Onno has now updated Users who don't want to bother with letter-by-letter keying could simply set the keys to send the names of their voice files. Those of us who want letter-by-letter could record the additional files and name them appropriately. |
This has nothing to do with Tlf (or maybe it does) but do you record only the letter names, or their phonetic names, or a combination? I know that when I am working I will switch between both sets depending on the strength and clarity of the other station. Strong and clear and I'm sure I got the call right I go with letter names. If I'm not certain then I switch to phonetics so the other station can offer corrections. I could see having both sets recorded and then using a key combination to grab the other. At the moment I don't see that Ctrl-F[1-12] or Alt-F[1-12] are in use. However, in windowing environments a combination may cause the desktop workspace to switch or close the terminal window (Alt-F4)! OTOH, Alt-0 to Alt-9 are currently extra CW messages and perhaps in phone they could be used for the alternate letter set. |
Hey, folks:
In setting up for ARRL DX SSB this coming weekend, I've been looking into voice keying from TLF. While the current voice keying option seems to work well with my setup, I also saw VK6FLAB's clever ssbdaemon project, which is a workaround allowing letter-by-letter voice keying. This is a major feature in N1MM+ that allows one to work an entire SSB contest without saying a word, a very appealing proposition for me as my wife somehow doesn't appreciate hearing me shouting random callsigns repeatedly from the basement.
Onno's script provides this function via a hack with cwdaemon's debug mode, which seems to work but has some side effects. TLF has to be in CW mode to do this, which means manually resetting the radio back to SSB after every band change. It also means TLF will log these SSB contacts as CW, and that cwdaemon can't switch to CW keying without restarting. Neither problem is a big deal in a single-mode SSB contest, but in a mixed-mode contest it could be very tricky to get both SSB and CW keying working, and to fix the log file to indicate the correct mode for each QSO afterward.
I'm not much of a C coder, but as I understand it, the current voice keyer system calls the play_vk script, passing a filename pulled from the rules configuration file. If it could instead pass the string from the keyer macro function directly, then putting Onno's file-search algorithm into play_vk would allow it to play files named after arbitrary characters. At least, I think something like that would work.
Regardless of the specific mechanism, I think this would be a great feature that a lot of SSB contesters would appreciate.
The text was updated successfully, but these errors were encountered: