Keybindings definitely needs some revision, also am I the only who finds the best S+P button behavior erratic? Won't be more appropriate a checkbox ?El 28 feb. 2024 21:48, Tom M0LTE via wsjt-devel escribió:This is, effectively, one and the same.To be frank, a ground-up rewrite, with a headless
This is, effectively, one and the same.
To be frank, a ground-up rewrite, with a headless service, a
well-documented network-accessible API, and a UI, perhaps but not
necessarily using the existing one, would be a highly worthy project in its
own right.
Could be a nice opportunity for
That’s what we did for Linux on my project, but it’s kind of a kludge. Better to have WSJT-X be able to handle audio IQ natively.On the Mac I used netcat and the “Blackhole” virtual audio driver. I pointed WSJT-X at the virtual audio device.73,KevinSent from my iPadOn Feb 28, 2024, at 11:15,
In the Linux world you can use PulseAudio to transport soundcard audio from
a remote RPi and radio over the net to a local desktop running WSJT-X. I
do this. It works fine provided that the latency is not too large.
On Wed, Feb 28, 2024 at 11:03 AM Alex, VE3NEA via wsjt-devel <
Splitting the UI and data processing code would mean a major rewrite of the project. It might be much easier to implement some
API, e.g. REST-based, for the functions that are currently performed via the UI. Then WSJT-X would run with its main window
minimized or hidden on the remote system, and
William,
You got the architecture right. The point is not having to render images
and treat UI events, thus having all processing power for mathematical
computation. X Windows System and Wayland are memory and CPU hogs and in
some cases those resources are at a premium...
As I read the code,
Hi All:
A perfect solution would be to uncouple WSJT-X from sound cards and simply
allow it to send and receive audio IQ data over the net. This would allow
WSJT-X to run anywhere, as long as it could send/receive the audio IQ. A
straightforward interface at the radio end of the link would
I guess you can use X forwarding
On Wednesday, February 28 2024, 09:59:11, William Smith via
wsjt-devel wrote:
I get what you were trying to do, and it is not a perfect
solution,
but many people use VNC or some other kind of remote desktop
protocol
to remotely control the computer that is
I get what you were trying to do, and it is not a perfect solution, but many
people use VNC or some other kind of remote desktop protocol to remotely
control the computer that is running WSJT.
Yes, it would be much better to unload the GUI and the output video
requirements from the poor
Depend on what you are trying to seperate -- sounds like the GUI FFT processing
is you concern perhaps the decoding too?
Here's the flow
RigAudio -> PC -> GUI (both fft and collect for decoder -> wav file -> decoder
(e.g. JT9.EXE) -> GUI
And you are talking aboutRigAudio -> PicoITX -> GUIWhere
Hello folks
Sorry if this has already been discussed!
I am Rafael, PU1OWL, and I was thinking if it would be possible to detach
the GUI frontend from the modulation/audio/realtime backend of WSJT-X so we
can make it a remote module
The architecture I envision is having a remote processor (e.g.,
11 matches
Mail list logo
