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@xxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jnovy@xxxxxxxxxx ------- Additional Comments From j.w.r.degoede@xxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review