Metering on DCA faders

[Raunoa]

dLive feature releases seems to fall into a 3 year timeframe currently.

I attended the AES Show 2023 last year, where I heard that Avantis has required a significant amount of development effort, which has led to a slight postponement of dLive updates. Perhaps someone from A&H can provide more details, but it seems they are currently focusing on the new release.

By asking them to change this, you are asking them to fundamentally change how they think about audio and design their systems.

Sorry to mention this again, but this is not about fundamentally change. It is about presenting information and making things more intuitive. In this case, they do not need to change the fundamentals, for example start direct audio under DCA or do something fundamentally different; it is just metadata that is easy to read. As a developer, I know that if they have connections with DCA, they have all the other information that is easy to request from channels. I appreciate how this topic has engaged many people here! 😀

[SteffenR]

What do you think is metadata in a live audio environment?
Metering? Really not. That is real time information as a stream.

Remember the iLive, where the metering information distributed to the instances of up to 10 editor versions have eaten up the network bandwidth very quickly.

As Brian said, your initial request is a fundamental change to the architecture, worth exactly nothing.
Just to show wrong metering data?

24 DCA need 24 listeners to the metering in every possible scenario, and the information needs to get sent out to all GigaACE devices and Directors present in the network.
Don’t forget the controllers attached to the network.
So I believe they (the developers) think very carefully about this problem.

[Raunoa]

I need to note that I’m not talking specifically about the forum subject. I’m referring to the ability to show a signal if a channel has a signal under DCA. I understand the metering point and the reason for not showing that.

What do you think is metadata in a live audio environment?

Ok, it seems I need to start explaining a bit how this can be done. Being in an audio environment doesn’t mean that everything is only about audio; there’s a lot more involved. Of course, I’m not a dLive developer, but I can assume some basic logic on how to make it work.

To determine if a DCA has a signal or not, you only need a 1-bit data flow for that information. With 24 DCA channels, it means you need to transmit only 24/8 = 3 bytes of data. This is nothing.

I assume dLive uses C/C++ for developing their mixing desk software, where audio data is managed using std::vector variables. However, additional information is not sent through this vector. Instead, each channel has a Config struct variable that includes metadata such as name, mute flag, color, etc. For various reasons, I believe they also have a flag like “isSignal” to indicate whether a channel has a signal, which is used by the controllers.

To determine if a DCA has a signal or not, we need to look at the channels under the DCA. With the Config struct information, we can check the “isSignal” flag. Using basic arithmetic, if at least one channel has a signal, is not muted, and its fader is not at -infinity, then the DCA’s config struct “isSignal” is set to 1; otherwise, it is set to 0.

In summary, we are talking about only 3 bytes of data flow, and that is super small data. 🙂

[Brian]

Raunoa – again, you are focusing on the technical aspects of your request. No one is saying it can’t be done. It certainly can be done. However there are very valid reasons why A&H may decide to continue with there method of handling DCAs and never implement this request. If this is the case and they don’t implement it, it’s clearly not due to a lack of technical knowledge. Obviously everyone is welcome to share their opinions and I’m not trying to squash yours, but as my last post tried to explain there are a lot more reasons why A&H may decide not to implement this that go way past the technical capabilities.

The greatest chance to see this implemented is in the DLive 2.0 firmware update. If it is not included in that update, then I think it is safe to say that A&H will never implement this request.

[Author]

Posts