Tracking

[copych]

@rdridder @midilab

• removed all timers from AcidBox
• made it compile in IDE 1.8.19, core v.3.0.7
• due to my ignorance, it's a lot of commits

[rdridder]

@copych
I have checked out your changes and I see a lot of modifications are made to the code. The buttons and running sequencer I had yesterday now don't work anymore. The left button seems to not work and if I press play the sequencer also does not run anymore.

Can you confirm that you have the base hardware layout running and working ?

[copych]

Oh I think I need to revert to your latest version and try to commit my changes again... It seems that it went wrong again. I tried to do something with Git CLI, but perhaps spoiled something .

[rdridder]

Ok, no worries.

What I would do is first establish a baseline, so a working hardware base with a working software base. In my latest commit I had a working button/pot configuration and a working sequencer. After we both have that compiling and working take next steps.

I also saw a lot of modifications in the midilab code which I would recommend against because that is a working codebase. We know Acidbox is working and Aciduino is working so let's keep that as is, we only need to write the glue to tie them together.

[copych]

Those lots of modifications were just workarounds for warnings which were considered as errors, and didn't compile in IDE 1.8.x. I tried not to ruin the logics. But I think that there were something wrong with my base version ( It seems there weren't your latest changes...

[copych]

• placed aciduino.run() back to the loop(), it runs now.
• It turned out that data and clock pins of the oled is mixed for some reason.
  (maybe change s3.h to
  U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, U8X8_PIN_NONE, OLED_CLOCK_PIN, OLED_DATA_PIN);
  )
• with PSRAM enabled the pinnage may require some tuning...

[rdridder]

@copych Great that you found the relation between the pinnage and the PSRAM. I was running without PSRAM enabled. I will try to find a working pin configuration with PSRAM enabled.

I did not experience issues with the oled but I guess using the defined pins will give a bit more flexibility in using the pins. If we use: U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, U8X8_PIN_NONE, OLED_CLOCK_PIN, OLED_DATA_PIN); it will be easier to use the pins we want for the oled.

Today I was working late and I am out of town the weekend. Hopefully I will be able to test something sunday evening.

[copych]

Great that you found the relation between the pinnage and the PSRAM. I was running without PSRAM enabled. I will try to find a working pin configuration with PSRAM enabled.

The bad thing is this seems to be manufacturer/model dependent. There's a solution using multiplexing, but I'd avoid it.

I am also away for the weekend.

[rdridder]

Otherwise we can make it simple and use a define to switch between pin configurations. I have a Lolin S3, not sure what board you have but we could define a MACRO to switch the pin definitions, something like.

#define PINCONFIG_S3
// #define PINCONFIG_S3_GENERIC
// #define PINCONFIG_S3_ADAFRUIT_FEATHER

This will then steer what pins to use or at least make it easier to swap the pin config.

[copych]

They say PSRAM occupies GPIO 35, 36, 37. GPIO 0, 3, 45, 46 are not recommended. GPIO 39..44 has some defaults that can be overwritten though.
PS GPIO 8 (def.SDA) and 9 (def.SCL) are defaults for I2C in Arduino env, that's why I had them mixed, and #define directives from s3.h just weren't used anywhere.
GPIO 10 CS0, 11 MOSI, 12 SCK, 13 MISO are dedicated for SPI0. These default pins run through the IOMUX instead of the GPIO matrix, and therefore have higher performance characteristics. The maximum frequency for IOMUX pins is 80 MHz.
GPIO 19, 20 are D- and D+ of the native USB
GPIO 43, 44 are USB Serial U0 TXD/RXD

[rdridder]

I am trying to make sense of these results. The bitshifting and XOR'ing is dramatically faster in the 2.0.17 core. I find it difficult to grasp why such basic operations would be much slower in a different core version. If I read: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/performance/speed.html They do mention cache misses and moving code into IRAM but I guess that needs to be benchmarked to check if it improves the situation. Anyway, just guessing, I have no clue actually.

I am going to dive into uCtrl for a while to check if I can find a nice extension point.

[copych]

I have found some performance issues in the 3.0.5, they were connected to the serial port handling. But in my case this is already said to be cured, as I've installed 3.1.0-rc3. I even tried to make an asm injection out of this function. And the same asm code runs faster on 2.0.17. I am missing something. Also it is strange that most of the other tested code runs almost at the same speed on both v2 and v3 ... IRAM_ATTR and WORD_ALIGNED_ATTR is used everywhere in testing routines, so it is not the case. Maybe that's something with converting to float. I need to sort it out. I maybe make an issue, so that those clever guys could check this. Only I should make a clean demo.

[copych]

About the uCtrl. As I can see there are 303 and 808 devices already made. So making a new module is probably not needed. I am not sure though what is the best way to connect the synths: catching prepared midi events, or inject before this stage.
Also should we use some kind of queue for messages, or call synth functions directly? What are your thoughts?

[rdridder]

About the uCtrl. As I can see there are 303 and 808 devices already made. So making a new module is probably not needed.
If I see how midi actually gets initialized in src/ports/esp32/s3.h from line 338 a midi interface is plugged into uCtrl. I think we can actually use this mechanism and add an additional midi output which would not output actual midi but would call the synth/sampler NoteOn/Noteoff methods.

I was analyzing the synth functions and a lot seems to be happening there. I guess we will need to work with a queue to trigger the noteOn/noteOff functions so they are not blocking the other midi signals and screw up the timing. However, we can start by just plugging in a fake midi component with a pointer to the synths/samplers and just call the methods to validate the idea. If we are succesful we can extend on the concept and try to make it run faster. What do you think ?

[copych]

Yes, it sounds reasonable. Anyways, control routines should be running on Core1 (assuming Core0 is running audio), this includes sequencer, UI and synths' noteOn/noteOff's, so the queue will hardly solve potential blockings. Though if there are such problems, we could run another task on Core1 for noteOn/noteOff's and try to play with priorities, letting these two tasks breath thru each other regularly via taskYIELD(). This will slow down the execution generally, but pseudo-parallelize the execution. (Oups @midilab answered )))

[midilab]

aciduino.cpp contains Aciduino::sequencerOutHandler where you hook sequencer actions, each track is configurable independently for a output handler, on roadmap there is CV and Gate for modular.

Just create a new handler like ACIDBOX_SND_MODULE and you are good to go.

// used by aciduino.seq object as callback to spill data out
void Aciduino::sequencerOutHandler(uint8_t msg_type, uint8_t note, uint8_t velocity, uint8_t track)
{
  switch(aciduino._track_output_setup[track].output) {
    case MIDI_OUTPUT:
      aciduino.midiSequencerOutHandler(msg_type, note, velocity, aciduino._track_output_setup[track].channel, aciduino._track_output_setup[track].port);
      break;
    case CV_OUTPUT:
      // soon boy...
      break;
    case GATE_OUTPUT:
      // soooooooon...
      break;
  }
}

[copych]

@midilab thank you for enlightening! We've been waiting for this moment.

[rdridder]

@midilab thank you for your reply. This sounds like a great solution. This will also make it possible to have three tracks for Acidbox and additional tracks for MIDI.

[rdridder]

@copych @midilab
I have created a very basic implementation based on the feedback by @midilab
I have a very basic implementation that turns notes on and off for the drummachine and synths. We can test and make this implementation better.

@copych Can you check if it also works for you ?

[copych]

@rdridder great news! I'll check it tonight.
You say it's basic. So what else do we want from it? CC auto ramps?
@midilab how does the sequencer transmit glides for tb-303: as overlapped notes or as portamento CC On and Off-s?

[midilab]

overlap notes, most 303 plugins or clones that acpet midi input use overlap for glide and a threshold velocity value for accent.
v2/AciduinoV2/src/sequencer/setup.h for accent threshould values setup

[rdridder]

You say it's basic. So what else do we want from it? CC auto ramps?

Right now I only implemented note on, note off. I haven't checked out all the uControl options but I see options like USE_POT_16 and USE_PUSH_8. I would envision that we use all these premade modules to add pots and buttons. Those pots can then send midi signals to control cutoff and resonance for example. I assume these signals will also end up at the callback and will be sent to the appropriate synth/sampler.

[copych]

I see. There are several common solutions coming to my mind, but they all require more hardware buttons and pots, if we want to make it usable in live performance e.g. So probably we'll have to add a multiplexer to add buttons and some rotary encoders and/or pots. It doesn't matter generally if they will control the sequencer or synths directly.

[rdridder]

Yes indeed. If you check the s3.h it will have several options listed with the hardware needed. See below.

// PUSH and LED modules require booth PUSH_SPI and LED_SPI to point into some spi device
//#define USE_PUSH_8 // uses 165 shiftregister (buttons)
//#define USE_PUSH_24 // uses 3x 165 shiftregister
//#define USE_PUSH_32 // uses 4x 165 shiftregister
//#define USE_LED_8 // uses 595 shiftregister
//#define USE_LED_24 // uses 3x 595 shiftregister
//#define USE_POT_8 // uses 4051 multiplexer
//#define USE_POT_16 // uses 2x 4051 multiplexer
//#define USE_TOUCH_32 // uses 2x 4067 multiplexer

