Request: OSC Feedback Support

jpooley-hearst commented 2 years ago

Would anyone be able to add OSC Feedback functionality in order to seamlessly integrate with QLC+, a lighting control software, and other systems which provide the feedback?

josephdadams commented 2 years ago

How would this be integrated given that every program that sends back OSC is going to send it back in a different format from every other program?

jpooley-hearst commented 2 years ago

I propose that the interface be similar to the "osc: Send x" interface currently implemented and allow the user to type in an OSC path and value that will trigger the feedback action, with the addition of simple logic (<, >, =) to parse whether the value is remarkable. I'm looking at the Hyperdeck module as inspiration

estilles commented 2 years ago

@jpooley-hearst While I have been tempted to propose some sort of generic feedback support, I also return to the conclusion it's probably best suited for a custom module. There already a request for a QLC+ module (bitfocus/companion-module-requests#612 ... I see you've already commented there).

jpooley-hearst commented 2 years ago

@estilles I would agree, but QLC+ doesn't provide a standardized OSC scheme to implement in a module. It tends to pass through the OSC commands from the controller as feedback. So a theoretical QLC+ module would need to implement an interface similar to the generic one I describe, and at that point we might as well open the module to all OSC products.

estilles commented 2 years ago

@estilles I would agree, but QLC+ doesn't provide a standardized OSC scheme to implement in a module. It tends to pass through the OSC commands from the controller as feedback. So a theoretical QLC+ module would need to implement an interface similar to the generic one I describe, and at that point we might as well open the module to all OSC products.

Implementing feedback in a module requires:

the module has some understanding the output it's receiving, so it can parse it
the module maintains an updated state (in some internal data structure) based on the output it receives

With this internal state, the module can then:

populate variables for user consumption
trigger feedback updates as described by the user

I'm not sure I follow what you mean by "QLC+ doesn't provide a standardized OSC scheme to implement in a module". The way I read the docs QLC+ always sends messages with addresses with the format /xxx/dmx/yyy, where xxx is the QLC+ universe number (minus 1) and yyy is the DMX channel number (minus 1 also), always with some float value as the payload. With this knowledge a QLC+ module could parse the address to obtain the universe/channel numbers, then store the received payload internally, where they can easily be retrieved using the universe/channel numbers. Additionally, QLC+ uses different port numbers per universe. A QLC+ module could, for example, allow the user the configure the universe(s) used, so the module would know on what ports it should be listening for output from QLC+. The module could then, theoretically send commands to and listen to output from multiple universes.

I think all of this makes QLC+ a good candidate for a custom module. The fact the payload sent by QLC++ isn't "standardized" on its own doesn't make a compelling case for adding feedback to the generic OSC module.

jpooley-hearst commented 2 years ago

@estilles not quite. It doesn't always use /xxx/dmx/yyy, if you bind a Virtual Console control to an OSC input string, it'll pass that input string as feedback.

estilles commented 2 years ago

Then the module should be flexible enough to be configured for the standard xxx/dmx/yyy addresses or the bound custom address. That is yet another reason to create a custom module.

jpooley-hearst commented 2 years ago

I would be greatly appreciative if either were implemented, but I once again will say that if we're going to make the QLC+ module that flexible, we might as well provide the OSC module the same flexibility. If that means copy-pasting code from the QLC+ module into the OSC module then sure

Julusian commented 2 years ago

Something similar is already supported in the generic-mqtt module, so it would be reasonable to do something for osc too.

I do find the way it creates variables to be very much a hack, but it works and is really useful..

elraval commented 1 year ago

+1 on feedback support on the Generic OSC module. I'm controlling MixBus/Ardour using the generic OSC module and I'm hacking custom OSC feedback from MixBus using the Reaper module "Change colors based on a custom OSC message". Something like this would be great so I would not have to use two instances to control/feedback from the same program. Also, features like value comparison would be great.