[wsjt-devel] Reference Spectrum Data

2018-12-21 Thread Robert Rearden
What are the headings for the data fields (columns) in the refspec.dat file 
that is generated by the Reference Spectrum tool?

Robert Rearden
ae...@att.net




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion regarding colors

2018-12-22 Thread Robert Rearden
For MacOS, this is taken care by JT-Bridge. 

Robert Rearden 
AE5UV
_

On Dec 22, 2018, at 8:41 AM, Tom Ramberg via wsjt-devel 
 wrote:

May I suggest using JTAlert which has already taken care of this?

73 de Tom OH6VDA

> 22. des. 2018 kl. 00:17 skrev I Z :
> 
> Suggestion regarding colors.
> I really love what was done in 2.0. Finally a great logger, many thanks!
> I miss one enhancement though. When I see a message from one station to 
> another (without CQ or my call), it is in white. It will be very nice if the 
> second call in this message was highlighted, telling me if I worked this 
> station before or not on this band.
> Example: K1AA ZS1ABC -10. I don’t care about the first station, which I may 
> not ever copy. But since I am receiving ZS1ABC, it would be very nice to know 
> if I worked him before or not. If I did not, I will probably wait till he is 
> done with K1AA and then call him. Otherwise I have to open the adif file and 
> look there manually, which is a hassle.
> Most of the semi-rare stations hardly call CQ.
> 73, W0IZ “IZ”
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] 2.0.0 "feels" slow in Mac OS 10.14

2018-12-16 Thread Robert Rearden
Hi Steve,

I have seen no discernible difference in the "feel" or responsiveness of the 
WSJT-X app between v1.9.1 under MacOS 10.13.16 and v2.0.0 under MacOS 10.14.2. 
However, my station configuration is different from yours and other apps 
installed on my iMac may be different from yours. I use an iMac (Late 2015, 3.2 
GHz Intel Core i5) with a Kenwood TS-480 via a SignaLink USB codec and VOX rig 
control. Associated apps are MacLoggerDX 6.20 and JT-Bridge 3.0.1.

Robert Rearden
ae...@att.net




On Dec 15, 2018, at 1:02 PM, Steve Huston  wrote:

Well I hope that wouldn't be the case, since it's not in the budget to
upgrade this machine any time soon so that would mean dropping the
mode(s) I've got the most enjoyment from in the last few years.

I realized there was another update for 10.14.2 that hadn't been
applied, so I did that and restarted everything.  Now it takes roughly
11 seconds from when the start of the transmit cycle should be until
there's audio output to the SignaLink.  Seems I've moved from "this
feels slow" to unusable now.  Tried resetting the configuration to no
avail, will keep poking around looking for something concrete.


On Sat, Dec 15, 2018 at 12:05 PM John Nelson  wrote:
> 
> Hi Steve,
> 
> I re-booted my MacBook Pro (2018; 2.3 GHz Core i5) from my usual 10.13.6 to 
> 10.14.1 to look more closely at timings with 2.0.0_GA  than I did earlier 
> with a previous test with rc4.
> 
> I use a Kenwood TS-870s with USB audio link via SignaLink and CAT control 
> with a USB-Serial adapter with FTDI chipset.   On Radio page “Rig" is set to 
> “Hamlib NET rigctl"
> 
> In QSO with N8DOD I found that timing was spot-on without the delays you 
> observe.   I wonder if 10.14 is more demanding on CPU speed than 10.12 which 
> the Mac Mini might not be able to provide?
> 
> — John G4KLA___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--

Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
 Princeton University  |ICBM Address: 40.346344   -74.652242
   345 Lewis Library   |"On my ship, the Rocinante, wheeling through
 Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
   (267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Unexpected Behavior - Halt TX

2018-12-01 Thread Robert Rearden
During last night's roundup, I had unexpected behavior of the HALT TX button.  
On two occasions HALT TX failed to stop the Tx sequence even though the HALT TX 
button was clicked during the first 2 or 3 seconds of the Tx/Rx sequence. AUTO 
SEQ was on at the time. Tx continued to the end of the normal Tx portion of the 
sequence and then halted. I operate on an iMac computer (late 2015) using Mac 
OS 10.14.1.

Robert Rearden
ae...@att.net




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] tone markers in JT65

2018-11-28 Thread Robert Rearden
Peter,

I use a Mac computer and have observed this same behavior by rc5 on my 
computer. 
_

On Nov 27, 2018, at 9:35 PM, Peter Sumner  wrote:

Hello Dev team,
 while reading the last batch of posts here, I noticed a reference by another 
that their system appear to jump into JT9 in certain circumstances so while 
pondering what is going on with my RC5 install, I noticed the Red TX marker on 
the waterfall is the size I would expect for JT9 and not the wider one expected 
for JT65 A, B or C. When I do select JT65C I can start to see the RX tone 
marker but all scrunched up together, yet decoding of our local JT65B beacon 
works when I go back to JT65B.

When I select JT9 the RX and TX markers are the expected small complimentry 'u' 
and 'n' shapes, when I switch to JT65 the TX marker is the same narrow one it 
was for JT9.

As best as I can tell the actual decoder seems to be happy but the logic teling 
the Wide graph what to do seems to be confused.

O/S reasonably fresh install of Windows 10 Pro X64, all updates applied

Is it possible for others to please check the behaviour of the JT65 modes 
(VHF/UHF features enabled) ?
Regards,
Peter, vk5pj

> On Wed, Nov 28, 2018 at 10:17 AM Peter Sumner  wrote:
> Hello Dev team,
>   I was asked today about the tone markers in the Wide Graph when using JT65 
> as it would seem in V2.x these have been dropped.  Could not see any mention 
> of this in the release notes but guess it was a development decision, just 
> want to make sure it was not an unexpected outcome?
> 
> A side by side screen capture (1.91 and 2.0 TC5)  is here: 
> http://www.users.on.net/~pedroj/wsjtx/WSJT-JT65.JPG
> 
> Regards,
> Peter vk5pj
> 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - UPDATE

2018-11-17 Thread Robert Rearden
FF

  - Advanced tab / Special Operating Activity: OFF


Any help would be appreciated.



Robert Rearden
ae...@att.net




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Possible Compatibility Issue WSJT-X and Mac OS 10.14.1 (Mojave) - ISSUE RESOLVED

2018-11-17 Thread Robert Rearden
John,

THANK YOU for confirming that your installation of RC4 is compatible with Mac 
OS 10.14.1. I was able to solve the issue based on your success with Mac OS 
10.14.1. 

Knowing you had successful operation in Mac OS 10.14.1, I decided to revisit my 
WSJT-X preferences. When I installed both v1.9.1 and v2.0.0-rc4, the sound card 
input was pre-populated with "USB Audio CODEC" so I did not see a need to 
change this setting at the time I installed the apps. However, your note 
convinced me the problem was probably audio related.

For both v1.9.1 and v2.0.0-rc4, I launched the app, changed the sound card 
input preference from “USB Audio CODEC” to "Built-in microphone", saved the 
preference and quit the application. I then restarted the application, changed 
the sound card input preference back to "USB Audio CODEC" and saved the 
preference. After this action, the issue of "no decode when ENABLE TX was 
enabled" was resolved and normal app behavior was restored for both versions of 
WSJT-X. 

Thank you again for your feedback... it convinced me that I needed to go back 
and look at my WSJT-X preferences rather than suspect Mac OS of being the 
source of the issue.

ISSUE RESOLVED.

73,



Robert Rearden
ae...@att.net




On Nov 17, 2018, at 11:27 AM, John Nelson  wrote:

Robert,

I read your two messages.   For the second message, are you being too 
impatient?Your first TX must have been at 15:31:15 but you didn’t wait for 
a decode and halted transmit - why?   
Were you using Auto Seq or not?

Remember RC4 does not decode 75 bit transmissions.  At the moment there are 
only a few stations active on 20m and 40m with RC4.   So you may see much 
activity on the waterfall display with no decodes.   Perfectly normal at 
present until more stations use RC4.

I normally run 10.13 on my MacBook (SignaLink + TS-870s) but to test your 
problem I re-booted to 10.14.1 with rc4 on 40m and immediately worked a DL2 and 
OE6.   Everything is running normally and correctly.   Decoding continues when 
ENABLE TX is active (but the rig is not transmitting).

I do not believe there is any incompatability problem between RC4 and macOS 
10.14.1.

Perhaps have refresh of the Quick Start guide.

