Cross talk cancellation doesn't work reliably

[3hhh]

My set has a lot of cross talk and setting all cross talk values of all pads to 31 still doesn't fix it.

I even set the cancellation time to 100ms, but I still observed cross talk on e.g. hard snare rim shots.

Imho the issue probably lies with the algorithm:
If I understand it correctly, it simply checks whether there were higher spikes in the past. However I observed in practice that cross talk spikes may actually arrive before the spike of the pad I actually hit. This is not taken into account by the current algorithm. Of course that would involve holding back the Midi output, which in effect introduces a latency.

[corrados]

However I observed in practice that cross talk spikes may actually arrive before the spike of the pad I actually hit

That is very interesting. I have not experienced such an issue with my setup.

Initially, I thought this would make no sense because if I hit a pad and this triggers another one, the pad which is hit should always be the first to trigger since it will take some time for the audio wave to travel from the original pad to the pad which give a false trigger. But this is just the view of the physics. It may happen that the pad configurations are different between the two pads (e.g. scan times) which can lead to the case that the original pad generates a MIDI signal after the other pad.

Hmm. As you wrote, introducing latency is not a good thing.

[3hhh]

I was considering to fix it by piping the edrumulus Midi output to Ardour and using a Midi cross-talk cancellation plugin there, then pipe it to drumgizmo. I'm unsure how well that setup will perform though...
Also it seems that there's no such pre-made Midi plugin out there (I found a native one for Reaper, but that's it).

If drumgizmo had some sort of plugin support, it'd be possible to implement it there as well.

[corrados]

Interesting concept of using an external tool to mitigate cross-talk. If that works, other similar projects like, e.g., eXaDrums could also use it.

[3hhh]

I'll test this filter for now.

[corrados]

Great. Please update us in this thread how it works and how happy you are with that solution.

[3hhh]

I noticed some delay on fast hihat pedal stomps. I guess those cause the most MIDI messages to be created and can overwhelm the script. Since that happened on a rather fast machine I guess it won't work too well on a raspberry pi.
However I improved the script a bit in the latest version, so that it's harder to run into the issue.
Possibly multithreading might help, too.

EDIT: That was just a bug, which I just fixed. The script may just work fine on a raspberry pi.

In total I'm pretty happy with it so far.

[corrados]

Thanks for the feedback. Maybe it's now time that you create a post in this discussion thread ;-)

[3hhh]

Fyi: I just fixed the code causing the aforementioned issue.

[3hhh]

New repo: https://github.com/3hhh/xtalk

[corrados]

Great :-). I have just added your repo as a sub-module in the edrumulus/tools directory.