Messages

Do these symptoms happen when playing with the KIT menu selected on page 1?

Do these symptoms get worse when playing on UNIT - Trig / KIT page 2?

The memory card is the cause of the lag for sure. Email 2box support, give them your S/N number and they should send you a new card in the post for free.

There is a polyphony limit on the 2box which can prematurely end sample playback, but it's quite high. I don't think that's what we are talking about here though.

I seriously doubt it will make any difference because the problem is not the hardware related.

This isn't to say increasing the precision, reducing the tolerances or increasing the sensor resolution (or polling rate) of the hihat controller won't help make the experience better - yes that does help.

But none of this will give our 2box module the ability to make separate chick and splash samples, nor play a long chick sample, nor will it enable transmuting. Which is the technology that plays all openness levels simultaneously and crossfades between those levels as you move the pedal.

Using an eDrumin may be more beneficial for calibration. I can even think of a trick to borrow a zone and divert a MIDI note - but it's an ugly solution.

It's a known issue with all Drumit modules.

You must only play with the KIT menu selected, on the first page preferably, with a kit that is saved.

The UNIT menu is different because it actively loads the calibration of the last triggered pad. This clearly involves some loading of settings into memory each time - so loading things frequently enough is likely bottlenecking the memory bandwidth or the CPU, causing the lag.

Even on the recently released Drumit 5 MK2, the underlying hardware is still based on the original 10 year old design in some areas. You should get used to the quirks the longer you use 2box.


P.S. I actually believe it's a CPU limitation since if you do enough Portnoy fills in the UNIT menu, the sample playback will queue up with uniform spacing, which would indicate running to a fixed clock speed. But it could also have something to do with the Command Queuing support on my A2 microSD card. 

SCHAN is on the same page where you select the MIDI channel for the module (1-16)

I tested more with Raw MIDI monitor but it really didn't seem to do anything, on or off. It's not a omni channel mode but I haven't tested the MIDI input though.

Given it's been a few working days and the 1.40 OS isn't official, I don't think it's the final code anyway. It could take months more waiting if that's true.

Well here's some good news; 2box now sends aftertouch!

Depends on which notes you use, it works in SD3 with:

Crash 1: F4
Crash 2: F5
Ride: B4

Still can't identity what SCHAN does but it's certainly not XStick or Positional Sensing (on note 6) still only 2 zone snares with 1.40.0

Well my 2box Drumit5 MKII runs just fine on 1.40.0.

There is now an SCHAN On/Off in the UNIT MIDI. 

I can't see any other new settings in the UNIT or KIT menus. No new FX, Hihat feels the same, etc. No noticeable difference in triggering except my crashes did need adjusting. Everything triggers very well I must add.

It's by design I'm afraid. The pedal splash accounts for both the chick and splash by cutting the splash sample short. You can replace the pedal splash with pedal chick articulations from a VST and extend the sample length by increasing the hold, but its not really a solution as it affects every zone.

The artificial muting is less artificial on dry hihats, but there really isn't a perfect solution unless they add a chick zone or allow a natural decay for zone 9.

Enabling real 3 zone snare support would be an excellent new feature.

They would need to code new midpoint thresholds in the unit settings however to allow us to calibrate it properly. Are we suggesting 2box no longer has a coder on their support team, which is why they cannot even approach these ideas? 

I've not got this type of audio corruption when hitting 4 triggers at the same time, but I can only suspect it's the memory card.

Take your memory card out and examine it.

Is it a generic "microSD" adapter with yellow tape over the end? Contact 2box support and get it replaced in the post.

It could also be data corruption on the SD card, in which case you should download DI5MK2-Content Folder 1 & 2 from https://2box-drums.com/support

Then download this tool: https://www.sdcard.org/downloads/formatter to format the card and copy the contents back on it. You must use this tool with any 32GB card otherwise 2box will not boot.

I appreciate the sentiment Deve, even if you aren't supporting 2box in an official capacity anymore, knowing somebody with those connections is reading means it doesn't fall on deaf ears. 

Currently I see nothing better than 2box for my needs, even with it's follies. The only thing that can replace my Drumit 5 MKII is a better 2box module that does everything the current Drumit 5 does, but better, with a hardware upgrade in certain areas.

The underlying tech is timeless, but 2box should try to fix bugs, when they can be identified. That's really the only expectation I have till product retirement.

