fluid-soundfont, generaluser-soundfont: add new sound fonts

[mojca (Mojca Miklavec)]

I'm opening a new ticket for discussing new packages for fluidsynth and GeneralUser sound fonts.

This was originally mentioned in #51842 as a potential dependency for TiMidity++.

Here's the code contributed by René:

• ​multimedia/fluidsynth (from ​master)

[RJVB (René Bertin)]

I'm all in favour for this :)

[mojca (Mojca Miklavec)]

• I don't see any reason to keep the two sound fonts as subports of fluidsynth. They have different descriptions, different master sites, different everything. You could just as well make three ports.
• The names are confusing enough already. I would (slightly?) prefer fluid-soundfont-gm and fluid-soundfont-gs. If you take all the patches from Debian, we could keep the naming somewhat consistent. I don't want to insist on that though.
• Where did you get the ​patch from? From ​Debian? I super hate the form it has at the moment and would be much happier if we would split it. Else let's just fetch the patch from Debian directly rather than including it as a whole in our MP repo.
  • In particular I would prefer to provide fluidr3_gm.cfg and fluidr3_gs.cfg as a separate standalone file rather than a patch, but all other files are annoying as well and people would get temptation to modify them. Less annoying if we take them directly though.

• ​Fedora recommends using ${prefix}/share/soundfonts. You picked ${prefix}/share/sounds/sf2. I'm not sure what other conventions are used elsewhere and I don't know if MacPorts already provides any sound fonts at all.
• What's the relation between fluitsynth and General User GL? Is ${destroot}${prefix}/share/docs/fluidsynth/GeneralUser-GS/${version} justified? I would kind of expect fluidsynth's documentation there and if the two projects are unrelated this might not be the most appropriate path. Same is true for other paths. But I'm not sure and I don't have any better idea.
• I guess that we should be able to come up with a livecheck for ​http://www.schristiancollins.com/generaluser.php

Random thoughts:

• The original link (​here) contains FluidR3 GM2-2.SF2 from 2013 rather than FluidR3_GM.sf2 and FluidR3_GS.sf2 from 2008, but I would ignore that fact and simply take things from Debian.
• Now that we have an example of packaging an SF2 font, the added bonus (once this work gets finished) would be to take a look at ​FreePats2 again. That's also an .sf2 file.

[RJVB (René Bertin)]

Replying to mojca:

• I don't see any reason to keep the two sound fonts as subports of fluidsynth. They have different descriptions, different master sites, different everything. You could just as well make three ports.

Initially I went for a fluidsynth subport because of the functional link to fluidsynth made by Debian/Ubuntu. It was only while looking at the 2 fluid-soundfont packages that I realised that 1) we would be putting the GM and GS soundfonts in a single port, and 2) that there's a (much) newer version of the GS sound font that is much more elaborate. And has a different license.

I'd still put both soundfonts in a single port myself, though.

• The names are confusing enough already. I would (slightly?) prefer fluid-soundfont-gm and fluid-soundfont-gs. If you take all the patches from Debian, we could keep the naming somewhat consistent. I don't want to insist on that though.

Naming is open for discussion, but the point remains there are 2 GS sound fonts. We could of course put the 2 older soundfonts under the -gm label, and the GeneralUser GS font as -gs.

• Where did you get the ​patch from? From ​Debian? I super hate the form it has at the moment and would be much happier if we would split it. Else let's just fetch the patch from Debian directly rather than including it as a whole in our MP repo.

Yes, I think so. It's a typical Debian patch that adds the whole debian subdir. We could strip out all the unused bits. Fetching from upstream is fine with me too, but (how) does that work with a gzipped patchfile?

• In particular I would prefer to provide fluidr3_gm.cfg and fluidr3_gs.cfg as a separate standalone file rather than a patch, but all other files are annoying as well and people would get temptation to modify them. Less annoying if we take them directly though.

The only way to get those from upstream would be to download a binary package; they don't exist as such in the source package.

• ​Fedora recommends using ${prefix}/share/soundfonts. You picked ${prefix}/share/sounds/sf2. I'm not sure what other conventions are used elsewhere and I don't know if MacPorts already provides any sound fonts at all.

Hmmm, I picked sounds/sf2 because that's what Debian and Ubuntu use, and I think that by extension that's where many software will look for soundfonts. There are none in MacPorts, so we have all liberty. But it does seem reasonable to install these under the existing standard sounds directory rather than in a parallel location.

• What's the relation between fluitsynth and General User GL? Is ${destroot}${prefix}/share/docs/fluidsynth/GeneralUser-GS/${version} justified? I would kind of expect fluidsynth's documentation there and if the two projects are unrelated this might not be the most appropriate path. Same is true for other paths. But I'm not sure and I don't have any better idea.

Good points...

• I guess that we should be able to come up with a livecheck for ​http://www.schristiancollins.com/generaluser.php

Maybe let's first try to assess how often this evolves?

• The original link (​here) contains FluidR3 GM2-2.SF2 from 2013 rather than FluidR3_GM.sf2 and FluidR3_GS.sf2 from 2008, but I would ignore that fact and simply take things from Debian.

Have you checked if there's an actual difference? I have assumed that the Debian package maintainers would have picked that up (5 years is long, even for Debian).

• Now that we have an example of packaging an SF2 font, the added bonus (once this work gets finished) would be to take a look at ​FreePats2 again. That's also an .sf2 file.

Yep. I looked at it and I don't see any advantage it could have over the original FreePats or the GeneralUser soundfont. Quality is maybe marginally better than the former but certainly not than the latter, and the number of voices is considerably more limited.

It doesn't seem to be possible to load and merge multiple soundfonts, and if that's confirmed there doesn't seem to be much interest in providing options that aren't very appropriate as a generic choice. Users with special needs are likely to know where to find "specialty" soundfonts, don't you think?

[mf2k (Frank Schima)]

Removing redundant keywords.

[mojca (Mojca Miklavec)]

My proposal for fluid-soundfont

[mojca (Mojca Miklavec)]

I attached my proposal for packaging what's in Debian (some files may be omitted from installation of course, but I felt it would be right to give some credit to Debian for making all the support files).

Quick observations:

• GS fluidr3_gs.cfg doesn't even provide support for accordion
• GM fluidr3_gm.cfg is sometimes better and with more "natural" sound for accordion, but it sounds terrible when playing quickly and the balance between the high pitches for melody and the basses is not even bearable to listen to; so apparently I'll have to stick with FreePats.
• cfg files use a mixture of LF & CRLF (may we depend on dos2unix for installation dependency?)

I noticed that Debian probably puts the files to etc/timidity. I'm not sure what's better, but when I think about it, etc does make sense. Then again Timidity seems to use share by default which defeats the purpose.

Have you checked if there's an actual difference? I have assumed that the Debian package maintainers would have picked that up (5 years is long, even for Debian).

I have no clue how to inspect sound fonts. And anyway there is no GM and the licence is different and ...

[mojca (Mojca Miklavec)]

My proposal for fluid-soundfont

[RJVB (René Bertin)]

Replying to mojca:

I don't have time right now but will check out your proposal later.

it would be right to give some credit to Debian for making all the support files).

Yes, that's why I installed a few of their files too (IIRC).

• GS fluidr3_gs.cfg doesn't even provide support for accordion

No, this file can be used in addition to the gm .cfg file; it provides Roland patches.

• cfg files use a mixture of LF & CRLF (may we depend on dos2unix for installation dependency?)

Not when you create them via the patchfile.

I don't think you ought to be concerned with "people would get temptation to modify them". They might, but it will rather be the installed version, while others might think twice before they start hacking in patchfiles.

I noticed that Debian probably puts the files to etc/timidity. I'm not sure what's better, but when I think about it, etc does make sense.

