MOD OSS - Will you help to improve it?

Developers
#21

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:

Screenshot 2023-10-11 at 19.42.49
Screenshot 2023-10-11 at 19.42.491313×538 32 KB

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 :slight_smile:

5 Likes
#22

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
#23

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
#24

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
#25

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
#26

There you go: Introducing the MOD App for desktops - Beta release - #39 by falkTX

2 Likes
#27

I second the suggestion of working on the API and UI aspects

4 Likes
#28

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
#29

You should be sainted, honestly.

4 Likes
#30

HAH! THANK YOU!

Plain old unadulterated selfishness is a large motivating factor here - I need to put together, in one document - a “cookbook” style document for several areas of the entire mod infrastructure.

Age and health related issues will be something of a barrier, as well as my hard-wired “shiny object” propensity.

2 Likes
#31

@Dave_Parker that would be freaking awesome :slight_smile:

4 Likes
#32

Thanks @gianfranco !

I really need to do this for myself - it would save me a lot of time, and other people might find it useful. If we get a few people kicking around ideas among themselves something useful will come out of it.

…“given enough eyeballs, all bugs are shallow”.

4 Likes
#33

Hi @Dave_Parker

Maybe you could think about creating unit tests too.

As you know, despite the high interest of MOD team in receive contribution from community, there is the maintenance barrier: with more contributions, more to maintain, and generally for a long term.

But if the mod source code had a high test coverage, the maintenance barrier could be decreased, because the tests will guarantee that new changes and contribution will not improperly change other non related things (as side effects).

In this direction, I created a pull request with unit tests configured. This branch introduces unit test for Snapshot endpoints.

I am also working on tests for host.py source code, initially focused on snapshot methods

Currently 19% of source code is hypothetically tested (most of them are default things that are automatically loaded).

9 Likes
#34

I’d also like to help with web UI refactor. From a brief glance it looks like there is a large job to decouple the page view from the server logic. By moving to a client/server architecture it would really open things up.

Would there be any interest for setting up some kind of community managed issue tracker or similar for organizing what needs doing and who might do it? It seems there are plenty of volunteers but managing people is a bottleneck, as is usual with these things.

6 Likes
#35

Hello, I’m also interested in doing work on the UI side.

For the life of me I cannot figure out how to start a new thread (topic?) in Developers, but if I could, I would.

As was previously suggested, a good start would be to document the APIs, such as the websocket connecting the mod-ui web client with its server side host.

So I tried some things…

The first thing: I know that with the physical MOD Dwarf connected, I can my browser at http:moddwarf.local and connect. Now instead, I downloaded the mod-ui from Github and used http-server (nodeJs) to run a local copy and tried to connect to the Dwarf, but of course it failed to connect the websocket because it is aiming at "ws://" + window.location.host + "/websocket". I manually changed my local host.js line 11 to force "ws://moddwarf.local/websocket": that made it to the Dwarf’s server, which then sadly rejected the connection. I am guessing that’s because the Origin of the Request Header in the websocket handshake is localhost and not moddwarf.local. That’s disappointing, and there’s no easy way to override Request Headers on the client side. It would be super nice if the physical Dwarf web server was willing to accept a websocket connection from anywhere - then you could write a whole new UI client and run from your desktop, so long as you used to proper protocol commands over the socket.

On to the second thing: I downloaded and installed the new Windows app. Firing that up, including the mod UI, I hit ctrl-shift-I and brought up the developer console in the app’s browser view. Hooray. You can make changes directly to c:\Program Files\MOD App\html, though you need to override some admin permissions to make working there less painful. I added a new console log output right before the websocket connection and saved. Right-click-refresh on the UI was not sufficient to bring in the new code (drat), but closing and re-opening the UI did it, I saw my new message on the console. That’s a valuable kind of progress - there’s a local html folder you can muck with and make new things happen on the actually app UI, and you can write to the console and see it.

The thing I have in mind with all this is to now shim a new ws middleware layer into the code and use it to console log out all the reads and writes on the websocket. Seeing it in action, plus inspecting the code, ought to be enough to properly document not just the format of the API but also its proper usage.

That’s not a small effort, but also not huge. With that in hand it ought to be possible to write a brand new client app. Or adapt the existing one as a starting point to something different, but a survey of the existing stuff, it looks like a lot to chew on with no code comments, etc. Maybe living with it for a bit will make it understandable.

TLDR - I’d create a new thread/topic dedicated to exploring and documenting the ui websocket protocol.

11 Likes
#36

Good ideas don’t always fit on a bumper sticker.

Keep posting!

1 Like
#37

I am not sure but I think that most part of websocket communication can seen here

1 Like
#38

OH NO! Code! And to think I sold my Wright/Stevens Addison-Wesley series years ago…

Double “OH NO”!! I just tried to create a github account and I already have one. It’s too early in the morning. I’m going back to bad and wait for the caffeine to kick in.

1 Like
#39

excellent, @Dave_Parker ! :wink:

#40

I wonder if ui and back-end dev could be parallelized in some way. As far as I understand, all our tweaks and amendments to any pedalboard - ultimately get distilled down to a new pedalboard.ttl file where all the fx, signal flows, midi assignments etc are ultimately stored.

Would it be possible alongside the architectural changes to separate ui and business layer, for people to work on some sort of ui app which works simply on the parsing and amending of pedalboard.ttl files. Of course this would mean that though you couldnt audition live changes (i.e change a value and hear the result) - it would allow for the creation of new pedalboards which could then be tweaked in audition.

This could be done by reading the pedalboard.ttl files directly from the device. But the question arises - what would be the characteristics of a new interface? I am thinking that the pedalboard is ultimately a graph of nodes (fx) and edges (cables). What would (for example) a mobile ui for something like that look like? A clickable uml diagram? A zoomable map something like a city with buildings and roads? Or some multiscreen flow diagram where you could swipe between different regions of the pedalboard?

Or would something adapted to ui devices like a playstation controller be more effective? I’e move joystick to the different fxs, select into an fx, and then move the joystick around the available controls (which would not be that much different to the existing mod ui).

I personally would be interested in collaborating on some kind of pedalboard.ttl parser if anyone else is

3 Likes