Reasoning

1. Settings is where this would reasonably live on any project.
2. A settings file allows you to isolate potential user-driven changes away from architecture.
3. It's easier to retain customizations between versions

Expected

1. Audio.lua contains the back-up constants for fanfare, used if there is no custom fanfare defined
2. Settings.lua contains custom fanfare; overrides default settings if present

Note

The git push that contained this change noted that it was to make you able to add/remove custom fanfare using an in-game method of some kind, but I couldn't find where that was possible in the right-click settings menu.

The problem here is ATT's settings file is included in the package. You are implicitly overwriting the user's
settings with every update if they do not match defaults.

This is bad practice imo, and the methods you propose are workarounds, rather than addressing the core issue. A settings file should be generated with defaults on first initialization of the module, and validated as having the correct values in each initialization after, adding missing categories or lines to the file if necessary. This ensures you do not overwrite an existing settings file while retaining forward-compatibility.

Granted, I do not know how easy this is in Lua, as I work mainly in python.

And you are correct on "I can just change the file paths in Audio.lua", but you already mentioned why this is undesirable, especially since it's a core library rather than a settings file and thus more vital to change with updates. I saved my paths to a scratch Lua file called Fanfare.lua, to copy paste across files in the future. I may end up making an addon much like the one you linked earlier just to make it easier on myself. But I still stand by the belief that expecting users to script (addon or WA alike) in order to do basic customization of ATT is an obtuse workaround covering up a core architectural flaw.

The problem here is ATT's settings file is included in the package. You are implicitly overwriting the user's
settings with every update if they do not match defaults.

Settings.lua is not a configurable settings file and has no expectation of being modified by the end user. It contains the logic that provides in-game access to manipulate the user's settings and base static default values of said options.

The actual storage of a user's settings is completely separate to the addon directory. All addons store their 'settings' i.e. 'Saved Variables' in the following file path: [WoWInstall]\[GameVersion]\WTF\Account\[Account]\SavedVariables\[AddonName].lua
What you would be expecting then, is to have your list of custom Audio files saved there and have functionality in ATT Settings.lua that loads the Saved Variables to include your custom Audio files automatically.

I could probably add a small snippet into Settings.lua to load a specific table key (if existing) from ATT's Saved Variables which could be treated as a custom-definition of Audio files to replace the ATT defaults. In this way:

• They would be stored appropriately between sessions and new ATT updates
• There wouldn't be modification of actual addon files needed to persist the custom audio
• There wouldn't be need of installing other addons or using in-game scripts to provide the audio files to ATT

The caveat is that the user would need to manually adjust the list as they see fit, since adding in-game UI support for this is a task I'm not willing to undertake at this time 😄

It seems there's a bit of a misunderstanding of what that change was enacted to accomplish. The goal is to slowly compartmentalize various portions of logic and functionality within ATT (the main file is still 25,000+ lines long... not great for maintenance). Packaging all the Audio-related functionality into a stand-alone file helps to keep it separate from unrelated logic.

The change also does expose public functionality (i.e. in-game it can be accessed from other sources) but there is no functionality to assign sounds via the UI in some way.

The 'Settings' for the Audio/fanfare itself is still contained in Settings. The actual 'Audio' that is available to ATT is now referenced in the Audio lib. A static list of available file paths doesn't really meet the implementation of 'settings' which can be modified by a user.

If you'd like an example of how a 3rd party might alter/modify the ATT sounds (which it sounds like maybe you've been doing and this change has broken your implementation?) there's already an example of a custom ATT sound pack (source) which was actually created by one of the ATT contribs, who themselves had been maintaining an alternate version of the Settings.lua file locally in order to provide more in-game sounds for ATT. Now, the implementation can be performed by a separate, stand-alone addon (or even a Weak Aura) and requires no modification of actual ATT files.

Does that help clear things up?

I agree that it's good to compartmentalize logic into specific easier-to-maintain libraries with clear abstraction and interfaces. I also agree that it's good to not require modification of ATT files. But I do think this implementation is clunky.

My confusion stemmed from ATT suddenly no longer respecting my custom fanfare. I can see through the ATT mod pack you linked that the expected behavior now is to change fanfare by writing your own script. I personally think asking users to make their own addon for basic customization of ATT is more obtuse than putting "rangerx-win.ogg" in a table in the settings file or providing some in-game interface to assign/remove fanfare without relying on other addons, but it seems in line with the project goals, so I retract my request.

Closing

I personally think asking users to make their own addon for basic customization of ATT is more obtuse than putting "rangerx-win.ogg" in a table in the settings file

Perhaps as far as 'difficulty of the initial action' is concerned, but you then have to maintain that change on your side through each ATT update since the file will typically be overwritten when performing an update. In that regard, doing slightly more effort to ensure a persistent user change in one action which does not need to be maintained should seem preferable. And no one can stop you from doing the exact same file modifications as before, but within the Audio.lua file instead of Settings.lua. All the file paths are available right there to be removed or added to as desired, if that continues to be your means of adjusting the audio ATT uses.

As I mentioned, an entire addon (though simple perhaps) is also not necessary to add sounds. Many users use the addon 'WeakAuras' to perform small bits of functionality throughout gameplay, and a script like this will automatically change ATT sounds when loading the game without additional addons:

if not AllTheThings then return; end
local Clear, Add = AllTheThings.ClearSounds, AllTheThings.AddSound
Clear("fanfare")
Add("fanfare", "Interface\\AddOns\\DBM-VPVEM\\count\\1.ogg")

Clear("remove")
Add("remove", 542342)

print("Added New ATT Sounds!")