BSynth upgrade

[Pete]

Here is a patch that puts back a couple of features that were in BeOS but missing from Haiku, and also improves the way it finds the necessary default Soundfont.

As originally written, BSynth inherited the BeOS/Beatnik naming of the instruments file, as "big_synth.sy". This is confusing because a soundfont, as used by the Haiku version has the standard extension ".sf2", and the old name referred to a proprietary BAE-format file. Also, in BeOS, the file was in the system area, because it was a component of the distributed system. The Haiku version inherited this convention and looks for the file in the system data directory.

However, a soundfont is not currently in the distributed system, and a user has to choose an appropriate font to download and install. In fact there are many choices, and the user may want to acquire several of them to be accessed at choice. So the system area, with all its protections against alteration, is not the most convenient place to put them.

With this patch, BSynth will look in a number of "synth" folders for "synth.sf2", which will usually be a link to the actual soundfont (which can be in the same folder or anywhere else convenient).

It looks first for "<B_USER_SETTINGS_DIRECTORY>/synth/synth.sf2". If that isn't found it tries "synth/synth.sf2" in <B_USER_DATA_DIRECTORY>, and then the same in <B_COMMON_DATA_DIRECTORY>. If all those fail, it still falls back to the old "<B_SYSTEM_DATA_DIRECTORY>/synth/big_synth.sy", in case the user has an earlier unchanged installation.

Note that any entry in the settings directory is expected to be a "setting" -- a link created by the user to designate the desired default soundfont. At the moment this must be done directly, but a Preferences app might be useful at some point.

The header MidiDefs.h has a new "#define B_SYNTH_FILE "synth/synth.sf2", and redefines B_SYNTH_DIRECTORY to B_COMMON_DATA_DIRECTORY.

The restored features are SetReverb and GetAudio.

The reverb settings try to match the old BeOS levels ("None" to "Dungeon") with fluidsynth equivalents. I'm not sure how close they are, as my BeOS machine no longer has audio for comparison.

GetAudio is probably similar to the way it was in BeOS. It is not an 'audio tap' that duplicates the audio stream; it simply grabs the current buffer contents (or less, depending on the request) and delivers the left and right parts. MidiPlayer's Scope is now appropriately active, anyway.

[Pete]

Enhancement patch to BSynth

[korli]

Just a question, why do you combine these two changes in one patch? They would definitely be easier to understand and more appropriate when done with more than one commit.

[Pete]

Replying to korli:

Just a question, why do you combine these two changes in one patch? They would definitely be easier to understand and more appropriate when done with more than one commit.

Somewhat unfamiliar with the process, I guess. I did all the work as a single effort, tested it all, and then committed it. In fact, I thought it would be more convenient as a unit. Sorry if that is not preferred.

[pulkomandy]

The reverb settings array should be "static const". Also, you could remove the first dummy entry and access it with "mode - 1" as an index instead, making the final binary 4*sizeof(float) smaller.

And, yes, splitting the patch in two would make it easier for us to locate the different changes and understand what's going on.

[jackburton]

I'd like to apply those changes, but I see the patch still references /boot/common which is no longer available. Moreover, I read the mailing list thread where Pete describes the problems created by the Package Management regarding the soundfont. I guess the first thing to do is to make it possible to install the SoundFont correctly so the rest can be tested.

[Pete]

[Now you know why I was peeved at some of the PM decisions made (:-/)]

I'm afraid also I got severely unmotivated by all the (IMO) unneccesary makework that people seemed to want me to do to get the soundfont package available. I got as far as making a usable hpkg for the font, though, which for now I've made available for download at ​http://goodeveca.net/haiku/timgmsoundfont-2011_12_11-5-any.hpkg

The scheme I adopted there, which I think is right for the current organization, is to add a /boot/system/settings/synth directory that contains a link 'system.sf2' to the user's desired system default soundfont. (The package installs the TimGM soundfont in /boot/system/data/synth, and points the user link to that. It also continues to link the old big_synth.sy, so that older libraries will still work.)

