search

tim-janik / anklang

MIDI and Audio Synthesizer and Composer
https://anklang.testbit.eu/
Mozilla Public License 2.0
51 stars 3 forks source link

Implement Downloader for Samples #25

Open swesterfeld opened 7 months ago

swesterfeld commented 7 months ago

Once we have support for playing samples via liquidsfz PR #7, we could implement making some content easily accessible for users. The idea would be that the user could download sample packs in our UI, and we would simply use curl (or something), download and extract the stuff for the user.

Here are some suggestions for content:

There is probably a lot more if we actively search for it. Content that can be automatically downloaded (or is bundled directly - we could also do this for a subset of the content) can be used in demo songs or presets that we ship. We should of course be careful to check that the licensing is really solid for everything we make easily accessible.

tim-janik commented 7 months ago

Yes, indeed, here some collection links for instance:

https://versilian-studios.com/vsco-community/ https://archive.org/details/SalamanderGrandPianoV3 https://archive.org/search?query=subject%3A%22sfz%22 https://musical-artifacts.com/artifacts?formats=sfz&order=most_downloaded

Often, SFZ files are intermixed with SF2 files however, I think it'd make sense to also support SF2 via FluidSynth.

tim-janik commented 5 months ago

Once we have support for playing samples via liquidsfz PR #7, we could implement making some content easily accessible for users. The idea would be that the user could download sample packs in our UI, and we would simply use curl (or something), download and extract the stuff for the user.

Can you provide a few more details, in particular:

swesterfeld commented 5 months ago
  • How does the user trigger downloads?

This may be relevant (how Ardour does it): https://www.youtube.com/watch?v=BmePT0kZ4pM Also how Hydrogen does it is explained here: https://www.youtube.com/watch?v=yQLEyMD0P04

In general I think a menu entry would be ok, that shows some kind of dialog to be able to select between different sample collections (like "Basic Drum Kits", "Salamander Grand Piano", "AVL Drum Kits",...) which can be installed and removed. This should also clearly indicate the Copyright owner(s) an license(s) for the content.

  • Should there be some kind of download location list to choose from?

I don't think so. We could simply put our stuff to some location that is always expected to be available (like a github release) and leave it at that.

  • Should there be automatic updates or notifications once content changes?

That would be nice to have, but not required in the first implementation. Also content changes can only add to the library, not really change existing content, in order to main compatibility with existing projects.

  • Where exactly should the downloaded content be stored (what directory)?

It should be configurable, but have a reasonable default. Here is what others do:

Personally I'd prefer ~/.Anklang, but I also know that people tend to not like dot dirs in their home; but if its configurable that probably would not be too bad.

  • What about sharing sample libraries with other users? Should we simply look in some standard locations (like Debian SF2 installation locations or so) and leave it at that?

Yes. We may want to be smart enough (as in hashing our expected content) to for instance detect if the user already has a SF2 in a standard location available and if not, download it for the user. That way, projects shared between multiple computer could rely on having that SF2 (mainly Fluid R3) always available, even if their distro/OS doesn't have it.

tim-janik commented 5 months ago
  • Where exactly should the downloaded content be stored (what directory)?

It should be configurable, but have a reasonable default. Here is what others do:

* Ardour uses subdirs in `~/.local/share/sounds` for its downloaded sample packs

* Bitwig uses a subdir of `~/.BitwigStudio/installed-packages`

* Hydrogen uses `~/.hydrogen/data/drumkits/`

Personally I'd prefer ~/.Anklang, but I also know that people tend to not like dot dirs in their home; but if its configurable that probably would not be too bad.

I don't think mixing XDG dirs and ~/.APP is a good idea. An app should either use ~/.APP or follow the XDG spec, and if the latter do it completely. Since we already try to follow the XDG spec...

If my interpretation is correct, we should probably use $XDG_DATA_HOME/anklang/samples, which should translate by default into $HOME/.local/share/anklang/samples/ (a bit too deep for my personal taste). Related, for dir in $XDG_DATA_DIRS: dir + "/anklang/samples" seems to be the locations that we should look for before downloading content (probably in combination with hashing as you said).

Can you second that, or did I misunderstand and XDG pieces here? (As for "configurable", following XDG means users have the ability to adjust $XDG_DATA_HOME...)

swesterfeld commented 5 months ago

If my interpretation is correct, we should probably use $XDG_DATA_HOME/anklang/samples

Yes, I think that is ok. I was worried at first a bit for putting too much data to a default location where the user can't see it, but my ~/.local/share/Steam/ is 14Gb in size, so we probably can download our data to ~/.local/share/anklang as well.

Still in an ideal world that only would be the default, allowing users to move this to another location (Bitwig lets you change the location for sample packs). For instance you may want to store your downloaded samples into a location that you do not backup or thats not on your smallish SSD that you use for your root partition. However, if this is too much work for now, just use ~/.local/share/anklang/samples and wait until someone complains about it. Can be fixed later.