— John G4KLA___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] MacOS Keyboard Shortcuts for V2.0.0GA

2018-12-18 Thread Robert Rearden
The list of keyboard shortcuts in the WSJT-X 2.0 User Guide and imbedded in the 
v2.0.0 app is Windows 
specific. I am attempting to develop a list of MacOS specific keyboard 
shortcuts. Below is the list of
keyboard shortcuts I have identified. I would appreciate feedback on any other 
keyboard shortcuts that 
have been identified.

The shortcuts below were only verified on MacOS 10.14.2 running WSJT-X v2.0.0 
GA.

NOTES:

• Esc = escape key

• cmd = command key

• fn = function key

• opt = option / alt key

• ??? = No keyboard combination for this command is currently identified

• Operation of some WSJT-X shortcuts involving use of the F11 function 
key require turning off
  the default keyboard F11 preference of "Show Desktop" in System 
Preferences --> Keyboard --> 
  Shortcuts.

• Operation of some WSJT-X shortcuts involving use of the F12 function 
key require turning off
  the default keyboard F12 preference of "Show Dashboard" in System 
Preferences --> Keyboard 
  --> Shortcuts.


IDENTIFIED WSJT-X KEYBOARD SHORTCUTS FOR MacOS

Esc   Stop Tx, abort QSO, clear next -call queue
fn+F1 Online User’s Guide
shift+F1  Copyright Notice
cmd+fn+F1 About WSJT-X
fn+F2 Open settings window
fn+F3 Display keyboard shortcuts
fn+F4 Clear DX Call, DX Grid, Tx messages 1-4
cmd+Q Exit program
fn+F5 Display special mouse commands
fn+F6 Open next file in directory
shift+fn+F6   Decode all remaining files in directory
???   Display Message Averaging window
fn+F8 Display Echo Graph
fn+F9 Display Fast Graph
fn+F11Move Rx frequency down 1 Hz 
cmd+fn+F11Move identical Rx and Tx frequencies down 1 Hz
shift+fn+F11  Move Tx down 60 Hz
shift+cmd+fn+F11  Move dial frequency down 2000 Hz
fn+F12Move identical Rx frequency up 1 Hz
cmd+fn+F12Move identical Rx and Tx frequencies up 1 Hz
shift+cmd+fn+F12  Move dial frequency up 2000 Hz
opt+1-6   Set now transmission to this number on Tab 1
cmd+1-6   Set next transmission to this number on Tab 1
???   Decode again at QSO frequency
shift+D   Full decode (both windows)
cmd+E Turn on Tx even/1st
shift+E   Turn off Tx even/1st
???   Erase
cmd+F Edit the free text message bpx
cmd+opt+G Generate standard messages
opt+H Halt Tx
???   Lookup callsign in database, generate standard messages
???   Monitor
???   Enable Tx
cmd+O Open a .wav file
???   Log QSO
???   Stop monitoriong
???   Tune
???   Save the most recently completed .wav file


Thank you.

Robert Rearden
ae...@att.net




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Loss of decodes during Tx/Rx cycle

2019-03-02 Thread Robert Rearden
Joe,


I have what may be a related audio issue on a Macbook Air (early 2015, 4 GB 
memory, 1.6 GHz Inter core i5) using v2.0.0 running Mac OS 10.14.3. Here is a 
brief summary of the audio issue.

Decodes works as expected when in MONITOR with ENABLE TX off. WAV files 
are saved.

When ENABLE TX is on, no decodes occur and the DECODE button does not 
"flash". No WAV files are saved. 

Once ENABLE TX is switched off, normal decodes resume and WAV files are 
saved.

During all the above, the waterfall is present showing incoming audio 
signals from the sound card (SignaLink USB) are presented to the computer.

In addition to the things you tried, I also reset NVRAM and SMC, but saw no 
change in the audio issue.

I have a workaround that will temporarily eliminate the audio issue and restore 
normal operation. This involves deleting the WSJT-X app from the app folder, 
emptying Trash, restarting the computer and reinstalling the WSJT-X app from a 
copy of the wsjtx-2.0.0-Darwin.dmg file stored on the computer. Downloading a 
fresh copy of the wsjtx-2.0.0-Darwin.dmg file from the web does not change the 
behavior for the workaround. WSJT-X log files and the WSJT-X.ini preferences 
file on the computer do not have to be deleted when restoring normal operation. 
 Once normal operation is restored, the app will exhibit normal behavior until 
