[feature] Add OSC Support

[Miniontoby]

Is your feature request related to a problem? Please describe.
I would like to be able to use LedFx with my OSC Server which I also use for QLC+

Describe the solution you'd like
I would like that an OSC package like python-osc will be added into LedFx and a way to add an OSC Server as 'device'

Feature Progress
P.s. all the things that are checked off here are located at my fork

• Add option to add an OSC Server as a device
• Add OSC Server integration/api. This way people will be able to control LedFx using a simple OSC client.

Discord thread

[sideeffectdk]

Yes, so much yes!
OSC support is such an underrated and often overlooked feature is programs such as these.
I've been advocating starting OSC development for a long while now, and I might just take the first steps myself.
But why stop with just adding OSC as a device?
There's unlimited possibilities to control LedFx from other OSC capable softwares if OSC was implemented both ways.
If you're interested in helping with the creation of this feature, come join our Discord and chat with me there:
https://discord.gg/PnPF4H9zC7

[shauneccles]

We'd love a PR for OSC support :)

[Miniontoby]

We'd love a PR for OSC support :)

A PR will come once all the tasks are completed OR we would move the second task into a different issue and I will make a PR and we will do the other task in a later PR

[Miniontoby]

Point 1 of 2 is now done!

For point 2, idk who to do it... so I hope someone else could help me out

[Miniontoby]

I updated the OSC Device in #464

Added a way to use custom path, added All_To_One send type (sends one big array with all the RGB data to the path)
And I updated the docs with the modifications I made

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

[bobh66]

I'm interested in sending OSC messages to LEDfx to control it from a lighting desk or QLab. Maybe mapping incoming OSC messages to the existing REST API calls makes sense? I can take a shot at a PR if that approach is reasonable.

[bobh66]

This is a generic OSC->REST implementation: https://github.com/ohglobal/OSC-REST as a rough example - I think a more application-specific OSC vocabulary is probably more desirable.

[bobh66]

The OSC to REST mapping seems to be pretty simple - any OSC path without an argument is equivalent to a GET on that path, a path with an argument is a PUT/POST on that path. The only odd case is delete, but that could be handled with /path//delete. I'll put together a PR and push it for review.

[bigredfrog]

We welcome any contribution, sure we can work our way to good for everyone!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

[bobh66]

/fresh

[bobh66]

I have a rough implementation of OSC server-side support using TCP and SLIP. It also could use UDP but I need TCP for my application so I can guarantee the commands are received by the server. If both are desirable we could listen on one port for UDP and another port for TCP.

I overlaid the OSC vocabulary on top of the REST API schema and translate all incoming OSC messages into the corresponding REST API call, and return the result of the REST API call back to the OSC client. That allows OSC REST GET messages like "/api/info", "/api/config", etc to reply back to the OSC client process.

I have also verified that PUT actions work, for example

/api/scenes '{"action": "activate", "id": "test"}'

will activate a scene called test.

I think it would be better to extend the vocabulary to look something like:

/api/scenes/test/activate

or

/api/scenes activate test

but my current goal was to reuse as much code as possible to get something working and tested.

The TCP server implementation is based on some work that has not been merged into python-osc yet, so I'm going to see if my OSC-specific changes can get merged there first, and then I'll look at pushing the LedFx-specific changes here.