My apologies for letting this sit: despite my disagreement with the
request, it has deserved a more comprehensive response for far too long.
Adrian Bunk wrote:
> you are missing the core problem here:
>
> wildmidi might not be useful without freepats, but I'd estimate 99% of
> all people installing libwildmidi1 do not want to use wildmidi at all.
I'd be surprised if even 1% of folk with libwildmidi1 installed have ever
heard of the wildmidi GUI interface, let alone have any intention of ever using
it. I've nothing against the interface, but the single most common reason that
libwildmidi1 is installed is as a handler for audio/midi, which is nearly
always with the gstreamer libwildmidi interface. In order to properly handle
this MIME type, we need to have a way to determine what audio to generate given
a MIDI sequence, which is most commonly done with the use of a soundfont,
patchfile, or other definition of which sound corresponds with which instrument
and note (typically for the general MIDI standard), hereafter collectively
called "soundfont". I believe freepats to be the smallest package in the
archive that can meet this requirement (the next smallest is
fluid-soundfont-gm, at 145MB, which then needs adjustment for the data to work
with wildmidi (proper sf2 support is planned for 0.3.0), so would end up being
even larger on disk post-install). I have heard of some projects that generate
audio rendering defintions at runtime, but I've not heard of any with wide
instrument coverage (and nothing even approaching the GM instrument set), and
many of them require fairly powerful hardware to run acceptably. I'd be very
happy to modify the wildmidi packaging to use a smaller soundfont, if someone
knows of one that is or could be in the archive, or with a runtime synthesizer,
if someone knows of one that is fast enough to run acceptably on the sort of
hardware users are likely to be running and can provide a filesystem interface
indistinguishable from loading a soundfont (it's probably easier to write a
gstreamer backend for the synth than to do it this way). My understanding of
the current state of audio interfaces is that the chance of finding hardware
MIDI rendering modules on a arbitrary system is becoming very low, and expected
to become even lower in the future. Given the power of modern computers,
compressed rendered audio is more common than MIDI for the average user (there
are still some games and web pages that use MIDI, but it is not as common
outside of music production as it was in the past), and this change in media
distribution has been noticed by the commodity hardware purveyors, who have
frequently dropped direct hardware support. Users who do have such hardware
(e.g. wavetable synth on a soundcard, outboard MIDI synth connected to some
MIDI port (from the soundcard, or a USB<->MIDI converter), etc.) would likely
benefit from the availability of another MIDI rendering backend, with the
default remaining that based on software synthesis on the primary processor(s)
(yet another gstreamer backend waiting to be written).
To make an analogy to another library that converts codepoints into
something that humans can sense directly, let's consider libpango, which
Depends on fontconfig, which Depends on fontconfig-config, which Depends on an
arbitrary disjunctive set of truetype fonts. I'm fairly sure that everyone
would agree that installing pango without installing any fonts is a highly
unusual use case, but conversely, I can imagine there exists at least one user
who has an installed font set from which they would like to purge all of the
packages representing the disjunctive set of fonts depended upon by
fontconfig-config. Further, there may even be a user who would prefer to use
only out-of-archive fonts. Given the rich variety of fonts in the archive, it
might be nicer for the disjunctive dependency of fontconfig-config to end in a
virtual package Provided by all the font packages in the archive, and for there
to be documentation on how users who only want out-of-archive fonts on how they
can achieve this. Practically, this is not considered an issue, as there is a
fair consensus that there are some sensible default fonts in the archive, and
if folk need different fonts for some reason, they should install more fonts,
and leave at least one of the fontconfig-config font dependencies installed
anyway. There may even be some users who never need to render text on the
screen (for example, those running a purely iconic environment), who may be
annoyed that they must install fonts in order to install some other package.
Similarly, the best solution for wildmidi is for there to exist
documentation on the best practices for packaging soundfonts (again, data
required to convert codepoints into something that humans can sense directly),
and for libwildmidi-config to Depend: upon freepats | gm-soundfont
(nomenclature subject to change in the event of the creation of an actual
soundfont packaging policy), so that users may select the appropriate soundfont
for their needs. Ideally there should be similar parallel documentation
suggesting to users how they can either A) define fake packages when using an
out-of-archive soundfont or B) quickly create data-file-only packages from
soundfonts so that they can handle out-of-archive soundfonts as packages.
There may also be some code to handle registration, presentation, etc. for the
installed soundfonts, so that all soundfont consumers can benefit from a
central soundfont repository, which would require appropriate patches to
wildmidi.
Despite this, the current packaging uses Recommends, rather than Depends:
in the default case, Recommends is installed, so the package is working. In
special cases, such as the user who wants to use other (potentially
out-of-archive) converted soundfonts and wants to remove freepats, or the user
who knows they will never render MIDI to audio, but happened to be forced to
install libwildmidi because some other package is less modular than they would
prefer, and wants to remove freepats, freepats can safely be removed without
overly disturbing the system: audio/midi may not be renderable by gstreamer (or
any other libwildmidi client claiming to handle audio/midi), but as noted
previously, some users may never encounter MIDI (or may actually prefer *not*
to hear embedded MIDI from web pages). Demoting what is arguably a dependency
even further, to Suggests, may provide better support for cases where one
expects never to use the library, but it means that the library is unable to
perform it's function, and the implicit contract to library users is broken:
such a change would immediately require the filing of a bug against gstreamer
that gstreamer0.10-plugins-bad claimed to render audio/midi, and failed to do
so without special additional configuration. Note that hackery to blacklist
freepats from a CD image or installation script whilst installing libwildmidi
causes the same issue.
> When a user installs pidgin (for ICQ) or totem-plugins-dvb-daemon
> (for watching TV), then it is unavoidable that libwildmidi1
> gets installed as a dependency.
>
> In both cases there's a dependency on gstreamer0.10-plugins-bad,
> and since libgstwildmidi is 1 of the 89 plugins there
> gstreamer0.10-plugins-bad depends on libwildmidi1.
>
> With apt defaulting to install recommends this implies that a user
> usually gets the 30MB freepats installed when he installs pidgin
> for ICQ or totem-plugins-dvb-daemon for watching TV.
If it is considered important not to install freepats (or another
soundfont) in these cases (or have it not present on initial install), then I'd
argue that it would be better not to claim to be able to handle audio/midi at
all, which would mean pulling libgstwildmidi out of gstreamer0.10-plugins-bad
and putting it somewhere else (perhaps leave a Suggests: as a hint for anyone
who wants support for handling audio/midi). By doing so, users will be unable
to automatically render encountered MIDI (most commonly on web pages) by
default and have smaller download/install requirements, which are the requests
behind this bug, and no new bugs would be created: users who installed
something that uses libwildmidi *would* be able to render the audio, as would
be expected (and likely claimed) by the package depending on libwildmidi. I
also prefer the idea of maintaining a less commonly installed package that
works to the idea of maintaining an extremely frequently installed package that
fails to work (or, more precisely, a frequently installed library that fails to
provide the services advertised in the API, such that the maintainers of the
reverse dependencies are vocal complainants). I'd much rather just have the
audio/MIDI handler installed by default, since ending the long series of bugs
complaining about how browser X, file manager Y, audio player Z, and subsystem
G were unable to render audio/midi was my primary motivation to package
wildmidi in the first place, but as those bugs are nigh invariably filed on
other packages (the concerned users having never heard of wildmidi), and it is
up to those other packages whether they want to have a dependency chain that
installs libwildmidi, I'm willing to leave that decision to those who maintain
those packages, and therefore receive those bug reports (which become support
requests, given the availability of a working libwildmidi).
Similarly, if there exists a smaller-footprint software synthesizer
gstreamer backend that can function effectively as the default audio/midi
handler, it may be interesting to change the default, such that
gstreamer-wildmidi becomes a non-default choice, for folk that want specific
characteristics of this solution. Something might be able to be done with
libgstlv2, but finding a GM-compatible synthesizer that doesn't use a patchset
or softsynth may prove difficult, and then one has to worry about the effects
of hiding the UI, etc. (it may be easier, after identifying such a synthesizer
to bind it's library directly to gstreamer than using libgstlv2). Runtime
synthesis performance should probably also be tested on some of the slower
architectures, to make sure that they can keep up with at least a single voice
120bpm MIDI track.
That said, if someone would like to construct a compelling argument that we
should install a default audio/midi handler that is not capable of generating
sound (or only generates silence), supplies a patch that causes libwildmidi to
do this in a safe way, provides documentation to help users configure their
systems to render audio/midi as sound, is willing to help the gstreamer,
browser, and file manager maintainers correctly triage the "MIDI doesn't work"
bugs, and has the agreement of the gstreamer maintainers that doing so is
preferred to splitting the plugin out of the plugins-bad set, I'd be willing to
upload such a modified package. I still don't think it's a good idea, but if
there is some really good reason (moreso than "save space" or "save bandwidth",
both better handled with the gstreamer change mentioned above), it is more
acceptable than demoting to suggests, which renders the package inoperative
without providing any easy means for recovery by affected users (either end
users or maintainers of packages that depend upon libwildmidi).
--
Emmet HIKORY
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
