Add soundfont selection option

[nuk380y]

It would be really cool to be able to set a specific soundfont for (a) an individual score, or (b) in a dotfile as a global configuration. This would allow for composers to switch soundfonts at will.

[daveyarwood]

This is a cool idea!

Back in the early days of Alda, I actually did something like this, but without the soundfont to use being configurable. The FluidR3 soundfont was included with Alda as a resource file, and Alda loaded the soundfont at runtime every time you played a score.

I ended up removing that feature mostly because I didn't want to force anybody to use any particular soundfont, but making it configurable would solve the same problem.

I think there are some obstacles, but I'm willing to consider doing this. The obstacles include:

• The player processes are spawned asynchronously (separate from the client), so we would need to have the client (optionally) communicate to the player process the path to the soundfont to use, and then the player could load the soundfont right before playing the score.

  • The client could do this in response to recognizing some directive in the score like (soundfont "/path/to/some/soundfont.sf2")

• It takes some time to load a soundfont, though, so it would be better to load the soundfont ahead of time if possible. Perhaps in addition to being able to tell the player "at runtime" (i.e. right before playing the score) to load a soundfont, there could also be a way to automatically have every player process load a particular soundfont on startup.

  • The global config option could be a way to do that. When the global config option (a path to some soundfont) is present, then when a player process starts, it will load that soundfont, otherwise it will use the system default soundfont like it's doing now.
  • This is effectively not much different from what you can do now manually (see these instructions in the Alda README), but it would provide a friendlier experience for newcomers. Editing a config file is a lot easier than what is described in those instructions.

I'm currently busy rewriting Alda from the ground up (Alda v2), but if somebody is interested in contributing these features, I'd be happy to discuss the technical approach. We would want to do it in the v2 branch, where the client is written in Go and the player is written in Kotlin.