some triggering event occurs. The triggering events I have discovered so far 
are (1) a change in the USB port the sound card is plugged into or (2) 
installation of a Mac OS software update (e.g. upgrade of Mac OS from 10.14.2 
to 10.4.3).

I have not used the MacBook Air for ham radio during the past week, so I have 
not examined the impact the v2.0.1 release may have on the issue.

I have also run v2.0.0 and v2.0.1 on an iMac (late 2015, 8 GB memory, 3.2 GHz 
Intel Core i5) under the same version of Mac OS as the MacBook Air using the 
same SignaLink USB sound card and do not have the audio issue described above.

The problem is very frustrating and I have yet to identify a fix.  I'm not sure 
any of this this helps, but would be interested if you get any promising 
suggestions.

73

Robert Rearden
ae...@att.net



Date: Sat, 2 Mar 2019 16:49:08 +
From: jbozell 
To: "wsjt-devel@lists.sourceforge.net"

Subject: [wsjt-devel] Loss of decodes during Tx/Rx cycle
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Hi folks,
Apologies for a cross post but I?m trying to tap into as much of the assembled 
expertise as possible. It's pretty perplexing.
If I'm simply monitoring with WSJT-X, the decoding happens like clockwork every 
15 second cycle (IC-7610, MacBook Pro, Mojave 10.14.3, 16 GB RAM, 3.5 GHz Intel 
Core i7). However, I've recently noticed that when I call CQ or answer 
another's CQ, there can be large gaps in the decodes.
The approximate 15 second pattern appears to be: CQ/normal decode/CQ again/no 
decodes/CQ again/no decodes/CQ again-Tx off/no decodes/normal decode/normal 
decode/normal decode/etc. And to be clear, this means nothing new shows up in 
the band activity window for several minutes of a Tx/Rx cycle.
I've tracked this over several minutes (today on 40 and earlier on 20), and 
sometimes as much as 2 minutes elapses before another group of decodes appears. 
It is also fully reproducible.
I'm guessing that there might be those who are trying to call me, but I'm just 
not seeing them and they give up. Maybe this is more common than I think and 
I'm just now noticing it? Is it a CPU issue? I?m suspecting the latter, but 
then again, the software should have completed its Tx work and should jump 
right into decoding. I?m only seeing this during a Tx/Rx cycle of exchanges.
Attempts to fix:
1) I put an additional ferrite bead on the USB cable ? no change. I also have 
moved the cable around, as much as possible ? no change (checking for RFI of 
some kind).
2) I have reduced the USB output to my Mac so that the green signal bar is at 
about 65 dB ? no change.
3) I have synchronized my Mac?s time at the time.is website ? all OK.
4) I have tested the effect of rf gain ? no change.
5) I have reduced power from 20W to 10W ? no change.
6) Toggle between Fast/Deep decode ? no change.
7) I have operated with only WSJT-X running, i. e., no other apps open ? no 
change.
Any ideas would be greatly appreciated! Thanks.

Joe/WB0CDY in CO




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Audio dropouts or missing decodes

2019-02-10 Thread Robert Rearden
Mike,

I have what may be a related audio issue on a Macbook Air (early 2015) using 
v2.0.0 running Mac OS 10.14.2. Here is a brief summary of the audio issue.

Decodes works as expected when in MONITOR with ENABLE TX off. WAV files are 
saved.

When ENABLE TX is on, no decodes occur and the DECODE button does not "flash". 
No WAV files are saved. 

Once ENABLE TX is switched off, normal decodes resume and WAV files are saved.

During all the above, the waterfall is present showing incoming audio signals 
from the sound card (SignaLink USB) are presented to the computer.

I have reset NVRAM and SMC, but saw no change in the audio issue.

I can temporarily eliminate the audio issue and restore normal operation by 
deleting the WSJT-X app, restarting the computer and reinstalling the WSJT-X 
app from a copy of the wsjtx-2.0.0-Darwin.dmg file stored on the computer. 
Using a fresh copy of the wsjtx-2.0.0-Darwin.dmg file from the web does not 
change the behavior. WSJT-X log files and the WSJT-X.ini preferences file on 
the computer do not have to be deleted when restoring normal operation.  Once 
normal operation is restored, the app will operate as it normally should until 
one of the following events occurs: (1) a change in the USB port the sound card 
is plugged into or (2) installation of a Mac OS software update.

