I had similar thoughts, re. searching the file system path not being a synth feature. But simply deferring to the application has other downsides when it comes to soundfont adoption in general - end users must manually configure each application and there’s no standard way to do this. Eg. for my application I chose to dodge this configuration and bundle a soundfont, which removes burden from less technical users but also means users who already have sound fonts installed need to download 100mb instead of 10mb.
Fluidsynth is probably in a good position to be able to define conventions like standard search paths and/or configuration files - it would be great if the result could be adopted by other soundfont based software? -sqweek > On 2 Nov 2018, at 03:18, Carlo Bramini <carlo.bra...@libero.it> wrote: > > 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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev