AMY Arduino drum and fm examples on ESP32S3 cause restart

[RocketManRC]

I'm experimenting with AMY and ran into the problems mentioned in the title. I'm building with PlatformIO using a project template that I've used many times before. The I2S device is a PCM5102A board which I got to work with some effort and the two sine wave and the voice_chord examples run as expected.

Since I'm using PlatformIO I ran the fm and drum examples under the debugger and found the source of the crashing for the fm one. This is because in algorithms.c at line 123 the order of the arguments is reversed from what is expected causing an array out of bounds error that is doing something bad. Changing that fixed the crashing but there is no sound generated.

I couldn't find the source of the crashing for the drum example so I built the desktop example for MacOS. In this case the drum example does run fine. The fm example however gives a sawtooth like sound without the fix and no sound when the fix is applied.

I wondering if the examples got out of sync with the library somewhere along the way? I did go through the commits over the past few months but couldn't see anything obvious.

BTW I really like the Tulip concept and have ordered a Tulip CC from Makerfabs. I also have some other things I would like to try with AMY itself or maybe a scaled down Tulip with no user interface except for configuration and control via MIDI.

[bwhitman]

Nice, thanks for checking out AMY!

I'll take a look at the Arduino examples asap. It's most likely they got out of sync -- we've been fully on Tulip the past couple of months and probably messed that up.

The FM example in examples.c was incorrect, that was a bug that popped up a couple of weeks ago and didn't check in examples.c. Try that again! (it's quiet but you should hear a bell-like tone)

[RocketManRC]

Still no joy with getting sound from the fm example on either of my projects after replacing examples.c. There must be something else that needs changing.

[bwhitman]

Just to make sure, change the velocity to much higher -- it's a very faint tone and may not show up on your DAC. Like change line 321 of examples.c to e.velocity=50.0f;

And if you're using Arduino, make sure you delete and re-copy the AMY repository (checked out from the main branch) so it's not using an older version.

[RocketManRC]

I've confirmed that examples.c in both of my projects are the current one and changed the volume as suggested but no luck with either project. I downloaded the AMY repo a couple of days ago and was working with that but now I've done a git clone for my latest test. Tomorrow morning I will start fresh in case I've messed something up along the way :-)

Thanks for pursuing this!

[RocketManRC]

I looked at this again to make sure I'm building the fm example with the modified examples.c and have added the velocity statement and there is no sound with either the esp32s3 or the MacOs application.

[bwhitman]

I've gone and made the amy-example binary play the voice chord (juno-6 patch 0) and then the constructed 2-op FM tone one after another (at a more reasonable volume.) On my Mac, when I run make in the AMY repo root, and then run ./amy-example, I hear a three note chord and then a bell-like FM tone at about the same volume. Can you try this (after a git pull) and tell me what you hear on macOS? Then we can debug what's going on in Arduino.

[dpwe]

No sound on Mac could be using the wrong audio device, I.e. needs -d 1 or something.

[RocketManRC]

The MacOS version works perfectly now. I built my previous version using XCode and maybe I messed something up or Clang compiles something that is incompatible?

I tried again with Xcode and the updated amy-example.c and get no sound from the fm tone (but do get sound from the voice chord). I don't know why I used Xcode as I much prefer the Makefile/Gcc method. Sorry Brian if I sent you on wild goose chase with that!

[RocketManRC]

Sorry I spoke too soon. In the Xcode project I had changed the call to note_on_mod() in algorithms.c to agree with it's definition and the fm tone didn't work.

Just to be clear, in algorithms.c at line 123 this is the call:

note_on_mod(synth[osc].algo_source[i], osc);

and the definition in line 99 is:

void note_on_mod(uint16_t osc, uint16_t algo_osc)

which I thought was causing the crash in the Arduino example but perhaps it is something else. Changing the order of the parameters in the call did fix the crash but didn't generate the tone.

[bwhitman]

The note_on_mod stuff seems correct to me. algo_osc in this instance is the "base" oscillator, the "control" oscillator that you send notes to. algo_source (not algo_osc) is the list of source oscillators (aka operators) that make up an ALGO voice. In algorithms.c's algo_note_on we take in the algo_osc as osc, and run through its set algo_sources to start sine note ons per operator. We pass note_on_mod the operator oscillator number as well as the algo_osc (base osc).

Having a bit of trouble following our troubleshooting, don't mind me -- are you hearing audio output with unmodified amy-example compiled from main on macOS now, or are you still having trouble? I'm sure there's some skeletons in our algorithms closet, but the DX7 patches work and sound great so I don't think we are rendering the wrong type of oscillator. So I'm hopeful to find our fix for your issue elsewhere!

[RocketManRC]

Yes everything is fine with the MacOS version now.

As for the Arduino example when I used the debugger I saw that the first parameter which is an index into the array was 0xFFFF so I thought that the order of the parameters was wrong but I guess I just jumped to that conclusion because of the naming. Probably a red herring.

[bwhitman]

ok great!! When I'm back up at my studio this week I'll test some Arduino examples. Thanks for your help, I'll be back!

[RocketManRC]

Anything I can do to help let me know. I am slowly figuring out how things work and loving it! Both AMY and Tulip are amazing projects (and of course Alles too although I haven't spent much time with it yet).

[bwhitman]

Also pasting in a similar report from discord user mathias:

Cool! I guess I may have found the issue (but sadly not fixed yet) with "amy.drums(clock+5000, 2); " not working with the ESP32 example. I am afraid that currently no time-based queuing of amy-events is working at all. So either the long clock = amy.sysclock(); does not work as expected or when in the main loop "short * samples = amy.render_to_buffer();" is execuded any e.time events are ignored. Whenever I add events they are (at least that is what I kind of observe) played "at once" and for some reason with amy.drums() that is too fast (or similar) and crashes the program (when I said everything was up and running, I maybe was a bit to optimistic, because at first I always tested with one note only and not sequences of notes, yet 😉 I suspeced that there may be some kind of #define constant not set correctly and tried out ESP_PLATFORM, but that seemingly is alread set

I'll be taking a look at this stuff this week.

[bwhitman]

OK, I think I fixed the drums restarting. See #142 but we were not resetting the oscs before changing the wave type. It's not clear why this crashes only on ESP32, but it's not something you're meant to do, so I just added an explicit reset in example_drums and in the ESP32 Arduino example.

I've also tested the (Now louder) example_fm example, and everything seems good on ESP32. Thanks to the discord forum member Mathias for help on the newer ESP_I2S setup we need to do as well.

[dpwe]

pcm.c:23 checks for logfreq[COEF_CONST] <= 0 which looks like a hangover from the pre-log-freq days. So I suspect it's the freq=220 rather than the wave=SINE that's triggering the crash. It would be interesting to see if freq=440 fixed the original problem (since I think the transition from negative to positive logfreq is at 261 Hz).

I'm not clear about the intent of the logic in pcm_note_on(), but it may be that we want == instead of <=.