Hotkey/Keystroke requests

I’m fairly new to Wfview, but looking forward to using it for some niche contesting and remote needs. Great piece of software!

I’m wondering if the following hotkey/keystrokes have been considered adding these? (Running 1.2d currently):

  • Equals (=) Key - Increase by 1Khz. This is currently mapped to + as well, but on keyboards without a number pad, this requires also pressing shift. - and = would be a bit more seamless when tuning.
  • Space bar - When held, set to transmit until released. When released, return to receive mode.
  • Left/Right arrows - Another way to Increase/Decrease 1KHz or other (possibly more intuitive than +/-)
  • Up/Down arrows - Increase/Decrease AF
  • Q?? - Mute(quiet) or unmute audio/AF

Looking forward to external device support (who can live without a foot pedal?! :).

Thanks for your consideration!

Hi Csharpen,

Those are good ideas. We also had some requests for arrow keys for tuning due to how annoying + and - are to access on most laptops (and then, how does one apply the shift modifier when you have to use shift to even get to those keys…).

As for PTT, of course you have control-T and control-R right now. I was looking around on amazon recently, and there are mini macro keyboards you can get with 5 or 6 keys, programmable at the hardware level to emit the desired key strokes. It would seem trivial to get one (they are around $25) and code a key for TX and one for RX, plus favorite tuning step keys.

But I’ll also say that Phil is working on code to support the ShuttleXpress and Shuttle Pro V2, which are controllers traditionally used for video editing and DAWs and such. But used with wfview, the knob and job support tuning, and the buttons can be assigned to common tasks such as PTT, mode, etc. I think it will be a big hit when we ultimately complete that work. Phil also has code to support the “official” icom USB controller.

Stay tuned here, we will update the keystrokes soon to include many updates people have asked for. Possibly also including a PTT “toggle” key stroke.

List of key requests:

  • Volume (possibly arrow keys)
  • Tuning (not using + and -, possibly arrow keys)
  • PTT Toggle

Anyone got some more ideas? Let’s her them!

Thanks,

–E
de W6EL

My current solution for ctrl-t and ctrl-r using a foot switch:
https://klsin.bpmsg.com/foot-switch-and-cw-keyer-for-wfview/

Hi Klaus!

I was looking for this! I remembered that someone had done this but I could not find it.

Do you want to sell my dad one? He’s trying to build a mobile HF setup.

–E
de W6EL

Hi Elliott,
don’t have really the time … but it’s simple and if you find someone and/or need more info (3D stl file), I’ll provide.
73, Klaus
9V1KG

A commercial product that should do this job is from X-keys:

Using their MacroWorks software it should be possible to set up a footswitch to just send the control key codes to Xfview. I’ve dug one out here in my shack, will experiment and report on success (or lack thereof).

I’ve installed the X-Keys MacroWorks for Windows, programmed it to send a ctrl-T when pressing down on the foot switch and a ctrl-R when lifting off the foot switch. Those keystrokes should only be directed toward Wfview, but I also tried it with the global scope.

It works fine when Wfview is the foreground app. However, I note that when I make another app (such as WSJT-X, doesn’t seem to matter) foreground, the “Transmit” button in the Wfview window is no longer highlighted and the foot switch doesn’t trigger any visible behaviour in either the Wfview window nor on the IC-9700 itself.

Might Wfview inhibit PTT control via ^T/^R when not in the foreground? If so, I’ll have to figure out how to do this via rigctld commands. Time to read the Wfview documentation more closely, too, perhaps “Enable USB Controllers” is another avenue.

Using one of our supported controllers, you can tune the VFO and operate PTT from the background, even if something like full screen YouTube is playing back.

I could always add the Xkeys as a supported controller, but that’ll be my last choice. Would rather operate in the paradigm of MacroWorks.

One can operate PTT via invocation of rigctl with the appropriate arguments, but I don’t want to have to run a process for each down/up of the switch. I could put something together that just runs rigctl once and pipes commands to it, will consider that.

Is there any particular reason that Wfview doesn’t respond to ^T/^R in the background? Any reason for that choice? Perhaps I’ll hack my own version and see if I can easily make it respond in the background with unintended side-effects.

That probably has to do with not being in focus.

You are browsing and typing in a site url and ends up all over sudden in notepad would also be weird.

wfview can’t respond to keystrokes in the background. Just like most other programs can’t. This is due to how desktops manage keyboard focus. Can you type in Notepad while it is in the background? Of course not. It should not be surprising that programs can’t intercept keystrokes when they are not in the foreground. I’m sure there are exceptions to this, such as key loggers and viruses. Maybe some programs can insert a kernel driver to do it or can register with the desktop such as some bottom-feeder apps do on windows.

Again, we have supported controllers which work just fine in the background. The supported controllers work much better than macro key hacks anyway, as you can assign the keys in wfview to do things that we don’t have keystrokes for yet. Plus the tuning dial on, for example, the Shuttle Xpress, offers a much richer experience for remote users.

I personally wouldn’t spend any more time on hacking together keyboard controllers. Just use one of the ones we have already coded up into wfview. You can get a Shuttle Xpress for $60 USD. Totally worth it.

Of course you wouldn’t want your physical keyboard’s keystrokes to broadcast to all background applications. Although I may be quite mistaken, I understood that at least in Windows it’s possible to send keystrokes to a particular application whether or not it is in focus; perhaps I’ve misunderstood Xkey’s MacroWorks application targeting and will check the documentation more thoroughly. In any case, this is a very OS-specific solution and so a more general solution would be better, so I think I’m going to go the route to send PTT commands to rigctld.

The supported USB controllers don’t appear to allow plugging in a separate physical switch, I’m talking about using a proper foot switch that would plug directly into a rig for PTT not a desktop switch to press with a finger. Of course I could hack one with a jack to jumper across one of the internal switches, but I don’t feel like doing that at the moment. The Xkeys device is intended for just this purpose, and I already have one.

As this will be a separate subsystem that will just send rigctl commands to the rigctld port on Wfview, it’s no longer a Wfview issue and I will shut up about it unless someone requests documentation/source on my solution.