bigcat1969 wrote:It sounds like the release is somehow set to 0?
It looks like VSCO2 was made purposely bad so people would buy the commercial version. Yes, I'm always blaming malice.
Hi there, Sam Gossner here- developer of VSCO 2. Just figured I'd pop in and answer a few concerns.
First off, no, VSCO 2 CE was not purposefully
made bad to force people to buy the commercial version. If I wanted to force people to buy the commercial version, I would put in a nag screen, forcefully collect e-mail addresses, disallow derivative works, and all that other horse hockey that many devs pull- not to mention sure as heck not make it CC0! There are already almost a dozen various conversions or derivative works, including two commercial ones so far -- that I am aware of
. All without needing royalties, licenses, or even credit. Frankly, I'm sorry if releasing 3 GB of anything into the public domain isn't a good thing from your perspective, but it was something I personally wanted to do for a long time and it's done some good things for quite a few folks out there.
When I started writing music back in 2009 (with good ol' LMMS), I spent a lot of time digging through the seas of ancient freeware soundfonts, many of which had vastly different sounding instruments at all kinds of low sample rates (I was shocked when I learned what an English horn actually
looked and sounded like a few years later). I was inspired by the works of developers like Mattias Westlund, who shifted through thousands of free samplesets online for months, organizing and processing them into a coherent soundset (Sonatina). However, I decided that a library which was not recorded consistently could never be easily used to create a consistent sounding orchestra.
I (somewhat rashly) resolved I would do better some day, and through VSCO 1 I thought I had achieved that... for about a day or two after release, and then I realized I could (or rather needed to
) do much better (if you think VSCO 2 is 'unusable', I am sincerely thankful you weren't there to try VSCO 1!). Thus VSCO 2 was born intended as a freeware library first, later blossoming (or feature-creeping) over two years into the full commercial library it is today.
Regardless, I wanted to put something into the public domain so people would at least have a solid starting point with fairly consistently recorded, 44.1/16 stereo audio with decent recording equipment and little to no existing room tone instead of the broad mixture of formats, stereo images, room levels, and tones that cover the spread of existing free sample sets. (fun side-note: a solid chunk of the solo CE sampleset was phase-locked at launch but a bunch of people complained about how "robotic" it sounded so I had those samples re-processed with less autotuning)
At the same time, uploading the whole 30+ GB raw sample set online and sticking a 'free' sign on it was increasingly out of the question as the library grew; I had already sunk over $10K of my savings (an admittedly paltry sum in the world of sampling) into recording and editing the project, not to mention hundreds of hours. If I ever wanted to live off of sampling (in particular, according to how the IRS defines 'business' vs. how it defines 'hobby'), it was necessary that I recoup these costs so that I could move on and make new products. Besides, the bandwidth costs of distributing a 30+ GB freeware library alone would exceed the cost of developing the library several times over anyway ($0.08/GB via S3 * 30 GB * >20,000 downloads/year = $48,000+)! That's why Simon Dalzell opted to distribute his Piano in 162 via torrents with a donationware "normal" download option.
If someone wants to buy the full library or any of my other commercial projects because they like what they hear, that means I can hire some musicians or contractors or buy some more equipment. If not, not a problem, enjoy the freeware and I hope it helps you make some music. I really don't know what else to say about the matter.
Anyway, back to VCSL- I often end up with odd instruments, quick test recordings, etc. that aren't big enough to warrant a commercial release, but would still put an entire rack of early 90's hardware samplers to shame in size and sample count. VSCO 2 CE was built from the VSCO 2 sample set, so that wasn't the place for them- instead I started this GitHub repository so folks could freely access these samples, maybe even contribute their own if they'd like. I like a lot of these samples a lot, but I just don't have the time or resources to do more than have them cut, tuned, and sorted.
The reason there is "only" 5 GB so far is that I've scheduled a few recording sessions over the next few months to make some new samples specifically for this new set. My plan is to substitute new samples for most of the VSCO 2 stuff, and to be honest, I kind of miss the days of running around with two mics and an interface that's small enough to actually fit in a backpack.
I don't currently have any plans to personally make a SFZ version or any other version, but I did make my SFZ automapper tool free, not to mention put up about a hour's worth of videos of me using the thing and editing the SFZ files. Once that's done the hard part, the things are darned simple to edit in a text editor so long as you have a list of opcodes handy (there are several online). There's a reason I picked SFZ and not SF2 (which requires an editor and doesn't support round robins) or Maize-based VST (which basically locks all the samples away in a monolithic file so the end user can't get to them and can't be edited beyond a few basic knobs on the UI).
If you have 10 minutes and do a little editing, you can turn any patch into a chorusy synth or whatever else you want. If you don't know how to do something, there are a shocking number of SFZ gurus around the web who are happy to help, and the good old tradition of trying stuff until it loads without spitting out errors (my personal favorite) is equally effective.
The one you're looking for is 'ampeg_release
'. It should be in the top 20 lines of every instrument, with a value in seconds. Change it (try 0.3 or 0.4 if you're not happy with what's there), save it; it auto updates in most SFZ players without even having to reload. I feel like Sforzando/ARIA run a bit short in their timings compared to something like Maize or Kontakt, although it could be that it's not a linear fade and thus it just sounds shorter. Unfortunately there's no way I can add a release knob or UI- to be blunt I don't know how the ARIA UI system works and even if I did, it wouldn't work in Linux Sampler or rgc:SFZ/SFZ to my knowledge.
If you find a particularly egregiously poor transition, hop into the sfz, find it, and tweak the volume= under the <region> with the corresponding sample=. Several folks have nicely already caught a few of these and pushed it back into the SFZ fork, and I've done a few tweaks myself whenever I have a moment or someone reports something particularly wrong.
On the other hand, crossfading also only takes a bit of time to set up, in particular for a simple velocity crossfade, but it's more than doable to make some quick velocity crossfading. With string ensembles you honestly can't phaselock them, so decently tuned samples will suffice. Set all the velocity ranges to identical (i.e. make the lovel=64 or whatever be lovel=1 and the highvel=63 or whatever be highvel=127; use a replace operation to do it in two clicks). Now insert under the <region>'s which were the lower velocity (typically labeled 'v1' or 'vl1' in the case of the strings):
and for the 'vl3' or 'v3' regions-
If you also stick 'amp_veltrack=0' in the <global> header and set all the instances of 'volume=' to '0', that should also preserve the original dynamic range of the samples, basically undoing all the velocity curve/volume tweaking mumbo jumbo that goes on currently. If you want to be particularly tricky, you can stick this in the 2nd velocity layer samples to soften the attacks-
Code: Select all
This will result in an attack of about .25 seconds by the middle of the velocities, and about 0.005 (5 ms) if you hit it at 127. You can get a shorter attack by using lesser values, say 0.4 and 0.395.
All of this is hypothetical, I haven't had time to test any of it (I've been up all night working through crunch time on another project), but you're welcome to give it a shot.