alt00N voicepack error

ProffieOS
1

I have the following folder structure

common
font
      alt000
      alt001
      alt002
      alt003
      alt004
      alt005
      alt006
      [rest of font folders]

Each alt00N contains

A full list of voice pack .wav files 
(for the test the voicepacks were copies of each other)  

A voicepack.ini with voice_pack_version=2

from what i have tested

working:

mnum 1-20

not working:

mloop, battlevl, mpercent, mrandom, vmbegin, vmend, volup, voldown, 
thirty, forty, fifty, sixty, seventy, eighty, ninety, hundred

i haven’t tested the rest of the voice pack since i don’t have edit mode right now

Serial

Found mnum files: 1-20 in Test
Found vmend files: one unnumbered file in Test
Found vmbegin files: one unnumbered file in Test

However only mnum work, the rest of the voice pack doesn’t show

I deleted everything from the common folder exept mselect and the clrlst folder
Result - no voice pack sounds played with the exception of mnum 1-20

The whole voice pack was tested on a normal font and is confirmed to work

Serial from control test

Found mnum files: 1-20 in Test1
Found vmend files: one unnumbered file in Test1
Found vmbegin files: one unnumbered file in Test1

The rest of the voice pack doesn’t show

Version

v7.15
config/Crossguard.h
prop: SaberFett263Buttons
buttons: 2
installed: Dec 18 2025 00:13:15
2

Voice Packs aren’t effect sounds, so they’re not applicable to altNNN. The only exception is mnum, it is set up as an EFFECT, but that’s more for function to be able to have numbers work.

Your Voice Pack needs to be in common or the root of the font and you can only have one per preset.

3

sad, will there ever be a way to use more than 1 voicepack

4

In one preset, no? You can have a different voice pack on each preset; just put the sound files in the root of the main font for that preset. The voice pack is for menus, not sure why it would need to be tied to an Alt, they’re not used in normal use of the saber.

5

I have voice packs in all my presets, i use battery level, volume menu and track player often.
In this particular case the voice packs were for a preset that cycled through anakin, obiwan, maul, mace, sidious, luke and vader

6

I can add support for having voice pack files in alt directories. I would put it behind a define since it’s a feature that most people probably don’t need, but it wouldn’t be particularly hard to do.

I might even be able to speed things up a bit. Right now it looks in each directory in your font path to find the sound files, but I could make it so that it just looks at where mnum is and expects the rest of the files to be in the same directory instead.

2 Likes
7

that would be wonderfull

8

Ok, I’ve implemented this on github.
Basically it assumes that the voice pack files are in the same location as the “mnum” files.
I haven’t had time to properly test it, please let me know if there are problems.

9

ill test it, but how do i use it

10

Try this? Place each pack in the same dir as mnum. Which should be the root alt00N folders.

Oh and you’ll need the GitHub master version of profile OS:

Go to code, download zip.

You notice that there’s a line of text after Profezzorn’s name that describes his solution to your request:

use mnum to decide where to look for sound library sounds
11

I am looking at the new code and noticed this:

Shouldn’t it be:
#ifndef SEARCH_FOR_SOUND_LIBRARY_FILES

12

No, it shouldn’t.
What makes you think so?

13

Because you added a new define which leads to the old search path for the voivepack audio prompts.

(I might be wrong here)
Without the new SEARCH_FOR_SOUND_LIBRARY_FILES define in every config, ProffieOS will search in mnum but with the new define ProffieOS will search where it used to search. IMHO this might break backward compatibility “continuity”.

Maybe I am reading this wrong, but the way I read the code is that everybody will need to add the new SEARCH_FOR_SOUND_LIBRARY_FILES define in their config if they don’t want anything to change?

14

It’s true, I almost always prefer to maintain backwards compatibility, which means you need to use a define to activate a new feature.

There are two reasons why I think maybe it’s worth doing it the other way in this case:

  1. For the vast majority of people it will make no difference, because the mnum files will only be found in the same directory as the sound library files.
  2. The new way of locating the sound library files is faster and should produce fewer audio glitches. (this only matters to other sounds that are playing when a library sound is played, so it’s a fairly minor advantage.)

If we decide to change it to ‘#ifndef’, then we should also change the name of the define.

15

That is why I pointed it out. I though you might have made a “mistake” but those are two good reason to do it your way. Thanks for explaining.