What does a blank screen and blinking gate buttons mean on the Befaco Lich?

OWL Lich
#1

I’m trying to port the Resonator model from Mutable Instruments Rings to the Befaco Lich module. I was able to compile the code using emcc and run it in the browser without issue using the OwlProgram. I’m running OwlProgram in a Docker container.

I was also able to compile the code into the patch binary format. However, when I uploaded it to Lich using the FirmwareSender the module ran for a couple of seconds without any output and then stopped responding, the display went black, and the gate button LEDs started blinking in turn (either button is lit up for about 150ms then turns off).

I’m trying to debug the code, and I was wondering if that behaviour has a specific meaning? I have not seen that behaviour before, and couldn’t find it described in the documentation on forums.

When I restarted the module the first time, none of the stored patches worked and I didn’t get any audio. I had to restart the module a couple of times (I tried starting it once in boot mode by holding the encoder) before it started working again.

Has anyone had anything similar happen?

I can share the code when I’m on my desktop.

#2

IIRC, button blinking is what bootloader mode does when you enter it. I think you should be able to confirm this based on USB device name if you check it in patch library.

I suppose that you’re crashing firmware, which could happen for various reasons. Typically it’s related to memory allocation issues or overflowing stack due to not allocating objects dynamically. Or it might be just a patch that’s too slow which will be detected and you’ll be returned to bootloader mode.

The best way to debug memory issues is by using “make grind” command that runs valgrind and was very useful for me when trying to get some more complex code to work correctly. Of course it runs it on native executable rather than what you actually run on OWL, but this is still much closer than what you get from emcc in browser.

As another experiment you could try setting “PLATFORM=OWL3” as environment variable (assuming that you have a Lich with OWL3 board). However you shouldn’t need it generally, the only exception is if you somehow end up writing a patch that is too large which generally is avoidable with C++ code.

I won’t have access ot OWL hardware for the next month or so, but I can at least take a look at your code.

#3

Thanks for the reply!

Yes, I think it went into bootloader mode. The patch library service was down at the moment, but I was able to check it from the firmware upgrade tool OpenWareLaboratory, and it was only showing the firmware version, which it usually doesn’t do.

I will go through the code and try to weed out places with potential issues.

The best way to debug memory issues is by using “make grind” command that runs valgrind and was very useful for me when trying to get some more complex code to work correctly.

I wasn’t aware of that option/target, I will try that!

I don’t think this patch is that large, the binary is 12 KB.

#4

Here’s the source for the patch. It contains the resonator model from Rings and its dependencies. All other files and (most of) the unused code have been removed. The resonator class is imported into the main patch file RingsPatch.hpp and used as a VC oscillator, and the parameters are mapped to the A, B, C and D pots.

RingsPatch.zip (23.3 KB)

Could the way in which the resonator instance is allocated be causing problems?

I wasn’t able to debug with the make grind command yet, since I’m running v21.1 of OwlProgram and it’s not available in that version. I haven’t had time to test the more recent version, and I recall having problems installing/running it inside the Docker container.

#5

Well, you should definitely consider trying to upgrade OwlProgram, preferably use the develop branch from github.

As for the patch itself:

  1. Resonator should be dynamically allocated. This might improve performance in some cases (on OWL3) and can resolve some problems with memory allocation
  2. calling .tanh() might be a bit too computationally expensive to limit signal amplitude, maybe try replacing it with .softclip(). I’m not even sure if it’s needed or maybe Rings code is guaranteed to never clip. This is probably only relevant on OWL1/2 hardware.

You should probably try to identify which place is causing your patch to fail, i.e. try running it with fixed frequency (with all V/oct stuff commented out), without calling Resonator::Process, with nothing at all in ::processAudio method, etc.

I might try running your patch myself, but if all else fails you could probably get something similar resuls from DaisySP library. It works well on OWL and includes some physical modeling stuff ported from Plaits