Re: [linux-audio-dev] drumset questions etc... Was: Re: disksampler 0.03 released, several fixes (non-blocking MIDI,ALSA,..)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] drumset questions etc... Was: Re: disksampler 0.03 released, several fixes (non-blocking MIDI,ALSA,..)
From: David Olofson (david_AT_gardena.net)
Date: Mon Jul 17 2000 - 12:02:54 EEST


On Sun, 16 Jul 2000, Benno Senoner wrote:
> Anyway I have a question now to you drummers / experts in drumsets on samplers.
>
> You know that when you play a drum set, pressing first the open hihat key and
> then the closed hihat key, will cause the open hihat to stop abruptly even if
> you did not released the open hihat key yet.
>
> I plan to include this feature or drumsets will not get very usable.
>
> But I need suggestions what kind of features traditional samples have in this
> area.
> eg. Would it be ok to say: the press of key Z will stop note triggered by key
> X and Y.
> Would this be ok ? So that every key press can stop n other notes arbitrarily
> choses.

The JV1080 has a "Mute Group" field for every key in a drum kit. This
field can be either "OFF" or a number 1..31, identifying groups of
keys that should basically play as if they were a monophonic patch.
(Not sure if this is how it's done, or if one NoteOn truly emulates
NoteOff for the other notes in the group - I'd prefer the latter, or
better both, selectable.)

No idea about the implementation in that machine, but I think the UI
makes sense. Groups is a somewhat more structured approach than
direct "key A mutes key B" mapping, and allows the group concept to
be easily extended later if required.

In general, I think this should use the same logic as mono/poly
patches - enables code reuse, and makes both drum kits and normal
patches more useful. Actually, as to the distinction patch/drum kit;
why have it at all? On the machines and software I've seen so far,
it's just a source of various problems, if it stretches beyond the
editor UI. A drum kit should simply be a multilayer patch.

That makes the solution to the Mute Group problem rather obvious:
The hihat is a single instrument, and doesn't have the capability to
play more than one voice at a time (*), and should therefore be a
layer that works in mono mode. Toms, on the contrary (provided this
is a "lo-fi" or synth set, where the same sample is reused), is a
kind-of chromatic instrument with one voice per pitch, which renders
to a polyphonic layer.

Oh, BTW, the usual mapping via key ranges (as it's handled by most
synths and SoundFonts [the editors, at least]) isn't very adequate
for drum kits. Check out how the toms are mapped in relation to the
hi-hat on the average kit, and you'll see why...

(*) Disregarding that it *does* affect the sound if the hi-hat is
vibrating or not when you hit it... This goes under "advanced
sampler programming", though, just as pianos featuring vibrations
activating nearby strings and that kind of things. (Yes, some piano
modules do emulate this!)

> What does mean stopping a note ?
> Normall the open HiHat when you release the key will decay relatively slow,
> but stopping it abruptly (eg when you press the closed hihat, the open sample
> stops playing without any decay) does not seem the perfect solution to me.

No, it's probably not. I'm not sure how pro machines do note stealing
(also used when running out of voices) when the waveforms need to be
changed or retrigged (as opposed to a simple pitch change or slide,
as it should be done for some mono patches), but I'd guess they do
one of the following to avoid clicks:

1) Wait for a zero-crossing in the current waveform before doing
   anything. Possibly run the new sound "virtually" in the
   background, so that the actual timing won't suffer - not very nice
   if the new sound has a very sharp and short transient, though!

2) Do a quick fade-out, but basically do as 1) in all other respects.

3) Do a quick "find best matching old-new sample pair" operation, so
   that the resulting signal skips from the old waveform into a
   suitable (early) position in the new sample. Similar problems as
   in 1) and 2).

4) Do a cross-fade. This will probably require at extra channel,
   unless the new sound has the same pitch and filter settings.
   (OTOH, the filter states should *definitely* be reset before
   starting a totally new sound anyway...) May result in flange
   effects if the cross-fade is too long, and the sounds are too
   similar. (I'm a bit worried about this for the hi-hat...)

5) Directly allocate a new voice, and then quickly fade the old sound
   in the background. Clean and easy to implement, but needs two
   channels. May suffer from flange effects, like 4; probably more,
   as *both* waveforms will be playing at 100% volume the first few
   samples. (With a cross-fade, the sum is never > 100%.)

Well, there doesn't seem to be a perfect solution. As the "correct"
solution depends on what kind of sound we're dealing with, probably 2
or 3 of the above should be supported for The Perfect Retrig Sound.

> How about instead of stopping it abruptly, forcing the note in decay
> mode (like releasing the key) and change it's decay volume envelope curve ?
>
> So that for example you can set a decay envelope from normal to very fast.

This is either low level (point 5 above), or patch level, where the
patch should define exactly how this should be done. How about a
"Mute Fade Out Time" field to go with every waveform? (Shold probably
be scaled along with the playback sample rate.)

As to other mute group/poly/mono methods, not really related to this
issue, they are basically;

A) Polyphonic.
   Simply allocate a new voice and do the usual thing on that.

B) Monophonic with waveform restart.
   This is where the above gets in, although it's a little bit easier
   than true voice stealing, as both the old and new waveforms
   belong to the same patch, and that patch explicitly tells us what
   to do; namely "Restart the waveform upon NoteOn."

C) Monophonic without waveform restart.
   Real simple. Just keep playing the waveform until *all* keys
   routed to this range/zone are released. The frequency will be
   modulated by pitch of new NoteOn events (in ways specified
   elsewhere in thi patch data, such as "slide", portamento,...), but
   nothing else will happen, except when the first NoteOn after
   silence is received.

D) Monophonic/polyphonic - external sync.
   I haven't seen this on anything but LFOs, but I think it could be
   useful for pad and string sounds. Basically, start the waveforms
   on events unrelated to NoteOn/Off. The simplest version would be
   no sync at all; the waveforms just play on, looping, totally
   disregarding the actions of the voices that play them. Anything
   more complex would probably require real time timestretching to be
   very useful. (ReCycle style phrases triggered by a single NoteOn
   spring to mind, but probably don't belong in this cathegory.)

A and C are essential, and supported by just about all synths.
(SoundFonts *do NOT* have this feature in any version I've seen, which
is one reason not to regard SoundFont as seriously usable in their
basic form.)

B is very handy for some patches, but you can probably live without
it, at least if you're not playing live. It *is* required to deal
with sounds that need different "Mute" and "final NoteOff"
characteristict, though, so I definitely recommend supporting it.

D may be a nice and simple way to make wavetable synthesize feel
less "dead", but I've never heard it in action. (AFAIK - haven't
programmed anything that can do it anyway.)

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jul 17 2000 - 15:58:11 EEST