Feature Request: Fader Levels for sends to Bus 1-12
christianliferantoul opened this issue · 4 comments
Hi there!
Our Online Livestream is run via Stream Deck.
We would love to see the Channel Fader Level that is being sent to a Bus.
Is it possible that we could get a new set of variables?
I'm going to need to look into this but I don't think this comes back with the standard state update, and this would be A LOT of calls to get this right. I think its 48 channels that can be sent to the 16 buses so that's 768 calls that would need to be done every however often which will make Companion very slow and possibly even cause chaos with X32 especially with things like fading
MIGHT be able to do it with... I think It was \batchsubscribe or something like that but as far as I recall I wasnt able to get that to work as expected without causing lag when I tried last time
It should only need to request all the values when connecting to the x32, after that any updates will be pushed to us because we subscribe to state changes with /xremote.
But yeah, making 768 more requests for data is not going to be great for performance when we do connect.
Reading those unofficial OSC docs, I don't think /batchsubscribe is what we need, but perhaps /node is what we need to be able to bulk load data? of course that does require more effort in loading the data and might result in a want to rethink how the known state is stored internally
@Julusian, will /xremote keep those new values up to date? I stand corrected but doesnt /xremote only bring certain fields data values back?
It might be /node that I'm thinking of (apologies it has been a while was quite fun trying to remember how to get my dev environment up and running earlier 😂 next lets see if I remember how to speak TypeScript and how often I use the wrong language) at this point I cannot even remember where we would need to add the /node for initial values. Its going to be an interesting weekend of rediscovery
yeah Im pretty sure that /xremote tells us of all changes made on the x32 other than metering.
So using /node to do the initial load, then leaving the rest to /xremote I think will work.
It has been far too long since I've done anything to this module, so I too have no idea of how it works :)