Licence page on old skins is pulliing new skin.

Just for clarity:

MicroMPX encoder is now part of Stereo Tool!

See the latest beta on the previous page. Decoder is also available there.

Will you be supporting SSB Composite clipping and Multipath Clipper in conjunction with MicroMPX?
(Seems when MicroMPX is enabled, both SSB and Multipath gets disabled?)

Are the 9x IP output streams able to be individually allocated some form of sending buffer so you can sync things (ie run a very basic SFN)?

Assume you will be updating your product page to purchase a valid license when 9.02 is released?

Running the decoder or encoder exe throws up an error indicating it could not find the libsndfile-1.dll?
Is it suppose to find it or the exe needing to be run from a particular location?

Those new color buttons (red, green etc) are new so they don't exist in any older skin.

was like that

Ok. "Small" problem then: Other programs DO use decimal numbers and they use the same command. And some might use a mix. Ugh. So how do I support both??? Without adding yet another selection, that nobody will know what to set to

(By the way, Windows "calc" can do these conversions!)


Edit: For now I'll just add an ASCII (MagicRDS) selection to the list. Which treats any number as hex. That's an easy fix for now.
Edit 2: Hm. Ok. The current code doesn't really make sense. For PTY, I was already expecting hex numbers. For AF I was expecting decimal numbers. Checking now what MagicRDS does.....
Edit 3: Ah. AFCH= seems to be MagicRDS specific (I googled "AFCH=" "RDS" and everything I find points to MagicRDS). So it's pretty easy to convert that to hex without any side effects.

Edit 4: Ugh. This makes no sense. MagicRDS sends the PTY code as a decimal number (and for some reason I was reading it as hex, not sure anymore why I did that...), but AF is apparently sent as hex. Greeeeeeat.....


Ok. So. This is a bit weird.

First, AF method A. I think I'm correctly supporting that now. (the next build will support hex numbers for AFCH=).

Then AF method B. I've tried the following: Set frequencies 87.7 (02), 87.8 (03), 87.9 (04) as AF's with the same content as our actual signal at 87.6 (01). Set 88.4 (09), 88.5 (0A) and 88.6 (0B) as regional variants.

Here's what MagicRDS sends me:

AF=A
AFCH=01,01,02,01,03,01,04,09,01,0A,01,0B,01
AF=1
AFCH=
AF=2
AF=B

That first line AF=A, makes no sense at all.
The 2nd line shows pairs: 01, 01/02, 01/03, 01/04, 09/01, 0A/01, 0B/01. 01 is our own frequency, the ones where 01 is first are identical, the ones where 01 the last on the list are regional variants (it's a bit more complex than this but in this case this is true).
Then, AF=1. Why?
AFCH= - an empty list - why??
AF=2 - why?
AF=B - makes sense, but why send AF=A first? Besides, for the RDS encoder itself it makes no difference, all it needs to do is send the list on the 2nd line. But NOT the empty list.

So, I'm not really sure what's happening here and what the extra lines mean. They will cause the current code to fail, because the 2nd line will be parsed after the first one and will clear the whole list.

This is what you get for method A:

AF=A
AFCH=01,02,03,09,0A,0B

Which makes perfect sense and works. Anyone any idea what's happening here?

(MagicRDS was written to talk to Pira's own RDS encoder, so it's basically a propriatory format)

Final edit: MagicRDS doesn't support more than 12 AF frequencies for method B. I could basically ONLY accept AFCH after AF=A, but without understanding what I'm doing that sounds like a bad idea...