I believe the problem is related to the USB port connection to the Macbook Air 
computer. I also run v2.0.0 on an iMac (late 2015) under the same version of 
Mac OS using the same SignaLink USB sound card and do not have the audio issue 
described above on the iMac computer.

I'm not sure this helps. If anyone has suggestions for further troubleshooting 
this issue, I would appreciate input.

Robert Rearden
ae...@att.net




On Feb 6, 2019, at 7:17 AM, Black Michael via wsjt-devel 
 wrote:

If any of you are seeing one of these symptoms.

#1 No decodes when signals are present on the waterfall...decode button will 
just "flash".  This indicates no WAV file was saved.
#2 During decode having to click Enable Tx or such to get decodes to start 
working.
#3 Any audio glitches or other behavior that indicates audio problems.

Please contact me for some testing...been doing a lot of audio testing and 
finding different solutions...no one solution seems to be in hand yet.

But...I've got a test version of WSJT-X that should tell you when you have 
audio problems.  First step is recognizing you have a problem :-)

de Mike W9MDB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] v2.1.0 and MacOS Catalina

2019-10-20 Thread Robert Rearden
Hi Bill,

Thank you for the information regarding use of v2.0.1 WSJT-X with MacOS
Catalina until until a MacOS build using Qt v5.13.1 is released.  I have used
v2.0.1 WSJT-X with MacLoggerDX 6.24 and TQSL 2.4.7 for the past week 
with no issues.

73,


Robert Rearden
ae...@att.net



On Oct 14, 2019, at 10:05 PM, wsjt-devel-requ...@lists.sourceforge.net wrote:


Message: 1
Date: Tue, 15 Oct 2019 00:35:58 +0100
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] v2.1.0 and MacOS Catalina
Message-ID: 
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 14/10/2019 21:44, Robert Rearden wrote:
> Is the current MacOS build of WSJT-X v2.1.0 64-bit that is compatible 
> with MacOS Catalina (v10.15)? When I run a system report on my Mac 
> with OS 10.14.6 installed, the report shows WSJT-X v2.1.0 is a 64-bit 
> (Intel) app. But the discussions I have seen indicate there is a build 
> tool issue related to support of MacOS versions 10.10 and 10.11 which 
> makes the v2.1.0 build crash on boot with MacOS Catalina. Is the info 
> I have incorrect?
> 
> If the?current MacOS build of WSJT-X v2.1.0 is not MacOS Catalina 
> compatible, is there a plan to release a build that is compatible with 
> MacOS Catalina and is there a schedule for its release?
> 
> Thank you? 73
> 
> Robert Rearden

Hi Robert,

the macOS build of WSJT-X v2.1.0 has some problems with the toolchain 
used to build it, it causes some crashes in some modes, usually but not 
always at startup. These issues will be fixed for the next release, note 
that the issues are not specific to Catalina.

There is another issue that causes a crash when loading the LoTW User 
CSV file, this is a known Qt issue that effects all platforms but only 
seems to manifest itself on Catalina. That may be an oversimplification 
as it is a thread safety issue and they can be hard to reproduce 
reliably. The issue is fixed it Qt v5.13.1, we have not yet used Qt 
v5.13.1 to build WSJT-X releases because doing so will will produce an 
application that will not run on macOS versions older then 10.12. As 
there are Mac users that cannot easily upgrade past 10.11, due to 
hardware restrictions, we are reluctant to upgrade the Qt version we use 
at this point. Fortunately the issue can be avoided by not using the 
LoTW Users CSV file, the only downside is that highlighting of probable 
LoTW Users will not be available.

The current recommendation for macOS users is that if the latest v2.1.0 
WSJT-X crashes then they should use the v2.0.1 WSJT-X which is available 
from here: https://sourceforge.net/projects/wsjt/files/wsjtx-2.0.1/ .

There are no Catalina specific problems that I know of other than some 
reports that the shared memory size must be enlarged as per the 
ReadMe.txt instructions on the WSJT-X installer DMG after an upgrade to 
Catalina. This will be apparent from the shared memory error on startup.

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] v2.1.0 and MacOS Catalina

