It wont be limited at all, real human players have no control as subtle as 256 levels, much less 65K levels... Nobody would even notice anything...
I know literally nothing about drumming but I've no doubt there are plenty of other characteristics of a drum strike than velocity. Such as the mass being applied to the hit (e.g. is it being hit with the weight of the stick alone or is it the drummer's whole arm) or the location of the strike, or the release time.
There are plenty of variables other than velocity -- location on the drum head being the prime one, but there are others. Because of this, sampling an acoustic drum kit involves capturing a suitable number of random variations, and the end result is often gigabytes (i.e. hours of content) in size, even though each sampled hit is just a few seconds long. Not having enough variation in your sample set makes the programmed drums sounds unnatural, since excessive repetition doesn't gel with how we experience acoustic drums.
Certain variables are more important than others, though. One notable sound is the 'rim shot' which means striking the drum head and rim simultaneously, which causes all kinds of constructive interference and results in a very powerful sound. It's the holy grail of rock drumming. In drum programming, rim shots are often a separate stack of samples with its own velocity layers, each layer with a set of random variations.
I would have been happier with a more general note spec that left the number of attributes and their resolution open and system-definable. This would allow 2D/3D/4D/etc control of note events, super-high resolution pitch definitions for microtonal support, and so on.
Bandwidth really isn't an issue any more, so there's no reason to limit the spec to a low common denominator.
Even so - 2.0 is better than the limitations of 1.0. So that's progress.
It bears some resemblance to OpenAL source parameters which is little surprise as Creative seems to have written it. Some obvious differences:
- sources' positions are sent in azimuth/elevation/distance, i.e. spherical coordinates instead of rectangular
- the positions are always relative to the listener instead of often having a listener that moves around in a stationary 3D world
- the source is now allowed to be both spatialized and stereo with extra parameters for angular distance between the "speakers", the roll angle of the pair, etc.
I located the PDF maybe on Google, maybe by accident more than a few years ago. (I think it was from MIDI.org even then) I had to make an account at MIDI.org in January just to look through the specs, and it was there. Now I can't find a link so I'm afraid it disappeared behind the MMA member paywall. <sigh> Here's to progress.
Also, I strongly believe in using dynamics throughout the set. The min-max range I use is one of the strongest impacts I have on what people feel. Tinkled whisper to roar
Though yes, like you, I love my other variables too like strike position, angle, etc
This doesn't analogise well to digital instruments, as the minimum and maximum velocity/amplitude/whatever is already known and defined. You already know what the exact potential dynamic range is before the first note is ever played. The concept of headroom doesn't exist. Anything that you can think of which you might define as "headroom" is either beyond the input and/or output capabilities of the device and therefore irrelevant, or it should be within the normal scale.
For this sort of reason many digital effects operate at an oversampled rate(i.e. they apply a FIR filter to represent approximately the same signal at a higher sample rate like 1.5x or 2x, do the processing there, then downsample again). Contemporary DAW software has tended towards doing processing in 64-bit floating point, while source recordings typically go up to 24-bit/192kHz, which is probably "way more than good enough" even if some room to inflate the specs further exists.
For playback, 16-bit/44.1khz stereo is still as good as ever. You're limited more by the other parts of the signal path in that case.
This is orthogonal to the issues remediated by oversampling (harmonic artifacts due to aliasing in non-linear processing like saturation, not distortion issues related to bit-depth).
16-bit velocity signals, if linearly mapped, means 96dB of velocity sensitivity which is pretty good. And it won't be linearly mapped, because exponential velocity mappings are already prevalent in the industry.
There's lots of way more interesting information to be represented that'd be more valuable than just a raw 24-bit velocity - the angle and location of the hit, how much pressure (not velocity) was being applied, how the stick moved while it was in contact with the skin, the material of the stick, etc., if you truly want to capture the dynamics of drumming.
Did you interpret the word “largely” to mean “entirely” by accident?
This post appears to be a generic diatribe on the facts about sound mixing. It does not appear to be a response to anything I wrote, which is not about sound mixing at all. My post was a rejection of the analogizing between MIDI data streams and sound recording.
For electronic drums I would of much prefered at least 24bit. Volume is by far and away a drum's most expressive dimension, so it will be limited by a 16bit velocity range. Adding velocity curves just masks the problem
Though of course 16bit is orders of magintude better than the current 8bit range