pine64 / OpenPineBuds

Community maintained firmware for PineBuds Pro
141 stars 18 forks source link

Language options for sound files #46

Closed ThatcherC closed 1 year ago

ThatcherC commented 1 year ago

Addresses https://github.com/pine64/OpenPineBuds/issues/44 by

This PR will also make it easy to make custom sound profiles if desired! The LANG variable need not be restricted to actual languages. For example, you could put nautical sounds files in config/_default_cfg_src_/res/pirates/ and build with LANG=pirate ./build.sh to get a swashbuckling build of the OpenPineBuds firmware.

ThatcherC commented 1 year ago

Thanks! I like the AUDIO_LANG suggestion. Do you think just AUDIO would make sense as a variable name? I can imagine using it for things that aren't different languages, but just different voices, like AUDIO=ThatcherC or AUDIO=C3P0. Either way, seems like a good idea to switch away from LANG.

Also, re:

On another note, it seems like it would be a good idea to replace all of the txt audio files with more a more common format

- agreed. Do you mean the sounds not included in the config/_default_cfg_src_/res/*/ directories? I'd like to work on those in a future PR so that all the sounds can be stored as MP3s or Opus rather than txt files.

On the note of the Opus format - I think this PR will conflict with #45 (the switch to Opus). We'll probably have to rebase either that one or this one. I feel like it might be easier to merge this one first (once both are approved) because this PR will move both languages to MP3s and add the AUDIO/LANG feature, and then the Opus PR can be modified to include both the EN and CN sounds. Open to suggestions there though!

FintasticMan commented 1 year ago

Do you think just AUDIO would make sense as a variable name?

Good idea, then it's not linked to languages, which is nice.

Do you mean the sounds not included in the config/_default_cfg_src_/res/*/ directories?

I more meant the ones in config/_default_cfg_src_/res/{eq,gs_hw,ring}/. FFmpeg complains if you try to convert them, and the resulting wav file is 0 bytes. This should definitely be addressed in another PR, but it's good to think about.

There will definitely be conflicts between these branches, but nothing that is too difficult to resolve. I think it would be a bit of a shame to have both the MP3s and Opus files in the git history, but that's not much of an issue. I think it would be fine to merge this first, then I'll rebase my PR.

FintasticMan commented 1 year ago

I think it would be easiest to just merge this, then I'll rebase my changes, and you can merge that. I don't think that having a couple of extra small MP3s in the git history is really much of a problem.