Author Topic: Turn Off Positional Sensing in DrumKat Turbo  (Read 2541 times)

510man

  • The Kat's Meow
  • ***
  • Posts: 193
Turn Off Positional Sensing in DrumKat Turbo
« on: August 31, 2014, 02:56:06 PM »
I use a DrumKat Turbo with a ddrum4. I recently had the FSR replaced in the unit because the dynamics of the pads, Pad 1 to be more specific, had lost some dynamics, or at least I thought they had. After receiving the unit back, there is no change. Same problem so $200+ gone. It's not wasted as I'm sure the aged FSR would need replacing at some point anyway.

What I have since figured out is that the DrumKat Turbo is sending pad positional sensing data the ddrum4. The ddrum pads support this feature but I didn't know the DrumKat was capable of doing positional sensing. It's kind of cool that it has this feature but I need to turn it off. Why?

The DrumKat pads are pretty small. Trying to stay in a two sq. inch section of the pad when reading a chart or playing with any speed is quite difficult. Second, the positional sensing is backwards. So for the snare drum, the smacking backbeat sounds are at the edges of the pad and the sounds you'd expect when playing near the rim of an acoustic drum are at the center of the pad. This creates a very inconsistent sound through the FOH system. The same thing happens on a HH pad. However, the softer bow sounds are in the center of the pad and the heavier edge sounds are near the edges of the pad. While this aligns well with how an acoustic HH works, it's difficult to play the bow or edge consistently on such a small pad.

The ddrum4 also supports velocity sensing. I assumed the DrumKat would only send velocity data and the ddrum4 would respond across its eight samples per drum accordingly. I need to keep velocity sensing turned on but positional sensing off.

Here's the questions. This has to be a MIDI controller setting the DrumKat is sending (aftertouch, etc.). What is it and how do I turn it off? What setting within the DrumKat sends the MIDI positional sensing data? If there's not a global setting, can I send a kit level MIDI command for each kit to turn it off?

Thanks for any suggestions here.

Vkat

  • The Kat's Meow
  • ***
  • Posts: 177
  • I'm a llama!
Re: Turn Off Positional Sensing in DrumKat Turbo
« Reply #1 on: October 11, 2014, 08:29:15 PM »
My drumKat is an older Non-Turbo model, but I would like to mention a few points.
I was not aware that the Turbo upgrade, was sending "positional" information.
AFAIK, the drumKat FSR is incapable physically, to send out different
"positional" information depending on WHERE you hit the pad.  It is sending out
that "positional" information, which is actually a CC# (often #16 or 17), that is
responding to how HARD the pad is hit.
I could be wrong about this, and hopefully Mario, or someone more knowledgeable about the Turbo will chime in.
In the meantime, I would suggest you connect your drumkat to a computer, and
use a program like"MidiOx", to see exactly what Midi information the Kat is sending.

gmbydmit

  • Extra Special KAT Poster
  • ****
  • Posts: 493
  • legend in my own mind!
Re: Turn Off Positional Sensing in DrumKat Turbo
« Reply #2 on: October 31, 2014, 04:17:14 PM »
I have a couple Turbo DK's and there is no positional sensing that I am aware of. The AM instruments that have FSR's, are very dynamic, but there is no positional sensing per pad....unless he is referring to Velocity shift mode, then one pad may appear that way, depending on where velocity shift takes place....

it sounds like the ddrum is similar to Roland's Vdrum module....different velocities (i.e. the further away from the cone on a Mesh drum you are makes the velocities decrease) internally telling the module to play actually a different note # or like Vkat said sends descreet internal CC's





510man

  • The Kat's Meow
  • ***
  • Posts: 193
Re: Turn Off Positional Sensing in DrumKat Turbo
« Reply #3 on: December 06, 2014, 09:26:20 AM »
Back on this one. I sent the DK to Mario. He confirms the Turbo does not send positional sensing data. However, I made Mario a video demo where he could hear the drum change sounds as I moved across the pad. So it's incapable of doing it, but it clearly doing it.  :-)  We just don't know how. Mario and I both hooked it up to MIDI Ox and there's no controller info moving across the MIDI cable. Mario and I both remain perplexed.

I had the FSR and the board replaced so it is, in effect, a new DK Turbo. With those changes, it still does audible positional sensing. In fact, having experimented more, it does it on all pads. It's just more noticeable on the snare pad and HH than the toms and cymbals.

Unfortunately, Clavia no longer owns ddrum and the new owner, Armadillo, knows very little about the electronic products and moved ddrum to an acoustic brand. Most of us know that Clavia didn't follow the MIDI standard on ddrum products so there's no telling what the ddrum4 is interpreting to create the positional sensing response. At this point, I will likely sell the ddrum4 and move to something else. Too bad as its sounds are quite good.


510man

  • The Kat's Meow
  • ***
  • Posts: 193
Re: Turn Off Positional Sensing in DrumKat Turbo
« Reply #4 on: May 21, 2015, 03:49:14 PM »
Still working through this problem. It does the same on a DM Pro, Yamaha DTX900, Roland TD-12 and a Korg Triton Extreme. That's five separate sound sources. While the Turbo can't send positional sensing data, its' sending something that the sound sources are reading as positional sensing since there are no other MIDI sources sending data to the modules and keyboard. I've had three sound sources connect at one time and they all respond the same way simultaneously.

510man

  • The Kat's Meow
  • ***
  • Posts: 193
Re: Turn Off Positional Sensing in DrumKat Turbo
« Reply #5 on: April 25, 2016, 06:02:19 PM »
This problem progressed to another level over the last 18 months. I have failed my original Turbo board, a loaner Turbo, a replacement Turbo board, three DK10 boards and a DrumKat 3.8. All units show some positional sensing then the pads start dropping notes. Eventually multiple pads stop working altogether. The pads may come back on temporarily if hit really hard or flammed with Pad 10 (not sure why this pad). Also, the flam must be a left flam with the failing pad played just after Pad 10. Resetting does not recover the unit. May be tied to the Dallas chip memory, but that doesn't explain the DK10 having the same issue. It doesn't have a Dallas chip. Net, the board has to be replaced to fix it. It plays great for a few days and then the cumulative failing process starts over.

The problem is likely environmental. I've had the power company install monitors on my house looking for harmonics issues, etc. Nothing. I've had units fail running on UPS battery power completely off the grid. Mario's team has been super supportive in trying to sort it out. They too are perplexed as I'm the only customer to ever experience this problem. I need the failed boards analyzed at the component level to see what is failing and then determine why it's failing. AM doesn't do component analysis. I totally get it. It doesn't make sense for them to do since replacing a relatively inexpensive board has historically resolved any problems seen. It's not cost effective to do component analysis unless many failures occur, which hasn't happened given it's a high quality product.

Failing a board when not connected to the grid has me stumped. Airborne interference? All pedals, controllers, wires, etc have been replaced. I don't know what happens if a MIDI cable crosses up. Mine all test good with the wire tester. I'd assume it wouldn't play if the MIDI cable is bad. however, it could, in create other problems and has done so in keyboards having read some keyboard forums.

I now need analysis help from the OEM that manufacturers the boards. They have to be able to troubleshoot components as part of the manufacturing process. Unlikely to happen though.

I've looked at other options and it quickly refreshes my memory as to why I've stayed an AM customer. The competitive products, frankly, don't work very well in comparison.