I don't recall patching timidity to use a location other than $prefix/share/timidity, so I guess it's Debian who patch timidity to look in under etc. I can imagine putting timidity.cfg under etc, but the other files seem better under share/something.

I have no clue how to inspect sound fonts. And anyway there is no GM and the licence is different and ...

Size could be a good clue here.

[mojca (Mojca Miklavec)]

My suggestion would be to:

• make the ports for sound fonts ready first
• make sure that fluidsynth is up to date (I didn't look at it yet, I'm waiting to resolve this first), if nothing else add the maintainer
• look at TiMidity++ next
• you can update the PR for VLC any time
• I'll need assistance with qsynth in case it's ready; I found a linux box where I installed it, but I have no clue what to do with it; but once it's ready you can also submit a pull request anyway

Replying to RJVB:

Replying to mojca:

it would be right to give some credit to Debian for making all the support files).

Yes, that's why I installed a few of their files too (IIRC).

I didn't see any. Just README and COPYING from original.

• GS fluidr3_gs.cfg doesn't even provide support for accordion

No, this file can be used in addition to the gm .cfg file; it provides Roland patches.

In that case I admit that I don't even have a clue how to use the files. (I made a symlink from timidity.cfg to the file I wanted to use.)

• cfg files use a mixture of LF & CRLF (may we depend on dos2unix for installation dependency?)

Not when you create them via the patchfile.

They do when I fetch the patchfiles from Debian directly.

I don't think you ought to be concerned with "people would get temptation to modify them".

In my attached example there is no separate patchfile (and thus no temptation :), the patchfile is fetched and applied on the fly from the Debian server.

I don't recall patching timidity to use a location other than $prefix/share/timidity, so I guess it's Debian who patch timidity to look in under etc. I can imagine putting timidity.cfg under etc, but the other files seem better under share/something.

We can put them to share/timidity then.

I have no clue how to inspect sound fonts. And anyway there is no GM and the licence is different and ...

Size could be a good clue here.

      257 20 jun  2013 Changelog.txt
    14848 21 jun  2013 Fluid R3- Readme.doc
148345256 20 jun  2013 FluidR3 GM2-2.SF2

vs.

     1086 19 feb  2008 COPYING
148398306 24 feb  2008 FluidR3_GM.sf2
  3201926 24 feb  2008 FluidR3_GS.sf2
     1042 20 feb  2008 README

and Changelog.txt

FluidR3 GM Soundfont Changes Log
Date     Version    Author          Action
20/06/13   2.2      Church Organist Missing note (#94) added to Violin and range extended to G7 (MIDI#103)
                                    for compatibility with MuseScore 2

and the readme starting with

FLUID® R3

Released to Public Domain on 12/25/01

©2000-2002 Frank Wen

[RJVB (René Bertin)]

Replying to mojca:

• make the ports for sound fonts ready first
• make sure that fluidsynth is up to date (I didn't look at it yet, I'm waiting to resolve this first), if nothing else add the maintainer

OK and OK. According to livecheck fluidsynth and the website is up to date.

• you can update the PR for VLC any time

Already done (I think), but that will have to be redone as a function of 1).

• I'll need assistance with qsynth in case it's ready; I found a linux box where I installed it, but I have no clue what to do with it; but once it's ready you can also submit a pull request anyway

Did you test it already? I got it to build (with some convincing not to make an autonomous app bundle) but it doesn't work reliably. It does when I switch it to PortAudio instead CoreAudio + CoreMidi, and keeps working when I switch it back, but otherwise it only logs error messages in system.log. Googling suggests that could be a known issue on 10.9 .

Either way it doesn't have a way to open other files (strange for a GUI app) and would require a patch to make it open files via the Finder.

Its niche seems to be the control over certain playback parameters it gives, but as a tool for simply playing back MIDI files as if they were regular sound files VLC does much better.

