Device LCD interface repository

Out of curiosity I was browsing the repositories of the Mod softwares and I noticed (if I’m not mistaken) that there’s no public repository for the onboard device control interface.

Am I right or did I miss it? Is it closed source? and if so, why?

The HMI, or Human Machine Interface as it is called, is indeed closed, because this more or less defines the entire physical UX. It is the only bit that MOD actually has to sell as a product. We can only hope that some parts may open up in the future, but for now I’m happy to have 99% of the stack be FOSS.

There have been requests to be able to add custom widgets or interactions from the plugin. I believe some ideas for extending this are being considered. But the firmware of the HMI devices themselves are unlikely to go FOSS.

Maybe just for the DUO? (since they are no longer being made, right to repair and all)


Hello @Tarrasque73,

I moved your post into the Developers category of the forum.
Have a nice day.

Greetings and God bless, Marius


Is it still true today that the HMI code is closed?
If so, are the datasheets available so that the community can write a new implementation from scratch?

I’m new here and really don’t understand the business side of Mod Audio but it seems to me that opening this code would make it possible for the community to use the device in ways not possible today, and that would sell more units, not less…

Yes, and no. The HMI and core design of the devices is the only IP that MOD really has. Since there is currently a business exploiting this IP it doesn’t make a lot of sense to release that for others to make their own competitive device.

I think it’s anyway extremely doubtful that “the community” would write their own firmware from scratch.

1 Like

I still don’t understand the business model, but that’s for Mod Audio to decide.
It’s a pity because I find this project really awesome and this piece of code is noise on an otherwise amazing record.

The protocol for the communication between the main OS and the HMI part is open, that being in GitHub - moddevices/mod-controller-proto: Protocol definitions for the MOD Devices controllers

That repo defines the messages possible to send from mod-ui and mod-host side into the HMI.

And yes, the actual HMI code is not opensource, otherwise doing a full product clone would become way too easy…
There is also the bigger project, we internally call it MOD build system, that is also not opensource and a critical part of MOD IP. It is what we use to create the entire MOD OS in 1 single step.
And dont forget the entire cloud infrastructure, from pushing OS images as automatic updates, plugin builds that also appear as updates, to device registration and licensing. More recently the AI pedalboard generator.
We also tried to do a demonstrator kinda thing in for which the setup is not open, though this last one we are not paying too much attention lately as it doesn’t scale well enough.

So it is not just the HMI code :wink:

I am a big supporter and enthusiast for all things opensource, and always push for MOD to have things open as much as possible.
We have the entire chain from kernel (see Commits · moddevices/linux-mainline · GitHub) to audio host (see Commits · moddevices/jack2 · GitHub) to the more known mod-host, mod-ui and all in between. Then pretty much all plugins being open too, the exceptions are typically 3rd parties and those where contractual/legal obligations do not allow us to keep it open.

With the GitHub - moddevices/mod-live-usb: MOD platform as bootable Live-USB image project (another opensource one) you can even have the entire thing running on a Linux system or bootable from a USB stick, it will build the entire core of the OS from that repo.

So, while we do have a few things closed yes, the parts that are critical to run the software on your own PC are pretty much all open and available.


Thank you @falkTX for your very detailed reply!
I can now better understand the reasons behind the decision to keep some parts closed.

As a user that is considering to buy a Dwarf for rehearsals and live gigs, but also a linux sysadmin and free software advocate since the 90’s, this is a major factor in my decision.

I’m trying to convince myself that when I buy a computer I don’t get the code for the BIOS, so in this case the HMI code it’s like the BIOS… :wink:

But then I start wondering that with that code someone could change the UI, for instance to simplify it and have a “stomp mode” and other mods. Maybe there is already a stomp mode (please let me know if there is) but this is just an example.

Anyway I want to congratulate the MOD team for their work because this is an amazing product! Hopefully you manage to keep it profitable for a very long time!


In what ways would this differ from the current mode of operation? Also, welcome to the forum! :slight_smile:

1 Like

I am thinking of a mode where for instance footswitch A would toggle a distortion, footswitch B would toggle a Reverb and footswitch C would toggle a Chorus. This would be fixed from factory, or maybe the effect on each footswitch could be selected from a limited number of plugins, but all from the dwarf and without the web interface. Basically a dumb mode. Please note that I never used a Dwarf, I’m currently reading the docs and watching videos so maybe this is already possible.

