[hpsdr] Developers: Don't Forget Local Client / Multiple Remote Server Architecture

[Scott Traurig]

Roger et al,

This is, unfortunately, the same sad old refrain. There are a lot of great
ideas out there and a lot of good work, but nobody putting it all together
in one amazing package. And I'm part of the problem because I am unwilling
to take the time to become a highly skilled C developer, something that
would probably take years based on the sophistication of the various
openHPSDR programming efforts.

As nasty and aged as the UI is, PowerSDR mRX PS remains the standard by
which all other clients, or servers, will be judged. Every time something
new comes out I try it and, very quickly, run back to PowerSDR. It is the
only place I can get:

- Serial port PTT switch support
- DAW type TX audio processing
- A high degree of customization of the spectral display
- PureSignal linearization
- Squelch
- ASIO support
- Focusmaster support
- True single sideband AM detection
- Programmable RX filter presets
- User selectable filter shapes
- Windows support
- Multiple simultaneous CAT connections
- MIDI controller support

And those are just my favorites. I'm sure others have their own list of
favorites not to be found in linHPSDR or piHPSDR or whatever. For example,
serial port key/paddle support--yup, that's built into PowerSDR (most
people don't even realize it). It remains a technological tour de force.

linHPSDR is compelling in that it is a fresh take on the problem, no doubt
very clean and professional in terms of it's code, and is more object
oriented in terms of receiver support. It is probably more amenable to
being split into client and server components. But until it has all of my
favorite PowerSDR functions it will never be a daily driver for me. Worse,
I've got a substantial investment in a Windows computing ecosystem that I
can't match on Linux. I could happily live with a Linux server. I've got a
couple of machines here that I could press into service/dedicate for that
quite quickly. But not for the client. Of course, for those who live for
Linux and know that Microsoft is the devil incarnate, linHPSDR is the best
thing since sliced bread ;-) And, perhaps also as significant, it is much
simpler than PowerSDR. It does not have 40 setup screens. 40 setup screens
is not for everyone (although it is for me!)

I'd love to see someone take PowerSDR, as ragged as it is, and split that
into client and server pieces. Or make it work with a linHPSDR based
server. Oh, and update the spectral display code to DirectX or openGL ;-)

The reality is, however, that the openHPSDR developer community is
extremely small, no more than a handful of people. Some are just interested
in it "because it's there". They write stuff until they reach the top of
their own private Mount Everest but never build the epic ski chalet on top.
Others are just interested in the super-cool DSP aspects, and only require
enough UI to just barely prove that the DSP works. Others add in cool
little features because they are skilled developers and they have certain
things they want. And none of this is wrong, or bad, or whatever, it's just
the way it is in the open source community. When the community is many tens
or hundreds strong you can get some amazing results. But when the community
is tiny, no so much.

If you read through the many thousands of dreams, wishes and complaints
about the available openHPSDR software over the years, you find one common
theme: there is comparatively little specific developer interest in UI and
ergonomics. Until we get UI/ergonomics oriented developers to take an
interest, such things will continue to take a back seat.

73!

Scott/w-u-2-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20180620/e2a731e9/attachment.html>