Hey there lads and lasses ![]()
I’m building a new dLive Companion module because the existing one is unmaintained and reads nothing back from the console.
Feedback/get routines are key to making the integration of dLive in companion meaningful.
without get/feedback, every controller is guessing at the desk’s state, button states drift, and you can’t do toggles.
As an example here is my current main use case:
I mainly use it for Talkback/Intercom purposes.
(because managing comms as a monitor engineer got on my nerves)
Everyone in the Crew who has a talkback mic is equipped with either a stream deck (via Raspberry Pi running satellite (PoE powered)) / or any device running Companion Web-View.
Thereby it is possible for every one to choose who he/she is speaking to, change level of everyone else in his personal talkback bus and also be able to see who has currently selected their talk2me bus.
This is just one quite basic example use case of how the current TCP/MIDI Protocol could be used to make dLive a more capable and versatile system.
From my point of view the current MIDI API is quite limited.
Many features / functions of the console are not yet implemented in the API / MIDI inteface.
Thereby I strongly want to suggest expanding the current MIDI over TCP protocol.
I think these additions would be in the low effort category but could yield great value for us users and fans of the dLive ecosystem. (also OSC support would be a great addition - but this may be a whole other argument)
here is a wishlist for protocol additions (with set and get to make them useful)
each and everyone of them would be a gain for us as users:
- select channel (and get currently selected channel)
- LPF integration (like current HPF integration )
- compressor integration (all models, all parameters)
- gate (all models, all parameters)
- preamp emulation settings
- fx modules
- ufx modules
- dyn8
- … - I guess everything that can be integrated is a great addition
This would not only make a possible companion integration stronger but could also yield great haptic control over dLive system (I guess above all for people doing fly shows with compact dLive director setups ? )
This may also be one of the biggest arguments for A&H not to make such API available (sales numbers / importance of surfaces ?)
But I would argue: Making dLive more capable and versatile system will always be a net gain for allen & heath.
What do you think ?
I kindly invite you to discuss the topic / possible gains and use cases of such implementation.
Kind regards
Krohmi