openAV-Luppp
openAV-Luppp copied to clipboard
openAVproductions
Controller Scripting
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:
- Easily support USB HID and MIDI devices
- Enable advanced controller support
- Shift buttons to remap certain controls
- Allow one hw control to change a range of parameters (support many:1 mapping from hw -> sw)
- Enable a good workflow for "scripting" controllers
- fast prototype-like workflow
- simple APIs to ease barrier of entry
- Minimize work needed for adding a controller script
- Ensure solution can be highly performant in the long-term
- Controllers continue to become more capable and have more features
- Screens and high-resolution touch-strips / sensors should be dealt with easily by Luppp
- The controller scripting language should integrate with Luppp easily
- to allow fast development and addition of Luppp features to the controller API
- Low effort in maintenance of controller support infrastructure
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.
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
Yes - a good tutorial video, along with demo template for easy "adoption" for new controllers is a good idea, thanks for the input!
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.
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.
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
Will test when i am back from holidays and have some controllers for playing around. Is there any documentation how to use it yet?