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.
4 Likes
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
- MOD is working towards too (or)
- 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 
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:
- 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
- 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. - somewhat related to the previous point, suggestions for updated plugin descriptions are always welcome.
- 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.
25 Likes
Sounds great the idea of plugin “ownership” or “management” is a great idea. I think more accurate descriptions of the plugins would help massively.
4 Likes
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.
2 Likes
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.
4 Likes
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.
10 Likes
Most of the stack is already opensource: MOD Audio · GitHub
See mod-host (running the DSP) and mod-ui (the webserver).
2 Likes
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 
) 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.
3 Likes
Hi @mszinger
Welcome to the forum and the community!
If you are willing to get involved, the timing is very good. We have recently released the Desktop App which will make involvement much easier for the community.
As @unbracketed has already mentioned, there were numerous talks here in the forum about this, and many of the features were actually implemented, but the fact is that things need to be detached, otherwise:
- the team is too small and is not able to cope with all the community demands
- the wishes of users are not always in line with the needs of the business
I highly believe in the community having authonomy but that must be able to live alongside the business. One of our ideas with the Desktop App is that we make this detachment and give authonomy to the community. I think it would be fantastic if I could simply enable a “community UI” in my device.
That is correct. The Web UI speaks to the host via a TCP socket. Here is a general diagram of the system:
The system is quite straight forward, with mod-ui acting as the center piece and mod-host as a very modular audio host that creates jackd clients for each plugin, and jackd taking care of the processing of the graph.
mod-ui is somehow bloated and currently contains both the front as the backend. It has the Web UI, the interfaces to HMI, control chain and mod-host, and an IO loop to take care of all messaging.
I would love if the community managed to work on the dismemberment of mod-ui, separating the Web-UI from the rest and publicizing a rest API for that communication. The API is already there, but it works internally and needs to fully defined/documented.
Once such an API is defined, we could actually have multiple different UIs depending on the wish,m as you also mentioned.
For that I think the input of the community is crucial, as you guys are going to be the “clients” if such an API.
And of course, the input of @falkTX @Asa @acunha @Markus @markuss and many others that have been involved is also important.
Looking forward to hear more 
5 Likes
Thanks for the warm welcome. Yeah, I immediately grok the need to split up the web client and server. I looked at the server side and said “yikes! Python!” - nothing personal, I’m just a Node.js guy. But if I could clarify the web API I could do exactly as you suggest, write a new client, probably a simple reference platform used to validate the API. Then all sorts of good things could happen.
Limited real-world and mental bandwidth, I’m going to go away for a bit and start chewing everything in github, wiki, etc.
Cheers,
Martin
6 Likes
well, this is exciting… the possibility of community-driven forks to explore alternate ways of pedalboard editing, as well as possibly addressing some of the longstanding community feature requests. this sort of model means that these can be clearly presented as alternate versions, while the official MOD version remains the carefully vetted baby of the MOD team. …kinda like the BETA plugins?!..
congrats to all who initiated the desktop version, and to all who participate in however this develops!
i’m not capable of doing UI coding, but will certainly be game to help with ideas and testing.
4 Likes
Hello, I would like to contribute working on the backend refactoring. My idea is to work on splitting the source code on well defined layers, uncoupling some things, such the web layer, the model classes, the frontend, the persistence, the mod protocol communication. It will enable to improve the code maintenance and also community contribution.
The main question here is that when we do a code refactoring, at long term, there will be a lot of code changes, that will be improbable to be accepted by the mod team. So, I was thinking about it and conclude that if I make small pull requests, it is more feasible to @falkTX accept them. I could also start organising the API REST documentation, so would be easier if someone try to develop a new/customized frontend, as instance.
Another possibility that I thought is a preview/beta mode into desktop application with optionally Sentry/Bugsnag integration for easier bug monitoring. The user could changes between the original mode and the refactored source code.
@gianfranco, if you are interested in this idea, we can make a meeting when we can try to define a way for helping Filipe work.
8 Likes
API and User-defined UI could facilitate some wanted quality of life improvements, like direct MIDI bindings editing, viewing all assignments on one page, lightweight “mobile” version of the UI without raster graphics - suitable for bluetooth connection (making bluetooth useful finally), smooth zoom in/out, disabling that auto stereo jack connection that annoys me this whole time, maybe integrating some external automation scripting to control assignments or pedalboards by network and rest calls (how about smartwatch app controlling MOD ), maybe possibility to save favourite pedalboards locally.
There are a lot of cool improvements and possibilities that may become true if python sources on MOD would be editable.
Hope that whatever comes - it would be possible to try it on MDX.
8 Likes
I second the suggestion of working on the API and UI aspects
4 Likes
Wow. Quite a lot to digest here. I’m a somewhat tech-savvy geezer with 30+ years IT experience, but I’ve never considered myself to be more than a dilettante in that regard. I’m thinking seriously about getting a Raspberry pi 5 (arm cortex-A76) in the next few months.
Also l’ve got the gcc-arm-linux cross compiler installed on an intel i7, so I’m going to start digging a little deeper into the software side of things.
I’m really nothing more than a “tinkerer” in the developer world, but beta testing and documentation are two things that I’d love to help with - particularly the documentation.
And then there’s my “holy grail” - the B. B. King Live at the Regal “Everyday I Have the Blues” tone that I can run through something and actually carry around - like the ehx 5mm/howitzer/44 magnum series.
“I’m not dead.”
4 Likes
You should be sainted, honestly.
4 Likes