par·ti·tion [pahr-tish-uhn]

  • The act or process of dividing something into parts.
  • The state of being so divided.

The above definitions can be found in any online or hard copy dictionary. Partitioning is a concept that all software engineers are very familiar with. In fact software engineers love to partition things. There is a common phrase used in software engineering “Divide and Conquer”. Software engineers know all too well that breaking up a large problem into many smaller problems makes it simpler to solve. It also provides flexibility in managing that large problem over time. It was this thought process that led to the concept of partitions in Tesira.

Many of us may live to one day tell our kids of a world before partitions. A dark age of system design where integrators had the unenviable task of informing a client they were shutting down their system to run a reconfiguration. Or hours – years even – of their life spent scrolling through a drawing area to find a single input level. Perish the thought!

Okay, maybe that was a bit overly dramatic, but if you are a system designer, you see my point. Many of us have run up against the limitations of a system viewed as a single configuration, regardless of size or the number of devices it contained. If a system change is required anywhere in the system, and regardless of how small the configuration change, the entire system must be taken off-line so that all devices in the system can be reconfigured. Many installations can’t be taken offline for reconfiguration even briefly.

Most systems are limited to one drawing area to place all system components, including inputs, outputs, processing, and logic. Although this works quite well for many systems, as system size and complexity grow, the limitations of a single drawing area quickly become apparent. Even with capable tools like the Birdseye viewer and layering, it is still cumbersome to scroll around the display on a large design. Additionally, as the number of drawing elements (blocks, lines, text, etc.) increases, the graphical rendering of the design begins to slow down.

Enter Tesira, and partitions. In a Tesira design, a partition is a logical container for a set of system components. The term “logical” is used because no physical device constraints are placed on partitions. In other words, a partition may reside in a single Tesira device, or it may span multiple devices. Conversely, a Tesira device may host a single partition or it may host multiple partitions. Realistically, the only constraint is that a single Tesira design may not host more than 32 partitions.

Using partitions in a Tesira design is completely optional, but they offer several benefits. With partitions you can now break your system up into logical areas that can then serve as configuration zones in your design, regardless of size or complexity. Each of these configuration zones can be reconfigured independent of the other configuration zones in the system.

As an example, consider two conferencing rooms (Room A and Room B) that are in the same Tesira system. If each conference room is placed in its own partition, you are able to reconfigure Room B even if Room A is in use during the reconfiguration process.

Interconnecting partitions
On occasion you’ll need to connect these nicely organized configuration zones you’ve created and pass audio or logic signals from one partition to another.  So a new block has been introduced with Tesira called a Partition Connector. Partition Connectors are used to pass signals from one partition to another. However, passing audio from one partition to another breaks their independent nature; partitions that share audio must be delay-equalized together**. To help manage this, Tesira supports three different delay-equalization models:

  1. Global: all partitions are delay-equalized as a single group (this is the Audia model)
  2. Per Partition: each partition is delay-equalized independent of all other partitions, even if they share audio signals via a Partition Connector
  3. Smart: during compilation, Partition Connectors that exist within the system design are used to determine the most appropriate delay-equalization

Equipment table and presets
Within Tesira, as in Audia, both the equipment table and presets remain at the global level. The equipment table will specify all of the equipment in your system design without regard for partitions. This is necessary because one physical Tesira device can host multiple partitions. This would lead to duplicate hardware entries and confusion if there was an equipment table per partition.

By default, presets aren’t specified per partition, either. However, you can create presets that only contain elements of a specific partition if you want.

Those are just a few of the attributes that make Tesira software partitions “magical”. There’s a lot of different ways they can be used to a designer’s advantage; hopefully you’ll find them useful in your future Tesira designs.

** If you decide to share audio signals between partition A and B and you reconfigure partition A, partition B might also have to be reconfigured even if you did not make any configuration changes within it. The factor that determines if partition B needs to be reconfigured is whether or not additional delays needed to be inserted into partition B due to delay-equalization.