Hello, if I can say my opinion, it would be better to leave that change outside the library. It looks more a feature for the application that it is using FluidSynth. This introduces also the need to distinguish between absolute/relative/virtual/network/etc paths, that can vary on different platforms. I doubt that just doing strcat() between the strings inside this "synth.soundfont-dirs" and the string written on the command line will be enough.
Although it may look useful for some typists, command auto-completation and command history of the shells give already a solution. Sincerely. > Il 1 novembre 2018 alle 13.16 Tom <remya...@gmail.com> ha scritto: > > Per request I'm moving this discussion to the mailing list. > > Motivation: https://github.com/FluidSynth/fluidsynth/issues/453 > Current PR: https://github.com/FluidSynth/fluidsynth/pull/454 > > Essentially the feature would add an option called " synth.soundfont-dirs". > I've chosen to make this a semi-colon delimited list, like > "/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's > "C:/soundfonts/"). When specifying soundfonts on the command-line, the new > functionality is to look for the soundfont in the current directory, and if > it's not there, search the other directories. This is so the user does not > need to specify an absolute path everytime. > > Some of the concerns: > > * How to implement the default path (env. variable, > dirname(synth.default-soundfont), custom path)? > IMO, the most intuitive place is to look in the current directory, then look > in locations determined by the filesystem hierarchy (FHS, XDG, etc; and > Windows equivalent). If we allow a run-time configurable option, the user can > rearrange the search path too. > > * Compile-time or run-time configurable? > Allow it to be compile-time configurable for maintainers to set a reasonable > default, but also run-time configurable for user convenience. > > * How to deal with other OSs? > See #1. > > * How to deal with files that exist in this default directory as well as in > the current working directory? > See #1. > > * After all: Why not writing a simple shell script for your use-case? > > Reducing duplication of effort. I think this patch is simple enough that the > user convenience to dev implementation ratio is good enough. > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
