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

[Roger Rehr W3SZ]

QSL on all, Scott!

I agree with your comments.  The realization that no one else was going
to write the software I needed anytime soon was why I did it several
years ago.  I enjoyed writing it and I have enjoyed using it. 

It WOULD be great if something with the depth and breadth of PowerSDR,
and that was (at least at the client end) Windows-based came along.  If
that happened, I would certainly give it a try.  I had considered using
PowerSDR instead of KissKonsole as the basis of my efforts, but KK was
much simpler and therefore more approachable than PSDR, and I thus felt
that my chances of success using KK would be much greater than if I
attempted the project using PowerSDR as the base.  I think I made the
right decision given my lack of experience and skill set at the time I
undertook the project.  Every once in a while I tell myself that I am
going to bite the bullet and repeat the task using PSDR as the base or
by starting from scratch with WDSP (using Warren's excellent "The
WDSP_Guide" documentation to help me along).  But for a variety of
reasons I haven't proceeded, and I likely won't proceed unless the stars
align extremely propitiously.

Thanks for the comments, Scott, and

73,

Roger
W3SZ


On 6/20/2018 5:04 PM, Scott Traurig wrote:
> 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
>