When we launched Audia in 2001, we developed a software compiler to go with it. But it was always a lot more than just a compiler. We didn’t make a big enough deal about it back then, so we’d like to retroactively make a big deal about it now.

What is a Software Compiler?

A traditional software compiler takes code that’s written in a human-readable format such as a programming language like C, C++, Fortran, or Pascal, and converts it into machine code. Machine code contains all the commands that the actual processing chips read, and sets all of the ones and zeroes to make the program work. That is what a compiler does at its most basic.

In the case of a visual programming environment like Audia or Tesira software, the compiler is taking visual representations of a program and turning that into machine code. Everything about an input block, for example, needs to be turned into machine code. The number of inputs, what those inputs are “wired” to inside the design file, and what physical inputs are actually being assigned to that block, all needs to be converted into machine code. Every single block. No matter how big the file. It’s a big job, and it has to be perfect.

In computer time, that’s a lot of work and a lot of computation cycles. But when we rolled out our compiler in Audia, all that manual programming was no longer necessary. The compiler quickly did all the hard work. It also setup and configured CobraNet connections for the system.

The Compiler Does Even More in Tesira

When we were developing Tesira, we asked the compiler to do a lot more. We always knew that our compiler was capable of great things, and we wanted to realize that potential in Tesira. That’s why we call it our “Configuration Engine.”

What does it do? It does all of the things that Audia did, and then some. For example, anytime audio needs to move from one piece of Tesira gear to another, AVB streams are set-up to contain any number of channels within the 420 x 420 channel count, connect listeners and talkers, manage both kinds of devices, and ensure all the right lines of audio are automatically going to the right place. The system designer never even needs to deal with it.

The configuration engine also computes the most efficient scenario of hardware that can operate the design file, and tells you exactly what Biamp gear is needed. By “most efficient,” we mean “least expensive.” Yes, the configuration engine will give you the most affordable system that can do what your design is built to do. Feel free to read that again before continuing.

The configuration engine also keeps track of your partitions and knows what changes have occurred. If you’ve changed a few partitions, but not all of them, and you hit the “Compile All” button, the configuration engine will only compile the partitions that changed, dramatically cutting the compile time.

In addition, the configuration engine takes responsibility for only taking down changed partitions when you send an updated file back into a system that is running.

We can go into deeper detail about this if you like. We’ve got some great information for you on Cornerstone.