eDrummer beta

[j_e_f_f_g]

I just finished the initial beta of my eDrummer software. This is a program that turns your computer into a drum sound module. Attach a MIDI controller (ie, MIDI drum pads, MIDI keyboard, MIDI guitar, etc) to your computer, and play a drum kit live via your computer's audio out. Or you could attach a MIDI sequencer, and have that play drums.

Think of it as a very, very simplified version of Linuxsampler designed for one purpose only -- to play a drum kit live. What does it do that Linuxsampler doesn't already do, you ask? Absolutely nothing whatsoever. Linuxsampler is a very complex sampler designed to play an extremely large variety of "instruments" in many different ways. It can certainly play a drum kit. But such complexity and versatility comes at cost, not only in the difficulty of configuring it for live use, but also in terms of processing overhead (which adds latency -- very undesirable for live performance).

eDrummer is designed to do its one thing with minimum overhead, and as little configuration as needed. It doesn't use Jack (with its horrifically slow process-boundary-crossing daemon, and float to int conversion for every single sample). eDrummer uses ALSA's lowest possible latency mode. And no floating point, so it's doable on that old computer collecting dust, or one of those $60 computers (ie Raspberry, Pandaboard).

If you want to try eDrummer, here's a zip file. It contains a 64-bit executable ("edrummer"). If you run a 32-bit OS, then you'll have to compile sources, or wait for... ::looks around:: ... GMaq to do it. Thanks for volunteering, G.

http://home.roadrunner.com/~jgglatt/edrummer.zip

Of course, you also need a drumkit. (The kit is separate from the program). edrummer uses a compressed kit format to reduce ram use. I provided a version of the Salamander drumkit here:

http://wikisend.com/download/431872/drumkit.zip

Note: Still a 90MEG download. That kit has only 2 toms. I've mapped the sounds to these MIDI notes (per Roland V-drum assignments). This can be changed, and after some testing with this kit, I'll release a utility for making kits.

Code: Select all

HiHat open:            46(A#2)
HiHat half open:      26(D1)
HiHat Tip closed:     42(F#2)
HiHat Edge closed:   22(A#0)
HiHat Pedal:             44(G#2)
Snare:            38(D2)
Snare Stick:    40(E2)
Tom 1:           48(C3)
Tom 2:           31(G1)
Ride:              51(D#3)
Ride Bell:        53(F3)
Crash:       49(C#3)
Kick 1:            35(B1)
Kick 2:            36(C2)

Unzip the kit, and put the files "edrummer" and "default.kit" in the same folder (with all the .cmp files).

The first time you run edrummer, click on the words "MIDI in". This will present a list of MIDI ins on your computer. Click on the one your controller is attached to. (Set your controller to MIDI channel 10).

Now click on the word "Audio". This will present a list of audio outs on your computer. Click on the one you want to hear the drums out of.

I recommend you exit the program now (before it crashes -- hey it's beta), and it will permanently save those settings. Whenever you rerun it, it will resume with those settings. None of this godawful, hair-pulling jack "session management" nonsense.

Lowering the Buffer setting reduces latency. Clicking on the big up or down arrows raises or lowers it. There are key shortcuts too, and those are shown in the bottom of the window.

Report any bugs, so I can ignore them. Hey, that's how developers have fun.

[GMaq]

Hi,

32 bit Zip here: http://www.bandshed.net/avlinux6-debs/e ... -32bit.zip

[phanaton]

Hi jeffg,

Great you already wrote most of the stuff and also included the sources .

I've directly tested it:

Report any bugs, so I can ignore them. Hey, that's how developers have fun.

So I have to report a few bugs already:
If you are in the 'Midi in' or the 'Audio' menu and press the up or down arrow, all available devices are shifted down.
Here is the reason:

Code: Select all

void dspDevName(void *gc, const char *cardName, const char *devName)
{
    ...
    y = (DevNum * 42) + 20;
    ...
    ++DevNum;
}

DevNum gets incremented, but never decremented.

Next bug is, if the you try to select the same midi-device as already used(I only have one right now) this error comes:

Code: Select all

edrummer: rawmidi.c:985: snd_rawmidi_read: Assertion `rawmidi' failed.

I'm not to much into all the midi/alsa stuff right now, so I couldn't really debug it...

Well annother bug is, if you try to lower the buffer-size, no sound is coming anymore, also if you change the buffer size back to its initial state.

And it has quite a problem with the loopback device(snd-aloop).
Like the name it loops the device in the 'Audio' menu like this:

Code: Select all

Loopback loopback00
Loopback loopback00
Loopback loopback00
...

I had to unload the module, to get it working...

A small bug is the 'Volume Up' triangle button, which is not working...

Since this is in a very early beta state I don't want to fill the whole thread with bugs

Alright since I have high demands(lowest latency ever possible) I was critical, and measured the program vs linuxsampler(both snare):

About 10-14ms system latency with edrummer(44k, 32 frames)
About 5-7ms system latency with linuxsampler and jack(also 44k and 32 frames)
All with my Audiophile192(snd_ice1724)

I edited all the snare-samples of the salamander-kit for linuxsampler(removed the silence at the beginning)

For informations to the Module-latency I made a good measurement for my TD-8:
(It's german, because I posted it already in a german forum: http://www.drummerforum.de/forum/p10721 ... ost1072181)
translation for 'Standardabweichung' = 'Standard deviation'

I measured the both programs with 0ms scan time.
You have to add 970µs latency because of the slow midi connection via the old DIN-connector...

Maybe if you try it with realtime-mode it's a bit faster... Or do you have already removed all the silence at the beginning of the snare? Since the lower tom isn't edited, because I could hear latency of about 20-40ms.

By the way are you programming in assembler a lot? Or is it common for very performant applications to use that often 'goto'?

Well don't take the facts to seriously

Best Regards
Philipp

[j_e_f_f_g]

I uploaded an update with some fixes.

If you are in the 'Midi in' or the 'Audio' menu and press the up or down arrow, all available devices are shifted down.

Yep, that should be fixed now.

try to select the same midi-device as already used this error comes:

Doesn't happen here with my usb midi device, but in looking over the code, I could see a potential race condition depending on how your MIDI driver is written, so I addressed that. See if the fix works.

if you try to lower the buffer-size, no sound is coming anymore, also if you change the buffer size back to its initial state.

Hmmm. Again, that's working here. And offhand I can't see a reason for why it could fail. What happens if you restart the program with the new buffer setting?

Also, start edrummer from a terminal window and check if there's any messages about unrecoverable errors.

problem with the loopback device(snd-aloop).

Again that puzzles me. I don't have snd-aloop installed, so for now, I just coded a workaround.

'Volume Up' triangle button is not working.

Fixed.

measured the program vs linuxsampler

Actually, edrummer's buffer size is in samples. Since it uses stereo (2 chan) output, 32 buffer size is actually 64 frames. And you shouldn't be using 44K with the salamander kit because it's 48k sampled. edrummer does no interpolation on samples, so at 44K those samples are just playing back slower than they should. With edrummer,all waves in the kit must be the same rate, and you must set edrummer to that rate. Linuxsampler undoubtably interpolates to 44K if that's what you set.

Try 48K and play the kit. How does the latency "feel" to you? If it's bad, you'll know it by how the timing feels. There are ideas I have yet to try to see how they affect timing. But right now, I'm looking for problems (like "this isn't even close to playable live" in which case some major redesign may need to be made).

[phanaton]

Hi jeffg,

Thanks for the fast fixes.
Now every bug I noticed is fixed .
Midi device reselect works, audio/midi device (up/down) selection works well and the loopback bug is also away!
Just on the fly changing of buffer size and Samplerate doesn't work, but this could be a hardware limitation...

Well then me as a performance junkie, I measured again with buffersize = 8(or like you said 16, because of stereo).
Well to make it short: I could reach with this setting 5-6ms!

Now just for interest, I lowered the lower bound of the buffersize to 1 frame.

Well just started the program, in the thought I only get junk as output, but - just a few xruns witch aren't really noticeable!

With a big grin on the face I measured it again(all with 48k): 3.5-4.5ms latency, thats about 0.4-0.9ms audio latency!
Damn what the hell!!

Just for further interest, I set the Samplerate to 96k (high pitched Snare )
And I got down to 3.3ms latency, just a very few xruns/underruns, not really noticeable (about 0.1-0.5ms audio latency).
What the heck! 1 Frame per channel at 96k
Thats f** fast!
I couldn't really believe it, so I had to made a few measurements, but all with nearly the same result(3.3-3.45ms system latency).
Wohoo that made my week .

Sorry for the euphoric rage, but this is just great, and shows, that not the hardware is the performance limit.

To the feeling side:
Yeah there is definitely a difference between 4ms and 10ms, I can play with both, but 4ms just feels faster, the response of everything is just more directly.
This just makes it hard to change to Superior Drummer again(I like the sounds very much), which is running at 10ms system latency...

Just a suggestion: Add also the possibility, to go down to at least 2 frames buffersize, wich is definitely possible without much xruns(I got in 10 minutes of playing maybe 10 underrun messages, but couldn't really hear those)

RT-Kernel + your edrummer app rules.

Ok to come down to earth again :

There are a few things wich I would like to see in the future:

setting the volume with the velocity message of midi( I think that lacks right now, (doesn't it?) because for example the kick has just the three vel-samples and is always quite loud)
Well the Hihat open/close switching is not optimal right now, do you know how it works in Superior Drummer? Like a short foot step/close, which lowers the volume, or makes a new close-open sound(for more perfectness, even a new sample for this, but then we might need a new sampled kit)

Well and then just more dynamic interface for the future, like midi-note-learning, maybe something, that shows all the drums and cymbals like in Superior Drummer.
But that doesn't need the highest priority right now...

Ah before I forget: I just noticed the Kick-"click" bug in your modified samples, which is described at the salamander drumkit homepage, I already fixed those, and removed all the silence at the beginning(which you mostly already did).
To take some work from you: maybe you send me the the utility(maybe per pm), you used for converting the kit, and I edit the samples to an optimum(for example removing the silence at the beginning of the floor tom). So you can focus on developing .

Best regards
Philipp

[j_e_f_f_g]

on the fly changing of buffer size and Samplerate doesn't work, but this could be a hardware limitation

No, it's undoubtably an ALSA quirk. I just need to figure out how to get ALSA to do what I want. This is not a critical bug though, so I'll work on other stuff first. Later on, remind me if I forget about it.

I lowered the lower bound of the buffersize to 1 frame.

You set buffer size to 8, or did you change the source to go lower than 8?

Thats f** fast!

Good. That's the whole point of this -- to make something suitable for live performance.

go down to at least 2 frames buffersize

Ok. My dev system is running stock Debian (no RT), so I couldn't test that low, and assumed it would be unrealistic.

setting the volume with the velocity message of midi

It does that. But the algorithm is not log. That may need adjustment (or you could modify the waveforms themselves).

Hihat open/close switching is not optimal right now, do you know how it works in Superior Drummer?

No, and this is what I need more details about.

a short foot step/close

How do you detect when it's "short". The pedal doesn't send note-off? Am I supposed to measure the time (or distance) CC4 goes from non-zero to zero?

more dynamic interface

Well, the kit is defined in a text file, so an enduser can change things. But I'll probably later do a separate GUI app for making a kit.

noticed the Kick-"click" bug in your modified samples

I fixed kick_P_1.wav. Was there more?

send me the the utility

I'm working on porting it from Windows to Linux. Should be within days.

[phanaton]

You set buffer size to 8, or did you change the source to go lower than 8?

Yes I set this Line:

Code: Select all

period_size = buffer_size * NumChans * (0x00000008 << FrameSize);

to this:

Code: Select all

period_size = buffer_size * NumChans * (0x00000001 << FrameSize);

and since "FrameSize" can reach zero, the effective Frame-Size can be 1 Sample per Channel right?

I also adjusted the rest of the code so that it will be also shown:

Code: Select all

...
static const char	FrameStrs[] = {'1',0,'2',0,'4',0,'8',0,'1','6',0,'3','2',0,'6','4',0};
...

Code: Select all

...
case XK_Right:
		{
			if (!WindowOp && FrameSize < 6)
...

Ok. My dev system is running stock Debian (no RT), so I couldn't test that low, and assumed it would be unrealistic.

Good to see whats possible .
Well the rt-kernel shows it's strenght here(all in µs):

Code: Select all

cyclictest -t1 -p 80 -n -i 10000 -l 10000
policy: fifo: loadavg: 0.93 0.77 0.59 1/334 8744          

T: 0 ( 8743) P:80 I:10000 C:   1048 Min:      2 Act:    9 Avg:   12 Max:      48

No, and this is what I need more details about.

Well I can record a midi-file, with Hihat fast close(step) and just normal Control if you want to.
Also maybe with some aftertouch from choking the cymbal.
Just some special things that aren't obvious.

I'm working on porting it from Windows to Linux. Should be within days.

Nice, I'm waiting for it.

I fixed kick_P_1.wav. Was there more?

There are also some clicks in the "high tom" etc. I just edited the original sample etc. with linuxsampler its now good.
Don't fix that much, I will do it , the time you need to port the utility to linux, I can remove all the silence(Sampleaccurate) and clicks etc.
Then I can upload it...

Maybe I'll send the whole edited kit also to the original owner...

Best regards
Philipp

[j_e_f_f_g]

I set this Line:

Ok, I can make that change. It will break the settings file format, so you'll need to redo/resave your settings. But I expected there may need to be some disruptive changes this early on.

zero, the effective Frame-Size can be 1 Sample per Channel right?

Yep. Since edrummer does a stereo mix, what you've done is ask for half a frame rate. But it's doubtful that's what you're getting. That's what edrummer is asking your ALSA soundcard driver for. But if your driver can't do that, it has 2 options:

1) Report an error to edrummer. (Not happening because then you'd see edrummer show an error message).
2) Use the lowest possible buffer size the driver supports, and expect edrummer to use that.

I suspect #2. After edrummer requests its size, and there's no error, edrummer then asks the driver "Now what size did you really give me?", and uses what the driver demands. edrummer doesn't report any discrepancy. It's a moot point because if that's your driver's limit, then that's it. And that's why you can't trust measurements that are made via software running on the same system, Your measurement system needs to be isolated so that software/driver 'quirks' don't affect the measurement.

One thing I'm pretty sure about -- you're almost certainly getting the lowest latency on the audio. I do have some idea on a possible speedup for MIDI input... later. But your best bet would be to bypass MIDI baud altogether, and rig up some USB-MIDI hardware you can directly attach your pads to. I know how to write an ALSA MIDI driver, so if you want to do the hardware, I can do the software part.

I can record a midi-file, with Hihat fast close(step) and just normal Control if you want to.

If you could do that, and also include a wave (ogg, mp3) of superior drummer playing those messages, then I'd know how to implement it.

aftertouch from choking the cymbal.

Ditto, but separate from the hat stuff.

[phanaton]

I suspect #2. After edrummer requests its size, and there's no error, edrummer then asks the driver "Now what size did you really give me?", and uses what the driver demands. edrummer doesn't report any discrepancy. It's a moot point because if that's your driver's limit, then that's it. And that's why you can't trust measurements that are made via software running on the same system, Your measurement system needs to be isolated so that software/driver 'quirks' don't affect the measurement.

Interesting Point, I just made a test:

Code: Select all

		printf("FrameSize = %d\n", (0x00000001 << FrameSize));
		printf("Buffer Size before: %d\n", buffer_size);
		printf("Period Size before: %d\n", period_size);

		snd_pcm_hw_params_set_buffer_size(AudioPlayHandle, hw_params, buffer_size);
		snd_pcm_hw_params_set_period_size(AudioPlayHandle, hw_params, period_size, 0);
		snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size);
		snd_pcm_hw_params_get_period_size(hw_params, &period_size, 0);

		printf("Buffer Size after: %d\n", buffer_size);
		printf("Period Size after: %d\n\n", period_size);

Output, when changing the Buffer size from 64 to 1 Frame:

Code: Select all

FrameSize = 64
Buffer Size before: 1024
Period Size before: 512
Buffer Size after: 1024
Period Size after: 512

FrameSize = 32
Buffer Size before: 512
Period Size before: 256
Buffer Size after: 512
Period Size after: 256

FrameSize = 16
Buffer Size before: 256
Period Size before: 128
Buffer Size after: 256
Period Size after: 128

FrameSize = 8
Buffer Size before: 128
Period Size before: 64
Buffer Size after: 128
Period Size after: 64

FrameSize = 4
Buffer Size before: 64
Period Size before: 32
Buffer Size after: 64
Period Size after: 32

FrameSize = 2
Buffer Size before: 32
Period Size before: 16
Buffer Size after: 32
Period Size after: 16

FrameSize = 1
Buffer Size before: 16
Period Size before: 8
Buffer Size after: 16
Period Size after: 8

Can I expect now, that the driver is working with such a low Framebuffer size?

Just for interest what happens, if only one Channel will be filled, I halfed the buffer/period size again, thats the output:

Code: Select all

Buffer Size before: 8
Period Size before: 4
Buffer Size after: 8
Period Size after: 4

Start error: Broken pipe

Your measurement system needs to be isolated so that software/driver 'quirks' don't affect the measurement.

You think so? All my measurements made quite sense, I think. What quirks shall happen?
I would do it, but I don't have the possibility right now(digital oscilloscope etc.)

so if you want to do the hardware

Well exactly that, I'm planning right now, but it's not that trivial, because if it shall be good after all, you need quite good DSP for it. Well at least I would say it will take a long time from now, to get reliable results...

By the way: you are using this tool with a keyboard right now?

If you could do that, and also include a wave (ogg, mp3) of superior drummer playing those messages, then I'd know how to implement it.

Here you go

Hihat_slow_close_open:
1. test: closing slowly the Hihat, while hitting with the tip of the stick
2. test: same as above, but with the edge of the cymbal
3. test: opening slowly the HiHat, while hitting with the tip of the stick
4. test: same as above, but with the edge of the cymbal

Hihat_Stomp:
Well obvious, just a fast close and then opening of the HiHat.

Crash_Ride_RideBell_Choke:
Also obvious, a few dynamic Levels, with different chokes, on Ride and Crash.

Shuffle_Beat:
Just a short and easy reallife Example with opening the Hihat(the timing "errors" are swing )

Well I haven't edited really, they are raw stuff, and you see even Superior Drummer isn't 'superior' with the Hihat stuff, it sounds kinda weird.

The "jumps" in the CC4, are because of the hit-impulse of the stick, its not really optimal, but to avoid that I need to set the spring of the Hihat to something mutch to high...
Generally I would say the Hihat controller would need a higher range for closing and open, and something, that recognizes the last very hard press(with an acoustic drum set there is a difference between normal press, and hard press with the foot).

If you need more feel free to ask.

Best regards
Philipp

[j_e_f_f_g]

It appears that your driver is giving me whatever I ask for, even if it's unworkable (ie broken pipe). So if it works with a period size of 8, with no broken pipe or heaps of xruns, then it works. Frankly, I'm surprised it works. Clearly, the latency of the audio output of edrummer on your system is a non-issue. I would bet that any attempt to reduce the overall latency with edrummer has to focus on replacing your midi connection with usb.

Have you looked into using a Brain Jr (http://lividinstruments.com/hardware_builder.php)? It's a DIY programmable USB-MIDI class compliant device designed to attach switches (ie, your pads) and pots (ie, your hh pedal). It already has the logic to generate midi note-on from the switches, and controller from the pots. It may suit your purpose right out of the box in just its default state.

http://wiki.lividinstruments.com/wiki/Brain_Jr

Here you go

I can't get it. It requires some windows d/l utility. Can you use http://wikisend.com ? It's free, doesn't require you to use Windows spyware to upload/download, and doesn't even require registration (although you can register if you want to be able to delete files you previously uploaded). I used it to upload that salamander kit.

[phanaton]

I would bet that any attempt to reduce the overall latency with edrummer has to focus on replacing your midi connection with usb.

Yeah thats it, Midi via the old Din-Connector is kinda slow(needs 970µs to send one note, if positional sensing is enabled it needs even 2ms just for the transfer...).
A Megadrum with ARM-Processor would get me superior Latency of maybe 1.5-2ms!

But I think everything under 5ms is meaningless for me, so I will stay with my TD-8, which has better dynamic recognition than the Megadrum-module...

Have you looked into using a Brain Jr (http://lividinstruments.com/hardware_builder.php)? It's a DIY programmable USB-MIDI class compliant device designed to attach switches (ie, your pads) and pots (ie, your hh pedal). It already has the logic to generate midi note-on from the switches, and controller from the pots. It may suit your purpose right out of the box in just its default state.

Well the whole stuff isn't that easy, just switches won't do the job, the dynamic gets lost, which is really important to me(and hopefully any other drummer)
There is needed DSP for getting the right dynamic, well at least you need an ADC, to get the volume out of the Pad.

But this device is quite nice for creating MIDI-Controllers thanks for the tip.

I can't get it. It requires some windows d/l utility. Can you use http://wikisend.com ? It's free, doesn't require you to use Windows spyware to upload/download, and doesn't even require registration (although you can register if you want to be able to delete files you previously uploaded). I used it to upload that salamander kit.

Strange, I can download the file... you need to click on the right small download button, it could be that there is some misleading Download-Button Add...

wikisend didn't work for some reason(tried to upload 3 times)... Nevermind here this should work: https://docs.google.com/file/d/0B76jwZp ... VtZ2s/edit

[j_e_f_f_g]

just switches won't do the job, the dynamic gets lost

Duh! I don't know how I overlooked that. Those are piezo electric sensors on your pads? I wonder if there's simple way to hook them up to the brain's pots through some sort of gate that triggered once when the sensor signal rose above a certain level, and didn't trigger again until after the signal fell below the threshold? That would give you the velocity.

For that matter, did you look at their newer unit Brain v2 (http://wiki.lividinstruments.com/wiki/Brain_v2) ? It says it supports velocity sensitive pads, and is easier to program via a PC.

this should work

Got it.

[j_e_f_f_g]

Phil,

I uploaded the compressor:

http://home.roadrunner.com/~jgglatt/convertwave.zip

It's the executable "convertwave" in the WaveCmp folder. It just throws up a file dialog telling you to select a wave. When you do, it makes a compressed copy with a .cmp extension. Then the dialog appears again to compress another wave. Click "Cancel" to terminate.

There's also a text file explaining how to manually edit "default.kit".

A GUI "Kit Maker" will later replace the above, but for now, you can make your own kit (perhaps with sounds you capture from superior drummer, and get a more accurate idea of what needs work). Just don't bother with aftertouch or controller. I didn't implement those until I study the example files you sent.

[j_e_f_f_g]

Now I know why superior drummer doesn't get your HH right. Your HH doesn't behave like a real HH. For example, at almost the same time, it says you're playing both the edge as well as the tip of your HH closed, while also stepping it. What???

I may need some more midi files of that HH, but for right now, I've made a try at implementing the pedal. Try the latest version. Set "HH pedal" to "Foot", and "Polarity" to "-". Make sure you use my new default.kit file.

These new settings mess up your saved settings, so you'll have to redo your settings (including MIDI and audio cards), and restart the program. Buffer size now goes down to one. Also, I fixed that other bug. You don't have to restart after changing buffer size.

[phanaton]

Hi jeffg,

sorry for not replying the last time.
Thanks very much for the compressor you uploaded, I'm now finished with removing all the silence from the salamandar kit to "Sampleaccurate" (536 Sounds, phew what a work...)
Incidentally, I also fixed the "click" bug of various sounds...

I adjusted the drums-configfile(default.kit) to my needs, including volume on some pads like the Hihat, Ride(decreased, because they were much to loud)

I uploaded the whole kit(every sound) including my "default.kit":
http://rapidshare.com/files/716882774/S ... it.tar.bz2

I think I also write an email to the owner(Alexander), if he wants to use my "corrected" version...

By the way it has a problem with 24 bit sounds, I think you should check the dithering algorithm here:

Code: Select all

...if (file.fmtdata.wBitsPerSample != 16)...

It also should check if it is a 32bit file etc.
Annother question, why aren't you using for example libsndfile? You would have much more options for loading sounds(like flac etc.)

Now I know why superior drummer doesn't get your HH right. Your HH doesn't behave like a real HH. For example, at almost the same time, it says you're playing both the edge as well as the tip of your HH closed, while also stepping it. What???

Yeah I can explain this, when I stomp on the Hihat-machine, the Pad gets the vibrations from the hitting on the clutch, and interprets that as hit on the tip or edge.
But thats not the main problem I mean, it's more the blending between the sounds (in this (future) case eg. "hihatSemiopen5" to "hihatSemiopen6")
That sounds just weird and unnatural in Superior Drummer...
I think, it's kinda difficult to get a realistic blending between those sounds...

I may need some more midi files of that HH, but for right now, I've made a try at implementing the pedal. Try the latest version. Set "HH pedal" to "Foot", and "Polarity" to "-". Make sure you use my new default.kit file.

What exactly has changed? Is there any "hearable" difference? If not, then it works...
For future versions: You could check which cc4 information is actually, and play a defined sound like "hihatSemiopen5" or so...
That may require a change in the "kit" format, for defining which sound at which cc4 information should be played...

I might have an idea for the right choking:
Look at this picture("stolen" from the german drummerforum, which I already linked to above):

You could implement something like the yellow line(capacitor effect), and do the choke sound, based on that volume/velocity, when the choke sound shall be played.

Annother idea:
I saw how you made it with polyphonic sounds(defined array with size = MAX_AUDIO_POLYPHONY)
The size of 8 you set is to little I think, if you play a lot of ride(long sounds) and then a roll on the snare, it sounds weird,
so I set it to 128(even with 64 I felt this effect).
But I think then it's more efficient to implement it as "Doubly linked list", since you could have dynamically amounts of sounds that are currently played(you could also set a limit if thats desired). But if there is only played a very few sounds, I would say it's definitely faster than the static array of a size like 128.
Just a suggestion...

For the dynamic volume(silent hit, loud hit...):
That definitely needs some "rework". I would do it as logarithmic volume curve, maybe also add an option on the "kit" configfile....

For the midi stuff:
Just ask what you need, I'll do it .

Some nice words :
You are almost at the quality of Ez-drummer(just faster), with the Salamander kit...

Best regards
Philipp