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:
Code:
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:
Code:
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...
Have you en/disabled the AF A method first? And deselected the frequencies there?
Like I said Hans, I think it's a great thing to build 'conversion tag'. A window with:
If ST gets "XXX=..." as data, interpret XXX as [Function].
(for example).
Let users map the RDS fields in the future, and make some documentation of what parameters StereoTool can handle (Like: AF accepts HEX (00..0F... = xyz), AF Accepts A,B or 0. Etcetera.
This way you don't have to build other functions or code in the future if there is new software you "don't support YET", and no more customizing the code of StereoTool for other software packages.
Voila: StereoTool RDS ASCII Commands Mapper is born.