Play user generated sound files from a separate SD Card folder

[mha1]

The PR adds a special function to play .wav sound files stored on a separate folder on the SD card (SOUNDS/USER). This is meant to offer separation of user generated/acquired sound files from downloaded pre-built SD card sound packs. EdgeTX compatible sound files stored in the SOUNDS/USER folder can be played using the "Play User Track" special function.

Summary of changes:

• added special function "Play User Track" (128x64 bw, 212x64bw and color LCD)
• added CPN support for special function "Play User Track"

User generated sound files in SOUNDS/USER

Companion support

Color LCD

212x64 bw

128x64 bw

[elecpower]

I can see the logic for doing so. However, since nothing prevents custom/user sounds/sound packs being stored in the SOUNDS folder I do not see many users bothering to use the proposed function.

Alternative solution, have Play Track look in both folders and USER takes precedence if duplicate names. Both folders would need to be merged and sorted in ui selection lists.

[pfeerick]

Same - I see the logic/reasoning behind this, but I wonder if there is a better way to do this... On colour LCD there could be a toggle between the system and user folders, and perhaps the same could be done with B&W - long press of ENTER when in the file picker? i.e. rather than add a new SF, make it possile for the existing SF to just toggle in place.

[3djc]

I can see the logic for doing so. However, since nothing prevents custom/user sounds/sound packs being stored in the SOUNDS folder I do not see many users bothering to use the proposed function.

Alternative solution, have Play Track look in both folders and USER takes precedence if duplicate names. Both folders would need to be merged and sorted in ui selection lists.

This merge at UI level cannot be done on BW radio at all, and would be messy on colorlcd too. What If I want my version of armed but sometime use the 'system' one ? The whole point of the PR is to allow the users to manage their sound without having Buddy (or any other way to add sounds) overwrite their sound

[3djc]

Same - I see the logic/reasoning behind this, but I wonder if there is a better way to do this... On colour LCD there could be a toggle between the system and user folders, and perhaps the same could be done with B&W - long press of ENTER when in the file picker? i.e. rather than add a new SF, make it possible for the existing SF to just toggle in place.

Toggle would be possible, but very likely impractical on UI side, because you would need to find space to indicate with folder is been used in a meaningful way, not so easy. And code wise, it would not be as simple as that

[pfeerick]

impractical on UI side, because you would need to find space to indicate with folder is been used in a meaningful way, not so easy.

Very easy - worse case is bw128 - top or bottom line, if the user folder is present - show a something like a " DEFAULT | USER " (or whatever phrasing) header, highlight the one that is active. use the page key(s) to toggle between them. The rest is just code.

But to be honest, I would prefer native folder browsing, so that the files can start to be grouped, and the file lists get shorter.

[mha1]

But to be honest, I would prefer native folder browsing, so that the files can start to be grouped, and the file lists get shorter.

That was my initial idea in forwarded as question to @philmoz (see brief internal discussion here: https://discord.com/channels/839849772864503828/909552654328406056/1334852838001479741).

[3djc]

But native browsing won't be an option for a while, I find it a shame to not respond to very legitimate user need to manage their own sounds vs provided sounds

[mha1]

@pfeerick I re-opend this awaiting your final verdict. Bang the gavel:

• go ahead and keep the PR updated
• scrap it

[philmoz]

I definitely see the benefit of this; but I'm not really sure adding another SF type is a good long term solution.

Extending the existing Play Track SF to allow the user to select either the SOUNDS/language or SOUNDS/USER folder seems like a better interim solution.

However it needs a way to store which folder is selected.

Currently the 'func' field of the CustomFunctionData structure is using 6 bits; but there are only 29 special functions max. So this field could be reduced to 5 bits leaving space for a new flag that could be used by Play Track to select the folder. It would default to 0 which would be the SOUNDS/language, setting to 1 would select SOUNDS/USER.

On color and 212x64 B&W radios there should be space to show the name as USER/sound in the SF list.
On 128x64 B&W we might just have to accept only seeing the selected folder when editing the SF.

If/when we support saving the full path, then we can do a conversion when loading.

[philmoz]

If reducing the size of the 'func' field is not acceptable, then we could also reduce the size of the 'repeat' field to 6 bits; but this would require some work.
It's current range is -1 to 60 with -1 being the 'play once but not on start' special value. If this was mapped to 63 and the field made unsigned it would fit into 6 bits. This would also need conversion when reading and writing the YAML files to keep compatibility.

[mha1]

Sounds like jumping through a lot of hoops just to avoid a separate SF.

[pfeerick]

It's more an indication of a more problematic architectural issue with custom functions ... i.e. limited to options/data they can store. Yes, this should continue, we just need to figure out if there is a better way to do it than yet another SF/GF, especially if it is short lived. Now is a good time for it to be raised, as 3.0 brings opportunities to move a lot of stuff around, and with dropping F2 this may remove some limits to what we could do.

…

On Wed, 12 Feb 2025, 6:31 am Michael, ***@***.***> wrote: Sounds like jumping through a lot of hoops just to avoid a separate SF. — Reply to this email directly, view it on GitHub <#5858 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKAIEQI65P6BNGXHJL2PJM3LAVCNFSM6AAAAABWJPQ2DCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJSGAYDGMJUGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mha1]

I'm glad this triggered what maybe is the start of an overhaul of SF/GF architecture. There's other and most likely more important architectural issues waiting to be addressed for 3.0. Like dual modules, telemetry etc. The question here is is the option of having user sounds urgent enough to warrant a 2.11 implementation. If so it shouldn't create more architectural oddities. I don't think there's a strong customer demand beyond nice to have. I'd rather close this PR than making SF/GF even more complicated.

[pfeerick]

The question here is is the option of having user sounds urgent enough to warrant a 2.11 implementation.

Not a chance (for the immediate future - how things look once 2.11 is out the door, and we start looking towards the first point release is anyone's guess). You missed the opportunity for that to even be considered by two weeks and 12 days. 🤣

[mha1]

Who knew you'd throw out 2.11 that quick? Just kidding. No hard feelings. Tell me to close and I'll close it.

[pfeerick]

Who knew you'd throw out 2.11 that quick?

You really want me to remind you of the reminders? 🤣 😝

Nah, perhaps retarget it for 2.11 branch at most, but I would just leave it for now while we think about it, and for 2.11 to settle. This would probably be the only way to sneak this capability into a future 2.11 minor release (for F2s) as we don't want any major architectural changes there now.