[Bug 430417] Review Request: PersonalCopy-Lite-soundfont - Lite version of the PersonalCopy General Midi soundfont

Sun Feb 3 19:53:53 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: PersonalCopy-Lite-soundfont - Lite version of the PersonalCopy General Midi soundfont

https://bugzilla.redhat.com/show_bug.cgi?id=430417

j.w.r.degoede at hhs.nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jnovy at redhat.com

------- Additional Comments From j.w.r.degoede at hhs.nl  2008-02-03 14:53 EST -------
Adding Jindrich to the CC because we co-maintain timidity++

(In reply to comment #11)
> Well, okay. I will recheck this later.
> 
> A question:
> Do you have any idea to deal with %_sysconfdir/timidity.cfg?
> What I am thinking now is
> - Each rpms providing timidity++ has its own patch config file
>   under %_sysconfdir/timidity-patches/, with the name having some
>   prefix indicating priority, for example
>   %_sysconfdir/timidity-patches/00-soundfont.cfg
> 
> - And when a rpm providing timidity patches is installed, it calls
>   a script in timidity++-base (for example) to update
>   %_sysconfdir/timidity.cfg (marked as %verify(not size md5 mtime) )
> 
> - Sysadmin can "edit" timidity.cfg by adding his/her own configuration
>   file under %_sysconfdir/timidity-patches/ and calling registration
>   script.
> 

I like the idea of having a directory with per soundfont timidity.cfg for the
patch config files. But I'm not sure this is the best way forward ...

First of all its important to understand that there are 2 users of
/etc/timidity.cfg :
1) timidity(++) itself a full midi synth meant for musicians mostly 
2) timidity deratives, consisting of atleast: SDL_mixer, allegro, libtimidity,
   wildmidi. Which are all midi playing libs mean't for embedding in another
   application and typically have less sound quality and matching much less CPU
   usage.

One of the problems is the timidity deratives only support a subset of
/etc/timidity.cfg syntax. Most noteworthy timidity++ supports a new soundfont
statement, which allows it to directly use .sf2 soundfonts / patches, which
means the whole conversion to GUS patch format can be skipped, and importantly,
since .sf2 is a much newer format it also includes some additional details
making timidity++ sound significantly better when directly using the .sf2 file.

Also the priority ranking you propose is impossible IMHO. With soundfont's there
always is a tradeoff between size and quality. Which not only involves diskspace
usage, but also involves memory usage when playing back a midi file.

Clearly the best tradeoff between memory usage and quality lies differently
between the standalone timidity++ and the versions meant for embedding in other
programs and the tradeoff also is dependent on the hardware capabilities of the
used system.

Well that about concludes describing the problem.

---

Now to a solution. The solution I would like to propose is to make the 2
different usage groups mentioned above (stand alone player versus embedded  into
other applications) use 2 different config files.

I propose to use /etc/timidity.cfg for the embedded case, as that is what all 4
embedded variants currently default too. Also by having an /etc/timidity.cfg
which does not use any of the later timidity.cfg extensions added by timidity++
there will always be an /etc/timidity.cfg present which is compatible with
whatever is looking for it, even manually installed applications.

timidity++ will then be patches to first search for /etc/timidity++.cfg and only
if that is not present fallback to /etc/timidity.cfg. So that a different cfg
file can be made and used for the standalone player case.

The idea is to have /etc/timidity++.cfg only contain a single "soundfont ....
.sf2" line, as the standalone player performs best with a .sf2 file.

The default versions of both .cfg files will get some comment lines at the top
explaining the difference, for /etc/timidity.cfg this will be:
# Warning do not modify this file if you want to change the setting for
# timidity++, the standalone midi player. This file contains a timidity
# compatible patch configuration for applications / libraries which want GUS /
# timidty format patches, like for example SDL_mixer, allegro and libtimidity.
#
# If you want to change the configuration for timidity++, edit /etc/timidity++.cfg
# instead. Only change this file if you want to change the configuration for
# other GUS / timidity format patch using applications

---

With this mechanism (2 config files) in place I don't think there is a need to
have a dir with patch config files. For /etc/timidity.cfg one best breed
compromise between size and quality can be choosen (keeping in mind the embedded
nature of its users). Given that I've currently only found 2 soundfonts which
can be freely redistributed, this and plain PersonalCopy, the choose is easy.
This one, as plain PersonalCopy is twice the size and thats way too big for the
embedded usage scenario.

As for /etc/timidity++.cfg, determining which soundfont is the best is going to
be hard, if not impossible. But there is no need for any per soundfont config
file storage, as each .sf2 file is a standalone unit including all needed cfg
settings in the file itself, all thats needed in /etc/timidity++.cfg is just a
single line pointing to the soundfont one wants to use.

---

This leaves the question howto make sure atleast a single soundfont gets
installed when timidity++ gets installed, for this I would like to suggest
making timidity++ having a Requires on the virtual provides soundfont2, and make
all soundfont packages Provide: soundfont2. That and all .sf2 files should be
installed under /usr/share/soundfonts.

Then /etc/timidity++.cfg can be generated in a %post (install only not upgrade)
to point to the first .sf2 file listed in usr/share/soundfonts . There will
always be atleast one such file because of the Requires: soundfont2

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.