Smarttrigger/Surge/JobekyP-P-S Triple Zone Ride

[maru_engineering]

...and I can confirm that with a small tweak of the midpoint (144 instead of default 128) I can get almost perfect separation between bow and bell when using Dual or three way Yamaha... Of course now I loose the edge switch functionality...

Better_Sepparation_small.jpg

[dmitri]

I see you set all inputs in the same XTalk Group. I guess I had to be more specific on this:

3. Place all the zones into the same (and exclusive only to them) XTalk group.

as you also need to adjust XTalk Level on all these inputs. You left them at 0 and when you hit one of the zones this will cause false triggering of one of the other zones.

[maru_engineering]

Hi Dmitri!

I was playing around, look, this time I had recreate your suggestion; I'm not a drummer but in this configuration the note separation seems much worse to me...

xtalk1.png

xtalk2.png

[dmitri]

You went from Level 0 straight up to Level 7. Did you try levels in between? I'm not suggesting it is going to be a perfect solution as it is based on XTalk suppression between independent inputs rather than on XTalk suppression between zones. I will think about you suggestion for a piezo/piezo/switch pads/cymbals but I don't have a hardware to do testing with so it may take quite a while to develop support for such pads/cymbals.

[maru_engineering]

Here is a picture of my 20'' ride; playing side to the bottom of the picture, bow piezos are under the aluminum covers in order to avoid hot spotting; the bell piezo is on the upper side of the bell, under the protection extension lip of the underside aluminum sheet that serves as edge switch (gap adjustable by the fixing screws) as well as extra dampening (the dampening material is sandwiched between this sheet and the bottom of the cymbal)... The extra clar PVC from the player side is balancing the weight of the connection box from the back and hopefully will prevent rotation...

Ride_small.jpg

[maru_engineering]

Hi Dmitri, thank you for your answer....

Yes, I went directly to 7 because I wanted the maximum suppression between the zones; but I think the problem is somehow related to scanning (polling) of the inputs... As you can see in the MIDI log a bell hit is wrongly detected when hitting the bow but then 14-20 ms later the correct bow note is sent as well...

I haven't seen this behavior when using the same input for bow/bell piezo... but then I loose the edge...

Let's see if other users are thinking that this implementation is useful; makes no sense to modify the firmware for just one person...

I don't know a thing about programming, but as far as I have seen it the pieces of code is already in, we just have to make valid the Roland 3way with the rim expecting a voltage (like Dual or three way Yamaha) instead of switch...

Thank you for your time and patience

[maru_engineering]

Ah, one more thing, are you planning a near future release of the firmware?

If yes, could you consider one thing?

I was working very hard on my snare, I could not get rid of the hotspot in the center; I decided to mount another cone towards the player side to take the velocity info and I thought to use the center cone just for the positional information but, if I set the note to 0 for the center cone input the PS processing ceases as well... So I have to leave an unassigned note there in order to get the PS info but that note is only clogging my sequencer... Of course the secondary cone input has a higher input number than the center cone input

It's just a suggestion, if you think it makes sense I can open another thread regarding the snare: I even implemented a capacitive sensor to detect the hand on the head in order to switch the head and rim signals to another input in order to get dampened head and crosstick articulations... I was able to handle that via additional hardware .... software, I cannot handle...

[dmitri]

Hi Dmitri, thank you for your answer....

Yes, I went directly to 7 because I wanted the maximum suppression between the zones; but I think the problem is somehow related to scanning (polling) of the inputs... As you can see in the MIDI log a bell hit is wrongly detected when hitting the bow but then 14-20 ms later the correct bow note is sent as well...

Try to increase MinScan on the bell input so that it is about 50-100% higher then on the bell input.

I was working very hard on my snare, I could not get rid of the hotspot in the center; I decided to mount another cone towards the player side to take the velocity info and I thought to use the center cone just for the positional information but, if I set the note to 0 for the center cone input the PS processing ceases as well... So I have to leave an unassigned note there in order to get the PS info but that note is only clogging my sequencer... Of course the secondary cone input has a higher input number than the center cone input

Again it will be tricky for me to test it while implementing it since I don't have such a pad.

[maru_engineering]

Hi Dmitri!

You mean bell min scan time 50-100% higher than bow?

For the snare I thought if it's possible to still send the CC16 as long as Positional Sensing is on, even if you set the note to 0... In other words note 0 should not disable the raw data processing just not sending note on/note off midi event... Just a thought...

[dmitri]

You mean bell min scan time 50-100% higher than bow?

Yes.