-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Downloader for Samples #25
Comments
Yes, indeed, here some collection links for instance: https://versilian-studios.com/vsco-community/ Often, SFZ files are intermixed with SF2 files however, I think it'd make sense to also support SF2 via FluidSynth. |
Can you provide a few more details, in particular:
|
This may be relevant (how Ardour does it): https://www.youtube.com/watch?v=BmePT0kZ4pM 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.
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.
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.
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.
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. |
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 Can you second that, or did I misunderstand and XDG pieces here? |
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 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 |
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.
The text was updated successfully, but these errors were encountered: