Problem with dual piezo management and hihat controller

[dmitri]

elrules, try this version:
It adds two settings in the 'HiHat Pedal' section:
1. Curve
2. ChckDelay

With the first setting you can counteract logarithmic HiHat pedal output.
With the second setting you can assign chick delay in milliseconds. With a default value 0 Chick/Splash behaviour is just like in previous firmware versions. When I set it to 20 I can avoid a chick with a splash and still have not badly noticeable chick delays but I must press/release a pedal really fast. When set to 50 chick delays become very noticeable although getting splash without a chick is much easier.

Note: Previously saved EEPROM and SysEx configs are not compatible with this version so if upgrading with a bootloader either set 'AuloadConf' to No before the upgrade or load default settings after the upgrade (holding key RIGHT while powering up).

So I guess these changes are not really needed.

[elrules]

Wait a bit! I still have to test it. This afternoon I will try that firmware. Hope I can get better performance with Addictive drums with this mod.

[elrules]

elrules, try this version:

megadrum32_20080918.zip

It adds two settings in the 'HiHat Pedal' section:
1. Curve
2. ChckDelay

With the first setting you can counteract logarithmic HiHat pedal output.
With the second setting you can assign chick delay in milliseconds. With a default value 0 Chick/Splash behaviour is just like in previous firmware versions. When I set it to 20 I can avoid a chick with a splash and still have not badly noticeable chick delays but I must press/release a pedal really fast. When set to 50 chick delays become very noticeable although getting splash without a chick is much easier.

Note: Previously saved EEPROM and SysEx configs are not compatible with this version so if upgrading with a bootloader either set 'AuloadConf' to No before the upgrade or load default settings after the upgrade (holding key RIGHT while powering up).

Wooowww!! this new firmware is great.

This is how I set those parameters:
Curve: Exp1 --> With this the log pot has been counteracted. It has now a smooth transition between zones. Tested with Addictive drums and Superior 2
ChckDelay: 15 --> with this parameter set to 15 I get EXACTLY the same response as my old td6.

Dmitri, you are a genious!!

About the Dual Head pads:
I have tried to set threshold in rims to 50, even 70. The problem persists. As I think, this problem is not about threshold (which affects only one trigger behavior). This is a matter of crosstalk between piezos of the same pad. I think there should be a higher restriction in crosstalk between piezos belonging the same dualhead input. I have tried setting Crosstalk to different values, from 0 to 3. with crosstalk at the minimum (1) the dual trigger effect is bigger. With 3 it is less but still persist. Will it be any possibility to implement some kind of internal crosstalk for piezos attached to the same dual input? The fact is that when you hit hard a pad, all the pad vibrates and the two piezos get a considerable ammount of vibrations, so they trigger at the (nearly) same time. Could it be implemented as an inter-zones miniscan time?

[dmitri]

About the Dual Head pads:
I have tried to set threshold in rims to 50, even 70. The problem persists. As I think, this problem is not about threshold (which affects only one trigger behavior). This is a matter of crosstalk between piezos of the same pad. I think there should be a higher restriction in crosstalk between piezos belonging the same dualhead input.

Both channels in a Dual Head pad are treated as in a supper crosstalk group - if signals are registered at the same time on both channels, only strongest of them is sent.

I have tried setting Crosstalk to different values, from 0 to 3. with crosstalk at the minimum (1) the dual trigger effect is bigger. With 3 it is less but still persist. Will it be any possibility to implement some kind of internal crosstalk for piezos attached to the same dual input? The fact is that when you hit hard a pad, all the pad vibrates and the two piezos get a considerable ammount of vibrations, so they trigger at the (nearly) same time. Could it be implemented as an inter-zones miniscan time?

Can you try setting Retrigger to 1 and DynLevel to 7 on both Head and Rim channels? and Maybe play around with DynTyme after that?

[elrules]

Ok, I will try that. But I feel like it is not going to solve the problem.

As far as I know, Retrigger, Dynlevel... all those parameters affect subsecuent hits on the same input. So, if the crosstalk is produced between two different inputs on the same pad (head and rim), then it is a different problem. Correct me if I am wrong.

The problem comes when megadrum receives a hard hit in the head. Well, ok, it triggers that with no problem. But then, after a microsecond it receives a hard (but no so hard) wave from rim piezo (that was caused by the hard hit making the entire pad to vibrate, and making a big wave on both piezos, one of them is triggered instantly, but, as the wave has a tail, the other piezo "seems" to have received another different hit). Megadrum cannot use minscan, retrigger, dynlevel or dyntime for supressing that false rim hit, as those parameters affect hits from the same input (head in this case). The only thing left is crosstalk, but then crosstalk is intended for all the pads in a drumset, to supress soft vibrations from other pads when one is hit, but what happens is that the hit was in the same phisical structure (the meshhead tom) so the residual vibrations are big enough to be considered a "true" hit. The result is that with a hard hit you get a high velocity note from one half-input (head or rim, it depends on which signal arrives before to megadrum) and another medium-hard note from the other half-input, X microseconds before (or whatever minimum time megadrum needs to trigger the next received signal after one is processed).

So, after these loads of text.... my conclusion is: I think that if there is no parameter (user-configurable or internal processing, it does not matter...) that can correct this, it would be nice to add a new minimum scan time between inputs of the same pad. If head triggers, leave some time to avoid triggering the rim inmediately after, and viceversa. This will not affect normal playing, because I think nobody performs "flams" on head and rims at the same time. Musically, you usually do a flam with both sticks in the head, or even with one stick in a tom and other in the snare for example, but nobody hits nearly at the same time head and rim, unless he made a mistake...

