Provide a UNIX domain control socket

[blufor]

...to control the application by other means (ie. StreamDecks and such). This integrates creating AF_UNIX/SOCK_STREAM listen socket with a very simple JSON API (using Poco/JSON) that allows one to do thing such as:

• switch presets
• toggle lock and shuffle
• get status

from outside of the application.

Wayland by design doesn't allow one to send keystrokes to non-active
windows. It's actually against the design.

Every API response reports on the status as well. The simplicity allows one to integrate practically anything with just bash, socat and jq.

In the examples/vj-control, one can find a tool that parses the output into stylish format that can be used on StreamDecks.

One thing I'm not very sure about is how it's hooked into the RenderLoop, however it seems to me there's no other (simple) way around it to properly report back with the status. It is definitely a compromise.

NOTE: I'm a senior devops engineer, however C++ is not one of the languages
I'm friends with (on the contrary actually), so - guilty as charged - I've used Claude Code to help me implement it. The feature is guarded behind -DENABLE_CONTROL_SOCKET=ON

[blufor]

example usage

[revmischa]

maybe something like https://en.wikipedia.org/wiki/Open_Sound_Control would be more flexible/standard?

[blufor]

@revmischa Using standard protocols is definitely a better approach and I'm all for that. However (not knowing the details of OSC) - doesn't this present a completely different communication model? Basically you get notified about changes (events) that happen on the other side, no? The implemented model in this PR is purely req->resp.

[kblaschke]

There's already an issue/discussion on that topic here: #74

IMO, the implementation should not be UNIX-specific, as the application is also available for Windows. It wouldn't be a good thing to implement two solutions for the same feature.

That said, using Poco::Net::ServerSocket instead of a raw file handle would do the trick, as this socket can work with IPv4/IPv6 and also UNIX sockets on platforms supporting it.

Given the nature of network services, care must be taken to not accidentally expose ports on a user's machine without explicit configuration.

Ideally, authentication and SSL/TLS support should be included as well, but given projectM will mostly run in controlled/closed networks and on home PCs, this can be added at a later point.

The JSON API should be documented and tested with an OpenAPI spec file, which will make it easy for other devs to write clients and also ensure proper API documentation and stability. Nothing is more frustrating for app devs than using an API which occasionally has breaking changes and has to be reverse-engineered from the source code.