From the comments seems to operate with basic shift registers and muxes.

[copych]

@rdridder @midilab
First it worked, i navigated through the menus and pressing the play button invoked playing straight hat and bass notes, then i randomly pressed some buttons, and rebooted the board by rst. (Maybe I pressed something called eprom while playing). After that I have a bootloop, I haven't decoded the backtrace yet, but according to the log, it bails out on initPorts.

[rdridder]

You could check in initSequencer, the eeprom init and reading is done in there. I was also fiddling around a bit in there because the output got overwritten. If I meddled in the load session (skipping the loading of the ouput part) the firmware would also crash. That is why I made the extra loop.

Another option to check if it is the EEPROM might be turning on erase all flash before sketch upload.

I guess the real solution would be to fix the EEPROM reading/writing but to test the setup I think this could help.

[copych]

@midilab @rdridder
Here's what exception decoder says:

PC: 0x00000000
EXCVADDR: 0x00000000

Decoding stack results
0x420cbbb3:  is in Engine303::clearStackNote(signed char) (E:\YandexDisk\arduino\AciduinoBox\src\sequencer/engine_303.cpp:432).
0x4200fed7:  is in AcidSequencerClass::clearStackNote(signed char) (E:\YandexDisk\arduino\AciduinoBox\src\sequencer/acid_sequencer.cpp:112).
0x4200f79c:  is in Aciduino::loadPattern(unsigned char, signed char, signed char) (E:\YandexDisk\arduino\AciduinoBox\src/aciduino.cpp:498).
0x4200fb41: Aciduino::initSequencer() at E:\YandexDisk\arduino\AciduinoBox\src\aciduino.cpp:58
0x4200fb78: Aciduino::init() at E:\YandexDisk\arduino\AciduinoBox\src\aciduino.cpp:10
0x420088c6: initPort() at E:\YandexDisk\arduino\AciduinoBox\src\ports\esp32\s3.h:415
0x4200c7d3: setup() at E:\YandexDisk\arduino\AciduinoBox\AciduinoBox.ino:250
0x42022793: loopTask(void*) at C:\Users\admin\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.0.7\cores\esp32\main.cpp:59
0x40384eda: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa\port.c:162

this is _onEventCallback(NOTE_OFF, _sequencer[i].stack[j].note, 0, i); here:

  if ( track <= -1 ) {
    // clear all tracks stack note
    for ( uint8_t i = 0; i < TRACK_NUMBER_303; i++ ) {
      // clear and send any note off 
      for ( uint8_t j = 0; j < NOTE_STACK_SIZE_303; j++ ) {
        _onEventCallback(NOTE_OFF, _sequencer[i].stack[j].note, 0, i);
        _sequencer[i].stack[j].length = -1;
      } 
    }
  }

/src/sequencer/engine_808.cpp:197 has similar instruction.

Manual says EXCVADDR: 0x00000000 usually means that application attempted to dereference a NULL pointer.
I haven't yet dove into the depth of the Aciduino code, so maybe you can fix it quicker?

PS Erase all flash before upload cured nothing actually.
commenting out these lines in 303 and 808 makes it run again, but I am sure this is not the way of fixing something )))

[rdridder]

I will check tonight if I can find the cause. The stack is used to save the note that needs to be turned off. Basically when a note on is sent a note off will be saved in the stack and will be turned off after a certain amount of ticks. So probably the stack is accessed before it is actually initalized.

[copych]

Thanks for the explanation. Then it'll work anyways, just stuck notes may appear.
I'va played around with what we have for the time being, and imho UI needs a heavy reworking. All the often accessed stuff should be available within one press, while routing and other setup functions could be moved further away, not only because of rare usage, but also to keep it away from the occasional changes.

[copych]

@rdridder btw, does GPIO 48 work for you? It's supposed to be NAV_LEFT, but no effect here for me. So I wonder if it's a software bug, or just my board defect, or burned/prohibited GPIO.

[rdridder]

For me all buttons work, also the left button mapped to pin 48. You can try to map it to some other pin and see if that works for you.

I have put the mapping in this comment. This is based on the reserved pins you have sent me so you should be able to find another suitable pin quickly: #10 (reply in thread)

[copych]

Yes, i have used this list for sure, thank you. BTW, I also experience some troubles with the pot input. This is surely due to the fact it's not soldered, but not only. ESP32's ADC is known to be noisy and highly dependent on the power source quality. So I think I'd comment it out for a while, or exchange it with the encoder. What is your experience in this matter?