• GS fluidr3_gs.cfg doesn't even provide support for accordion

No, this file can be used in addition to the gm .cfg file; it provides Roland patches.

In that case I admit that I don't even have a clue how to use the files. (I made a symlink from timidity.cfg to the file I wanted to use.)

timidity.cfg shows how: you specify both. I think that if you look at the contents of these files you'll see that they don't specify exactly the same channels.

20/06/13 2.2 Church Organist Missing note (#94) added to Violin and range extended to G7 (MIDI#103)

That doesn't seem completely devoid of interest, but we can start with the older version shipped by Debian and then see if there are requests to push the newer version. That is if you yourself don't see a reason for it.

[mojca (Mojca Miklavec)]

I didn't test qsynt. I only started it on a linux box that I had at hand and had no clue what it does.

I later figured out how you did the configuration of timidity.cfg. That makes it clear, one just has to source another configuration. I'll use that next time for testing.

I wouldn't worry about anything about the font that's not in the Debian repository (unless someone complains - unlikely given that we don't currently provide any MIDI support and nobody ever complained at all). It's not worth the troubles.

[RJVB (René Bertin)]

I'm finally getting around to looking at this. It looks fine with me, but you haven't included the current version of the GeneralUser soundfont at all. Do you want to ship that as a separate port, or as a subport? It's true that it's linked only indirectly to fluid(synth), so we could ship it under a different name (gu-soundfont? generaluser-soundfont?)

I didn't test qsynt. I only started it on a linux box that I had at hand and had no clue what it does.

You have to start it with a midi file, AFAIK there currently is no way to let it open a(nother) midi file once it's running.

[RJVB (René Bertin)]

Oh, and re: ${prefix}/etc/timidity : are you patching/configuring TiMidity++ to look there for its config file?

[mojca (Mojca Miklavec)]

I included just the fonts from one website. The other package (GeneralUser GS) with the dropbox font is still to be written and I would prefer to make a separate port rather than a subport. I was hoping to get your feedback, publish this font and then do the other one. (And once we have both, continue with TiMidity.)

No, I didn't patch TiMidity. I forgot what I did, it's pretty long since I touched the ports, but I think I made symlinks and later realized that sourcing files is the way to go (without testing). And when including files I guess that one can use full path anyway. I only mentioned /etc because I saw it in Debian. We can put the files anywhere, but I would prefer to be consistent between different packages (this one, GeneralUser GS, freepats, ...). Suggestions welcome. (I basically forgot most of the stuff, but if one font needs the other, we could make a runtime dependency.)

So please let me know if you are OK with the approach of two separate ports (different authors, different names, different sources, ...) and whether you have any other suggestions about this particular package.

[RJVB (René Bertin)]

I'm fine with a separate port for the complete GeneralUser soundfont. I'd publish them both at the same time though. YMMV, but I find it gives much better sound quality in general than the soundfonts Debian provides.

I also forgot most of the details of what I did already :-/ but I had a look at my own TiMidity port. I cannot see any patch or configuration option to have it expect its config file under ${prefix}/share/timidity so for now I *presume* that's the default. We'll take that bridge when we get to it.

So please let me know if you are OK [...]

Yes. The only suggestion I have would have (which would speak for publishing both ports at once) is to integrate with the port select mechanism. I see that I have a symlink 000Default.sf2 in my soundfont directory which allows applications that use alphanumeric sorting of a selection of soundfont files to pick up a specific one as the preferred soundfont. Of course we can also do that later, when the exact need for this kind of thing becomes clear.

[mojca (Mojca Miklavec)]

Replying to RJVB:

I'm fine with a separate port for the complete GeneralUser soundfont. I'd publish them both at the same time though.

Fine with me.

YMMV, but I find it gives much better sound quality in general than the soundfonts Debian provides.

I have no clue what Debian provides, so this doesn't help me in any way :)

I also forgot most of the details of what I did already :-/ but I had a look at my own TiMidity port. I cannot see any patch or configuration option to have it expect its config file under ${prefix}/share/timidity so for now I *presume* that's the default. We'll take that bridge when we get to it.

It seems to use /opt/local/share/timidity/timidity.cfg here. I didn't test anything else.

Yes. The only suggestion I have would have (which would speak for publishing both ports at once) is to integrate with the port select mechanism.

What would be the options? If we use port select, then I don't understand what happens if none is selected. If we are talking about selecting the font for TiMidity, we could create a port timidity-config +freepats [+]fluid that would only install a single configuration file.

I see that I have a symlink 000Default.sf2 in my soundfont directory which allows applications that use alphanumeric sorting of a selection of soundfont files to pick up a specific one as the preferred soundfont.

I don't understand what this does and how it works.

[RJVB (René Bertin)]

Replying to mojca:

YMMV, but I find it gives much better sound quality in general than the soundfonts Debian provides.

I have no clue what Debian provides, so this doesn't help me in any way :)

The ones from your current port, which are the soundfonts Debian provide in their fluid-soundfont package :)

It seems to use /opt/local/share/timidity/timidity.cfg here. I didn't test anything else.

Same here.

What would be the options? If we use port select, then I don't understand what happens if none is selected. If we are talking about selecting the font for TiMidity, we could create a port timidity-config +freepats [+]fluid that would only install a single configuration file.

Just like with other ports the selection mechanism would allow to select a default soundfont from among the installed soundfonts, in such a way that you can get the soundfont you want in all situations. I think qsynth was the reason I created the symlink: it take a soundfont path, and then seems to use the file in there that comes first in standard alphanumeric sorting.

I don't understand what this does and how it works.

I'm not thinking very straight today, is the explanation above clearer?

[RJVB (René Bertin)]

my proposal for a port providing the GeneralUser GS soundfont

[mojca (Mojca Miklavec)]

The reason why livecheck doesn't work is because

curl -A "MacPorts libcurl" http://www.schristiancollins.com/generaluser.php

returns 403, most likely to drive bots away (if you remove libcurl, it works).

[RJVB (René Bertin)]

I expected something like that; something even nastier protects the dropbox location (like when there are no search permission on a directory).

So do we figure out a custom livecheck connection method (and how) or do we just use the workaround I found?

[mojca (Mojca Miklavec)]

I understand DropBox. I don't think it's worth implementing ugly workarounds to fix this.

[mojca (Mojca Miklavec)]

Other than that the port looks ok to me. I'm not sure to what extent it's ok to rename font files. And someone's idea was to change the name from "generaluser-soundfont" to "soundfont-generaluser" in line with "py-*", "qt5-*", but that's a stylistic choice. It's not like we are having lots of sound files anyway.

[RJVB (René Bertin)]

Actually, ports depending on qt5 have a -qt5 suffix. That was the consensus a while back (in part because the qtN- prefix was already used to distinguish Qt *providing* ports), and I've been adhering to that. That would be an additional argument to put the soundfont first: these are ports providing soundfonts, not ports that depend on (or provide something for) a specific soundfont. Then again the rest of the world refers to the Fluid soundfonts, or the GeneralUser soundfont, so it would only be logical that the port names reflect the natural (English)language.

Why would it not be OK to rename a font file, if it's basically just wrapping it to all lower case and removing spaces?

Is checking an archlinux site for new version availability an ugly workaround? Seems less ugly to me than getting everything from a comparable site (debian's) ;)

[mojca (Mojca Miklavec)]

Yes, soundfont at the end is more natural language.

What I meant with an ugly workaround was literally ugly patching of macports to pass a different browser id to avoid the blocking to be able to get the livecheck directly from upstream.

Livecheck from Arch is not optimal, but probably the best we can do at the moment.

[mojca (Mojca Miklavec)]

In 57625883/macports-ports:

fluid-soundfont, generaluser-soundfont: new ports

Closes: #52992

[mojca (Mojca Miklavec)]

We have some problems. The installed package seems to contain some backup files that I didn't notice earlier, but I don't understand where they come from:

x ./opt/local/share/sounds/sf2/._GeneralUser_GS_v1.47.sf2
x ./opt/local/share/sounds/sf2/GeneralUser_GS_v1.47.sf2
x ./opt/local/share/examples/generaluser-soundfont/
x ./opt/local/share/examples/generaluser-soundfont/._All Night Long.mid
x ./opt/local/share/examples/generaluser-soundfont/All Night Long.mid
x ./opt/local/share/examples/generaluser-soundfont/._GUTest.mid
x ./opt/local/share/examples/generaluser-soundfont/GUTest.mid
x ./opt/local/share/examples/generaluser-soundfont/._Take 5 - by Paul Desmond.mid
x ./opt/local/share/examples/generaluser-soundfont/Take 5 - by Paul Desmond.mid
x ./opt/local/share/examples/generaluser-soundfont/._The Christmas Song.mid
x ./opt/local/share/examples/generaluser-soundfont/The Christmas Song.mid
x ./opt/local/share/examples/generaluser-soundfont/._To Make the End of Battle.mid
x ./opt/local/share/examples/generaluser-soundfont/To Make the End of Battle.mid
x ./opt/local/share/examples/generaluser-soundfont/._earthday.mid
x ./opt/local/share/examples/generaluser-soundfont/earthday.mid
x ./opt/local/share/examples/generaluser-soundfont/._majicalljarr.mid
x ./opt/local/share/examples/generaluser-soundfont/majicalljarr.mid
x ./opt/local/share/doc/generaluser-soundfont/
x ./opt/local/share/doc/generaluser-soundfont/._CHANGELOG.txt
x ./opt/local/share/doc/generaluser-soundfont/CHANGELOG.txt
x ./opt/local/share/doc/generaluser-soundfont/._GU1.43 Percussion Map.pdf
x ./opt/local/share/doc/generaluser-soundfont/GU1.43 Percussion Map.pdf
x ./opt/local/share/doc/generaluser-soundfont/._LICENSE.txt
x ./opt/local/share/doc/generaluser-soundfont/LICENSE.txt
x ./opt/local/share/doc/generaluser-soundfont/._README.txt
x ./opt/local/share/doc/generaluser-soundfont/README.txt

[RJVB (René Bertin)]

Ah!

I do *not* get those. Did you install a binary package from the build bots or one created locally?

I think those ._ files might come from unzipping the original archive but what I don't understand is how the end up in the destroot. This is what's done during destroot:

    xinstall -m 644 "${worksrcpath}/GeneralUser GS v${version}.sf2" ${dir}/GeneralUser_GS_v${version}.sf2

    set dir ${destroot}${prefix}/share/doc/${name}
    xinstall -m 755 -d ${dir}
    foreach f {CHANGELOG.txt LICENSE.txt README.txt "instrument lists/GU1.43 Percussion Map.pdf"} {
        xinstall -m 644 "${worksrcpath}/${f}" ${dir}
    }

    set dir ${destroot}${prefix}/share/examples/${name}
    xinstall -m 755 -d ${dir}
    xinstall -m 644 "${worksrcpath}/GUTest.mid" ${dir}
    foreach f [glob -nocomplain "${worksrcpath}/demo MIDIs/*"] {
        xinstall -m 644 "${f}" ${dir}
    }

Even if unzipping the archive creates those ._ files we shouldn't be copying them into the destroot.

Mojca, is your ${workpath} on an HFS filesystem? You'd be seeing this kind of behaviour if you're using a FAT32 system, for instance.

[mojca (Mojca Miklavec)]

No, I'm not using any FAT32 system. I'm not sure if it came from a local build or from a server because that depends on whether the package was already built on the server at the time when I experienced this problem. But I'm currently unable to reproduce it, so let's forget about it.