Anyway my point was that with access to the code it would be possible to make the device make things and reach audiences that are currently not available. Things that the MOD team does not have the resources to implement themselves.


Yeah, I think it’d be cool to have access to the HMI code, as a developer and open source enthusiast, but I’m currently okay with the situation as a user :slight_smile:

At one time, there was the goal of making control assignments and plugin selection from the HMI (as opposed to the web interface), but that has been de-prioritized. You can certainly assign endless knob and footswitches to control plugin enable/bypass and other controls, but you only get 2 switches per page. I guess I’m just trying to figure out what you know or don’t about how the HMI works, which is kind of hard in this format :slight_smile:

And to be super clear, I hope this isn’t coming off as hostile in any way, as that is not my intention! Really just trying to understand your vision of HMI operation :slight_smile:

1 Like

And to be super clear, I hope this isn’t coming off as hostile in any way, as that is not my intention! Really just trying to understand your vision of HMI operation

I didn’t took it as hostile. In fact I thank you for taking the time to reply.
Hopefully what I am saying is also not taken as hostile because I feel the project is amazing!

Regarding my understanding (or lack thereof) of the HMI is off topic in this thread which is about the code and license. I’ll educate myself first and create a new topic if needed. Thanks!


No hostility detected here! You are in good company here! Most of us think MOD stuff is pretty amazing :slight_smile:

What makes a project amazing is also its community and so far the reception as been friendly and informative. Thank you all. :+1:


Forgive me if I’m not fully understanding what you propose.

The assignments as you propose in your topic are currently possible, including multiple assignments per switch or encoder.

This bit, however

Is a recipe for disaster, in my opinion. If one such assignment is made standard in the interface, that opens the door to many more requests for other such features and an endless questioning as to why ‘this’ assignment and not ‘that’ one.

Whereas adding more features is not a problem, the fact that it can be done via existing plugins and the freedom that comes from that is probably more useful than tweaking the firmware.

I see your point when it comes to open-source, but this layer is the only one that is proprietary, and essentially the only part of the entire MOD product that cannot be reproduced in hardware, so I can understand the commercial rationale for keeping it as such. It “hurts” the open source community – I’ve seen posts to that effect in forums, but as a product being sold at a considerable price, being open as it currently is is already to some extent a market liability.

Good luck regardless of your choosing to move forward with MOD or not.


This two quotes show exactly why it wood be good for the code to be open. The MOD team can still ship the version that they decide to be the best (for business and other reasons) but a person or group would be able to do their version to better suit their needs.

1 Like

These cannot co-exist in a finished product in the market without the risk of making the product dispensable and/or obsolete. With new boards and controllers being available, it becomes too easy for someone with a modest investment to fully replicate the MOD environment at an even lesser cost. As a matter of fact, the entire audio stack being open source would make a MOD competitor be possible at a fraction of what their investment was in the current market.

I respect your opinion and desire to fiddle with it and/or have it optimised at a personal level, but I can’t see any benefit to the MOD as a business entity to allow that to happen. It “would be good” for some and could be detrimental – if not lethal – to the company.

It might be preferable for you to look into products like Zynthian or PiSound, which are fully open source. In fact, the Zynthian allows for custom designs and implementations and is not constrained in physical format. It is possible to build a fully customised Zynthian box that runs MODEP and add whatever switches and encoders to one’s liking. (I’ve seen one that had a tube preamp stage, for instance.)

Disclaimer: I am not affiliated with MOD Audio UG.


EDIT2: what I said previously was wrong, got confused with Beebo, disregard this
Keeping old post contents for posterity and transparency

Small correction, not everything Zynthian has is opensource, the same scenario with “mostly open but a few critical bits are closed” applies there too. I dont know too many details to be honest, just heard it from someone that investigated the matter

EDIT: I might be confusing this with Beebo, will ask around…


I can’t tell for sure, but here’s what the website says:

But yes, there might be some bits that are not fully open. They used a custom HiFiberry at one point. (My guess only, I don’t have any knowledge whatsoever).

Thanks for the links to Zynthian and PiSound. They seem great projects. I also found Pi-Stomp. The first two seem more oriented for synth because they don’t have foot switches. It should be possible to connect a USB foot switch but that’s more stuff to carry around. And currently it seems that buying a Raspberry Pi is still not that easy…