MOD OSS - Will you help to improve it?

I’ve been musing on this for a whlle now.

Background: I’m an ICU nurse with nearly 30 years of prior IT dev experience.

I’ve contirbuted to a number of OSS projects in the past such as home assistant, yarn and rollup … it has always benefited me (and others)

I love the MOD ecosystem, the fact that it is OSS means I can tweak to support my gig’ing. My Dwarf is the main element in my pedalboard (Plus a midi pedal) … who would need anything else? lol

MOD have had some hard times recently.

There are a number of requests here in the forum for changes to the UI (and other stuff) and I feel they do not have the capacity to addres these.

Given the limited resources at MOD and their obvious need to focus on their proprietary firmware code and hardware (IMHO) I wonder if there are a number of us who would care to contirbute to making this the best platform on earth by contributing to the OSS elements of the system.

  • I’m a techie and would love to help with MOD OSS development
  • I’m not a techie but I love MOD
  • Other

0 voters


great initiative, @SamIAm… i really hope the MOD folks are into it!

not sure your survey captures those of us who aren’t programmers, but who regularly build complex MOD pedalboards and are interested in deep testing and bug reporting… that would include me! :wink:


I think there is an overload of those and only a tiny minority of developers :wink:

Personally I am a dev, but I try to stay far away from front-end stuff and the one time I dove into some of the back-end I was quite lost. Of course I do applaud the effort to try and coordinate some additional development effort into the MOD software stack!


I’m a frontend web developer, would love to help out where possible. Don’t have a huge amount of free time but definitely feel like I’m missing some extracurricular web dev work.


A VERY good point, testing is essential to ensuring quality.
Another key contribution is great documentation.

I’m not sure if editing the poll would break it so I won’t try …

  • I would help with coding
  • I would help with testing
  • I would help with documentation

0 voters


It would only take a few folks :slight_smile:
And I suspect there are people who use the MODAP stuff who would get involved too.


I can do full stack, but the front end stuff has never been my strength … but such is the power of collabrative OSS, many hands and all that! :slight_smile:


I am a dev with some background on both Linux and Windows (I prefer Linux but work on Windows in my main job). I would LOVE contributing to code and have been fantasizing on doing it for a very long time, but realisticly, I won’t be able to carve any time for it in the near future.
Still I am happy to follow what you guys are doing. Maybe doing a bit of code review here and there, a bit of testing, maybe dropping my two cents from time to time, about code or about how to organise the work… I don’t know.


Including changes from community members into official MOD repositories it’s not likely to happen soon and/or with ease. AFAIK the only person that supervise the codebase is falkTX and he’s probably overwhelmed by already planned activities. For what I’ve understood, work on external plugins is always welcome but changes on the mod-ui side (for example) from individual contributors will be hardly included in the official codebase. With the resources that MOD Audio has at current time there’s no space for project management with external contributors, task lists and the like. Small changes like bugfixes and very little improvements are likely to happen because they cost less in terms of code review but do not expect to see your changes ALWAYS included into master branch. Before doing some work (and waste your time), try to talk with falkTX to see if there’s something worth to work on.


I take your point, there are significant benefits to OSS community engagement.
I have been in touch with @falkTX about this suggestion and with his impressive OSS experience I have no doubt that he will make the best choice for MOD and it’s customers.


Hi @SamIAm I was going to reply to your PM but since you made a public post we can keep conversation here.

The initiative is for sure appreciated but as others have certainly noticed it is much easier to handle developments on plugin side vs system features.

Open-source development has a lot of “one-off” contributions, where an author/developer wants to see something happen in a certain software and pushes for that feature (which is nice of course) but from my experience they do not stick around to maintain it and assume the main developer of whatever they are targeting will take care of future maintenance.

For MOD’s case even if developers would stick around to maintain their contributed part of the codebase, it creates an imbalance due to their work not being remunerated or compensated.
And I would say at this point the main pain points for new users coming to the MOD platform are not the lack of features but a matter of polish and quality of the whole experience. There are a few features that would be quite nice to have, but we can still improve on a lot of things before we consider new ones.

And @redcloud is on point, for now it is just me taking care of plugin store management, releases, kernel updates and fixes, cloud issues and many other tasks.
As much as I would like to lead efforts for getting more stuff done via contributions, my time is already quite filled up and I think it is already frustrating to some other devs here that were hoping to see their stuff more actively integrated…

The best so far is to have contributions for things either

  1. MOD is working towards too (or)
  2. are self-contained not risking breaking anything else on the system.

I have seen developers that were once quite engaged trying to push for a feature slowly give up on the entire thing because our (MOD) side moves too slow and cannot accommodate their request in a timely fashion (or quick enough before they lose interest).
It is just hard to justify spending time on these things when we are the ones that need to keep maintaining them forever, if anything breaks during updates we cannot rely on someone that once pushed a feature X months/years ago again as they have 0 obligation to come to our help.

One recent item that got some fixes (still in progress) is the tuner, that is self-contained enough that we can change things without potentially breaking the rest of the system. @brummer is taking the lead on that and it is very appreciated. Helps a lot that the original tuner implementation was from him too :wink:

