Stereo Tool
https://www.forums.stereotool.com/

Stereo Tool 9.84 BETA
https://www.forums.stereotool.com/viewtopic.php?t=31304		 Page 2 of 20
Author:  PaddyC [ Fri Dec 24, 2021 10:17 am ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:

[*] Clipper Multipath Stereo: Now only active for FM, and it now works for anti-phase audio for values > 90 degrees.
Is it really a good thing? I mean, for a station which is using ST at the studio and using just a clipper and stereo generator at the transmitter, don't you think this feature is useful?
Author:  hvz [ Fri Dec 24, 2021 12:09 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
Quote:

[*] Clipper Multipath Stereo: Now only active for FM, and it now works for anti-phase audio for values > 90 degrees.
Is it really a good thing? I mean, for a station which is using ST at the studio and using just a clipper and stereo generator at the transmitter, don't you think this feature is useful?
Good point...
Author:  MrKlorox [ Fri Dec 24, 2021 1:48 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Beta13 VST GUI works in BreakawayOne now. Check the links if they haven't been updated.

edit: nevermind, things were updated as i posted this.
Author:  2Sense [ Fri Dec 24, 2021 2:27 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
The required timeout is currently set to 150 ms, I guess I could reduce that. Can you make a short video that I can use to see/measure how long the pauses are?

Also, is that last block way longer? It looks far too long to send in 1 second at 4800 baud.
Yes, the last block is longer. I wondered about this, so I experimented by setting the GPS to send different sentences.

Sending only GGA, GSA and RMC didn't work at 4800 baud but is fine at 9600 baud [the three sentences are around 190 characters]
$GPGGA
$GPGSA
$GPRMC
<pause>

Interestingly, sending only GGA and GSA works fine at 4800 baud - the NMEA data flag becomes active and GPS lock is reported. [The two sentences are around 121 characters]
$GPGGA
$GPGSA
<pause>

It seems then that this issue may indeed relate to the number of characters sent / available time during pauses?

As standard this GPS seems to send at 4800baud using the NMEA sentences I described in my previous post. The longest block (9 lines) seems to be around 569 characters which may be an issue?
Its seems that 4800 baud is not uncommon for these types of devices, so it would be nice if it worked straight out of the box.
Does ST need NMEA every second with the requisite pause as a marker? I.e. would an the long blocks be an issue?

I would be interested to test with a timeout value that is less than 150ms.
Author:  hvz [ Fri Dec 24, 2021 2:41 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
Quote:
The required timeout is currently set to 150 ms, I guess I could reduce that. Can you make a short video that I can use to see/measure how long the pauses are?

Also, is that last block way longer? It looks far too long to send in 1 second at 4800 baud.
Yes, the last block is longer. I wondered about this, so I experimented by setting the GPS to send different sentences.

Sending only GGA, GSA and RMC didn't work at 4800 baud but is fine at 9600 baud [the three sentences are around 190 characters]
$GPGGA
$GPGSA
$GPRMC
<pause>

Interestingly, sending only GGA and GSA works fine at 4800 baud - the NMEA data flag becomes active and GPS lock is reported. [The two sentences are around 121 characters]
$GPGGA
$GPGSA
<pause>

It seems then that this issue may indeed relate to the number of characters sent / available time during pauses?

As standard this GPS seems to send at 4800baud using the NMEA sentences I described in my previous post. The longest block (9 lines) seems to be around 569 characters which may be an issue?
Its seems that 4800 baud is not uncommon for these types of devices, so it would be nice if it worked straight out of the box.
Does ST need NMEA every second with the requisite pause as a marker? I.e. would an the long blocks be an issue?

I would be interested to test with a timeout value that is less than 150ms.
569 * 8 / 4800 = 0.948 seconds, so that would mean that the pause is at most 50 ms. That's not much... especially since on Windows the data is typically processed in burst. And yes, we do need *something* to indicate that a new block of data arrives, to link it in time to the audio pulses. I don't think that there is any standard "first line" or something that's sent, otherwise we could have used that. Maybe something like "the first line that contains a new time stamp" would work, but that's tricky and might fail in other cases.

How did you make it send less data?
Author:  2Sense [ Fri Dec 24, 2021 4:27 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
Quote:
Quote:
The required timeout is currently set to 150 ms, I guess I could reduce that. Can you make a short video that I can use to see/measure how long the pauses are?

Also, is that last block way longer? It looks far too long to send in 1 second at 4800 baud.
Yes, the last block is longer. I wondered about this, so I experimented by setting the GPS to send different sentences.

Sending only GGA, GSA and RMC didn't work at 4800 baud but is fine at 9600 baud [the three sentences are around 190 characters]
$GPGGA
$GPGSA
$GPRMC
<pause>

Interestingly, sending only GGA and GSA works fine at 4800 baud - the NMEA data flag becomes active and GPS lock is reported. [The two sentences are around 121 characters]
$GPGGA
$GPGSA
<pause>

It seems then that this issue may indeed relate to the number of characters sent / available time during pauses?

As standard this GPS seems to send at 4800baud using the NMEA sentences I described in my previous post. The longest block (9 lines) seems to be around 569 characters which may be an issue?
Its seems that 4800 baud is not uncommon for these types of devices, so it would be nice if it worked straight out of the box.
Does ST need NMEA every second with the requisite pause as a marker? I.e. would an the long blocks be an issue?

I would be interested to test with a timeout value that is less than 150ms.
569 * 8 / 4800 = 0.948 seconds, so that would mean that the pause is at most 50 ms. That's not much... especially since on Windows the data is typically processed in burst. And yes, we do need *something* to indicate that a new block of data arrives, to link it in time to the audio pulses. I don't think that there is any standard "first line" or something that's sent, otherwise we could have used that. Maybe something like "the first line that contains a new time stamp" would work, but that's tricky and might fail in other cases.

How did you make it send less data?
I delved into some manufacturer specific info. The GPS uses a SiRF chipset, the associated demo software allows you to change the config of the device (e.g. baud rate, sentences, switch between NMEA mode and SiRF protocol, etc.). From what I have read, the device setup (e.g. baud rate) can also be changed by sending a serial command.

This seems to vary per manufacturer, but to change to 9600 for SiRF, it would be something like: $PSRF100,1,9600,8,1,0*0D (SetSerialPort). The $PSRF103*** set of commands is seemingly used to enable/disable certain messages (Query/Rate Control).
It doesn't seem like there is a standard across devices though? Seems to be specific to the manufacturer / chipset etc.? Some info here for three chipsets including SiRF. https://learn.sparkfun.com/tutorials/gp ... s-receiver

At one point I thought I lost GPS lock but that may have just been a transient issue. I need to test a bit more but I imagine sending only a limited number of NMEA sentences (e.g. just GGA), or using a higher baud rate, will leave a good margin for the pauses. I'm had hoped there would be a simple cover-all solution for the use of generally available USB GPS units, but now I'm not so sure. :(
Author:  MrKlorox [ Fri Dec 24, 2021 5:03 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Clicking the SB meter at the bottom with the Wideband off still takes one back to the primary processing page. Is this one of those old GUI things that likely won't be fixed since it presumably works properly in the new UI?

Thanks

EDIT: Okay this seems major. I can't get ASIO to work at all. No matter the API. beta 13 x64 win. Reverting back to 9.83 made it all work again.
Author:  phantomfm [ Fri Dec 24, 2021 5:27 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Bug report:

1. MicroMPX Decoder ARM32 Beta12: FM-OUTPUT TAB/input waveform in FM Tilt Correction only responds on scale adjustment
2. MicroMPX ENcoder ARM32 Beta12: INPUT TAB/output waveform in FM input Tilt does not respond & ZOOM function does not respond

Happy hollidays all !
Author:  hvz [ Fri Dec 24, 2021 6:51 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
Bug report:

1. MicroMPX Decoder ARM32 Beta12: FM-OUTPUT TAB/input waveform in FM Tilt Correction only responds on scale adjustment
2. MicroMPX ENcoder ARM32 Beta12: INPUT TAB/output waveform in FM input Tilt does not respond & ZOOM function does not respond

Happy hollidays all !
Confirmed. I also see the wrong icons pop up, so something is broken there. Here the whole screen goes black if I click on those icons.

Edit: They move again, but the zoom buttons still don't work. I'll run a rebuild tonight...
Author:  hvz [ Fri Dec 24, 2021 7:23 pm ]
Post subject:  Re: Stereo Tool 9.84 BETA
Quote:
Clicking the SB meter at the bottom with the Wideband off still takes one back to the primary processing page. Is this one of those old GUI things that likely won't be fixed since it presumably works properly in the new UI?

Thanks

EDIT: Okay this seems major. I can't get ASIO to work at all. No matter the API. beta 13 x64 win. Reverting back to 9.83 made it all work again.
Cause found and fixed. I'll run a rebuild tonight.
Page 2 of 20 All times are UTC+02:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/