Hi Thorsten et al.,
Thorsten Glaser wrote:
> Iâd be happy to add an /usr/share/sounds/sf2/default.sf2 alternative
> to musescore-general-soundfont-lossless (which is about half a GiB
> already and expected to grow). Please note the changed location, as
> /usr/share/sounds/ is where soundfonts in Debian are expected to be
> packaged, and weâve been subdirectoryâing them by format.
I am fine with any location for the default.sf2 file but agree with you
that we should stay consistent with the present packaging behaviour.
> Do we also wish a /usr/share/sounds/sf3/default.sf3 ? Iâve got four
I don't have a strong opinion about this. My concern is merely that we
have at least one soundfont installed so users can play MIDI
out-of-the-box. We can still decide wether to extend this to other formats
once we've got an implementation for SF2 alternatives working.
> On the other hand, putting them into /usr/share/sounds/sf?/ would
> make the programs pick them up in soundfont listings, so perhaps
> the different location (or just /usr/share/sounds/default.sf{2,3})
> might make sense?
I don't see a problem with a soundfont appearing twice, once under its
original filename and once as "default.sf2". Quite the contrary, I think
we should not "hide" it from users, it should be clear that there are
several soundfonts available and one of them is declared the default.
> Should we also make all packages providing an alternative for this
> Provides some virtual package, for others to depend on? Iâd suggest
> sf2-soundfont and sf3-soundfont for naming, and SF3 soundfonts can
> Provides both of them.
Either this, or we could even introduce a real package that depends on one
of the providers and itself provides the named symlink and the
alternatives invocation in its maintainer scripts.
> Alternatives priorities could also be tricky. They can even differ
> between default.sf2 and default.sf3â¦
I believe that if you install a several-hundred-MB soundfont package you
did this for a reason and apparently want to use this soundfont as your
new default. So, as a rough measure, we could probably start with
timgm6mb-soundfont and increase priority with increasing package size.
> This might be tricky. Would uses rather have no sound (e.g. if we
> require GM) [or more soundfonts installed] or bad sound (e.g. if we
> donât require GM, and, say fluid-soundfont-gs is the only installed)?
The point is that playing MIDI should immediately work out-of-the-box with
at least fluidsynth and gstreamer if one of the packages providing the
alternative is installed. So, I guess any SF2 soundfont providing a GM set
should be sufficient?
> Another point to think of: admins can locally install any¹ other
> soundfont by just copying it into place, and those can also serve
> as default soundfonts. This offers two questions:
In Debian, we can really only take care of other software that is in
Debian. However, we can make it as easy as possible to use Debian's
mechanisms for software not packaged, c.f. game-data-packager.
> ⢠how easy is it for non-packaged things to be added to the
> Debian alternatives system? I think itâs just one command,
> which we could document in the consumers of soundfontsâ readmes.
It should be just one command, indeed, and we could document it somewhere,
e.g. in the Wiki. However, this already exceeds the "it should just work"
use case. If you care enough to install your own soundfont then probably
it can be expected that (a) you either already figured out how to tell
your MIDI rendering software how to use it or (b) you are able to nuke the
alternatives symlink and point a new one to your favourite soundfont
instead.
Thanks for your input!
- Fabian
