Web interface

[mdwn]

A web interface should be introduced so that mtrack can be monitored and controlled over a network connection.

[mdwn]

I'd actually mark this as the next most important thing. In the case of on stage disaster, i.e. MIDI controller fails, the current way of triggering otherwise is the command line.

This is a terrible user experience, so adding in a web server is critical.

[gulbrand]

I'd be interested in helping with this.

I could probably put together an Axum-based http server using htmx that has the buttons to control various events. That seems like a good enough incremental start, but I wanted to also get a sense for direction you had in mind. Could go with Leptos for a more flexible evolution. Htmx can go a long ways, but depending on complexity of features and real-timeliness in the browser side, something with closer integration with wasm in the browser might be more appropriate. Do you have a preference?

I can do either.

Also, a bit about me:

For live performance, I currently use Reaper on a Raspberry Pi, a MIDI Captain Foot Controller, an X32 Rack, a Scarlett 18i20 from the pi to the X32. I have a Dante card in the X32, but I don't use Dante live....yet. This works well, but I want a simpler setup and one that is more flexible. Google search led me here. I have a few other interfaces as well and can also help test those out separately from this issue.

It seems like maybe my goals align with the goals of this project? Would love to chat more on discord if you're open to live discussion.

And one caveat:

I need to check with my employer to get approval to contribute to open source (mostly to get a conflict of interest review), I don't see any issues surfacing there. In the meantime, here are a few thoughts:

Regards,

Mark

[mdwn]

@gulbrand That would be amazing! I don't have strong opinions on this -- full disclosure, I'm neither well versed in front end stuff nor all that much in Rust. :-D So I'll defer to you here if you'd like to add it.

It does indeed sound like your goals align with this! FWIW, I've more recently tested this with an X32 Rack and the player works well with it.

Not a problem on the employer review.

[gulbrand]

I just got the approval to contribute.

Quick question, what do you think about me adding an OSC compatible network server? Then, a separate UI that uses the OSC interface?

[mdwn]

Sounds brilliant to me!

[tobiaslabu]

I have been experimenting with an OSC integration for mtrack. I need to do some cleanup, but could provide some working code.

Edit: I've uploaded my take at implementing OSC in mtrack here: https://github.com/tobiaslabu/mtrack/tree/addOscSupport
It still needs some tests.
I can relate to the general disclaimer in the README of this project as I am also not very experienced using Rust. I still hope my efforts can help the project.

[gulbrand]

@tobiaslabu I took a quick scan and this looks pretty close to what I had in mind. I think we're on the same page generally.

I'm happy to do a deeper review but it looks good to me high level and it might be a week or so before I can circle back to this.

One thing I noticed, though I'm not sure yet if this might be an issue here. Using std::sync::Mutex in the same context as tokio can cause a deadlock because std::sync::Mutex::lock() blocks. If the mutex is used in any async code, trying to lock it will block the runtime and could cause a deadlock. The solution in some cases is to use tokio::sync::Mutex, which doesn't block, but has to be used from an async environment. This is tricky.

I didn't look closely enough at this. Thought I'd point it out just in case.

[tobiaslabu]

@gulbrand Thanks for the feedback! The std::sync::Mutex does not seem to pose an issue as of now, but I'll keep it in mind and have a look if replacing it with a Mutex from tokio works in this case.

I just committed some changes that include tests similar to the MIDI controller test and the functionality seems to work fine so far. I think that a lot can be done in a cleaner way, however, I am not sure if I will get a lot done before January.