I believe certain settings (maybe X-Trg) aren't being preserved between power cycles on my 2box Drumit5 mkII. Even if a working config is saved beforehand, I know some settings aren't being applied until I modify the unit settings.

Issue A) At buzzroll velocity (lowest) it will trigger rim articulations on the head instead. This is with the following config:

--------------------------------------------------------------------------------
Trig            Type    Gain      Thresh   Mask   Curve   Xtalk   X-Trg   X-Adj
--------------------------------------------------------------------------------
Snare         PadPP     8            -48       1      Norm    Low     LP      0dB 
Snare Rim   AcTr2     8            -34       8      Norm    Low     HP      12dB

There is nothing wrong with these settings, I have a perfectly calibrated rim piezo on my snare.

However upon cold booting the module, issue A returns until I change a unit setting like Xtalk strength (to Medium in this case). It might not matter which setting I change, but the moment I do, it seems like my Xtalk / X-Trg settings apply correctly and issue A disappears immediately.

So it seems like certain unit settings are not loaded correctly when the module is cold booted.

With issue A being the only thing I see affected, I'm suspecting it's the X-Trg settings that aren't being read upon booting, because the .dkit has them saved correctly. So I can only guess that the boot sequence is not recalling all the saved unit settings from the dkit file.

Hopefully this bug can be resolved in a new OS Version. 

The 2box editor supports opening 44.1k 24bit but the 2box module does not. It saves it as 44.1k 16bit. However I don't think this is the cause of the problem here.

Correct, it's not latency, it's a memory access log jam, so yes it could be a memory card problem with your sample in particular (the technical reason why 2box dislikes certain WAVs is still a mystery)

I would try the following to resolve the issue:

1) Set 10 decay for all instruments
2) Change the hihat and ride on that kit to try isolate the culprit dsnd.
3) Save your dsnds with max tuning 4 (reduces the size)
4) Buy a new A1 MicroSD card

I believe I have discovered a bug whereby a footsplash (zone 9) note is triggered when striking the bow or edge while opening the hihat from a fully closed position.


A footsplash note will often replace what should have been a bow or edge articulation at the equivalent velocity layer. This is problematic for playing hihat barks occasionally.

The module doesn't seem to register (on the display) that it played a note from zone 9 when this happens either, so it's possibly not logged in MIDI - although I haven't checked this yet.

This is on Drumit5 MKII, with any hihat dsnd, with a Roland VH-11, but it would be good if other people could confirm this for me on their modules. This bug seems to be present regardless of calibration settings. If you have PFACT set accordingly to achieve foot splashes, this bug should be apparent.

Yeah a big part of the problem is a lot of the diagnosis has been guesswork, trail and error.

From my testing with halftime, we've improved things somewhat by reducing the input polling (in theory). But it's still very much a fine balancing act with 2box, as it is with Megadrum or eDRUMin. If you have one thing out of bounds, the system halts while the queue of commands is processed. I think triggering issues play an equal part to issues with the memory card.

I hope the next 2box has more headroom for error. The thresholds are very narrow currently. Just playing on the unit screen for example is enough to cause a queue. Once everything that causes a queue is resolved, then you have your perfect drum module.

Hmmm, I had no idea of the history of problems with custom samples.

If you can find a way to share your problematic DSNDs with me privately (or your DrumIt5MK2.dkit) I would be interested to see if I can experience the same issues on my 2box.


I'm suspecting you have a trigger parameter issue because I went through the same growing pains with 2box as I did with Megadrum. The main lesson from any of these "Linux" modules is; parameters make or break the experience and they give you the freedom to break it!

I don't think any of this is well documented or understood, but once you learn how all edrum modules work, you develop a sense of CPU stress or out of bounds / trigger anomalies robbing CPU cycles. 2box would definitely be susceptible. It's the same principle as the random access memory tester. If you peak once, it stalls.

I've spotted so many things like that on 2box since I got it, I haven't even had the time to write about the issues yet, but you can cause faults with trigger parameters on any module that allows it.

Have you tried disconnecting your hihat pedal? (as that sends the most continuous data) I'm pretty confident in the Kingston Canvas Go Plus 64 GB A2 - so I'm hoping this is a trigger parameter issue. I haven't done any SD2 exports with SDSE yet and the SD3 export I tried of an EZX2 kit wasn't as good as the native EZX2 export for reasons of missing velocity layers, not lag or anything of the sort.