Ey dmitri, how do you see it? has what I tried to explain had any logic? I hope so...

This new dualzone pad triggering management could also be helpful for cymbals with bow and bell piezos in the same pad. It could make triggering them more consistent and reliable, couldn't it?

[gastric]

Based on the fact you're reporting significant rim piezo levels on head hits, which shouldn't be the case, maybe your trigger construction is the issue and there is simply not enough physical isolation between the head and rim piezos?

I know for Roland modules you're directed to putting the rim piezo on the same crossbar or structure as the head piezo. That is due to the fact Roland modules specifically require less physical isolation in order to process positional and the various triggering correctly.

However, modules like the Alesis and MegaDrum, at least based on my understanding of it's triggering capabilities as it exists today, require better physical isolation. The rim piezos should not be mounted on the same physical structure. Instead, they should be mounted on the shell away from the head piezo, about 1" down from the actual shell rim. This should provide excellent physical isolation. And your head crossbar, assuming you did a crossbar construction, should have some amount of isolation applied such as Beatnik's direction to use bonded washers to mount the brackets and expansion nuts to mount the piezo plate. Based on my limited testing with my own equipment the Beatnik isolation doesn't completely eliminate rim activity on head hits but it does reduce it quite a bit. Which is apparently enough.

[elrules]

Believe me. My pads are well isolated. I have followed all the tips from the gurus at vdrums and with several roland modules (td6 td12 and td10exp) I didnt have problems when I tested them, in fact they worked better than original roland pads i had

[dmitri]

You probably won't believe me, but MegaDrum has algorithms in it to deal false triggering in dual heads.

Several factors are involved which may produce false triggering or missed hits. The problem for me here is that I cannot reproduce it with my combination of a rack and a Pintech dual head pad.

When you hit hard a dual piezo pad on a head first time (or when hard hits are far apart) MegaDrum registers it as a head hit because signal from a head piezo is stronger than from a rim piezo (respectively normalized against their individual maximum levels). Both head and rim channels will be inhibited for 'Rettriger' amount of time.

Suppose that the pad is ideal but the rack mounting is not. After the strong hit, vibration may travel through the rack and come back to the pad. If this vibration signal comes back to the pad after the rettrigger period has elapsed and the signal is stronger than Threshold and dynamic threshold it is very likely that it may cause a new (although weak) signal registered on the rim because the rim piezo mechanically is more rigidly attached to the rack. Now if this vibration signal is registered by the rim it will inhibit both the head and rim channels for another 'Rettrigger' milliseconds. And if the next hard hit on the head comes within this rettrigger period it won't be registered.

This is only one of the possible situations/theories when strong fast head hits may be missed. Based on this theory it is advisable to raise Threshold level for the rim channel.

Also it would be very useful to make a video demonstrating the problem with as much detail as possible.

[elrules]

You probably won't believe me, but MegaDrum has algorithms in it to deal false triggering in dual heads.

I believe you THinking it better, if you hadn't done those algorithms, setting pads as two single piezos or setting them as dual piezo would have been the same config result...

Both head and rim channels will be inhibited for 'Rettriger' amount of time.

Ups! with this new info I don't know then what it is MinScan for. I thought MinScan was the minimum ammount of time to be able to trigger again. But as that function is provided by retrigger,... what is then MinScan for? (By the way, it is great that retrigger and dynlevel affect both dualpad zones, if not, my problem wouldn't have a solution until you make more firmware coding, seems a problem of finding optimal settings)

If this vibration signal comes back to the pad after the rettrigger period has elapsed and the signal is stronger than Threshold and dynamic threshold it is very likely that it may cause a new (although weak) signal registered on the rim because the rim piezo mechanically is more rigidly attached to the rack.

This sentence confirmed me that retrigger and dyn threshold affect both channels of a dualzone pad. (But those parameters can be set to different values on each input... then you mean the effect produced inside megadrum when a pad is hit is that retrigger an dyn threshold routines are activated or "launched" for both inputs whatever zone of the pad is hit)

Now if this vibration signal is registered by the rim it will inhibit both the head and rim channels for another 'Rettrigger' milliseconds. And if the next hard hit on the head comes within this rettrigger period it won't be registered. This is only one of the possible situations/theories when strong fast head hits may be missed. Based on this theory it is advisable to raise Threshold level for the rim channel.

[/quote]Now it makes sense what you said me about lowering retrigger. But missing hits is not the problem I have. My problem is that I get hard-hits on rims together with hard-hits on heads. I will keep thinking to see if everything start making sense...

Also it would be very useful to make a video demonstrating the problem with as much detail as possible.

Very good advise. It is the best excuse for me to finally record the megadrum demo video I promised weeks ago...how lazy I am....

[dmitri]

MinScan. Minimum scan time for the input.
Measured/shown in 1/10th of millisecond. Can be set between 1 and 100 (0.1 - 10ms)

When MegaDrum detects a signal above Threshold/Dynamic threshold, it will keep sampling it for MinScan period of time before marking the signal as registered and making it ready to be sent over MIDI next MegaDrum scans (scan time is set by 'Latency') all channels for registered signals.

Lowering it will improve Latency (MegaDrum latency is between Latency and and Latency+MinScan) and may worsen level accuracy.
Raising it will worsen Latency and may improve level accuracy.