Device View

Master Control


The Master Control interface is not an audio object, but an entity in the xAF framework which enables the user to define control inputs to the device.

The defined control pin(s) can be routed to one or many virtual cores, as shown below. A direct connection to a Core Object is not allowed, because the received control messages are queued and processed by the AudioCore class. The dequeue process will take care of calling the correct core object(s) and broadcasting (if multiple connections are used for a pin).

For the ControlIn audio object, the Control IDs can be selected from the available list as before or added from the new custom Control IDs list.
For more details on adding and editing control IDs, refer to the section on Control IDs and the process of assigning them to control pins.

Sorting Master Control Pin Data

You can click on any of the column headings to sort the data. Clicking alternately will change the sorting direction from ascending to descending or vice-versa.
The ascending order of the Pin column is the default sort order for the Master Control.

The following features are not supported in the current release for the Master Control.
– Undo – Redo operations are not supported for master control actions.
– Load Device Config will not read control connections and master control related data like Queue size, Queue Data size, Streaming buffer size.
– Moving of pins up and down is not supported.
– Pin labels cannot be edited for master control.

 

Device Object Properties


A device is a combination of four layers: Device Layer, Physical Layer, Virtual Core Layer, and Core Object Layer. When you select any of the layers, you will see the properties of the selected layer on the right side.

Device Layer

Device layer properties include Device Name, Hardware, and Software version.

Device layer properties are not editable.

Physical Core Layer

Physical Core layer properties include Physical Core Name, Physical Core Type, and MIPS.

The “Physical Core Name” property in the Physical Core layer properties can be changed, but the “Physical Core Type” and “MIPS” properties are non-editable.

By default, the “Physical Core Name” property value is the same as the “Physical Core Type”. If you want to change the physical core name, enter the value for “Physical Core Name”, the updated Physical Core layer value will be reflected in the device view, then click on the save button to save the changes.

Only from the Device File editor window, you can update the Physical Core Type.

Virtual Core Layer

The Virtual Core layer includes the following properties:

  • Core ID: Display the core ID.
  • Core Name: Display the core name.
  • Data Format: Display the date format type.
  • Task Priority: Display the date priority value.
  • Queue Size: Number of messages in the queue. This value defines how many tuning and control messages can be stored simultaneously. This value should be a power of 2 and bigger than the number of control inputs of this virtual core.
  • Queue Data Size:  Total size of all messages in the queue. This value should be set to a power of 2. The size of this value is driven by the following points: sum of block controls, size of tuning data.

    Example: 2 controls, with each using a group size of 256 values. Queue data size >=  2 * 256 * 4 (sizeof float) + head room for xtp  cmd header & tuning messages -> 4096 bytes

  • Guard Time: Time to avoid message processing as a percentage of interrupt time.
  • Ramp Time (ms): Duration between two processing states (in ms), when the Core Object processing state is enabled.
  • Core Object Processing State: Enable or disable the processing state for Core objects in the core.
  • Streaming: Enable or disable streaming. Enabling the streaming option allows you to set “State Variables”, “Probe Points “, and “Level Meters”.
  • Streaming Queue Size: Number of streaming messages to be stored within one calc period.
  • Streaming Buffer Size: This size is defined by multiple factors and has to be built as a sum of and power of 2:
    • Probe Points are used: Number of enabled PP * the biggest block length used in all xAF instances of this core * 4 (size of float) bytes
    • SFD meters used: Number of used sfd meters * 4
    • State variables streamed: Sum of used variable sizes * 4

Queue Size and Guard Time will be supported only for Devices with audio library version “O” release and above or “M+2” release and above.

Enable Core Object Processing State and Ramp Time will be supported only for Devices with audio library version “O” release and above.

Processing state for Core objects will be applied only if Enable Core Object Processing State was enabled before Send Device Configuration.

Enable Probe Points and the Number of Probe Points will be supported only for Devices with audio library version S release and above.

Core Object Layer

Each core object has different properties. For more details refer to the ToolBox.

Magnifier Options


  1. Fit to Window: Click on this button will change the current view to the size of your device view window.
  2. Zoom to 100%: Click on this button will return the view to 100% zoom.
  3. Zoom In: Click on this button (+) to zoom in for gradual increments.
  4. Zoom Slider: Slide to the desired percentage zoom setting.
  5. Zoom Out: Click on this button (-) to zoom out for gradual decrement.

Undo and Redo Operation


The undo and redo feature allows you to reverse or redo previous actions.

  • Undo: The undo feature allows you to reverse the previous action by restoring the design state to a previous design state.
  • Redo: The redo feature allows you to perform the action that is undone.

Undo/Redo operation is supported for the following actions:

  • Adding/ Removing core objects.
  • Adding, removing, and changing connections.
  • Changing core and core object position.
  • Changing core and core object properties.

The scope of undo/redo is within the selected device.

Undo/redo action will not restore the tuning data state.

This feature is limited to 1000 actions.

When a new manual action (dragging new object, changing connection or position etc) is performed, all existing redo records will be cleared. As a result, it will not be possible to redo any previous actions.