Idea: Test edrumulus on x64 hardware

[3hhh]

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

[giff25]

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?

[3hhh]

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.

[giff25]

Ok, would it make it easier because we would be able to see the live output similar to Arduinos Serial out?

[giff25]

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.

[corrados]

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.

[giff25]

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.

[giff25]

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

[corrados]

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.

[giff25]

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.

[giff25]

Also related to this issue, I see you were starting to mess around with platformIO. Have you considered ESP-IDF as an alternative?

[corrados]

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.

[3hhh]

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 .

[giff25]

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.

[giff25]

GCC is of no use for ESP32. We need the Espressif compiler to do the job.

is the espressif compiler what you currently use?

[corrados]

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.