This is why plugins are a much safer part of the ecosystem to target, though yeah it is also very technical in nature.
Thing is, dealing with plugins does not have to be just code. Thinking out loud there are quite a few things that help the whole community a lot and does not need coding skills:

  1. make list of plugins that have direct replacements, so eventually we could put them in a “legacy” category, perhaps to even be hidden from the store - with the result being less user confusion with many plugins that do the same thing
  2. become “manager” or “owner” of certain plugins, then creating a forum topic specific for a plugin so that questions/discussion around it happen on it but one person is the “master” that knows the plugin very well - we could easily add the “see discussion” button for these forum posts, helping users to find more information about random plugins and having a centralized place for discussing it
    We kinda already have this for new plugins where the developers are directly involved with their publication to the store, like aidadsp and looperlative, but many older ones like CAPS and TAP that we ported over into the platform do not have the original developer on board.
    It should be possible to organize people around certain plugins, where they become the ones to talk to about them.
  3. somewhat related to the previous point, suggestions for updated plugin descriptions are always welcome.
  4. mini communities around a specific kind of platform, like max-gen, puredata etc. some of this already in progress

now offtopic, but what I am doing at the moment I hope to be useful for the plugin situation… based on the modgen by another developer here on the forums, trying to get a “cloud builder” that can deal with building max-gen, max-rnbo, faust, puredata, etc based plugins in a easy way. so the mini-communities can grow more organically, without users needing to roll their own docker services and alike.

then also have the same platform host all the current “beta” plugins on the store, since the logic for pushing plugins to a device is the same anyway. this would allow us to finally clean up the entire store of those plugins that we once uploaded but for sure are never going to be put in stable.

for now the case of max-gen builds takes priority as it is something that was working before but got broken, so trying to fix that as soon as possible. then extending to other build types.


Sounds great the idea of plugin “ownership” or “management” is a great idea. I think more accurate descriptions of the plugins would help massively.


I think this is an issue with a lot of open source systems though, specifically with Mod it is more of an issue because you have a closed/open system based on hardware, you really don’t want the core of your hardware product being unstable. You just don’t have the staff for this sort of thing, its basically just you.

A bit annoying but that is how it is.

1 Like

I can see that, I imagine that there is mileage in publishing these on the github site with the “help wanted” tag and see who steps up.


Hey @SamIAm

We have released a desktop version of the software: Introducing the MOD App for desktops - Beta release

I think that engaging the community on cooperating around that project might the best path for the community to get involved.

1 Like

Awesome! Tho I will need to wait a bit, I’m a Mac user.


Hello, brand new MOD Dwarf user here, also brand new to the forum. Zeroed right in on this thread, I’m a 30+ yr experienced software developer.

My first impressions with the Dwarf is - brilliant concept and device, so much potential is unreachable at this point. The UI is painful, and I will probably not stick around to evaluate the quality of the actual plugins if the flow is really this rough.

Immediate needs IMO include:

  • mouse wheel must do zoom +/-
  • needs an Audition feature that makes it simple to swap one plugin for another
  • needs a tray area at the bottom with large & direct access to parameters of the currently selected plugin

Quickly scanning the forum pages, I didn’t find any sort of feature roadmap or pinned/maintained list of feature. Maybe they’re somewhere and I’ll find that…

Given that the UI is purely a web app served from the device, and presuming that means actual changes to the device are communicated back via some protocol (restful http api, web socket…?), if MOD is too resource-bound to make UI improvements, maybe they would consider open-sourcing the relevant protocols to free the OSS community to make alternate UIs. There’s a strong case to be made for multiple different UX/tools depending on the sort of thing you are creating.

Pulling for this very promising product to succeed.


Most of the stack is already opensource: MOD Audio · GitHub
See mod-host (running the DSP) and mod-ui (the webserver).


Thanks, I am checking it out now. The architecture seems reasonable, so that’s good news, too.

Hi @mszinger , welcome to the forum.

I share some of your feelings about the overall UI and experience. Over several years on this forum there have been numerous discussions about alternate interfaces and additions needed to make for a more streamlined workflow. In my experience, many in the community have some preference for the current pedalboard builder UI (they just don’t know any better :joy:) For better or worse, I’d say it’s a big part of the brand, maybe more so now with the focus on the desktop app.

It’s been quite a while, but I’ve poked around the source, and you can open a web inspector and watch the web socket traffic to get a pretty good sense of what data is being exchanged in response to UI events. So in theory you could develop your own UI over the web sockets API. I agree that having some documentation would help indicate that rolling your own is something MOD supports in spirit, and a few of us could probably write a first draft based on what we can inspect right now.

Your suggestions are good - I think the Desktop app already has a new audition / swap feature!

needs a tray area at the bottom with large & direct access to parameters of the currently selected plugin

I agree and think there’s room for a few tools for better managing pedalboards:

  • There have been several good suggestions for improving the hardware assignments dialog like batch editing of assignments, copy/paste, drag/drop, having labels
  • Having a dialog for viewing and directly editing all MIDI assignments
  • Better tools for managing snapshots - copy/paste, update all snapshots when the pedalboard changes, ability to view and directly edit what gets saved in the snapshot, ability to exclude some plugins from snapshot, etc.