The asynchronous input has been added to the main channel. While it's inspired by lty2008one's fork, the code was dramatically different. You can always check his fork. Again, shout out to lty2008one.
A easy to build e-box with Arduino Leonardo/ProMicro. Huge thanks to lty2008one for improving performance on Switch.
Play demo: Senpuu no Mai [Heaven] Full Combo.
- Nintendo Switch Support
- Easy to build.
- Arduino Leonardo/Pro Micro
- Piezo sensor x4
- 1MOhm resistor x4
- Bread borad and wires(you can print your own circuit board if you want)
4 piezo sensors, one pin to the GND, and the other to the A0-A3. Connect 1MOhm resistor to each sensor parallelly.
Note: Piezo sensor will generate both positive and negative voltage when it got hit, so it probably doesn't really matter if you connect positive or negative to GND. You might have heard that negative voltage will probably damage the analog pin. However since the current generated by the sensor is really really low, I would say it's most likely safe. If that concern you, you can use diodes or diode bridges to fix this issue.
In Arduino IDE, board manager, download Arduino AVR Board.
Then, you need to download Keyboard and NintendoSwitchLibrary in your Arduino IDE's library manager.
Then compile and upload the code to the board. then it should work fine.
You need to change the VID and PID first.
In board.txt( Arduino IDE 1.8.x ).
leonardo.vid.1=0x0F0D
leonardo.pid.1=0x0092
leonardo.build.vid=0x0F0D
leonardo.build.pid=0x0092
Location of board.txt can be various depends on your IDE version. For current Arduino IDE, both 1.8(legacy) and 2, it should be in C:\Users\USERNAME\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.6
For Linux user, it should be at ~/Arduino15/packages/arduino/hardware/avr/1.8.6
Then connect Pin1 to GND, hit reset button. (Or plug into the Switch while connecting) It should work fine now.
To switch back to PC mode, connect Pin0 to GND and hit reset button. (or plug into the PC while connecting).
Uncomment extendKey() can map D0 and D1 to Button::PLUS and Hat::RIGHT. In case you want configuration in NS2. However I'm not sure if there will be any negative effect on the perfermance.
Switch button definition list (more information at Nintendo Switch Library):
Button::Y
Button::B
Button::A
Button::X
Button::L
Button::R
Button::ZL
Button::ZR
Button::MINUS
Button::PLUS
Button::LCLICK
Button::RCLICK
Button::HOME
Button::CAPTURE
Hat::UP
Hat::UP_RIGHT
Hat::RIGHT
Hat::DOWN_RIGHT
Hat::DOWN
Hat::DOWN_LEFT
Hat::LEFT
Hat::UP_LEFT
Hat::NEUTRAL
Uncomment analogMonitor() and comment all the section in main loop below. Then you can check each sensors analog value after passing the threshold.
Also some commented line can be found for different debug purposes.
// Serial.println("DECAY");
// Serial.println(threshold); //Check decay, in order to set proper k_increase and k_decay.
Once a analog value is higher the threshold, a input will be detected.
We all know AC Taiko was built with 4 parts: left rim, left surface, right surface, right rim.
However, unlike electronic drum set, where each piezo sensors are seperated, there will always be some connection between each part of the Taiko drum, no matter the base wooden plate or the rubber surface. So when you hit one part, the other 3 parts will also be vibrated, causing all the sensors delivering signals.
If the noise signal from the other parts was detected before the actual part that got hit, a mistaken input will happen.
To prevent mistaken input, we need to create a buffer window. It will start storage all the analog input into buffer for a short period. Since the noise analog value on other sensor should be smaller than the one which actual got hit, comparing each value in buffer, the largest value should be generated by the actual sensor got hit.
The parameter cd_length will effect the buffer size. If it was set too large, it will take a significant time to find the largest number, causing input latency. If it was too small, the buffer windows may not cover the largest value from the sensor.
If the buffer time and key press time is too short, even shorter than the vibrating time, when the whole input process is over, the sensor will still sent signal, and again once it's higher than the threshold, another input will be triggered. Causing double input in one hit. The harder you hit the drum, the more significant this issue will be.
That's why I imported dynamic threshold. the harder you hit the drum, the higher the threshold will be raised. which let the threshold higher than the vibration.
The dynamic threshold will be the maximun analogValue in buffer multiplied by k_increase. and in every loop the current threshold will be multiplied by k_decay until it's back to the original threshold.
In src/NewLeonardoTaiko, we have attempted to introduce a new dynamic threshold method.
During the actual analogRead() sampling process on the Arduino Leonardo, after hitting the drum, the sensor values read exhibit a gradually decreasing trend rather than oscillating between positive and negative values. To address this, we can create a sliding window. Within this window, the oldest value entering the window is used as a baseline to dynamically adjust the threshold, thereby determining whether the most recent value entering the window corresponds to a triggered hit.
In practical operation, separately adjusting the threshold changes for each of the four channels can be cumbersome. Therefore, we use the value obtained by subtracting the oldest value from the latest value within the sliding window to derive a unified change value.
Under this approach, since the sensor values typically show a decreasing trend after a strike, after processing with the sliding window, if the resulting value is a suddenly increasing positive number, it indicates that the sensor is being hit. If it is negative, it signifies that the sensor value is decreasing, indicating no hit.
By leveraging this characteristic, we can achieve debounce purposes by setting and adjusting relevant parameters.
For Home console and PC version of Taiko no Tatsujin, you need to press two button simultaneously to hit big notes for higher score. In the arcade you don't need to do that. In theory, in You need to hit the drum harder at big notes for higher score. However in newest arcade version it's also obsolete. This code also doesn't provide support for true simultaneous input. But you can always map one hit to multiple buttons to simulate simultaneous input.
You can also imply some smoothing filter to preprocessing the raw analog input signal. In my case, the sensors are good enough.
The value to trigger a input. use 5V as reference, divided the signal from 0 to 1024. The lower it was set, the more sensitive the drum will get. If it's lower than the idle noises which piezo sensor will definitely generated, random input will occur.
How many loops to read all 4 sensors' analogValue. Since cd_length define one loop for all 4 sensors, buffer_size should be 4*cd_length.
Which means you can change this value to adjust the buffer size. The smaller it was set, the faster response you will get after hit the drum.
Every time a hit was detected, the threshold will change to the largest pin value multiplied by k_increase. Which can prevent double input when the cd_length/buffer_size was set too low.
Every loop the current threshold will multiply k_decay in order to go back to the original threshold.
The size of the sliding window used to determine the dynamic threshold.
The threshold for triggering a strike, which initiates crosstalk detection. Since the INTERNAL 1.1V is used as the reference voltage, the signal becomes more pronounced compared to the default 5V, resulting in a higher trigger threshold than in previous versions.
How many loops to read all 4 sensors' analogValue. Since cd_length define one loop for all 4 sensors, buffer_size should be 4*cd_length.
Which means you can change this value to adjust the buffer size. The smaller it was set, the faster response you will get after hit the drum.
break_check_limit defines the window for monitoring signal changes after a strike, while reset_threshold specifies the change value that should be considered significant.
After a strike, the triggered sensor is locked, and the debouncing algorithm is executed. Due to inherent signal jitter, merely detecting a negative change value during debouncing is insufficient to confirm that the sensor is no longer being struck. Therefore, break_check_limit is introduced.
When the sensor's change value exceeds reset_threshold, it indicates that the signal has not yet entered a consistent downward trend. If the change value falls below reset_threshold, the algorithm continuously reads the change values. If the number of consecutive change values below reset_threshold reaches the limit set by break_check_limit, it indicates that the sensor signal has transitioned into a declining trend, confirming the strike has ended. The lock is then released, and debouncing completes.
Nintendo Switch support from
NintendoSwitchControlLibrary by lefmarna.
lty2008one for improving performance on Nintendo Switch.
Algorithm inspired by multiple Taiko project, including:
ArduinoTaikoController by LuiCat.
Taiko-Input by sachikoxz12.