Slightly off‑topic, my apologies for that, but I suspect this thread is the best place to find people who can help. I recall this being talked about, but couldn’t find that thread…
I’m wondering what the most practical way is to explore or audition a bank of SF2 presets (eg Fantom X folders), without having to go through the full workflow every time, long‑pressing the preset, pressing again to move up to the folder/bank, scrolling to the next preset, loading it, etc.
Is there any trick or option to have Vangelis (or Oram, for that matter) preload samples directly from the preset‑browsing menu? (Yes, I have “Preload Presets: On” in the webconf)
@hannesmenzel what’s the expected behavior? From your comment I understand soundfonts are preloading while browsing presets, but I don’t see it happening in current Vangelis. Is it something that changed from Oram, or is it something just not working for me, for some reason?
It’s active, I just double-checked.
I booted Oram, just in case, and the behaviour is the same: with FluidSynth, preset doesn’t load when browsing the available presets, only when I push the Select button (4). BUT I just realized the preloading works fine with SFizz, so I should look deeper on FluidSynth specific options. It bugs me that I think I had this working when I first explored Fantom X soundfonts :\
For me it works in FluidSynth. But only within an SF2 file, not between SF2 files. That is different than how Sfizz works with SFZ .
About the note-on preload that @hannesmenzel mentiones, I opened a ticket for that so it would work better for soundfonts but I didn’t hear anything about that yet.
I’m ready to get started on this, but we need to figure out how to organize any new repos, and create them. I’ve prepared a version of Accurate Salamander Grand that’s low-latency and takes only 190MB rather than 1.09G. I’d like to check it in!
One option is to have a single repo for all samplesets. To give users easy access to any single sampleset we could use the release artifacts feature, so you could easily download a zip file for any sampleset (and the build process might do this too.)
The other option is for each sampleset to have its own repo.
In any case, they should belong to the zynthian project, or perhaps be another zynthian project if multiple repos.
I converted 24-bit to 16-bit, which now that samples are normalized, is fine. It also allows flac compression to compress significantly more due to not having to preserve the random low order bits.
I used the “min” version, which omits hammer noises and release samples (as these also use additional voices). It seems like the difference shouldn’t be that big, so I understand your question.
I also made some improvements that I plan to post back to the maintainer (like more accurate release times that change as you go up the keyboard.)
I would make this the default piano and definitely include it in Zynthian. IMHO, the release process shouldn’t involve someone adding samplesets by hand, so everything that ships with Zynth should either be in our repo or pulled by a script in our repo.
I could make this buildable by pulling from the original and running a script, but it’d be time consuming. A few minutes perhaps. LMK what you’d prefer. I’m split. There’s a simplicity and bullet-proofness to just hosting all the files. But pulling from the source would help us keep up with any updates. Above that was discussed and the latter point wasn’t considered very important. Interestingly, Accurate Salamander is an exception because it is being updated now and then. But IMHO the current is way good enough. I’ve really been enjoying playing it, especially with my resonance plugin (on Windows only so far though, since I haven’t figured out how to build that for zynth yet!)
Also, I believe we should have two categories: samplesets that are included with Zynth, and ones that are tailored as needed for Zynth but not included, and these should be easily installed by the end user.
Regarding packages, so far I’m talking about what should be included by default. I wasn’t aware of the “packages” feature earlier, but we definitely should use that for larger samplesets (like the complete Accurate Salamander Grand package we currently have.) I’ll be interested to know how those work: how to set them up, how installation of a package works, what stuff is in a Zynth repo to support a given package, etc.
In any case, I’m stalled. I can’t create a repo in the project, and there’s no repo to submit a PR to.
So, unless someone creates a repo, there’s nothing more I can do, other than start whittling on other samplesets. But frankly, I don’t want to pile up a bunch of things to commit later and possibly never.
I’m thinking the best way of managing package data (samplesets).
Until then, please, send a link to the “Accurate Mini” soundfont for testing and i will create a package for it.
I was searching for a violin today. (An instrument that is often difficult to accurately emulate.) Having given up on the SF2 soundfonts I had available I started to look at SFZ with mixed, but generally poor results. I observe some very odd noise on the VSCO2 SViolin patches which sounds like noise from poorly handled reverberation. Is anyone else hearing this? I am running at 48000 fps.
I’m tempted of start using git LFS for this. It seems the obvious solution.
I could self-host a repository without storage limits, but i already have enough sysadmin burden with the current zynthian infrastructure and i don’t want to add more to the list.
Github offers LFS for free and IMO, it’s quite generous. They limit per-file size to 2GB, but i think we can live with this. We could avoid having packages bigger than this. In the worst case, we could fragment packages. They say nothing about maximum storage size per-repository.
But before going forward … someone have some experience with git LFS and could give some advice about it?
I don’t have any experience with git LFS at all, but from the website informations and a youtube tutorial it might be possible to track wav and flac files referenced to git lfs instead of hosting entire packages (zip/tar…). So the sfz and yml files could stay on the repository. This way the maximum per file size would apply to each sample file.
Maximum total storage must be according to the subscription plan, I find 10GB for free on the internet.
So, next question is, one repo per sampleset, or “one ring to rule them all.” The consensus seems to be the latter.
But that raises the issue that the repo would get very large, and to do work on just one sampleset, or to download just one sampleset, you need to pull them all.
A possible solution to this could be to keep only the .sfz files, licenses, readmes, etc. in the repo, but store the full sampleset (including these) as zip files as release artifacts. Then you could easily pull the relatively small repo, pull the sampleset zip, do whatever.
The downside to that is that anytime a single change is made to any sampleset, a new release needs to be created containing all samplesets as release artifacts. At least, I think.
I’ve been thinking about it and this is my proposal:
Let’s use a git LFS repository for each package.
Let’s have an “Official Packages” repository that includes, as sub-repositories, the official list of packages. For adding a new package to the official list, the author(s) would make a PR to this repo.
There could be “Unofficial Packages Lists” that users can configure in their zynthians, similar to adding unofficial repos to your linux distro.
Zynthian Packages can be installed/uninstalled from webconf or CLI.
Zynthian Package format has been already defined in this thread:
It should be improved and documented in the wiki, but i consider it’s still a “kind of proposal” and probably will evolve in the next weeks/months.
Regarding soundfonts, they would be managed as zynthian packages, including the factory collection (it’s already a package in Vangelis!).
There is no limitation/imposition about how many sample sets should be stored in one repo/package, but for big samplesets, it seems reasonable to have a dedicated repository/package.
I just started moving all current packages to git LFS repos and i will create the “zynthian official packages” repository with the list.
Great! I did notice the Packages menu when I finally got Vangelis working for me. I think it perfectly fits the bill as currently set up: one packages for the (optionally) built-in samplesets, and other packages for other samplesets. I also like the idea that a single package might contain multiple samplesets, especially when they’re not large, or when they’re already a collection.
I also really like the “uninstall” feature.
Here’s my repo for Accurate Salamander Grand, reduced for Zynthian:
PS: after seeing the packages, I’ll update this repo to match and post back when it’s done. Meahwhile, anyone can still pull it to play the piano.
I’ll be very interested to see how packages are created.
I also think we should identify the things that each sampleset should have, in addition to what’s required for a package. I assume packages can be more than just samplesets, and there might be differences between the info for a package vs the info that gets loaded onto Zynth for displaying and choosing samplesets.
At a minimum, for each sampleset we should have:
name
brief description
full description
controls (might be a yml file, explains both CC controls and keyswitches.)
license
LMK if there’s anything else that every sampleset should have.
