corrados
Idea: Test edrumulus on x64 hardware
Testing would be easier, if edrumulus could run on x64 hardware with emulated I/O.
It would also make the current Octave modeling unnecessary as an input signal could be directly run against the edrumulus code and the MIDI output be observed.
Ultimately it would enable automated testing via the CI pipeline.
One of the projects claiming to accomplish this: https://github.com/Arduino-CI/arduino_ci
Do we currently have a standard way to view the midi output?
Also, How would that get rid of the need for octave? wouldn't we need to see the processed digital signal rather than the midi output?
On 5/28/25 21:48, Victor Butkov wrote:
giff25 left a comment (corrados/edrumulus#141)
Why use a x64 system?
Some standard PC hardware was the point.
Ok, would it make it easier because we would be able to see the live output similar to Arduinos Serial out?
If you were planning on testing that way then we need to refactor the codebase into modules because right now there isnt enough organization for it to be testable by modules (or at least the current modules are wayy too large for it to be effective)
I can open a new issue of refactoring if we want to move forward with it.
As for octave I think we still need it in the case of new hardware. If we wanted to automate this there are a few libraries in python that could do it.
I found out that each new function which was introduced caused more CPU cycles. Since we want to have a maximum number of inputs, it is not desired to have new functions.
For what reason do we need tests? Did the software crash in the past? At least it was never crashing for me.
Having a reference model in Octave/Matlab is a must for me.
We can declare the functions as inline, it'll cause zero changes in performance while being able to separate the code into more neat units
There are several forums online that recommend prioritizing neat testable code over optimization. The code optimization can be done later via specialized tools.
For what reason do we need tests? Did the software crash in the past? At least it was never crashing for me.
Testing in this way just makes it easier to make changes in the code later down the road. Also I was thinking we might be able to automate the configuration process for new hardware after we figure out unit tests
Also also, we can potentially use some python libraries for the analysis instead of MATLAB/Octave so that its all part of the code; however i am not sure how this will effect the program size and whether we have enough memory to store it on the chip
use some python libraries for the analysis instead of MATLAB/Octave
This is how the Edrumulus algorithm design works: https://github.com/corrados/edrumulus/blob/main/doc/algorithm.md#algorithm-development
declare the functions as inline, it'll cause zero changes in performance
Depends on the compiler. I am not sure if the ESP32 compiler does what you expect it to do.
use some python libraries for the analysis instead of MATLAB/Octave
This is how the Edrumulus algorithm design works: https://github.com/corrados/edrumulus/blob/main/doc/algorithm.md#algorithm-development
Sorry I misunderstood the current process. How are you porting the code?
declare the functions as inline, it'll cause zero changes in performance
Depends on the compiler. I am not sure if the ESP32 compiler does what you expect it to do.
We can choose which compiler we use. I know GCC is very good at optimizing C/C++.
if this is your build process, then I think it would be worth changing it. From what I know the arduino IDE is THE worst IDE/build tool all around.
Also related to this issue, I see you were starting to mess around with platformIO. Have you considered ESP-IDF as an alternative?
How are you porting the code?
I port the code "by hand".
I know GCC is very good at optimizing C/C++.
GCC is of no use for ESP32. We need the Espressif compiler to do the job.
if this is your build process, then I think it would be worth changing it.
This is just my personal preference. I even do not use platformIO, the configuration is just for the GitHub runner. You can use any IDE you like.
Do we currently have a standard way to view the midi output?
Also, How would that get rid of the need for octave? wouldn't we need to see the processed digital signal rather than the midi output?
The idea was to not have to view anything by hand, if everything works as expected.
Essentially all input signals are here and could be replayed as virtual ADC input against an emulated edrumulus implementation. The output would be MIDI, which can be easily automatically verified via unit tests (must be 3 hihat pedal stomps of increasing velocity or whatever).
Currently testing against the edrumulus C code only works if you have the respective drum hardware and the respective board and must be conducted manually.
The octave model enables some semi-manual testing of the input signals against the octave model, which in theory should be identical to the C code, but of course it won't be 100% accurate.
Anyway this was just an idea and I gues it would be quite a massive undertaking to implement it. It's unlikely that I'll do it at least. The same probably applies to @corrados .
Essentially all input signals are here and could be replayed as virtual ADC input against an emulated edrumulus implementation. The output would be MIDI, which can be easily automatically verified via unit tests (must be 3 hihat pedal stomps of increasing velocity or whatever).
ahh I see, I overcomplicated it a bit. I can look into emulators and whether we can create an environment for this within a week; furthermore, starting with verifying one hit of each pad type (e.g. one hi hat, one snare hit, one tom etc.) should be pretty simple. I think its going to start getting complicated if we try to test different combinations.
GCC is of no use for ESP32. We need the Espressif compiler to do the job.
is the espressif compiler what you currently use?
GCC is of no use for ESP32. We need the Espressif compiler to do the job.
is the espressif compiler what you currently use?
Yes, it is.
So from what I can tell @corrados chose one of the only/better options for simulating adc with octave, while espressif has their own simulator it doesnt seem to support device drivers so I think emulating I/O is not going to be possible at the moment; however, I do think doing unit testing with CMock would still be beneficial. This way people can develop/test their functions without needing all of the hardware present.
If we want to move forward with it, I just need to know how to interact with the repo (I.e. develop the unit tests on a separate branch or fork the repo, etc.). let me know how you would like me to proceed and I can start developing them.
You need to ask 3hhh. He created the "Idea". I actually do not see a need to do unit tests in the current state of the project. If we would have algorithm changes all the time and need to verify functionality, that could make sense.
If you are searching for things to improve in Edrumulus, you should pick one from the TODO list. E.g. the user documentation could be improved, see, e.g., https://github.com/corrados/edrumulus/discussions/164
The original idea was about integration tests with an emulated board to make developing & testing new features and adding new pads more simple, not about unit tests for functions to make sure they work as expected.
So from what I can tell @corrados chose one of the only/better options for simulating adc with octave, while espressif has their own simulator it doesnt seem to support device drivers so I think emulating I/O is not going to be possible at the moment; however, I do think doing unit testing with CMock would still be beneficial. This way people can develop/test their functions without needing all of the hardware present.
If we want to move forward with it, I just need to know how to interact with the repo (I.e. develop the unit tests on a separate branch or fork the repo, etc.). let me know how you would like me to proceed and I can start developing them.
@giff25 If you want to contribute to Edrumulus, I just created a new Issue with an idea I had for some time now. Since I do not have time for this right now, it would be great to get feedback if something like this is feasible or not.