You are here

Review, question/suggestion on mapping and MIDI controller.

Yep! The old-school drum-kit sampler Drumkv1 is a hit.

Rui has done a great job on another fine piece of software.


I have been creating soundfonts with Swami to load into Qsynth
with custom drum kit samples, it's tedious but works.

The main reason and problem to solve was always having to load
the same soundfont numerous times so individual drum sounds can
be panned without appling the pan in the actual .wav sample.

The MIDI spec does not really take drum kit notes into consideration
for continous controllers like pan, pitch etc just an overall
track setting that is applied to all events on the track. The
drum notes can be split into individual tracks and audio panning
used once the individual track audio is recorded back in but it's
also tedious and time consuming. Cubase solves this with VST but
it's not available on Linux and not always the easiest thing to use.
Qtractor may already do this too and I just have not found it.

With Drumkv1 the pan setting actually operates on the individual
drum note (drum sample) so cymbals, toms or any sample can all be
panned individually from the loaded kit. The MIDI drum track can
now stay together. I was hoping to find somthing that could do just
this and Drumkv1 has it.

It's really easy. Sample some drum sounds or download some free
ones and start building kits. No need to create a soundfont, no
multiple instances of the soundfont just simple .wav files loaded
into a logical drum kit.

The phaser effect brings back some fond memories.

Couple of thoughts :

When adding samples and saving the kit it would be nice if a separate
file could be attached with a user defined drum map. One drum sound name
for each of the notes that map the custom drum kits to the standard 0-127
MIDI notes. Basically, custom kits rarely line up with the standard
GM/GS defined naming. Nothing fancy needed just a user defined note
name to the actual MIDI note number.

MIDI automation comes to mind. I have not tried this yet but it could
be usefull if Qtractor MIDI controller messages could set some of the
parameters on the drum kit or effects.

If controller messages are handled then a really nice one to handle
would be the CC#4 (foot controller). Most electronic kits today send
CC#4 for the hi-hat pedal. With the CC#4 value between 0 and 127 and
a little mapping the hi-hat could trigger more than the standard 3 sounds.
With 0 being fully open and 127 fully closed a set of ranges could be
used to map a different hh-hat sound based upon the foot controller.
Then samples like : (closed tip, 1/4 open tip, 1/2 open tip, 3/4 open tip,
open tip, closed edge, 1/4 open edge, 1/2 open edge, 3/4 open edge,
open edge and pedal chic) could be trigged by 2 midi notes and the
value of the foot controller.

Today I preprocess the .mid files as described above and actually create
the correct hi-hat MIDI note-on/off events (base on CC#4 value) to map with
a set of custom hi-hat samples. The CC#4 events are also removed
during the process since the new events usually need to be tightened
up in the mix.

I would say Drumkv1 covers 90% of what I need in order to create
easy nice sounding custom drum kits .

Thank You Rui!

rncbc's picture

hi, thanks for your thoughts. really appreciated.

re. MIDI automation: besides the fixed CC#1 (modulation), CC#7 (channel volume), CC#10 (channel panning) pitch-bend, there's nothing much you can do via explicit MIDI controllers. however, there's the possibility to automate any of the current parameters as in the plugin form when controlled under a lv2 host like qtractor or ardour3. add to that that you can assign any MIDI controller to any plugin parameter then you'll have MIDI automation alright.

alas, there's a catch that applies to the way drumkv1 works though: automation applies only and dynamically so to the parameters of the current selected element, selection of which is only accessible via the GUI--that probably makes it all a nonsense curiosity as far as the drumkv1 automation possibilities goes. sorry for that, but that's the way it is ;)

cheers && happy holydays

Hi Rui, thanks for the reply.

Good to know about the lv2 automation potential.

I noticed that sometimes the saved drum kits do not pull up the
assigned saved samples when I reload Drumkv1. Saw some information
about physical path vs relative path being a problem in an earlier
version. I am using the 0.5.1 build from the Fedora 20 repository.

When I looked over the ~/.conf/ the paths
are stored with the physical path and are correct. There are
no spaces or special characters in the path or drumkit name. I
also see that the actual drum kit file looks fine. I made a backup
of the kit and compared them, they are the same. If I point to
the backup the samples do not load either.

I wonder if there is a specific setting I have tweaked that is causing
the load of the drum kit file to fail. I am just running Drumkv1
in standalone mode not as a plugin yet. I launched it from the CLI
to see if any errors were being output to the console when selecting
and drum kit and have not seen anything related to reading or writing the
drum kit file, just a deprecated font conf when launching and that's all.

So, I am a old tired musician/developer (my pay job is developer HA!), I
download the source project to take a peak. [scary music starts] Now when
I say developer I mean back to the 70's (370 Assembler, COBOL, CICS, C) up
to today which is all Java so my C++ skills are lacking to say the least.

Before I dabble into the source I'm thinking strace when launching drumkv1
to see if the file read and writes are occurring on the drumkit files
based on the path in the drumkv1.conf, maybe the path is different.

Next, download Qt designer and save the world but, before that :

Is there a already known solution?


rncbc's picture

make note that literal paths to all samples are actually stored as references in the preset xml file (.drumkv1 suffix) and not on the .conf file which deals about the user preferences and configuration--all sample file paths are (should be) stored relative to the .drumkv1 preset file location. nothing else matters.

if, for instance you move the .drumkv1 preset file around, then you also should (must) move the sample files in the same way around, as far to keep the relative paths reachable and loadable alright.

does any of the above make any sense and does it possible related to the issues you're finding?


Thanks Rui,
I just keep the samples with the .drumkv1 so everything stays relative.
Still not sure what I did to make this happen. I will keep a tight track
of what I do so if I duplicate the mistake I can let you know.

Add new comment