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.
Any other opinions on this?
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?
I’m downloading the pieces and following the notes and will see how far I can get without help!
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.
RT Audio: GitHub - thestk/rtaudio: A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.
PortAudio: PortAudio: Building PortAudio for Windows using Microsoft Visual Studio (as usual it’s a bit complicated to build libraries for windows…)
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.
I would be interested in your take on the code too, we work on it so much that we don’t often get a fresh take on it.
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!
Found a way to do it with 9 Zip from the Microsoft Store.
On to next step!
Finished the RT Audio clone. Next step is downloading and building the .dll for PortAudio which I will take up tomorrow.
It’s a command-line program, you just run it like this:
gzip -d file.gz (for example)
My directions are very inspired from what I do under linux, so you may have found a more conventional way with 9 Zip.
Ha! I’ve been in Windows too long. Didn’t occur to me that it was command line! Will know next time.
9 Zip is gui.
Depending on where you have installed portaudio/rtaudio, You “may” need to adjust the wfview.pro file to find the files in the correct locations.
I have assumed that all additional libraries are installed “alongside” the wfview source directory:
The sources for everything are:
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.
73 Phil M0VSE
the rigs bandstacking already preserves a few things. We might fill in the details of the rig’s information and extend it.
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.
Thanks Phil and Roeland. I hope to make some progress today and at least get to the successful build state.
that would be cool!
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 …
PortAudio is a challenge. Which API do I build to and do I build 32 or 64 bits or both?
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.
Incidentally, I would recommend installing the latest v5 Qt (v6.x requires modification to qcustomplot and various other changes to wfview) Also I find the Visual Studio add-in for Qt5 very useful https://download.qt.io/official_releases/vsaddin/2.5.2/qt-vsaddin-msvc2019-2.5.2-rev.01.vsix
73 Phil M0VSE