Ken --
I was wondering if I have SuSe 9.3 Pro if
I will be able to possibly run the Linux
version on a dual booted PC with the Delta-44
card in it?
Sounds like a good system for this.
will you be able to create a Linux version
with statically linked libraries that might
mean execution on more Linux distributions?
Static linking would bloat the executables without helping
distro and dependency problems much at all. There are more
critical dependencies in things like the audio subsystem,
python modules, etc. than in the DSP process. Static linking
of the libs in the DSP executable wouldn't help the other
dependencies at all.
All the talk about the importance of the
Command Line is making me feel that maybe
the Linux version has no point-and-click
console?
Not a single one, no.
From day zero, an absolutely critical principle in the
design has been: decouple everything as much as possible.
The dual principle of this, if you will, is: make it easy to
have many different UIs and configurations as possible.
The DSP code itself is utterly ignorant of what's on the
other side, physically, of the soundcard. There's nothing it
needs to know about the SDR-1000 in particular. All
knowledge of the SDR1K is embodied a layer *above* the DSP.
By the same token, the SDR1K hardware knows nothing about
what's on the other side of the soundcard and parallel port,
softwarewise. Same remark goes about layering.
For that reason, the DSP process and control are completely
independent of the hardware control. If they are confounded
in the Windows version, that's an artifact of the
development history, not a design decision. In fact, as both
the DSP and the PowerSDR console have matured, they have
been increasingly decoupled along the lines of the Linux
version, with an *increase* in efficiency and robustness.
Does anyone have screen dumps of such a beast?
Only experimental ones.
Or is it in the works for the future?
Here's what's happening. I mentioned before about layering
*above* the DSP and hardware. That's what we've been calling
the Virtual Radio. It's realized only by implication in the
Windows PowerSDR, but it exists explicitly as a body of
Python code under Linux. This is the code that implements,
for example, a "VFO" that jointly operates on the DSP and
the SDR1K hardware, without those components otherwise
interacting.
A graphical console in turn is layered on top of that
Virtual Radio. As mentioned, we would prefer to see a
proliferation of consoles, each adapted to a different
purpose. The principle there is to endow each UI with just
as much complication and screen real estate as is required
for the application. For some apps, like integrating the
code with gMFSK, there *is* no console. It's all controlled
by existing gMFSK features.
The Virtual Radio code just went into a new generation last
week, and will be sent out into the world after the Windows
1.4rc is done. After that, it is only a short step to what
we've envisioned all along as the real VR implementation, in
XML.
Was there any thought of using the Beppe console
graphic under Linux?
If somebody wants to do it, sure.
Our hope has been that jDttSP embodies what *everybody*
needs from such software, in a moderately universal way.
It stops there, however. The UI is what each of us
individually wants or needs for our own purposes. I
personally have little use for a "horseless carriage" UI,
but if somebody else wants to whip one up, it shouldn't be
too hard. The PowerSDR console ought to be pretty
straightforward to move over to Linux, too. We're trying to
make such things as easy as possible.
Outside of the DSP and hardware control proper, the guiding
principle is the Bruce "Utah" Phillips rule: whoever
complains about the food, gets to be the next cook.
Perhaps the Python implementation might have a
graphical console?
Above the DSP- and hardware-level C code, it's all Python.
73
Frank
AB2KT
