Scoring Central

Full Version: VCSL
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
(04-21-2018, 01:32 AM)peastman Wrote: [ -> ]Here's a few inconsistencies I've come across so far regarding naming.  My current thought is to split the filename between underscores and try to interpret each piece, so that depends on having a consistent syntax for each piece.

Most instruments indicate the note by name.  But a few of them indicate it by number instead, such as the pipe organ.

Many instruments indicate velocity layers by dynamic markings like "mf" and "ff".  Others use the specifications "vl1", "vl2", etc.  The electrophones indicate it with the numbers 53, 92, and 124 (the velocities they were generated for?).  The glockenspiel uses "soft", "medium", and "loud".

Round robin is indicated in a variety of ways.  Most often it's by "rr1" and "rr2".  But sometimes it's by adding the digit after the dynamic marking, such as in the crash cymbals.  Or it can be a digit all by itself, like with the cajon.

Over time, I've improved my naming convention to be more standardized. Some of this stuff is several years old and thus hasn't benefited from those changes.

The electrophones were auto-sampled by Samplit, so they used "computer-friendly" notation like that for pitches and velocities, I believe.

When making our automapper, we used a "dictionary" system, which basically interpreted the 'human-readable' tags such as 'vl1' and 'mf' and gave them semantic values in an ordered list (e.g. ppp=1 and vl1=1, pp=2 and vl2=2), and likewise with individual pitch dictionaries for various notation/pitch methods. The mapper could then interpret by going "ah yes, I have a 1, 3, 5 in velocities for MIDI note 60, I should use a three-velocity mapping for this note". The system, although much simpler than yours in features, is quite robust, so it can deal with multiple velocity notations, varying numbers of RR, and other potential risks.
That's what I'm planning on too.  The problem is that it requires knowing in advance what convention is being used for each field.  If it finds a number all on its own, that could be a note number, a round robin index, or a velocity.  Likewise, "f2" could either indicate a note, or a velocity and round robin index.

If the fields always appeared in a consistent order I could rely on that instead.  But the ordering of fields, and which fields are or aren't present, isn't consistent either.
(04-21-2018, 02:14 AM)peastman Wrote: [ -> ]That's what I'm planning on too.  The problem is that it requires knowing in advance what convention is being used for each field.  If it finds a number all on its own, that could be a note number, a round robin index, or a velocity.  Likewise, "f2" could either indicate a note, or a velocity and round robin index.

If the fields always appeared in a consistent order I could rely on that instead.  But the ordering of fields, and which fields are or aren't present, isn't consistent either.

That's why I always try to use 'rr' and 'vl' to indicate which are those fields, and use note names rather than MIDI note numbers.
Quote: That's why I always try to use 'rr' and 'vl' to indicate which are those fields, and use note names rather than MIDI note numbers.

That sounds great as a convention to use.  It's just that right now, a lot of files don't follow it. Smile   I can work around that, but if you rename the files to follow that convention then generating SFZ files can become a much more automated, less manual process.
(04-21-2018, 05:01 AM)peastman Wrote: [ -> ]
Quote: That's why I always try to use 'rr' and 'vl' to indicate which are those fields, and use note names rather than MIDI note numbers.

That sounds great as a convention to use.  It's just that right now, a lot of files don't follow it. Smile   I can work around that, but if you rename the files to follow that convention then generating SFZ files can become a much more automated, less manual process.

I'll see what I can do. You can also do some on your end using a batch renamer.
(04-21-2018, 05:01 AM)peastman Wrote: [ -> ]
Quote: That's why I always try to use 'rr' and 'vl' to indicate which are those fields, and use note names rather than MIDI note numbers.

That sounds great as a convention to use.  It's just that right now, a lot of files don't follow it. Smile   I can work around that, but if you rename the files to follow that convention then generating SFZ files can become a much more automated, less manual process.

Just saw your commit, thanks! I will check these out right away.

For the future, I have set up a new 'sfz' branch for the main project which you may work out of or commit to instead of the master. I'd like to keep the master to have only the samples, for minimal confusion.  Smile

Ok, so I noticed a few things-

- 'Rel' designates Release. These regions should be appended as a new <group> (or with a new <global>) with the opcode "trigger=release". "trigger=attack" should be placed in the <global> or each <group> of the normal sustain as well for it to work right. I included an example with the ocarina below. I may add release samples to more instruments over time, as they add an incredible amount of realism to the samples, especially when without additional reverb.

- The tenor recorder is pretty quiet. The easiest fix for this kind of thing is a volume= in the global, but unfortunately volume= is overwritten if it is included elsewhere lower down the chain, so some sort of 'additive volume offset' may be a good idea for your script, so it can add a user-entered int to the calculated volume it uses.

- While having custom volume tweaks to normalize/smooth over the samples is a good idea, it can cause inaccuracies, such as with instruments like tin whistle, harp, or piccolo, which are much higher sound pressure level in their higher registers than lower. If I were to do that, I would interpolate the change, maybe to only 50%, so that it doesn't completely overwrite any natural volume curves. Obviously this is a matter of taste/opinion, so what you do is up to you.

A few more I noticed-
- Piano is 1 octave too high (note that most instruments are C3=60=middle C, only a few, if any, are C4=60)
- Piano has an attack of .1. The maximum recommended attack for "de-clicking" is 0.005- this will remove the chance of any non-zero starting points in samples from causing a click sound. The 'Release' group may have a higher 'ampeg_attack' than 0.005, up to the length of the 'ampeg_release' of the 'normal' group (i.e. 0.5); basically making a crossfade into the release. Smile
- The recommended maximum release length is 0.3 or 0.4. Sometimes as little as .25 or so is plenty; I've even regularly done some Maize instruments as short as .15.
- Generally it is best to "favor" the low velocities more, so they take up more of the velocity layers. I typically place any high velocity layer at ~100 or above, as that seems about a comfortable trigger point. Overall, I felt the high velocity layer was a bit too easy to trigger for the piano, for example.
- If you want to win MAJOR brownie points, you could try a velocity crossfade on the yamaha piano. I don't know how well it will work, but someone tried it out in Kontakt on one of the other pianos and it came out fantastic. Phasing is always a risk with this, but it's worth trying I think.
When recording in stereo, how should the left and right channels be oriented? I mean, I'm sitting in front of the microphones, should the one on the left be the left channel, or should it be the right channel since it would be the right for my "audience"?
(04-22-2018, 02:25 AM)Michael Willis Wrote: [ -> ]When recording in stereo, how should the left and right channels be oriented? I mean, I'm sitting in front of the microphones, should the one on the left be the left channel, or should it be the right channel since it would be the right for my "audience"?

Audience is typical for winds, strings, and brass. Stuff such as pianos, harps, drum sets, and mallets may be done with player position stereo recording via overheads or "player" mics.
I'll make those changes and send a new pull request to the sfz branch.  What values would you like me to use for attack and release?  These are just default values.  Ultimately you'll want to customize them for each instrument, but right now I'm just trying to auto-generate files, and I don't know of any automated way to pick appropriate values for different instruments.

The main purpose of the volume correction is to make all the samples for each note consistent.  Otherwise the volume jumps when it goes between layers and the round robins sound different from each other.  I also do a little bit of normalization to smooth out differences between adjacent notes, but that's just a local correction.  It doesn't change the balance between high and low registers.  Unfortunately, the largest allowed value for "volume" is 6 dB, and some of the samples are already hitting that limit.  If you want the recorder to be louder, I think you need to actually amplify the samples.  Some of them are super quiet.


Quote: - Piano is 1 octave too high (note that most instruments are C3=60=middle C, only a few, if any, are C4=60)

Is there any way I can tell which convention is being used for each instrument?  I could try to figure it out by analyzing the sound, but that won't be completely reliable.  The routine for calculating frequency sometimes picks up on a prominent harmonic rather than the fundamental.

I might try crossfading if I'm feeling really ambitious!  But I suspect that without phase locking, that's not going to work too well.

Is it ok if I rearrange/rename the folders a little so that whenever there are release samples, they'll always be in a folder called "Releases" and the corresponding sustains will be in a folder called "Sustains", with subfolders for the articulations?  That's how some instruments do it, but others arrange or name them a bit differently.

There's one case I'm not sure how to interpret.  The Steinway grand piano has three folders called "NoSus", "Sus", and "Rel".  What's the difference between "Sus" and "NoSus", and which ones are the releases meant to be used with?
(04-22-2018, 02:45 AM)peastman Wrote: [ -> ]I'll make those changes and send a new pull request to the sfz branch.  What values would you like me to use for attack and release?  These are just default values.  Ultimately you'll want to customize them for each instrument, but right now I'm just trying to auto-generate files, and I don't know of any automated way to pick appropriate values for different instruments.

The main purpose of the volume correction is to make all the samples for each note consistent.  Otherwise the volume jumps when it goes between layers and the round robins sound different from each other.  I also do a little bit of normalization to smooth out differences between adjacent notes, but that's just a local correction.  It doesn't change the balance between high and low registers.  Unfortunately, the largest allowed value for "volume" is 6 dB, and some of the samples are already hitting that limit.  If you want the recorder to be louder, I think you need to actually amplify the samples.  Some of them are super quiet.


Quote: - Piano is 1 octave too high (note that most instruments are C3=60=middle C, only a few, if any, are C4=60)

Is there any way I can tell which convention is being used for each instrument?  I could try to figure it out by analyzing the sound, but that won't be completely reliable.  The routine for calculating frequency sometimes picks up on a prominent harmonic rather than the fundamental.

I might try crossfading if I'm feeling really ambitious!  But I suspect that without phase locking, that's not going to work too well.

The 6 dB max is incorrect information, at least for ARIA-based systems. I've nearly blown out my speakers with a simple typo before (e.g. 120 dB instead of 12 dB!). I don't know what the actual max is, but it's waaay more than 6 dB. You can hear this in the SFZ's I made for VSCO 2 CE- they will go well above and beyond +6 dB.

Ideally, everything should be normalized. However, this has two major issues-
1. Any relationships in volume intended between instruments are lost, such as an oboe being recorded more quietly than a trombone.
2. Any super-quiet sounds get boosted, along with the noise floor, meaning people are more likely to experience issues when those sounds (e.g. a quiet rim click or col legno versus a snare drum hit or a bartok pizz, respectively) are played. This means at the end of the day, the creator of the sfz's should manually tweak a "general offset" for the sample set as a whole, without having to manually tweak EVERY sample. A simple additive variable in the code as I suggested would allow this, although manual tweaking is inevitable for at least some of the samples in mixed articulation patches (e.g. a drum kit patch).

Distinguishing between conventions is really easiest done by ear. Locate a C3/C4 sample and compare it to a known middle C (best is a known-good piano). You can also use a range chart (I keep a 'spectrotone chart', not for the actual spectro/tone part, but just because it has general ranges of all orchestral instruments written in MIDI key numbers with a nice piano keyboard annotated with key numbers, notation, pitches, and frequencies). It's something that can take time to really develop a good ear for with some instruments- I once mapped a timpani up a fifth from what it really was by accident!

You should assume that 90+% of the sample set (especially the "easy"/"well-annotated" stuff) is C3=60. It's what Kontakt and most other samplers uses. On the other hand, there are a few older things I cut myself that I did under C4=60 (which is technically the "more correct" one, but has a smaller following in the world of digital audio). These tend to be older samples, and for the most part, you won't even see those.

May I suggest the group defaults as the following for pianos-

Code:
ampeg_attack=0.004
ampeg_release=0.3


(for the 'sus'/'normal' group, put 'trigger=attack', for the 'rel', put 'trigger=release')

For sustaining instruments-

Code:
ampeg_attack=0.5
ameg_vel2attack=-0.495
ampeg_release=0.3

The ampeg_attack and ampeg_vel2attack will work together to create a soft fade at the start of the sample at low velocities, which diminishes as the attack is greater. You can tweak these values by decreasing ampeg_attack and ampeg_vel2attack together. The difference between the two is how much of an attack is left at velocity 127 (in this case 0.005, or 5 ms, which is just enough to clean up any unwanted clicks, although it could be even shorter).
If there are sus and rel, set them up like above. This can probably be automated if you can build instruments from within multiple folders ('default_path=' inside of <control> is your friend, especially since you can put multiple <control> headers in an instrument).

You can couple the ampeg_attack with a lowpass filter with a similar envelope if you want to go overboard, but this will at least get the job started and make controlling brass and strings much more lively and dynamic seeming.
Try this with the filter. To be honest, not sure where to put it or if it even works... should be sfz 1.0 compliant-

Code:
fil_type=lpf_1p //a gentle lowpass
cutoff=22100
fil_keytrack=15 //slight keytracking to stop high notes from being too dull at inception

fileg_depth=6000 //not sure about this one, cryptic, may not even be needed or may break everything!
fileg_start=19 //percentage of cutoff - edit this!
fileg_attack=0.5
fileg_vel2attack=-0.495

On the other hand, it might be handy to have the script instead (or additionally) set up a filter whenever it notices there is only one velocity, to enhance the effect of the lower velocities-

Code:
fil_type=lpf_1p //gentle lowpass
cutoff=6000
fil_keytrack=15
fil_veltrack=2250 //again not sure about this setting, but that might just work
fil_random=100 //a little 'jitter' to help :)

You could alternately have it hooked up to CC1 for sustaining instruments for the modwheel lovers by swapping out 'fil_veltrack' for 'cutoff_cc1'.

Crossfading a piano is much more forgiving, as each note consists of multiple strings which phase together in their own way. Most of the pianos in VCSL are fairly precisely cut, so there should be less phasing than typical, but I can't promise it would be 100% perfect. You can crossfade any section (2+ instruments) without needing to worry about phasing regardless, and many solo instruments will work *okay* (but not necessarily fantastic) without phaselocking.

The crossfading is rather straightforward; to be honest, I don't know why I haven't had it implemented in my automapper (probably a fear of messing it up).
For a two-layer instrument, all samples are mapped to the full velocity range (1-127, or 0-127).

Then, the upper layer receives 'xfin_lovel=1' and 'xfin_hivel=126', for example (although you could pick a higher/lower combo, such as 10 and 119, for example). The lower layer receives 'xfout_lovel=1' and 'xfout_hivel=126' (or again, the same combo as used before). The lovel and hivel should match between xfin and xfin out for best results, and can be anywhere on the keyboard, even 50 and 70, for a very brief crossfade in middle velocities (perhaps to soften the transition a little bit).

With three layers, the situation is very similar again, but the numbers are different, this time with the bottom velocity mapped 1-64, the middle 1-127, and the top 65-127. The bottom xfout_lovel might be 10 and hivel 59, the middle gets both xfin and xfout, with xfin_lovel at 10, xfin_hivel at 59, then xfout_lovel=70, xfout_hivel=117. Finally, the top gets xfin_lovel=70 and xfin_hivel=117. These are just examples, and will leave a 10-velocity range for each of the samples to be "alone" in.

By default, SFZ spec indicates the curve of the crossfade is 'power' (as in 'equal power curve'), which is better for mixing non-phaselocked material. You can change this to 'gain' (as in 'equal gain curve'; better for phase-locked material) with 'xf_velcurve=gain'. You will probably want to leave it as-is though, but it's worth trying both options.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16