Swedish sound files numbering and collision

[MetalMusings]

Hi,

the sound files for Swedish language is missing from the download site.
We have an updated the sound files with the correct numbering and want hem added to the download server.

A bug is found in tts_se.cpp SE_PROMPT_POINT_BASE is too low and sound file numbering for ".0" will collide with the higher numbered unit sounds files.

These two changes should go together I guess.

[kilrah]

What radio type? What OpenTX version?
You know that there have been changes between 2.0 and 2.1, and that the numbering has changed between both requiring packs to be adjusted, right?

[MetalMusings]

OpenTx 2.1.12 ( I think). One of the latest. Taranis.
Yes I am aware that the numbering changed and that is the problem because there were never any new sound files made available on the download server when 2.1 was released. So everyone ends up renaming some files, typically those for "minutes" at least.

[kilrah]

It's either 2.0.17 or 2.1.6.

We don't have automated generation for Swedish so rely on someone to provide an updated pack.
If you send us one we can include it and correct SE_PROMPT_POINT_BASE accordingly.

[MetalMusings]

Yes I can provide an updated sound pack.
Have to make sure that SE_PROMPT_POINT_BASE is large enough
Considering all units in enum TelemtryUnit possible as a sound file in singular and plural than SE_PROMPT_POINT_BASE should be at least 115 + 2*38 = 191. Say 200? Is this the right way to determine SE_PROMPT_POINT_BASE?

[kilrah]

In the english file we have

EN_PROMPT_UNITS_BASE = 113,
EN_PROMPT_POINT_BASE = 165, //.0 - .9

in swedish:

SE_PROMPT_UNITS_BASE = 115,

so I guess 170 would be enough.

Some units are virtual and thus will never be spoken.

[MetalMusings]

Makes sense. Also largest number in the updated soundfiles is 0164, so even 165 should work.
Me and some other persons will test and make sure we have the numbering set up correct, could take some day(s). There is no difference between X9D and X9E between sound files, right?

[kilrah]

No, all ARM-based platforms are identical.

[MetalMusings]

Thanks. I have tested and found something odd. I add a telemetrysensor with unit "A" and make Companion tell me its value and it says "zero ampere". Good. But Taranis says "zero volt", all units are off by one. I can see in the I18N_PLAY-functions that there are many (unit+1) and (unit-1) in tts_se.cpp where tts_en.cpp only has unit. I can see that the off by one can come from that. Does Companion use the same I18N_PLAY-functions? It doesn't I guess since the units work there.

[kilrah]

Are you sure you've got the same pack on the radio and PC? The functions should be the same.

[MetalMusings]

Should be the same. Ok. Hmm.
I have looked into tts_se.cpp and it doesn't look quite finished. There are number of #defines not used, the unit-1/unit+1 thing and the overlapping numbers. So I took a deep look yesterday and changed tts_se.cpp to be more or less a copy of the EN version. Also made the Swedish sound file numbering identical to EN. Compiled and tested on my Taranis yesterday, yes it works fine. I need to test with Companion as well so will install Windows tool-chain and all that.

I think this is a better way to do it. A simple fix could not solve the Swedish sound file numbering issue, so we do it the same was as the EN way.

[kilrah]

Yes that's the correct way to do it :)

[MetalMusings]

One guy tested with a GPS sensor and ran into unit problems again. GPS position and date units overlap with the "point 2" sounds. I can easily adjust SE_PROMPTS_UNIT_BASE and that solves it.
But i realize that all (most (at least EN)) translations have the same problem with overlapping sound numbers for gps position/date units against the "point 0"-numbers. How will they have to solve this? I would like to have the same solution for numbering as for all the other translations.

[MetalMusings]

One way to do it without breaking everyone's voice file numbering is to change in myeeprom.h
UNIT_CELLS = FIRST_VIRTUAL to
UNIT_CELLS = 300 // 300 as an example, must be high enough
Numbering of voice files for GPS units would not collide with existing.
As far as I can see, the enums in enum TelemetryUnit are just numbers, they don't refer to a place in memory and will not change memory size if altered. Should be safe?

[kilrah]

But then you'd break everybody's model setups ;)

[kilrah]

One guy tested with a GPS sensor and ran into unit problems again. GPS position and date units overlap with the "point 2" sounds.

What did he do? "Play Value GPS"? That is not supposed to be played, so the problem is rather that this should not be allowed in the choices list i.e. any telemetry item where unit >= UNIT_FIRST_VIRTUAL should be masked out of the list of choices for Play Value (that's the whole point of virtual units, they're for internal "bookkeeping" but define that the value is not something that can be presented to the user as such).

[MetalMusings]

Oh I see, that would be popular :)
Yes Play value is what he did.
Play Value GPS gave 57129 komma 3 where "komma" is swedish for decimal-dot
Plays Value GPS date gave 0 komma 1.
But I see what you write and I am happy to see that I don't need to consider those units.

We will be ready tomorrow I think, we are looking over flight-mode voice files.
How do I submit the material to you?

[MetalMusings]

Okay I think we are ready. I have a voice pack and a new tts_se.cpp (77 lines diff).
How?

[kilrah]

Ideally use the Github workflow for the code (fork, create a branch from master, commit, submit a pull request).
For the pack you can upload it to a file transfer site like wetransfer.com and paste the link here.
If you're lost with github you can do the same for the code.

[MetalMusings]

Great, thanks. Links to the files are here.

https://dl.dropboxusercontent.com/s/dedkkro9yvler4m/Swedish-taranis.zip
https://dl.dropboxusercontent.com/s/xsgbyi3w038eef7/tts_se.cpp

I'll have to read up on github.

[kilrah]

Committed and uploaded