2019-10-14 Thread Robert Rearden
Is the current MacOS build of WSJT-X v2.1.0 64-bit that is compatible with 
MacOS Catalina (v10.15)? When I run a system report on my Mac with OS 10.14.6 
installed, the report shows WSJT-X v2.1.0 is a 64-bit (Intel) app. But the 
discussions I have seen indicate there is a build tool issue related to support 
of MacOS versions 10.10 and 10.11 which makes the v2.1.0 build crash on boot 
with MacOS Catalina. Is the info I have incorrect?

If the current MacOS build of WSJT-X v2.1.0 is not MacOS Catalina compatible, 
is there a plan to release a build that is compatible with MacOS Catalina and 
is there a schedule for its release?

Thank you… 73

Robert Rearden
ae...@att.net




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Power Slider problem with macOS Big Sur

2020-11-14 Thread Robert Rearden
I just upgraded to Big Sur from Catalina. The mouse action described in Greg 
Vatt's email regarding the power slider anomaly also occurs in WSJT-X v2.2.2 
after upgrade to Big Sur.

Robert Rearden
ae...@att.net




On Nov 12, 2020, at 10:45 PM, wsjt-devel-requ...@lists.sourceforge.net wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

  1. Power Slider problem with macOS Big Sur (Greg Vatt)


--

Message: 1
Date: Thu, 12 Nov 2020 21:45:07 -0700
From: Greg Vatt 
To: WSJT Developers 
Subject: [wsjt-devel] Power Slider problem with macOS Big Sur
Message-ID: 
Content-Type: text/plain; charset="utf-8"


I upgraded to macOS Big Sur today on its official release. Everything was 
checking out fine with WSJT-X v2.3.0-rc1 8f99fc and I was about ready to 
attempt to make an on-the-air contact. I went to check the power level by 
sliding the PWR Slider and that?s when I noticed the slider thumb action is now 
inverted. 


Here is the slider prior to any mouse-down action.




When first placing the mouse-down action over the slider thumb and then 
moving the mouse up, the slider thumb actually goes down in the opposite 
direction and the level increases to 0 db (it is now at maximum level output to 
the radio). (Not captured in the screen grab is that the mouse location now is 
actually at the very top of the slider control but the slider-thumb is at the 
very bottom as shown.).

 SUMMARY:  The output audio level tracks the mouse-down location movement but 
the control thumb location displayed is inverted.







The reverse also happens when the mouse-down movement is toward the bottom of 
the slider but the slider-thumb moves in the opposite direction to the top of 
the slider. This creates the HMI problem with the level of the output audio now 
corresponding to its minimum when the slider-thumb is at its maximum level, and 
vise-versa.






Another issue is that when the mouse button is released the slider thumb 
disappears all together from the control as shown below. (It does reappear 
eventually after clicking one or more times somewhere else on the window.)






No other findings:

The sliders in the waterfall window appear to move as expected and I haven?t 
been able to find any other instance (in other programs) where the slider 
behaves abnormally (still checking). This one slider in WSJT-X which controls 
the PWR level appears to be the only instance of this behavior.  I also 
reverted back to WSJT-X V.2.2.2 and it also exhibits the same control issue.



Greg  -  NC7B



PS: Bill, if you get this twice I apologize but I guess on my first attempt to 
post this I used my other email account and it got intercepted for the 
moderator to review before it would go through.
-- next part --
An HTML attachment was scrubbed...
-- next part --
A non-text attachment was scrubbed...
Name: step1.jpg
Type: image/jpeg
Size: 75812 bytes
Desc: not available
-- next part --
A non-text attachment was scrubbed...
Name: step2.jpg
Type: image/jpeg
Size: 83184 bytes
Desc: not available
-- next part --
A non-text attachment was scrubbed...
Name: step3.jpg
Type: image/jpeg
Size: 85673 bytes
Desc: not available
-- next part --
A non-text attachment was scrubbed...
Name: step4.jpg
Type: image/jpeg
Size: 79271 bytes
Desc: not available

--



--

Subject: Digest Footer

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--

End of wsjt-devel Digest, Vol 81, Issue 18
**

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel