Associating Events/Tallys to Audio/Video Senders and Receivers

[jwpwh]

This is not an issue as much as a couple of questions about how to use the events and tallys described in IS-07. In particular, how to associate an event or tally with a specific Audio/Video sender and/or receiver. I am trying to figure out how to adapt IS-07 to an existing system. There are a couple of issues which I would like some input on.

In our existing system, we have what we call LIOs. They are just binary signals so they are not as rich as what is in IS-07. We have what are called Input LIOs which correspond to something like pushing a button. We also have Output LIOs which correspond to lighting a light or doing some other action. Each LIO has a direction (input or output) and a Function. (e.g. On Tally, Off Tally)

Each audio signal (senders and receivers) can have a number of associated LIOs which can be a mixture of Input and Output LIOs and various functions. When an audio sender and receiver are connected, then the LIOs on the two signals are matched so that an Input LIO with a specific function on one signal is matched to one or more Output LIOs of the same function on the other signal.

As an example, a receiver signal on an audio surface corresponding to a fader might have an Input LIO with a function of On Tally. The fader could be connected to a sender signal like a microphone with an Output LIO with the same function. When the On button on the fader is pressed, the Input LIO is set to On and causes an OnAir light associated with the Output LIO of the sender signal to be turned on. In the opposite direction, a Cough button associated with the microphone would be an Input LIO on the microphone signal and would be matched with an Output LIO on the fader signal and the associated fader would essentially mute the audio from the microphone while the cough button is pressed.

My first question is how to associate the events and tallys in IS-07 with specific Audio senders and receivers. This may not be intended to be covered in IS-07 and if this is the case, where is it covered? A facility could have several faders and several microphones and they would all have LIOs so the need to associate each of these LIOs with specific faders and microphones seems important.

My second question is how to determine who has "control" of an output LIO. In the example used above, the microphone signal sending the audio has an Output LIO for turning on an OnAir sign. If the microphone happens to be connected to several faders on different surfaces, the question becomes which of those surfaces controls the OnAir sign? We have taken the approach that the fader receiver on the surface can be "locked" or "unlocked" and only "locked" signals can have exclusive control of the output LIOs on the microphone. If there are more than one "locked" signals that the microphone is connected to, then the first connected "locked" signal has LIO control. A queue of locked receivers is kept so that as receivers become disconnected or unlocked, then the next receiver in the queue has LIO control. If all connected receivers are unlocked, then no receiver has exclusive LIO control and behavior may be hard to predict. So the question is whether there is any facility in IS-07 or elsewhere for arbitrating which event source an event receiver should listen to?

My apologies if these questions are not appropriate here.

Thanks.

[mjeras]

Hello,

Thank you for your detailed use case - if you are an AMWA member I would encourage you to take part in the IS-07 group as we need input on real-life implementations, especially at this stage of development of the specification. If you are not an AMWA member or just not in the IS-07 project and would like to become one, please let me know and I'll try to help...

As far as the associating IS-07 resources with RTP (audio , video, anc) streams, grouping should be used (BCP-002-01). The problem with this is that the grouping as it is is limited to natural groups within a device and I am not sure if that is or is not a problem fin your use case. For example, if you are talking about associating one boolean IS-07 input with an audio input on the same device so that the control system knows that they belong together, than it is a case for BCP-002-01. If you would like to associate them and they are not on the same device, then an extension of the BCP is needed (one was proposed but not accepted in the first version). The BCP-002-01 grouping would in that case not only indicate the two inputs go together, but also what is their role (For example, one role could be AudioIn001 and the other LioIn007). Those groupings are mainly meant to be static, but I think it should be possible to update the grouping tags in the registry and create different groups. Of course, the control system would have to handle what happens when an input/output moves from one group to the other. As a part of the current IS-07 work, we will try to standardize and publish some of the most common IS-07 roles as that is critical for future interoperability between devices.

Regarding the second question - an NMOS receiver (of any type, RTP or IS-07) can listen to only one source so if your device would like to connect to multiple sources it would have to create multiple receivers and manage the priorities internally and the behavior would be implementation specific. I think you would get to a solution what would be analogous to the current case you have described above.

I hope this answers at least some of your questions, I am happy to clarify more either here or on a call if required...

Best regards,
Miroslav

[jwpwh]

Miroslav, thank you for your prompt response. I am not sure about the AMWA membership but I will look into it.

I looked into the BCP-002-01 and I see what you mean about the limitation with the natural groups. Sometimes, our LIOs are on the same physical device as the associated audio signal, but in general, they do not have to be. So the limitation to natural groups would be a major impediment.

It also seems like there would need to be a way to identify what we call the LIO Functions. I assume this is referred to as Role in BCP-002-01. Our list of Functions has grown over time and just represents what we have needed for our audio signals. We also have a number of "User Defined 1", "User Defined 2", etc functions so that users don't have to be limited by what we have formalized.

Are there receivers for events and tallies? I know there are receivers in the sense of the communications mechanism like the web-sockets but I mean receivers in the sense of something that could be specified in a grouphint or in the NMOS registry? IS-07 identifies senders of events/tallies and this is easy to understand for something like the state of a button which we would call an Input LIO. For something like an OnAir light though, how is that represented in IS-07? We call it an Output LIO because it matches up to an Input LIO and when the button is essentially on, then the OnAir light goes on.

Any of our audio signals can have a mixture of Input and Output LIOs. In order to match up the LIOs in terms of directions and functions, "someone" needs to know all the details for both ends of the audio connection. In our case, the someone is essentially the "master" that I mentioned earlier. NMOS seems to provide the identity of the sender to the receiver but it seems like the sender does not easily know the identity of all of the receivers. I am not sure how the "matching" of the lios can happen when all of the information is not readily available. IS-07 seems to be focused on how to communicate the event information so I am assuming I am asking about something outside the intended scope of IS-07.

With regards to the second question. I did not mean to imply that there was one receiver with multiple senders. It was the other way around, there is one sender (like a microphone) and multiple receivers (like faders on surfaces). It is likely that only one surface is "active" at a time but the OnAir light is associated with the microphone and we need to determine which of the surfaces is currently in control of the OnAir light so that it is lit at the proper times. We also provide feedback to the surface so it knows whether it is in control or not.

Thanks.

[garethsb]

Yes, there are NMOS IS-04/-05 Receivers as well as Sources/Flows/Senders of IS-07 Event & Tally. They'd correspond to your Output LIOs, I think.

It is intended that in IS-04 v1.3, Sources will indicate the event_type that they emit and that Receivers will be able to indicate the range of event_types they are capable of accepting.

[garethsb]

While BCP-002-01 covers only grouping within an NMOS Device or Node scope so far, there's nothing to prevent a control system using these or similar tags to do higher level associations (automatically or with user assistance) between Senders and Receivers that are not part of the same Node.

[jwpwh]

I would like to continue this discussion but sort of start over. As before, I recognize that this might not be the best place for some of this discussion but maybe it is a place to start.

In an existing system, we have an object called a Signal which contains an Audio Sender or Receiver and some number of Logic Senders and Logic Receivers. If the Signal contains an Audio Sender, then the Signal is a Source Signal. If the Signal contains an Audio Receiver, then the Signal is a Destination Signal. In either type of Signal, the directions of the Logic elements can be mixed with respect to senders and receivers. A Signal could contain just Logic elements. In this case, the signal is LIO-only and it can be either a Source Signal or a Destination Signal.

Each Logic element within a Signal has a direction with senders being called Inputs and receivers being called Outputs. In addition, each Logic element has a Function like On Tally, Off Tally, Cough, etc. Each Input Logic element must have a unique Function within a Signal. The Output Logic elements do not have to have unique Functions. There could be multiple Output Logic elements (receivers) with the same Function. (e.g. multiple On-Air lights)

Each Logic element is associated with a physical object like a wire of some kind and can be configured to be in at most one Signal.

The Connection Administrator within our system works at the level of the Signal with a Destination Signal being connected to a single Source Signal. A Source Signal could be connected to many Destination signals. When a connection is made, the audio elements (if present) are checked for compatibility and connected if compatible.

Then, the Input Logic elements of the Source Signal are matched to the Output Logic elements of the Destination Signal based on the assigned Functions. A single Input Logic element could be connected to multiple Output Logic elements if multiple output items have the same Function.

Similarly, the Input Logic elements of the Destination Signal are matched to the Output Logic elements of the Source Signal based on the assigned Functions. This last step is slightly conditional if the Source Signal is connected to multiple Destination Signals. In this case, each of the Destination Signals could have Input Logic elements which want to connect to the Output Logic elements of the Source Signal. The Connection Administrator has to decide who wins in these cases.

My concern is how does this map to NMOS? Here is the current thinking.

• As a Logical entity, an NMOS Device can be used to represent a Signal.
  • The Senders and Receivers of this device will correspond to the Audio sender/receiver and the Logic senders and receivers.
  • The Audio and the Logic elements could be on different physical devices (i.e. their IP addresses might be different) but are all associated with the same logical Signal.
• The Connection Administrator would need all the Device information of both Signals in order to completely connect all the different elements of the Signals.
  • Since the NMOS Senders and Receivers identify the NMOS Device, this seems somewhat straight-forward. Not necessarily easy, but straight-forward.

Some questions:

• How should the Functions be represented?
  • The grouphint tag seems like one possibility with the Role being the function except the Role is supposed to be unique within the same group. The immutability might also be an issue. Signals are generally defined during an installation but they could be changed later (assuming they are not actively connected.)
  • A better possibility might be to use the "measurement" on the event_type field.

One of the main reasons to do this work is to allow our objects to be used by other vendors and for us to be able to use objects from other vendors. While the standards are dealing with low-level details about the mechanics of describing and making connections, it seems like additional information is needed in order for a Connection Administrator to make decisions.

• We use the notion of the Logic Functions in order to know how to connect the different Logic Elements. Is there any sort of standardization in this area? We can use our existing functions but will anyone else know what they mean?
• We use the concept of the Signal as a bundle of audio and logic in order to create a usable shorthand for making useful connections. Is the NMOS Device a reasonable approach for this?
  • How are others dealing with this?
  • Is there any notion of making connections of Devices in addition to connecting the individual components?