Fabian Greffrath dixit:
>Hi Thorsten et al.,
>
>> Do we also wish a /usr/share/sounds/sf3/default.sf3 ? Ib^@^Yve 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.
True, but that would lead to major unnecessary package churn with,
in my case, about 700 MiB (compressed size) per upload. I’d prefer
to avoid that, for snapshot.d.o sanity and users on poor bandwidth
connections (i.e. Germans) ☻
>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
OK, /usr/share/sounds/sf[23]/default.sf[23] then.
>> Should we also make all packages providing an alternative for this
>> Provides some virtual package, for others to depend on? Ib^@^Yd 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.
Oh, interesting. Is there prior art for this? I think it can only
add alternatives for those packages that are actually installed…
… for simplicity, I’d use this dependency though:
timgm6mb-soundfont | sf2-soundfont
(preferring the tiniest of its providers as the real alternative,
for when the package is installed in buildds)
>> Alternatives priorities could also be tricky. They can even differ
>> between default.sf2 and default.sf3b^@&
>
>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.
OK, good point, although I’d decrease opl3-soundfont as it’s special-use
(and whether fluid-soundfont-gs should be included at all?) and put
MuseScore_General (actively developed) over all Fluid ones (frozen).
Going by Installed-Size in apt-cache policy:
fluid-soundfont-gs 3149 10 sf2 (I think)
timgm6mb-soundfont 6069 20 sf2 (I think)
opl3-soundfont 131891 30 sf2 (I think)
fluidr3mono-gm-soundfont 23091 40 sf3
fluid-soundfont-gm 145169 50 sf2 (I think)
musescore-general-soundfont-small 39002 60 sf3
musescore-general-soundfont 83917 70 sf3
musescore-general-soundfont-lossless 477837 80 sf2 (confirmed)
The sf3 ones can also fulfill sf2.
Does this look agreeable? Did I miss any (I did a search for
packages with “soundfont” in their name)? Did I misidentify
any non-SF2 ones as SF2?
>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?
Sure. Some people consider GS sufficient for MIDI, some don’t, it
really depends on what kind of music to play. Just leave out
fluid-soundfont-gs and start with timgm6mb-soundfont at 20
if we do that. Easier to change later.
>> Another point to think of: admins can locally install anyB9 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.
OK.
>> b^@" how easy is it for non-packaged things to be added to the
>> Debian alternatives system? I think itb^@^Ys just one command,
>> which we could document in the consumers of soundfontsb^@^Y readmes.
>
>It should be just one command, indeed, and we could document it somewhere,
Agreed.
>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
Changing the alternative might be easier and robuster.
> or (b) you are able to nuke the
>alternatives symlink and point a new one to your favourite soundfont
>instead.
Ouch, don’t do that…
>> This (#929185) may also affect timidity, which has its own format,
>> but with a trivial config file can support any SF2 (at least, did
>> not try SF3) soundfont:
>
>I didn't even know this! I believed timidity was still bound to the pats
>format.
It was news to me as well, but happy news.
>> Ib ve opened #920373 against timidity to have sourcing this, commented
>> out, added to the stock timidity configuration (which already shows
>> commented-out entries for several other soundfonts).
>
>If it is this easy to tell timidity use SF2 soundfonts then I agree we
>should prepare its package for this.
OK. timidity maintainers, do you copy?
>Thanks for your input!
You’re welcome,
//mirabilos
--
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.
