After thinking about this while using my 7300, I’ve come up with what I would like to see when switching bands. Maybe I’m the only one, maybe not, but here is what I would like to see:
Instead of simply having a button per band that relies upon the transceiver’s inherent band-stacking capabilities and trying to capture those settings, I would like to be more comprehensive. For each band, I would like not only the frequency and mode, but any other settings that may be useful for the current conditions. This includes Attenuator, Preamp(s), RF Gain, Noise Blanker, Noise Reduction with adjustments, Filter selection with adjustments, Auto Notch, Manual Notch with adjustments, Squelch, Ref level, maybe even RF power and others.
Rather than having one button per band, I would like a set of buttons that could each define all of the settings for a given frequency. There could be multiple buttons for a single band, if desired - maybe 10 or 12 or more total possibilities. This could be presented in rows - one for each frequency. They would initially be blank, but when selected when blank, the current set of settings would be used to populate the selected row. When a new row is selected, the current settings would be used to update the current row, in case changes were made. This would act like band stacking, but be more comprehensive. I know that many times I have been bouncing between two frequencies on a single band, and have found that, due to local noise or QRM, I have had to use different filtering or noise reduction on one of them.
That sounds good to me! The BSR is quite limiting, and, some radios don’t even have it, or have it but not for every band of interest (missing ham bands: 60M, 4M, some of the really low bands, etc). Being able to define our own common ham bands and keeping settings with each one would be great.
If anyone wants to contribute code for this we would certainly welcome it.
Thanks! Just forget what the radio does for Stacking. Wfview could do Super Stacking!
What is a good programming environment to use to develop this? Right now, I only have Windows 10 with Visual Studio 2019 that I use for work projects. Is it better to have a Linux box?
Is there some place on the wfview site that has developer suggestions?
Ok, ok, I looked harder and found the Developer info on the site. I will do some reading. Is the info there pretty accurate? Is VS2019 a good enough environment?
Sweet! Super Stacking! Yeah a computer can do so much more with memory. It’s really silly, IMO, how many HTs still have only 100 memories, for example. Like, how many kb does it really take to have a few thousand with categories?
If you do the super stack, the user preferences will have to be modified to hold the data. You might want to look at the memory function and how we store an array of similar data. You could maybe make a struct for a band stacking entry, put in it all the parameters that seem worth recalling, and then loop through that when you save preferences. I actually think my 7300 saves some pieces between bands, such as attenuator and preamp. So this is not a foreign idea at all really, we’re just doing it the super-stack way!
Yes, the directions are good on the site. The only thing is, the newest master branch code will require RT Audio and PortAudio, which I have not added to the directions yet.
For RT Audio, you can just clone the source to the folder containing the wfview source code folder, just like we do for some other libraries. For PortAudio, you need to build a DLL.
Ok, thanks, Elliot. No promises, but I’ll give it a go. I’ve been away from c and c++ for a while, but hopefully it is like riding a bike! It will be an adventure! I’ll reach out if I run into walls. Working on setting up the environment now. I also have VS2022 but will start with VS2019 as the instructions suggest, just in case.
Will be happy to provide feedback, Elliot. Right now I’m just trying to make sure I have disk space! qt is large! I unchecked some of the non-VS2019 stuff. We’ll see how it goes!
I have installed gzip from gzip-1.3.12-1-setup and added C:\Program Files (x86)\gnupg\bin to my path, rebooted but gzip.exe will not run. No screen appearance, nothing. Makes it hard to unpack QCustomPlot-source.tar.gz!
Depending on how “bleeding-edge” you want to be, you might find it advisable to checkout the latest release of most of the libraries above?
You will likely want to build both x86 release and debug versions of portaudio and opus as the wfview build will look for the correct ones depending on whether you are making a release or debug build. The rest of the libraries/dependencies are built as part of wfview rather than as .dll files.
Unfortunately, building on win32 is a much more complex process than Linux (which can be achieved with a single script) but once the environment is setup, you should be good to go (until I add another dependency!).
I would recommend creating an account on Gitlab and ‘forking’ wfview to your own account. You can then submit any pull-requests direct to us for evaluation.
the rigs bandstacking already preserves a few things. We might fill in the details of the rig’s information and extend it.
Currently:
BAND
REGISTER NUMBER
OPERATING MODE (MOD/FIL SETTINGS)
DATA MODE/TONE SETTINGS
And then we could add indeed preamp/att/etc. I think they currently are not stacked but “standard” like if you leave CW with VAR AGC, it will end up with that regardless of register stack number.
I don’t have the windows build env myself so if you happen to make some notes and tips that could be added… we can add it to the documentation. Always welcome.
I do linux builds and tbh it’s in my fingers and a small script that builds it anyways as all the prereq are there …
I have only used PA_USE_WASAPI as many of the others require additional libraries (and WASAPI is the current recommended API). Although wfview will build in both 32 and 64bit modes. We have concentrated on 32bit at the moment. We may migrate to 64bit for the releases at some point but there is limited benefit really.
