Wow, cool stuff.
I don’t know how many have such a controller, personally I’m only aware of Satobox’ work on the (less involved) Mackie Control template.
i finally succeeded sending sysex messages to the Main LCD display.
Great!! I’m curious to see the implementation, as I’ve only got software based (tablet) controllers that could display text.
Ideally (for Duplex anyway) the implementation details could reside in the MCUPro “driver” class. But this is of course something that would require a generalized way to send text, including how to specify special characters, linebreaks etc. In the longer term…
I’m thinking of making a good suite for MCUPro with Duplex, with certainly its own ‘Duplex Application File’ so i’ll not have to modify the core files at everyupdate! I want to modify the Effect App to control the Instrument FX devices, as it works only for Track Devices for now. I will probably use the NOW application as the MCUPro have many buttons that should be used. Some controls (buttons) will be duplicated in the diffferent config files like the transport ones.
Applications are full featured lua files, having just an entry point (__init) and a few required methods. So yeah, it’s certainly possible to sidestep the Duplex internals and communicate directly with the hardware (if this is what you intend).
However, you will miss out on various I/O optimizations - side effect being, that the Duplex core code can be quite hard to decipher…
I also have some other ideas with the display, but i’m afraid the latency it generate will not allow much traffic!
I would probably create a queue system, in which messages are scheduled for transmission and transmitted with regular intervals (lua has approx. 10 updates per second). This way, you’ll avoid choking the bandwidth but of course, add a little bit of latency. Not that it should matter much when we’re just talking about display updates?
Their feedback’s CC indexes are offseted by 32so that’s the only reason i changed ‘MidiDevice.lua’
Incoming and outgoing CCs are not the same on the MCU? A more clean approach would probably be to overriding that particular MidiDevice method in a dedicated MCU class.
Device classes are located in the root of each controller folder, e.g. the Launchpad has a little extra code to handle color LEDs
I use the actual duplex version ( not the beta),
You are aware that the most recent beta has support for 14-bit CCs and NRPNs? Not sure if this applies to the MCU though, or if it’s using pitchbend for those high-res sliders. Anyway, I’ll give it a spin with the latest version too (0.9.5)