The purpose of this feature is to provide a complete layout of the target device to the end user and allow as much configuration of the device as possible. The idea is to provide information on, for example:

• The number of physical inputs and outputs to the device
• The number of physical cores on the device, how many audio tasks they support and information on their types and capabilities
• Routing restrictions between cores

And then allow the user to, among other things, dynamically (without re-compilation) change:

• The audio task signal flows
• Routing between those and the device IO

For more information on how to use this feature within GTT, please check Device Identification

Virtual Cores

Dynamically configure all audio tasks and routing between them

The user can now, without recompilation, change the signal flow within the audio tasks rather than just the instances themselves. For example, to connect an instance running at a sample rate of 6 kHz to one running at 48 kHz, the user had to change the platform code and introduce some sample rate conversion in between, and thus recompile the code. Now however, this can simply be done by adding the two instances into the newly introduced virtual core and add an SSRC in between.

Similarly, changing audio routing between physical cores and audio tasks previously required recompilation and  platform code changes – now that can be achieved dynamically as well.

Understand amplifier layout and physical restrictions

With the file describing the device layout, the user can now design within the hardware limitations that are drawn out in the GUI as opposed to having to have prior knowledge of how the amplifier looks like and what it can and cannot support. This also provided additional safety as the tool now prevents any restricted/unsupported actions.

Interchange entire signal flow between VST and hardware

A user can start simulating their amplifier on VST and then take those same exact files and flash them to the amplifier without any modifications. Similarly, these files can be read back from an amplifier and downloaded to VST in an instance.

Connect to an unknown amplifier

With this feature, a user can connect to an amplifier with unknown software (and even hardware details) and GTT can read back the layout and entire signal flow running on it. This can come in very handy when you have a a random amplifier sitting around and no idea what’s on it.

The workflow for using this feature starts with an offline process that involves providing the hard physical description of the amplifier, things like the physical cores on the amplifier and the amplifier input and output. This is described in more detail below and the output of this stage is a file called, “device.flash”. This file, generated by GTT, should then be compiled in with the amplifier code. This is a one time process. From then on, the user can connect to this amplifier and read-back the device layout from GTT; this process is described further below. Once a device is setup and established in GTT, the user can then, within the restrictions described in the device.flash file, draw the signal flow they desire with more granularity than before. This is further described here. 

In this stage, the user has to describe the physical restrictions and characteristics of the amplifier they are working with – this is information that cannot change without actually changing the hardware or re-compiling the code.

This data includes but is not limited to the following. The full specification is described in the xTP Specification document:

• Physical Cores:
  • Number of physical cores
  • Type, capacity and names of the physical cores
  • Number of Audio tasks running on each of the physical cores
• Virtual Cores – this describes the audio tasks
  • Task Priority
• Device Input chunks
  • User chosen name for a group of the inputs
  • Sample Rate the data is being sampled at
  • A mask that describes what these inputs are allowed to connect to, i.e. what virtual cores and device outputs these inputs can be routed to.
    • Note: this does NOT describe the actual routing, simply what is feasible.
• Device Output chunks
  • User chosen name for a group of the outputs (outputs that share name/sample rates are grouped together)
  • Sample Rate the data is being output at
• Virtual Core Input Groups
  • User chosen name for a group of the inputs 
  • Data format
• Virtual Core Output Group
  • User chosen name for a group of the outputs
  • Data format
  • A mask that describes what these outputs are allowed to connect to, i.e. what virtual cores and device outputs these virtual core outputs can be routed to.
    • Note: this does NOT describe the actual routing, simply what is feasible.

This data is provided as input to GTT in an offline process (no connection to the device). Once this input is provided, the tool will generate and export a file called “device.flash”. This file should then be compiled into the amplifier code and be made available for GTT to read it back and understand the limitations of the amplifier.

This process is a one time process and this file only needs to be modified if the hardware is modified or any of the items described above are changed and software has been re-compiled.

The first time an amplifier with a freshly downloaded device.flash file is connected to GTT, the user should “discover” the device from GTT (check GTT User Guide). This process basically creates a template of the device with the layout specified in the device.flash file. This template can then be dragged into and used as part of a project in GTT. Below is an example of what the result looks like.

Once a GTT project is available with a valid device configuration layout loaded, the user can create a signal flow from scratch or read back an existing signal flow from the amplifier if one exists.

To start creating the audio flow, the user can drag in the required core objects into the virtual cores. An example list of core objects:

Within a virtual core:

• Connections can be made only between core objects with matching block lengths AND sample rates. Buffer and Sample Rate Converter objects are available to provide conversion when needed.
• Virtual Core Inputs can have input buffers coming in at different sample rates and block lengths as long as the minimum increment of processing time is a divisor of all other processing times. Same applies to connections going to the core outputs. For example:
  • Input buffer 1 has block length 32 and sample rate 48k, and input buffer 2 has input block length 64 and sample rate 96k 
  • Input buffer 1 has block length 32 and sample rate 48k, and input buffer 2 has input block length 64 and sample rate 48k 
  • Input buffer 1 has block length 32 and sample rate 48k, and input buffer 2 has input block length 24 and sample rate 48k 
• To pass the input buffers directly to the output without any processing within the virtual core, use a Buffer object with equal input and output block length and sample rates.

Outside the Virtual Core:

• Connections can be made between cores and device IOs as long as they are allowed
  • Whether or not they are allowed is defined in the mask field mentioned in device.flash above
• Virtual Core Outputs can connect to other virtual core inputs even if the sample rate and block lengths do not match
  • Th expected sample rates and block lengths for each virtual core IO group is defined in the device.flash file as well.
  • There are no assumptions made on what the platform is doing between Virtual Cores. The platform can have SSRCs, buffers etc between virtual cores.

Once the design is complete, the user can download the signal flow to the amplifier. The downloaded files will include the following:

• One core file per virtual core in the signal flow. This file describes:
  • The core objects within the virtual core
  • The routing within those objects
  • The destination of the output pins of the virtual core
• One signal flow file per xAF instance
  • This is the same legacy file
• One input device routing file:
  • This basically describes how the device input buffers are connected to the virtual cores and/or the device outputs.