Re: [fluid-dev] Allow soundfonts to be searched from multiple directories

[Reinhold Hoffmann]

My optinion is that searching and organizing soundfont files are the task of
an application and NOT of fluidsynth. Our applications come with a standard
soundfont file but in addition with the feature that the user can load a
non-standard soundfont file based on own needs. Our applications also gather
where the soundfont file is located and that the user can easily switch
between different soundfont files. The biggest effort here is anyway the
user interface which is different for each app.

fluidsynth and the fluidsynth LGPL libraries are a clean focus to
synthesizer features where searching and organizing soundfont files is more
a data managing task rather a task of a synthesizer software.
(I also imagine that searching and organizing files is strongly dependant on
the platform e.g. Windows is different than Linux and macOS (access rights,
paths etc.)). My view, the energy of the open source input of smart people
should be towards the core value of a synthesizer which is unique where
organizing files is just a kind of "doing" without special skills.

Reinhold

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:address@hidden
Im Auftrag von sqweek E.
Gesendet: Freitag, 2. November 2018 07:08
An: FluidSynth mailing list
Betreff: Re: [fluid-dev] Allow soundfonts to be searched from multiple
directories

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 <address@hidden> 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 <address@hidden> 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 
>> address@hidden 
>> https://lists.nongnu.org/mailman/listinfo/fluid-dev
> 
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev