Now that we have multiple velocity layers in an instrument, it would be cool if we could use the plugin grabber to generate multiple layers from a VSTi.
The plugin grabber currently lists the velocity that will be played. What I’m envisioning is replacing “velocity” with “max velocity”, and adding a “number of layers” parameter.
So, a max of 127 with four layers will create four samples: 1-32, 33-64, 65-96, 97-127. The actual velocity used to record each sample could be the highest value in that layer (in this case 32, 64, 96 and 127).
If a max velocity less than 127 is chosen, the samples would still be spread across the full range of playable velocities. So, if we substitute 64 for max velocity in the above example, they would still be spread as 1-32, 33-64 etc, but the samples would be recorded with velocities of 16, 32, 48 and 64.
During the alpha we were not sure how to deal with velocity and volume mappings in the grabber, thus skipped this for the beta. Indeed an obvious request, cause we now have both, sample grabbing and velocity layers. But maybe someone of you here has an idea how to solve the following problem:
Samples which are played back via the velocity layers in our sampler, do linearly map velocity to volume: 0x7f -> full volume, 0 -> silent.
This assumes that the original sample is sampled at its full volume - which is just fine and expected when load “raw” samples and assigning them to keys & velocity.
When sampling a plugin at a lower velocity, it maybe already has lowered its volume with the velocity, but we don’t know by which amount (and if at all - that’s all up to the plugin internals).
So if it already has applied velocity to its volume, the result will be too quite. If we would auto-maximize every grabbed sample, we would destroy probably wanted dynamics between the different keys / velocities.
Another reason of course also is that note + vel maps easily create tons of sample data. As long as we don’t support DFD streaming this maybe is more disappointing than helpful.
If the user picks 128, then for each note in Range, the note is scanned 128 times. […]
If the user picks 2, then for each note in Range, the note is scanned twice (Once at 128, once at 64)
If the user picks 1, then for each note in Range, the note is scanned 1 time (128, maximum velocity)
Pseudo code, where foo is a note in Range:
foreach foo {
if (previous_render == current_render) continue; // Don't store this, it's the same sample as the last
else { [...] }
}
Maybe some fuzzy comparator for (previous_render == current_render), stuff I know nothing about and am making up?
Yes, this results in huge files. But this is what people want.
An option in Instrument Editor to stop mapping Velocity to Volume? With Velocity Tracking Device we already have the ability to use this to control other aspects of a sound so might be good in general to be able to remove it from controlling Volume and seems to help with the problem above too.
This is a common problem for any sampler. So eventually a volume/velocity scaler is needed as part of the instrument setting it self.
You will experience the same thing if recording real instruments where playing softer will record lower amplitude and vice versa. You usually don’t wanna adjust/normalize each sample when doing this. But not all instruments have this characteristic difference in amplitude. So this needs to be adjustable in the end.
I think users can live with if some sampled vsti loses some of its dynamics if you auto-maximize. Its a bit like, take it or leave it.
I would love the feature anyway!
After all you do often lose somethings as soon as you sample.
But are you really sure that you will?
It should be very easy to test with a few plugins.
I think most users would also rather have it sooner than having to wait a year or two for DFD streaming
Thinking about it further and fully disabled wouldn’t help. Although that would be good for the above example of using Velocity Tracking if so had say only 2 samples, one at 64 and one at 127 velocity you would want 65 to sound quieter than 127 but it wouldn’t if it was fully disabled. Hopefully having a from 127 to 127-Range where Range is how many velocity levels the sample is played over may work in many situations. Maybe having this as the default for when this kind option is enabled but having an Advanced Velocity Editor where you can set max and min for each sample layer.
Getting quite complicated but hopefully the three basic modes would be usable in most circumstances, with maybe a little level matching.
It would if the plugin you’re sampling is quieter at 65. Isnt the point of the plugin grabber to capture the sound of the instrument as closely as possible.
But you are only taking two samples to use, one at 127, one at 64. Can’t always sample for all 127 levels of all notes. WOuld destroy your RAM for a start!
Yeah sorry, I see what you mean now. But if you sample four or five layers the jump wouldnt be that noticeable. If velocity crossfading gets added in a far future then this problem goes away.
A good starting point would be making velocity to volume mapping optional. It’s possible that user wants to sample instrument in which velocity controls for example filter and not volume and the automatical velocity to volume mapping screws everything.
