Disconnecting a rimshot input makes regular hits become rimshots about edrumulus HOT 23 CLOSED

from edrumulus.

Have you tried to adjust the rim shot threshold to mitigate the incorrect rim shot detection on a disconnected cable?

from edrumulus.

Have you tried to adjust the rim shot threshold to mitigate the incorrect rim shot detection on a disconnected cable?

Yes, but reliably only with a threshold of 31.

from edrumulus.

Is it a rim switch or a piezo on the rim?

from edrumulus.

from edrumulus.

Are you sure the piezo is directly connected to Edrumulus input? Because a piezo has a high resistance, see e.g. this page: "A piezo material is basically an insulator. That means the internal Resistance is extremely high.".

I.e., if the piezo is directly connected, it should not make a difference if it is connected to Edrumulus or not.

from edrumulus.

But anyway, this is actually not a supported use case for Edrumulus. You either connect your dual-trigger pad with a stereo jack connector to an Edrumulus input. Therefore, always both piezos or no piezo is connected. If you permanently want to disconnect the rim piezo, you simply configure the pad in Edrumulus as a single-trigger pad.

from edrumulus.

from edrumulus.

So essentially you're saying that this is an instance of #91.

To prevent #91, only band pass filtering or some application logic such as "if there are more than X (configurable per port) triggers per second from a single port, disable that port & inform the user".

from edrumulus.

My experience is that it either works or it does not work. If I am using a very noisy USB power and I get a lot of spikes in the ADC reading, Edrumulus will not work good at all. You can turn on spike cancellation and increase the threshold but the trigger performance will be bad. It is better to solve the issue and use, e.g., a powered USB hub (which I use for my prototype 4 and it works very well).

And my opinion is still, if the rim is not connected, you should disable it in the Edrumulus pad settings and the problem is solved. If you have unconnected inputs, you could set the threshold to the maximum value and the problem is solved. You do not need that input anyway.

And I agree with you, if the rim is accidentally disconnected, you will immediately notice it by the Edrumulus behavior in that situation and then you can fix the hardware issue.

from edrumulus.

My signal and SNR seem very fine since I use Rp=100k, Rs=1k, velocity threshold 2 & high sensitivity. I could even remove the powered USB hub and power the Teensy from a desktop PC USB port without noticing any difference.

We digress though. If you don't want to fix that issue, that's fine as well. It's your call after all.

from edrumulus.

My signal and SNR seem very fine since I use Rp=100k, Rs=1k, velocity threshold 2 & high sensitivity. I could even remove the powered USB hub and power the Teensy from a desktop PC USB port without noticing any difference.

Looks like I need to revise that as once I connect more than just the snare, I have a lot of noise in my circuit. Is this a common well-known issue or do I have to suspect that my circuit is bad somewhere?

from edrumulus.

I connect more than just the snare, I have a lot of noise in my circuit

I do not have such an issue with my ESP32 prototype even if I connect multiple pads to it.

from edrumulus.

So I kept the circuit & kick input pin stable (A0) and moved the snare pin around for testing on a Teensy 4.1.

The results are very confusing:
Snare on A9/A8 produces the aforementioned noise (but only with the kick connected), snare on A10/11 has less noise, same on A17/18 and snare on A14/15 (I tested #103) runs into ADC max (the LED blinks) on medium velocity hits. All of that just by recompiling edrumulus with new pin numbers and moving the snare input cable around.

Why does the ADC quality depend so much on the input pin? Any ideas what to try?
I'm lost.
Btw it's not the Teensy power input - I even ran it on batteries and experienced the aforementioned noise.

from edrumulus.

snare on A14/15 (I tested #103) runs into ADC max (the LED blinks) on medium velocity hits

That's a very interesting find. Maybe that is the reason why you were not happy with my analog front end design and selected your own resistor values. Maybe the reason was that your Teensy input was somehow attenuated causing the problems.

I have a Teensy 4.0 which works fine with the Edrumulus code. Obviously, there seem to be some incompatibilities between Teensy 4.0 and Teensy 4.1, unfortunately.

I can see in your code (#103) that you did changes at the ADC configuration. The "MIMXRT1062DVL6A keeper" gave me headaches when I was trying to support the Teensy. In your code I see that you use "INPUT_DISABLE". Do you really want to disable the inputs? Or is it to disable the keeper?

One reason for the effects you see could be (which I do not hope) that your hardware has a defect. Maybe some high spikes from the piezos did harm the inputs.

from edrumulus.

That's a very interesting find. Maybe that is the reason why you were not happy with my analog front end design and selected your own resistor values. Maybe the reason was that your Teensy input was somehow attenuated causing the problems.

One reason for the effects you see could be (which I do not hope) that your hardware has a defect. Maybe some high spikes from the piezos did harm the inputs.

Yes, maybe you're right that my Teensy is broken - especially since I noticed that I hadn't minded the gap. ^^
So the Piezo may well have sent some negative voltages to the ADC input for a while.
On a side note: If that bricks the Teensy, I wonder whether the Teensy may brick when it's switched off and someone plays the drums for fun (e.g. kids)?
Anyway my parameters apparently even somehow work without the voltage divider lol.

I can see in your code (#103) that you did changes at the ADC configuration. The "MIMXRT1062DVL6A keeper" gave me headaches when I was trying to support the Teensy. In your code I see that you use "INPUT_DISABLE". Do you really want to disable the inputs? Or is it to disable the keeper?

It disables the keeper. I also removed the pin-specific code as the ADC library should do it better anyway. The ADC library e.g. also implements load balancing between the ADCs.

from edrumulus.

It disables the keeper. I also removed the pin-specific code as the ADC library should do it better anyway. The ADC library e.g. also implements load balancing between the ADCs.

More than two years ago, I have used the same functions as you now do but this was my comment: "try to disable keepers [...] seems not to work".
See e66203f.
And after that, I introduced the direct modification of the registers instead:
See f52ad60.

So, obviously, I was not happy with this function. I cannot remember the details but it certainly had a good reason to modify the registers directly because I also prefer to use the API functions normally.

from edrumulus.

Hm I now tested the Teensy with the voltage divider connected to several pins and some simple analogRead() code and the voltage continually degrades from 1.65V to 1.4V and possibly less. I'd say it's gone for good...

It disables the keeper. I also removed the pin-specific code as the ADC library should do it better anyway. The ADC library e.g. also implements load balancing between the ADCs.

More than two years ago, I have used the same functions as you now do but this was my comment: "try to disable keepers [...] seems not to work". See e66203f. And after that, I introduced the direct modification of the registers instead: See f52ad60.

So, obviously, I was not happy with this function. I cannot remember the details but it certainly had a good reason to modify the registers directly because I also prefer to use the API functions normally.

I'm pretty sure you were unhappy because it didn't work as you attempted to use analog pin numbers with pinMode(), which only accepts real pin numbers. At least that's what the incorrect code you referenced indicates.

from edrumulus.

I'm pretty sure you were unhappy because it didn't work as you attempted to use analog pin numbers with pinMode(), which only accepts real pin numbers. At least that's what the incorrect code you referenced indicates.

No, it was not about the pin numbers. That worked fine for me all the time. It really was about strange behavior of the ADC input.

Maybe your Teensy is not dead but just is not configured correctly and shows a weird behavior caused by this. Can you upload an official example source code from the Teensy page which makes use of the ADC to check if they are really broken?

from edrumulus.

I recommend to start with my values of the resistors first since I use these schematics for a long time and very happy with it. It has a 100k resistor in series and that should also protect the Teensy/ESP32.

from edrumulus.

from edrumulus.

I was just curious if you are happy with my schematics if the Teensy is ok (and not broken) because I would like to know if the Millenium pads really have such a lower output voltage compared to the Roland pads.

from edrumulus.

This doesn't happen with my new working Teensy, i.e. this issue was just caused by the Teensy being broken.

from edrumulus.