Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 16bit note velocity

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



>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.

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...


Not my experience. The expressive control is exponential, so either you clip on either end of the velocity spectrum, or you get discrete steps at the lower end.


I agree with the previous person that 256 levels of amplitude should be sufficient purely when it comes to velocity as long as these levels are spread appropriately (i.e. non-linearly). If the expressive control is exponential, that suggests to me that the data itself should be exponential.

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.


Speaking as a producer who's programmed a lot of natural-sounding drum tracks...

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.


The new attributes in the spec should make it possible - although not entirely easy - to include 2D position information with note on messages.

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.


3D positioning was added to 1.0, described in RP-049 dated 2009-07-23. The parameters' MSB is 61 (0x3D, nice)

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.


I'd agree with you for synthesizing, particularly with a master volume knob. But playing live my volume range is from audible to just me (So I can plan what people will hear), to easily the loudest thing going ;) Which is louder than you want to set your CD player :)

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


Remember that drums are two dimensional, but circular, so there is at least one more thing in their response: the timbre if the sound is affected by the radial location of the hit, which encourages different harmonics and hence a different sound. You can also hit parts other than the drumhead - and the rim and head (nearly) simultaneously.


You wouldn't be able to tell between a hit in velocity 1 or 2 or between 254 vs 255 is my point.


If the velocity is a^x, with a a number like 1.1 and v a number between 0 and 255, I would agree. However, what I’ve seen is that 2 is twice as loud as 1 and 256 twice as loud as 128. That means soft passages become discretized and uneven.


Why wouldn't 65536 separate velocities not be enough, even for the most expressive drummer (or indeed for any other instrument)?


I'd bet money on it that you couldn't tell even if it was 10-bit. 16-bit gives you 65536 levels of volume, that's surely overkill for anything a human can control or recognize. You certainly can't consistently drum with 65,536 different levels of volume. You wouldn't be able to even do 256.


99% of digital recorded music only has 16 bit velocity for every sample. I think it'd be fine.


16bit is sufficient for listening, but it leaves no headroom for production. Modern music is often recorded in 24bit and only rendered to 16bit as the final step.


That is correct for recording with microphones, however that is largely to avoid having to be overly precise with setting levels in order to maximise the value of those final 16 bits.

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.


No, because digital processing adds distortion to the signal, which means that having an input beyond perceptual accuracy still matters to a production needing to apply lengthy effects chains. It just matters less than the case of a quiet signal recorded at a linear bitdepth.

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 concerning a velocity control signal, not a stream of audio samples. This control signal would be mapped the internal processing of a synthesis or sampling engine, resulting in an audio signal whose data format (analog or 16/24/32-bit digital) comes down to the physical characteristics and design of the synth. Once it leaves the synth, a host can convert to whatever it needs to have enough headroom for further processing.

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.


I'm still having a hard time believing that the drum computer only having a 16-bit representation of the velocity of the stick hitting the pad will matter in its goal to produce a velocity-scaled (probably 24-bit) sample on its output port.

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.


“No” what?

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.


You also need good mics and preamps otherwise some of your 24 bits might be filled with noise.


Good luck finding any analog gear period that can saturate 24 bits and not have noise in the LSBs, it just doesn't exist. That's not the point of 24-bit audio, it's not needing to worry about clipping. That's why knocking it down to 16-bit for playback is practically speaking fine.


velocity != bit depth of a recording


Your resolution problem with electric drums is not MIDI, it's your drums.


Remember that music on a CD has only 16bit depth. It's plenty of dynamic range, especially for a control signal that can map to any output amplitude range.


It's plenty of dynamic range only when you know in advance what the lowest and highest values are going to be so you can scale it correctly, or if you're using a logarithmic scale. Neither are as convenient as higher bit depth linear scale.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: