Ehm, please don’t ![]()
I find it very handy to use both the web GUI and the on board editor at the same time, and I remember a post of another user who tweaked the software to bypass that nag screen.
If you think you really need to solve the issue, maybe you should prevent the web GUI from saving a binding if the onboard editor it’s opened.
Don’t get me wrong… But you can’t take that hiatus. lol… Looking forward to more updates. This project is sensational! Congratulations!
Hello,
as expected development slowed down during december and january, too busy at work, but I’m near a new release.
I hope to finish the last things in the next weeks ![]()
@jon I didn’t manage to reproduce your bug would mind to send me the pedalboard?
Sure! I’m really happy that you are getting back on this ![]()
Little note, not sure why, but I was not able to share the pedalboard via the share pedalboard feature over the pedalboard feed. I was always getting an error both with your MOD OS version as with the original. So I took it over ssh.
Here is a zip file of it: https://drive.google.com/file/d/1hFIIzDIyY53oWH0Kg_COsFkyu8AbHVP8/view?usp=sharing
I have another thing to add on this: the controls that actually show up is what I have assigned on the normal assignments system. First page, first sub-page.
Thank you so much for creating this great addition to the ModDwarf! I understand that it`s a lot of work and possibly extra work with bugfixes and so on.
Anyway, I still dare to wish for implementation of two way midi. Maybe this would still work? Midi cc out nrpn by AndrewCapon · Pull Request #62 · mod-audio/mod-host · GitHub
I will also try to report if I discover some bug.
That would be great !
@AndyCap (Andrew Cap already made the code but was never merged with the MOD OS.
I can’t find it…
Here is a thread talking about it this some Guthub links
Hi all,
this year it’s been harder than usual for me to get back to my normal pace, and I still have very little free time (day job, family, and music of course). Things are slowly getting back to normal though.
Right now I’m working on the last bug [1] I’d like to fix before doing a release.
It hasn’t been the most fun task — it turned out to be quite tricky, and there are still a few issues to iron out that can cause the controller to crash pretty badly ![]()
Here’s a video showing my progress so far [2]. Keep in mind that the settings are specific to each pedalboard.
I hope to finish this and release a new version soon [3]. After that I’ll try to take a look at the patch Andy linked, but I can’t promise anything since it’s a module I haven’t really looked into yet.
[1] “assign all” function: include only a subset of a plugin’s presets · Issue #20 · sejerpz/alabs-mod-custom-images · GitHub
[2] https://www.dropbox.com/scl/fi/ugj5jursu87ocy54fe9np/Mod-Dwarf-Preset-Selection.mp4?rlkey=mshd442cv61j5ifowjgzwexea&st=b5b778po&dl=0
[3] GitHub · Where software is built
Some quick news: I’m finalizing the development, and if there are no surprises I’ll try to release a new version this weekend.
To gather more information about the controller crashes, I added a new screen with some useful debug information.
If your controller crashes, please send me a photo.
Both the screen and the footswitch LED color contain important details that can help with debugging.
haha, fantastic! hope this debug info will help fix any problems quickly!
Yep, it depends on the type of crash. In cases of heap or stack corruption the information may be unreliable, but for most other kinds of bugs the PC contains the faulting address and the LR contains the return address of the caller function.
I tested this, and with an exact copy of the firmware compiled with -g I can retrieve the exact .c line using addr2line:
arm-none-eabi-addr2line -e out/mod-dwarf-controller.elf 0xbece
/home/andrea/Alab/Devel/mod/mod-dwarf-controller/app/src/main.c:129
For this reason the crash screen also shows something like v.839cfe79, which is the git commit hash of the distributed firmware version.
Also, the color of the central footswitch indicates the type of fault.
In this case red means a Hard Fault.
The original firmware always used magenta but switched the LED that was lit. I preferred to keep the same LED and just change the color ![]()
I’ll try to document everything better in the starless wiki.
EDIT: On a side note, I noticed that the linker files hardware.c file is incorrect. Not all the available RAM was reserved for heap usage — only about 40 KB out of ~64 KB available. I’m still carefully double-checking the changes needed to fix this.
Hi Andrea,
I just noticed on your github the bug “CV Bindings duplicate entries in combo #34”: it also happens for Control Chain bindings.
All the best!!!
From the commit log [1] it looks like I applied the same fix to CC devices as well, so please try again with the next release.
Let me know how it goes, since I don’t have any CC device to verify the fix on my side.
It’s always good news when this post is updated. Looking forward to the new version. Thank you very much for your work!
After a long night digging into this, I can confirm that not all of the HMI memory is configured as heap regions.
With the current setup, only a total of 40 KB is reserved for the heap memory pools.
INFO:root:----------------------------------------
INFO:root:HMI LOG: 'SRAM: 0x10010000, SRAM0: 0x20008000'
INFO:root:HMI LOG: 'Reg. 0: 0x10006000-0x10008000 (8KB)'
INFO:root:HMI LOG: 'Reg. 1: 0x20000000-0x20008000 (32KB)'
INFO:root:HMI LOG: 'Total: 40KB'
INFO:root:HMI LOG: 'Free: 4528B'
INFO:root:----------------------------------------
This is what I’ve configured now (8K reserved for the main stack, I hope will be enough):
INFO:root:----------------------------------------
INFO:root:HMI LOG: 'SRAM: 0x10010000, SRAM0: 0x20008000'
INFO:root:HMI LOG: 'Heap: 0x100046c0-0x1000e000 (39232 bytes)'
INFO:root:HMI LOG: 'Sys stack: 0x10010000-0x1000e000 (8192 bytes)'
INFO:root:HMI LOG: 'Reg. 0: 0x100046c0-0x1000e000 (38KB)'
INFO:root:HMI LOG: 'Reg. 1: 0x20000000-0x20008000 (32KB)'
INFO:root:HMI LOG: 'Total: 70KB'
INFO:root:HMI LOG: 'Free: 35568B'
INFO:root:----------------------------------------
The question now is: why did the original firmware use only 8 KB from the first memory bank for the heap, leaving the remaining ~56 KB mostly for the stack (56 KB − 19 KB for bss + noinit)?
@falkTX or someone from the MOD team — does anyone remember the rationale behind this decision?
EDIT: I’ve just pushed all my changes. So far this firmware version looks very stable.
If any FreeRTOS experts are around, I’d appreciate some feedback on the heap changes.
Here’s the commit: fix heap memory region definitions, add option to enable rdimon, bett… · sejerpz/mod-dwarf-controller@d2c360c · GitHub
New release - aLabs version 9
After quite some time, a new release is finally out \o/
In this version I focused mainly on controller stability (@jon — please try it with your pedalboard).
I also managed to implement preset binding selection [1].
A small additional feature is the ability to change the audio buffer size directly from the device, through the system settings [2].
Download: Release aLabs version 9 · sejerpz/alabs-mod-custom-images · GitHub
[1] Presets bindings selection · sejerpz/alabs-mod-custom-images Wiki · GitHub
[2] System Settings · sejerpz/alabs-mod-custom-images Wiki · GitHub
Hi Andrea, I confirm: it works also for the Control Chain.
Thanks!!!
Since I don’t have any CC device, could you send me a screenshot of the binding overview on your unit when you have some time?
I implemented the feature completely blind, without being able to test it myself, so I’m curious to see whether it actually works.
Hi Andrea, thanks for your work !
I just tested your new version. I don’t know if it’s a bug or a feature… In the Web GUI the option to save, rename and delete presets of a plugin is greyed out, and every time I save a new preset, the small square is positioned on the right and it doesn’t appear in the Dwarf’s list.

Those are bugs for sure, I’ll take a look asap. Thanks
EDIT: fix just pushed, waiting for more testing before redoing a release ![]()

