That's cool -- I admit the choose pack dialog was a hack, inasmuch as it was just the fastest thing I could throw in there to allow picking the pack without manually editting the config file (although you still had to go into the config file to disable this and use whatever you specified as the "default" directory, so that probably wasn't so convenient), and isn't really the right solution for the reasons you point out, plus it's your project to decide what's more annoying than helpful.
If we were to allow switching the pack without manually editting the config file, would we want something more in the line of the filesystem browsing dialog (of course, specifying that what we want is a directory) that Windows makes available to most programs? (I think it's called the "Open File Dialog", obviously enough. If only everything about Windows were that obvious, really...)
Google says (if I'm understanding correct) that in Java, using Java code rather than OS-specific stuff, there's a Swing thing for this and an Awt thing for this. (At least, I think Awt is a general Java library like Swing; I'm not familiar with Awt though.) Would we want the Swing way (assuming this is what we want at all)?
Given that the pack initially loads before the GUI, would it make sense to have SoundSense.java call whatever directory-choosing browser/method is ultimately used before loading the pack the first time? Or would it make more sense to load the GUI and let the GUI load the pack so it's all handled normally in the GUI whether loading, reloading or choosing a different directory? Or would it be best to continue initially loading the default pack specified in the config file, and make changing it require letting Soundsense load the current one before you get to the GUI where you can switch the pack directory and reload? I'm actually leaning toward the middle option, assuming there's not some other way to integrate it that I'm overlooking, and still assuming that having some way within Soundsense to change the directory without manually editting the configuration is desirable (I know I at any rate would use it, though as I said before I'm an oddity and it needs to be something that at the least can be switched off so as to be nonintrusive for anyone who wouldn't use it).
I also have an entirely unrelated issue -- yesterday I discovered that setting delay="8500" in your sound element does not wait 8.5 seconds to play music on a channel. (8.5 seconds is the length of the Bay 12 Games and Toady One logos/whatever before the DF intro.) Is that intentional? I don't see any particular reason not to allow the user to deliberately set music (channel-bound sound) to come on only after a sound effect or pause, unless how the channel works is incompatible with setting a delay. I was hoping to be able to make music play at the end of a sound effect, or over the DF intro after the Bay 12 / Toady One logo thingies at the beginning. Of course I could just make it a channelless sound effect -- but then I can't stop it early when other music is switched on. (By the way, it also appears, unless I got horribly turned around trying to figure this out, that haltOnMatch actually defaults to false if not present, which probably is intentional but I had assumed otherwise based on usage examples -- I'll have to double-check the directions on that point.)
To throw on the brainstorming pile: another wild thing that might be handy is to make SoundsXML read/write instead of just read so that another GUI/application could be built to assist in creating and editting sound/music listings. (Would that be able to write comments if it's possible at all? If not that could be a notable limitation...) That's practically a whole new project, however, albeit entirely connected to this one. Hey, I might do it if I find enough time before my interest wanders to something completely different. (If I don't, I might come back and do it in a couple years if nobody has and one day I wake up and feel like it. When it comes to spare time projects I'm not spending my employed forty hours a week on, I can sometimes be a fickle coder, but I try to work with stuff in such a way that it doesn't hurt to leave it and come back to it later.)
Going on New Year's visit to relatives tomorrow, so I may not be back for a week, but I'll make sure I look for any replies/comments by next weekend at least.