openAVproductions / openAV-Luppp

Luppp is a live performance tool, created by OpenAV productions.
http://openavproductions.com/luppp
GNU General Public License v3.0
259 stars 45 forks source link

Controller Scripting #146

Open harryhaaren opened 7 years ago

harryhaaren commented 7 years ago

To properly support USB HID and MIDI devices, and provide tight integration with software, Luppps controller handling mechanism must be refactored and become more flexible. These are the key goals of this refactor:

In order to enable the above features, a specific design using Events is used to ensure that there is little overhead in adding new features to the controller scriptability. I'll push a branch in the coming week/weeks (time permitting) with a prototype implementation for adding basic controller support.

geraldmwangi commented 7 years ago

Maybe It would be good to have luppp write a template *.c file, with the most important functions to be implemented and where things like controller name, author ... are already entered at the relevant place. should be easy to implement

harryhaaren commented 7 years ago

Yes - a good tutorial video, along with demo template for easy "adoption" for new controllers is a good idea, thanks for the input!

georgkrause commented 7 years ago

i thought about this one and i think it would be much better to implement an osc interface. this way anyone can write script against this in a language he or she want.

harryhaaren commented 7 years ago

I don't object to an OSC interface to Luppp: but using OSC as a messaging protocol between MIDI controllers and the RT audio thread makes no sense because the MIDI in/out is done by the RT thread.

Externalizing all comms to OSC is not a good idea from a threading POV, since the messages cannot be sent from the RT thread. To solve this, buffering would allow moving the OSC message to an offline thread, and sending it over the network from there. Beaware this causes an extra hop between threads to send, and another to recieve a reply. Given a controller will need to do lookups of the "state" (eg: Track Send Active) to show it on the controller, this requires a lot of ping-pong messages; and vastly complicates things like simply looking up a value that would otherwise be available (eg a function call to getTrackSendActive()) from the same thread.

I understand that an OSC interface seems useful - and it enables more I/O control flexibilty for Luppp which would be a good thing. Also OSC is terrible for long-term API stability (C API/ABI is generally much better - at least you get compile errors when it breaks :)

Again - I'm not against adding an OSC interface to Luppp, but it doesn't belong in the core messaging between RT and controllers, it belongs in a controller interface - which binds itself to a specific (user-configurable) port - to allow multiple of these OSC controllers interact with core Luppp.

harryhaaren commented 6 years ago

For clarity, the solution to this issue is ctlra support.

coderkun commented 6 years ago

@harryhaaren, should this issue then be used for Ctlra instead of #194?

harryhaaren commented 6 years ago

Hey All,

I've just pushed a new branch ctlra_v1 to Github, which implements a hacky version of Ctlra support for Luppp: https://github.com/openAVproductions/openAV-Luppp/pull/203

Please beaware that this is NOT production grade, and only of interest for developers or alpha testers for now. There are lots of features missing, but it shows some good progress, and allows others to get some insight and input if they so wish :)

Cheers, -Harry

georgkrause commented 6 years ago

Will test when i am back from holidays and have some controllers for playing around. Is there any documentation how to use it yet?