B_SYNTH_DIRECTORY would revert to /boot/system/data/synth for now, but it seems to me a rather useless definition anyway, and should be deprecated. 'big_synth.sy' should definitely be deprecated, but should remain as a link for the moment.

My original search chain can probably be drastically simplified. In fact it may only really need to look at /boot/system/settings/synth/system.sf2. Eventually (as others have suggested too) I think there should be a Preferences setting -- probably in Media -- to directly specify an arbitrary soundfont. This perhaps could just set system.sf2, so the synth wouldn't need any further changes.

[jackburton]

Thank you. Did you write a recipe for it, by chance ? Otherwise, I'll try to do that myself.

[jackburton]

Nevermind, I'll just modify the existing haikuports recipe. I think I'll proceed like this:

1. Modify the haikuports recipe to create the global writable link in /home/config/settings
2. Update the midi kit code to look for the synth first in /home/config/settings/synth/system.sf2 and as a fallback

in /system/data/synth/big_synth.sy so that you can replace the system font just by changing the link.

3. update the modified soundfont and upload it somewhere (haikufiles ?), modify the recipe to point at this new location.

Actually point 3 could be done first.

4. (but I won't do that, at least not in the foreseeable future) Create a midi preflet, or integrate it in the media preflet, to be able to choose a given soundfont.

[bonefish]

Please omit 1. If you do 2., it is not necessary, and packages shouldn't mess with the user settings anyway.

[jackburton]

Replying to bonefish:

Please omit 1. If you do 2., it is not necessary, and packages shouldn't mess with the user settings anyway.

You're right, and in fact, while I started doing (2) I thought about this a bit more, and realized this by myself. By the way, I find the symbolic link stuff not so nice, what about this instead: BSoftSynth looks for a settings file like /home/config/settings/synth which contains the path/name of the synth file ? Well, yeah it works just like a symbolic link, but somehow I find it nicer. Opinions ?

[bonefish]

If external software needs to find the file as well, a symlink would probably be easier. OTOH an API to get the path would be even better. If other settings might be added in the future, a settings file would be preferable IMO.

[jackburton]

I went for the simpler solution for now (a symlink or file in /home/config/settings) in hrev47887.

[jackburton]

I also applied the reverb part of the patch in hrev47888. What's missing is the GetAudio part.

[Pete]

Sorry I wasn't around during your earlier postings, but there are still a few points arising.

I think the time to retire big_synth.sy is now. It is a horribly inappropriate name now that we're using soundfonts rather than Headspace files. And with /boot/system/data/synth being PM, the only way it could appear there is via the current timgmsoundfont.hpkg. That can be updated in a hurry. I suppose big_synth.sy could be left there just in case anybody is using the current package, but the synth should first look for /boot/system/data/synth/synth.sf2. I'd prefer to dump it right now, and let affected users install a revised package.

I would somewhat prefer to have a subdirectory 'synth' in settings, as I think it's clearer to the user. Also it would provide a home for any future settings we might think of. Maybe "synth.sf2" is specific enough, though.

Why do you prefer B_USER_SETTINGS_DIRECTORY over B_SYSTEM_SETTINGS_DIRECTORY? I rather considered the system default soundfont to belong in the latter. Would be good, actually, to have both, I guess (thinking ahead to multi-user, or even if the user wanted to replace the default temporarily, without messing with the system link).

[Pete]

Replying to jackburton:

I also applied the reverb part of the patch in hrev47888. What's missing is the GetAudio part.

Thanks, but why did you omit the latter? It seemed to work quite well in my patch, and it prevents the window in MidiPlayer being annoyingly inactive...

[jackburton]

Replying to Pete:

Replying to jackburton:

I also applied the reverb part of the patch in hrev47888. What's missing is the GetAudio part.

Thanks, but why did you omit the latter? It seemed to work quite well in my patch, and it prevents the window in MidiPlayer being annoyingly inactive...

Just a matter of missing time, and doing one thing at a time. Since I had to apply the patch manually, I wanted to break down things at the minimum level. I'm applying that part now.

[jackburton]

Replying to Pete:

Sorry I wasn't around during your earlier postings, but there are still a few points arising.

I think the time to retire big_synth.sy is now. It is a horribly inappropriate name now that we're using soundfonts rather than Headspace files. And with /boot/system/data/synth being PM, the only way it could appear there is via the current timgmsoundfont.hpkg. That can be updated in a hurry. I suppose big_synth.sy could be left there just in case anybody is using the current package, but the synth should first look for /boot/system/data/synth/synth.sf2. I'd prefer to dump it right now, and let affected users install a revised package.

Ok. The only problem I see is that B_BIG_SYNTH_FILE is a public define and is "/synth/big_synth.sy". Changing that will break binary compatibility with applications which open the synth file by their own (are there any?). I'm all for changing it, but I'd still like to know the implications. Moreover, I'd guess we should also add a B_NONPACKAGED_SYNTH_DIRECTORY where to put the "user" synth files.

I would somewhat prefer to have a subdirectory 'synth' in settings, as I think it's clearer to the user. Also it would provide a home for any future settings we might think of. Maybe "synth.sf2" is specific enough, though.

Done.

Why do you prefer B_USER_SETTINGS_DIRECTORY over B_SYSTEM_SETTINGS_DIRECTORY? I rather considered the system default soundfont to belong in the latter. Would be good, actually, to have both, I guess (thinking ahead to multi-user, or even if the user wanted to replace the default temporarily, without messing with the system link).

The system soundfont is currently retrievable via big_synth.sy (or whatever we'll call that one). If the user installs a new soundfont (system-wide) the big_synth.sy symlink would point at the new soundfont. If we drop that one, we should definitely look into B_SYSTEM_SETTINGS_DIRECTORY (but only after B_USER_SETTINGS_DIRECTORY).

[jackburton]

Replying to jackburton:

Replying to Pete:

Replying to jackburton:

I also applied the reverb part of the patch in hrev47888. What's missing is the GetAudio part.

Thanks, but why did you omit the latter? It seemed to work quite well in my patch, and it prevents the window in MidiPlayer being annoyingly inactive...

Just a matter of missing time, and doing one thing at a time. Since I had to apply the patch manually, I wanted to break down things at the minimum level. I'm applying that part now.

By the way, I just noticed that the GetAudio part breaks binary compatibility, as you are adding some class members (so changing the class size). Since there are no reserved items to be used, we can't do that.

[jackburton]

Replying to jackburton:

I also applied the reverb part of the patch in hrev47888. What's missing is the GetAudio

By the way, I just noticed that the GetAudio part breaks binary compatibility, as you are adding some class members (so changing the class size). Since there are no reserved items to be used, we can't do that.

Nevermind, BSoftSynth isn't public, luckily.

[jackburton]

About the GetAudio part: From what I see, playsound can be called multiple times. If so, there is a memory leak, since we allocate memory and assign it to fMonitor without deleting it first. Would be okay to call delete[] on it first ? Moreover, we write the data as floats and then we read it as int16s in BSynth::GetAudio(). Is it okay ?

[jackburton]

I've committed your patch in hrev47893 (with the memory leak removed). I've only tested playing a midi file in MidiPlayer under VirtualBox. Doesn't seem to crash, at least. Please test and let's close this ticket.

[Pete]

Many thanks for doing all that. Sorry about the memory leak! (:-/) I'll test as soon as I get a chance.

(BTW, I forgot to mention that Tim Brechbill, the author of the soundfont, supposedly has my fixed version now, but he hasn't put it up for download yet. I'm hesitant to bug him, but if he makes it available having an archive location of our own is less important.)

[Pete]

Unfortunately, I invariably get an exception (in GetAudio naturally (:-/) when I try to play any file in MidiPlayer.

This is with a recompile of your code. hrev47893 is noi in the nightlies yet, and I don't have a current git tree to update, so I used my pre-PM tree (as the midi library hasn't otherwise changed since then). I get the crash in both my matching pre-PM system, and my PM one. (My version -- with the leak -- doesn't crash.)

I'll eyeball the code and see if I can see the problem, but I'm not sure how to enable source in the debugger for library code.

[anevilyak]

Replying to Pete:

I'll eyeball the code and see if I can see the problem, but I'm not sure how to enable source in the debugger for library code.

In order to do that, you'd need to build a debug version of the corresponding library, and put it in ./lib from wherever you're running your MidiPlayer executable from (or in some other location that's in LIBRARY_PATH before system/lib)

[Pete]

Replying to anevilyak:

Replying to Pete:

I'll eyeball the code and see if I can see the problem, but I'm not sure how to enable source in the debugger for library code.

In order to do that, you'd need to build a debug version of the corresponding library,

Sorry to be an ignoramus, but I just haven't grokked jam yet. How do I tell it to make a debug version?

[Pete]

Replying to jackburton:

About the GetAudio part: From what I see, playsound can be called multiple times. If so, there is a memory leak, since we allocate memory and assign it to fMonitor without deleting it first. Would be okay to call delete[] on it first ? Moreover, we write the data as floats and then we read it as int16s in BSynth::GetAudio(). Is it okay ?

Actually looking at my original code, I don't see a leak... Maybe I'm looking at things wrong, but I only create the fMonitor buffer if it doesn't exist. All further calls to PlayBuffer use that. It then gets deleted when BSynth finally goes away. (I'm not sure if it's possible for 'size' to vary, but it doesn't matter if it does because any attempt to transfer sommething larger just gets clipped; smaller just leaves a hole. For the crude purposes of GetAudio, we don't care.) And deleting and creating the buffer each time must slow things down quite a bit.

I think your code is crashing due to a race condition. GetAudio can get invoked just when fMonitor has been deleted.

Check my logic, but I think it's OK to use my code.

[jackburton]

Replying to Pete:

Replying to jackburton:

Actually looking at my original code, I don't see a leak... Maybe I'm looking at things wrong, but I only create the fMonitor buffer if it doesn't exist. All further calls to PlayBuffer use that. It then gets deleted when BSynth finally goes away. (I'm not sure if it's possible for 'size' to vary, but it doesn't matter if it does because any attempt to transfer sommething larger just gets clipped; smaller just leaves a hole. For the crude purposes of GetAudio, we don't care.) And deleting and creating the buffer each time must slow things down quite a bit.

You're right, there wasn't a memory leak. But size could vary, and I don't know if it does, too. Anyway, since your code didn't contain a memory leak, I'll revert to using it directly, especially because it doesn't crash :)

I think your code is crashing due to a race condition. GetAudio can get invoked just when fMonitor has been deleted.

If this kind of race condition exists, I guess we should use locking to protect these variables.

[Pete]

Replying to jackburton:

Replying to Pete:

I think your code is crashing due to a race condition. GetAudio can get invoked just when fMonitor has been deleted.

If this kind of race condition exists, I guess we should use locking to protect these variables.

No, locking shouldn't be needed here. GetAudio won't try to read fMonitor until it has been created, and once it has it won't be deleted until the synth has stopped. It doesn't matter what data is there, as long as there's something.

BTW, could you [just for me...(:-)] add a B_SYSTEM_SETTINGS_DIRECTORY check after the B_USER_SETTINGS_DIRECTORY one, and also check for synth.sf2 in B_SYNTH_DIRECTORY just before finally devolving to big_synth.sy.

As far as I can see, though, the only old BeOS app that might be able to use big_synth.sy in Haiku is MidiSynth1.7. However, it does things "cleverly", looking in B_SYNTH_DIRECTORY for a list of whatever's there, so it doesn't need it. Everything else I've found that might want it can't find it in Haiku anyway (hard-coded probably, but I don't have the sources). So I think it could be removed now without anyone being bothered.

[Pete]

I just noticed another stupid... Not anyone's fault - except History's (and maybe an unknown Be engineer).

B_SYNTH_DIRECTORY is not one of those in FindDirectory.h. It is an equate in MidiDefs.h. In BeOS it was equated to B_BEOS_ETC_DIRECTORY, and in Haiku it had to be switched to B_SYSTEM_DATA_DIRECTORY. So anything written "correctly" and compiled for BeOS won't run in Haiku anyway (though probably will if recompiled. (I remember that I in fact recompiled MidiSynth1.7, so not surprising it works!)

B_SYNTH_DIRECTORY doesn't even match the other definitions. B_USER_SETTINGS refers to a ".../settings" directory and so on, but B_SYNTH_DIRECTORY refers to the parent, so you always have to insert your own "/synth". I think this should also be deprecated strongly. It should not be used in Haiku code.

[jackburton]

Replying to Pete:

Replying to jackburton:

Replying to Pete:

I think your code is crashing due to a race condition. GetAudio can get invoked just when fMonitor has been deleted.

If this kind of race condition exists, I guess we should use locking to protect these variables.

No, locking shouldn't be needed here. GetAudio won't try to read fMonitor until it has been created, and once it has it won't be deleted until the synth has stopped. It doesn't matter what data is there, as long as there's something.

Doesn't look like a so useful function then :-) Seriously... the only use we have for it in the tree (for now) is the MIDI Player scope ?

BTW, could you [just for me...(:-)] add a B_SYSTEM_SETTINGS_DIRECTORY check after the B_USER_SETTINGS_DIRECTORY one, and also check for synth.sf2 in B_SYNTH_DIRECTORY just before finally devolving to big_synth.sy.

Done in hrev47897

As far as I can see, though, the only old BeOS app that might be able to use big_synth.sy in Haiku is MidiSynth1.7. However, it does things "cleverly", looking in B_SYNTH_DIRECTORY for a list of whatever's there, so it doesn't need it. Everything else I've found that might want it can't find it in Haiku anyway (hard-coded probably, but I don't have the sources). So I think it could be removed now without anyone being bothered.

Ok. I have another question. Let's say we drop big_synth.sy, and prepare a set of packages containing different soundfonts, and the user picks and installs one of them, or more than one. How would you select the "default" soundfont in that case ? Meaning before the user has configured its preferred soundfont via symlink or via the not-yet-done midi preflet ? Should we just pick a random one ?

[Pete]

Replying to jackburton:

Replying to Pete: Doesn't look like a so useful function then :-) Seriously... the only use we have for it in the tree (for now) is the MIDI Player scope ?

Pretty much... (:-/) I can't prove it, but I think it works pretty much like the BeOS version did. The BeBook says: "This function is designed to feed waveform displays (and the like); it isn't intended to be used as a "sound spigot" that you can pipe to a file (for example)." I gather the idea was just to give some indication of the data flowing through. That's why I don't want it to be more processing-intensive than necessary.

BTW, could you [just for me...(:-)] add a B_SYSTEM_SETTINGS_DIRECTORY check after the B_USER_SETTINGS_DIRECTORY one, and also check for synth.sf2 in B_SYNTH_DIRECTORY just before finally devolving to big_synth.sy.

Done in hrev47897

Many thanks.

Ok. I have another question. Let's say we drop big_synth.sy, and prepare a set of packages containing different soundfonts, and the user picks and installs one of them, or more than one. How would you select the "default" soundfont in that case ? Meaning before the user has configured its preferred soundfont via symlink or via the not-yet-done midi preflet ? Should we just pick a random one ?

Good question... I don't think anybody has thought about this very hard! Actually I've never been particularly keen on the idea of a "system" synth directory. Seems to me its only use is if you have a single system soundfont. If you want to give the user a choice, there is very little point to it at all; if you provide a way of letting the synth know where it is (via a link in /boot/system/settings/synth) or whatever) the font can be anywhere.

If you are going to have a system directory with several fonts in it, I would assume the last font loaded would change the synth.sf2 link (in that folder) to point to it. If the user wants another, they would change the link in /boot/system/settings/synth. (If you look at the hpkg I made, it sets the boot/system/settings/synth, but with the keep-old flag, so that it doesn't mess with user preference.)

As I mentioned previously. probably the only current app that might make use of it is MidiSynth, which builds a menu from everything in B_SYNTH_DIRECTORY/synth, so you can pick. OTOH if your font is anywhere else, it can't get to it. In my MusicWeaver Synth module I just let the user drag whatever font he wants into the control panel (or find it via FIlePanel).

[Pete]

OK, after thinking about it a while, I'm going to state my opinions a bit more forcibly. It might even classify as a rant. (:-))

I submit that packaging Soundfonts in hpkgs is completely wrong-headed. They are just (single) files, for gosh sakes, and one of the nice things about Haiku has been its flexibility. There are lots of superb sf2s downloadable from the web, and to force them to have to be made into packages so they can be unpacked into a system folder is just ridiculous. Again the only possible rationale is for a standard system soundfont available from the repository. We don't need more than one of these. The user should just be able to download another from wherever it can be found (as I have done many times), and be able to make it available to the synth. (And of course this is just what the settings link allows.)

Before PM there was probably a reasonable use for /boot/system/data/synth, as the user could at least change the big_synth.sy link. But now it should have just one use -- to hold the standard default font, and make it easy for the new user to install. There is no point in packaging others to go in there too. It's needless work, and restricting.

That's the way I see it, anyway.

[pulkomandy]

I don't see any difference between sound-fonts and truetype fonts (hence the name ;)) and I think they should work the same way. We have some fonts packaged in our repos because it is a convenient way to install them, and because some other apps may depend on them. But, there should also be support for non-packaged fonts in /boot/system/non-packaged/data.

Apps can use the new BPathFinder API to look for font files in all relevant directories, and ideally each app would allow picking a custom soudfont file. That part will work ok once apps are updated to use BPathFinder, but it leaves us with two problems:

• Legacy apps won't use BPathFinder (this is a new API introduced with package managemet), and even worse, they may still use the hardcoded B_SYNTH_DIRECTORY. We should make sure there is a symlink to a soundfont at the expected place there. Any soundfont will do, this is legacy support only and does not need to be configurable. The default soundfont package can provide the symlink.
• We still want a "no-brainer" way to play MIDI files for example in MidiPlayer without the need for configuring anything. This can be made configurable with a settings file, symlink, preference panel or whatever; but there must still be a fallback so that you can play MIDI files on a fresh Haiku install. For this, we need at least one packaged soundfont on which the Haiku package can depend, and we need a default value in the settings file or in BSynth, so the default sound font is used when the settings file is missing.

[jackburton]

Replying to pulkomandy:

I don't see any difference between sound-fonts and truetype fonts (hence the name ;)) and I think they should work the same way. We have some fonts packaged in our repos because it is a convenient way to install them, and because some other apps may depend on them. But, there should also be support for non-packaged fonts in /boot/system/non-packaged/data.

I agree with you.

(about the default soundfont and the need for legacy apps to find soundfonts)

There is already such mechanism in place, since BeOS. BSoftSynth will load a "Default" soundfont on creation, already. The way the default soundfont is selected is an implementation detail. Currently, we inherited from BeOS the need to create a symlink called big_synth.sy. What I have in mind is this:

Like fonts, or any other kind of data, there will be four places where soundfonts could be placed: /boot/system/data/synth /boot/system/non-packaged/data/synth /home/config/data/synth /home/config/non-packaged/data/synth

The midi preflet (or the view in the media preflet) which I already started writing will present a list of the soundfonts found in those directories, plus (if needed, I don't have a strong opinion on this, but I guess it could be handy) an "Import Soundfont" button, to be able to choose a soundfont from any location, which will be then copied into /home/config/non-packaged/data/synth. The user could then choose the preferred soundfont, and the preflet will write a setting file into /home/config/settings. BSoftSynth will parse this setting file and load the user selected font. If the file is not present, it will load the system settings file (if present). Otherwise it will load a "default" system soundfont. How the "default" system soundfont (the one loaded when there is no settings" could be determined by a symbolic link in /boot/system/data/synth. This is what big_synth.sy does now. Since it doesn't seem to be used anywhere, I'd even rename this to"default.sf2". This link would be created by the soundfont packages. The last installed soundfont could owerwrite the default preference, or could leave it untouched, I don't know.

[bonefish]

Replying to jackburton:

The midi preflet (or the view in the media preflet) which I already started writing will present a list of the soundfonts found in those directories, plus (if needed, I don't have a strong opinion on this, but I guess it could be handy) an "Import Soundfont" button, to be able to choose a soundfont from any location, which will be then copied into /home/config/non-packaged/data/synth. The user could then choose the preferred soundfont, and the preflet will write a setting file into /home/config/settings. BSoftSynth will parse this setting file and load the user selected font. If the file is not present, it will load the system settings file (if present). Otherwise it will load a "default" system soundfont. How the "default" system soundfont (the one loaded when there is no settings" could be determined by a symbolic link in /boot/system/data/synth. This is what big_synth.sy does now. Since it doesn't seem to be used anywhere, I'd even rename this to"default.sf2". This link would be created by the soundfont packages. The last installed soundfont could owerwrite the default preference, or could leave it untouched, I don't know.

No, please. In the same way installing a font shouldn't change any global setting, installing a sound font shouldn't do that either. If no one uses the global system sound font symlink anyway, let's just omit it. A per-user setting suffices. If there isn't a user setting yet, just use some heuristic to pick one. If we provide TimSoundFont by default with Haiku, then try that one first. If it isn't there, use the oldest one, the one with the funniest name, or simply first one found in any sound font directory. At that point write the setting, so it remains stable until the user chooses a new one (or uninstalls the selected one).

[jackburton]

Replying to bonefish:

No, please. In the same way installing a font shouldn't change any global setting, installing a sound font shouldn't do that either. If no one uses the global system sound font symlink anyway, let's just omit it. A per-user setting suffices. If there isn't a user setting yet, just use some heuristic to pick one. If we provide TimSoundFont by default with Haiku, then try that one first. If it isn't there, use the oldest one, the one with the funniest name, or simply first one found in any sound font directory. At that point write the setting, so it remains stable until the user chooses a new one (or uninstalls the selected one).

Fine by me, I don't have a strong opinion on that, and it seems reasonable, anyway.

[Pete]

Replying to bonefish:

Replying to jackburton:

The midi preflet (or the view in the media preflet) which I already started writing will present a list of the soundfonts found in those directories, plus (if needed, I don't have a strong opinion on this, but I guess it could be handy) an "Import Soundfont" button, to be able to choose a soundfont from any location, which will be then copied into /home/config/non-packaged/data/synth.

Please -- a link, not a copy. Soundfonts tend to be big!

How the "default" system soundfont (the one loaded when there is no settings" could be determined by a symbolic link in /boot/system/data/synth. This is what big_synth.sy does now. Since it doesn't seem to be used anywhere, I'd even rename this to"default.sf2". This link would be created by the soundfont packages. The last installed soundfont could owerwrite the default preference, or could leave it untouched, I don't know.

No, please. In the same way installing a font shouldn't change any global setting, installing a sound font shouldn't do that either.

But the way I read it, this is not what's being suggested. The link being set is just a standard name in the same /boot/system/data/synth directory to point to the one soundfont in that directory. There is essentially no point in having more than one font there, because that's just the ultimate default. I see the only use for that directory is as a fallback if no user selection has been made. There might eventually be a choice of packaged system soundfonts from the repository, but the user would just replace the one with another, and the link would get replaced, too.

It's true that if there is just one font present, the synth could just pick that, but the link is convenient.

[Pete]

BTW, soundfonts should have a mimetype. Can't find an existing one, so I guess we're free to invent it. "audio/x-soundfont"?

[jackburton]

Replying to Pete:

Replying to bonefish:

Replying to jackburton:

The midi preflet (or the view in the media preflet) which I already started writing will present a list of the soundfonts found in those directories, plus (if needed, I don't have a strong opinion on this, but I guess it could be handy) an "Import Soundfont" button, to be able to choose a soundfont from any location, which will be then copied into /home/config/non-packaged/data/synth.

Please -- a link, not a copy. Soundfonts tend to be big!

IMHO an "Import SoundFont" Button which creates a link would create some really bad user experience. Imagine the user that has just downloaded a 256MB Soundfont into the "Download" folder. He then proceeds to "Import" the soundfont with the preflet. He then proceeds to delete the downloaded soundfont, since it has been imported already. The link would then be broken. At that point, I'd avoid putting the "Import Soundfont" button and leave the user on his own, if it could create these kinds of issues.

[bonefish]

Replying to Pete:

But the way I read it, this is not what's being suggested. The link being set is just a standard name in the same /boot/system/data/synth directory to point to the one soundfont in that directory. There is essentially no point in having more than one font there, because that's just the ultimate default. I see the only use for that directory is as a fallback if no user selection has been made. There might eventually be a choice of packaged system soundfonts from the repository, but the user would just replace the one with another, and the link would get replaced, too.

I was under the impression that there are (or can be) applications that work with multiple sound fonts or there's at least a use case that a user may switch between multiple installed sound fonts on a somewhat regular basis. If that is not the case and having only a single sound font installed is the only thing that makes sense, I would already declare that as conflicts at the package level, so that installing a sound fount would automatically uninstall the previous one. In that case a symlink with a well-known name in data/synth is an option. Or the sound font file could simply be named like this in the first place.

Replying to jackburton:

IMHO an "Import SoundFont" Button which creates a link would create some really bad user experience.

[...]

At that point, I'd avoid putting the "Import Soundfont" button and leave the user on his own, if it could create these kinds of issues.

Agreed, creating a symlink as the import action isn't a good solution. The file should simply be moved, if an import action was implemented at all. There was a recent discussion about how to deal with importing fonts. I don't recall the outcome, but I think we should handle both similarly.

[jackburton]

Replying to Pete:

BTW, soundfonts should have a mimetype. Can't find an existing one, so I guess we're free to invent it. "audio/x-soundfont"?

I only found this: ​http://www.filesuffix.com/it/extension/sf2 I'm not sure we can invent new one, though.

[Pete]

Replying to jackburton:

Replying to Pete:

IMHO an "Import SoundFont" Button which creates a link would create some really bad user experience. At that point, I'd avoid putting the "Import Soundfont" button and leave the user on his own, if it could create these kinds of issues.

On reflection, you're right. An "Import" button is not useful. Clearer and cleaner to let the user populate non-packaged/data/synth as they desire, and have your preflet scan that (and the other relevant directories) to list the available set.

[Pete]

Replying to bonefish:

I was under the impression that there are (or can be) applications that work with multiple sound fonts or there's at least a use case that a user may switch between multiple installed sound fonts on a somewhat regular basis. If that is not the case and having only a single sound font installed is the only thing that makes sense, I would already declare that as conflicts at the package level, so that installing a sound fount would automatically uninstall the previous one. In that case a symlink with a well-known name in data/synth is an option. Or the sound font file could simply be named like this in the first place.

From my experience there are likely to be two main ways soundfonts will be used.

There's the user who just wants to play Midifiles, so he just wants a font that "sounds good". "Sounding good" may well be a matter of personal choice, but once found that will be the standard one to use in future. It will necessarily be a GM (or better) set of instruments.

Then there are the "specialist" fonts that provide some sort of custom sound, like the "Might wurlitzer" and "Vintage Synth" packs that I found. In general these bear no relation to GM, so aren't much use for playing standard Midifiles. OTOH, I like to plug them into the MusicWeaver Synth module (which is independent of BSynth, BTW; it connects straight to fluidsynth), for some "interesting" live playing. They are so unrelated to BSynth requirements that I don't think they need to be bothered with in this context. Perhaps best to keep them out of the .../data/synth directories entirely.

For the BSynth system font, I think any of your suggestions would be fine.

[Pete]

Replying to jackburton:

Replying to Pete:

BTW, soundfonts should have a mimetype. Can't find an existing one, so I guess we're free to invent it. "audio/x-soundfont"?

I only found this: ​http://www.filesuffix.com/it/extension/sf2

I see they just fall back to application/octet-stream, which is hardly useful.

I'm not sure we can invent new one, though.

From my uderstanding, it's perfectly OK to invent a mimetype for local use, as long as it uses the "x-" prefix. We can add it to our local set without offending anyone else.

After that, though, comes the icon... (:-/) At the moment I'm blank on what that should look like.

[jackburton]

Implemented in hrev47887 and later commits.