Using the RPL Attributes Diagnostic page

Scope

This document explains the basics of the RPL Attributes page found in the Engine of Element, Fusion, and Quasar console engines.

In Quasar Engine, the RPL Attributes page is renamed to DSP Parameters, as shown here.

The information displayed on the resulting page is the same for all.

Description

In Element, Fusion, and Quasar, the console software communicates all its parameters to the Engine software. For example, when you press the Program 1 button on a console fader, the console instructs the engine to mix that fader's source with the final Program 1 output according to all the other fader parameters.

Sometimes, viewing these engine settings is helpful instead of relying on what you observe (or someone else observes) on the physical console.

An example of this might be the fader position. Faders can be moved "virtually" by many of methods. If a fader is moved virtually (without the user moving the physical fader), then the position of the physical fader will differ from where the engine thinks the fader is. This can create confusion for the user.

The problem used for this example

The user says the fader is ON and UP, but no audio is coming out for that source. To verify this, we need to see what the ENGINE thinks the state of that fader is.

As noted in the Scope, Quasar is slightly different; however, the information is the same

  1. Log in to the main web page of your console.

  2. Click on Diagnostics under the Mix Engine heading.

  3. Click on the RPL attributes button.

The displayed page has LOTS of information; however, we're going to focus on just a few settings. The most important information is near the TOP.

First, for our example, the source is on Fader #8 (Or Chan 8:) on this page.

The attributes that are important here are;

  • SRCT - The Source type loaded to a fader.

    • 0 is no source

    • 4 is a Line source type

  • FAxx - Fader position according to the ENGINE. (-32768 is -inf or down, otherwise in the format XX.X, where -58 would equal -5.8db)

  • ONSW - State of the ON switch (1 is ON, 0 is OFF)

  • PGM1 - Is the fader assigned to PGM 1 (1 is ON, 0 is OFF)

What does our fader say?

Recall that the user says the fader is UP and ON. That is inconsistent with what we see here.

We can see that the fader has a Line Source assigned (SRCT = 4), that it is ON (ONSW =1), and assigned to PGM 1 (PGM1-1). However, the fader is at -32768 (FAxx) which is fully down.

This explains why there is no audio coming from that fader.

How does it get this way?

There are many ways a fader could get moved. Possibilities are;

  • SoftSurface remote control software is being used.

  • An HTML panel from Pathfinder is being used to control faders.

  • There is some other logic in Pathfinder that manually sets a fader position.

  • An automation system has control of the fader position.

  • Someone has manually typed at Livewire Control Protocol command to set the fader position.

All of these assume that you do not have motorized faders in your console

How do I fix it?

In our example, the engine thinks this fader is down. To regain control, the user must move the physical fader to that position. Just moving the fader partially up or down does not re-establish control. The fader must move and "hook" the virtual position to regain any control.

Is there a way to prevent this?

No, not really. It's all used as designed. The only consideration would be moving to motorized faders, where the physical fader would move whenever something controlled it virtually.

Let us know how we can help

If you have further questions on this topic or have ideas about improving this document please contact us.