Strata is available at a special launch price of US$25 during December 2025. The standard price will be US$75.
When you invoke a DAW and work on some music, the DAW software typically loads as a single operating system (macOS or Windows) process. Each process in the computer has a memory address space, which is critical to the operation of the software.
Typically, when a DAW loads an audio plugin (e.g. a VST3 plugin), it loads the plugin's code into the same process as the DAW. This means that the DAW and the plugin both reside in the same address space. This, in turn, means that the DAW and the plugin can damage each other and cause each other to crash. Specifically, it means that a plugin can cause the DAW to crash. A DAW can load fifty plugins, and it only takes one bad plugin to crash the DAW and all the other plugins.
To avoid the problem of plugins crashing their host DAW, some DAWs do not load the plugin software in their own process's address space. Instead they create a new process just for the plugin and load and run it there. Then, if the plugin crashes, it only crashes the plugin's process. It does not crash the DAW's process. So the DAW can notify the user that the plugin crashed, give the user the option of restarting the plugin, and keep going. This is called plugin sandboxing.
Before continuing, it's important to clarify a point of terminology. A "plug-in" refers to a particular plugin created by a plugin vendor. For example FabFilter Pro-Q4 is a plugin. A "plug-in instance" (or "an instance of a plug-in") is when you add a plugin to an effect chain in your DAW. For example, your DAW project might use FabFilter Pro-Q4 in seven tracks. The plugin is called "FabFilter Pro-Q4" and there is an "instance" of it on each of seven tracks. Each instance has its own parameters and settings which may be different from that of the other instances.
There are lots of ways of doing plugin sandboxing. The Bitwig DAW provides several sandboxing modes, so I'm going to describe those. Other DAWs typically provide one or two of these at best. This is the most risky mode.
with Bitwig: In this mode, all plugin instances are run within the Bitwig process. So this is the no-sandboxing-at-all mode.
Together: In this mode, Bitwig creates a single other process dedicated to plugins and puts all the plugin instances in that process. This means that if a plugin instance crashes, it will take down all the other plugin instances, but will not take down Bitwig.
by Vendor: In this mode, Bitwig creates a new separate process for each plugin vendor. For example, there might be one process for FabFilter and one process for iZotope and one process for Cableguys, and so on. It then places all the instances of all the plugins of the vendor in that process. So, for example, you might have a DAW project that has five instances of FabFilter Pro-Q4, six instances of FabFilter Pro-R2, and three instances of Cableguys Shaperbox. In Vendor mode, Bitwig would create one process for FabFilter and place the five instances of Pro-Q4 it and the six instances of Pro-R2 in it too. It would also create one process for Cableguys Shaperbox and place the three instances of it in that process. In this mode, if a plugin instance crashes, it will take down all the instances of all the plugins made by the vendor associated with the process, but no other plugin instances.
by Plug-in: This is the same as "by Vendor" except that each plugin gets its own process. So, for example, you might have a DAW project that has five instances of FabFilter Pro-Q4, six instances of FabFilter Pro-R2, and three instances of Cableguys Shaperbox. In "by Plug-in" mode, Bitwig would create one process for FabFilter Pro-Q4 and place the five instances of Pro-Q4 it and one process for Pro-R2 and place the six instances of Pro-R2 in it. It would also create one process for Cableguys Shaperbox and place the three instances of it in that process. In this mode, if a plugin instance crashes, it only takes down all the other instances of that specific plugin.
Individually: In this mode, each individual plugin instance gets its own process! In this mode, if a plugin instance crashes, the crash does not impact the DAW or any other plugin instances (including other instances of the same plugin). This is the safest mode of all.
If "Individually" is so great, why not run in that mode all the time? Well this might be sensible in the future, but for now, it's a little more complicated.
The different modes have a different impact on memory (RAM) consumption. When you create an operating system process, the process comes with a fixed overhead RAM cost. Typically this is of the order of 30MB. So in "with Bitwig" mode, there will be no cost. In "Together", there will be a 30MB cost. In "by Vendor" mode, there will be a RAM cost of 30MB times the number of distinct plugin vendors in your project. In "by Plug-in", each distinct plugin you use will incur a cost of 30MB. Finally, in "Individually" mode, each instance of each plugin will cost 30MB.
Whether this RAM cost matters to you will depend on how much RAM you have and how many different plugin vendors and plugin instances you have in your DAW projects. Nowadays, you probably don't need to worry about the RAM impact until you get to "Individually" mode.
The "Individually" mode comes at an additional extra cost. All the other modes load just a single copy of each plugin's code into your computer's memory. However, the Individually mode will load a plugin's code once for each instance of the plugin. This means that if you have a plugin that contains a particularly large amount of code (eg. 100MB) you will be consuming this much RAM for each instance of the plugin. This also applies if the plugin tends to use lots of memory for its data structures. Because of these considerations, think hard before using Individually mode.
One advantage of having all the plugin instances loaded into the DAW's address space ("with Bitwig" mode) is that the DAW and the plugin instances can communicate quickly. There is a small delay when different operating system processes talk to each other. It's not typically significant though. It probably mattered more a few years ago when CPUs were slower.
Some vendors that create plugins whose instances talk to each other get the instances to talk to each other through memory. This means that if you separate the plugin instances into separate operating system processes, they can no longer talk to each other. For example, instances of iZotope Neutron 4 talk to an instance of iZotope Visual Mixer to do mixing. If you separate the instances into different processes, they can no longer communicate. This means that "Individually" and "by Plug-in" modes will prevent iZotope Visual Mixer from working. It is for this reason that I run Bitwig in "by Vendor" mode rather than "by Plug-in" mode.
In contrast, some vendors have engineered their plugins to use non-memory ways of communicating (e.g. TCP networkworking) so it doesn't matter to these plugins if you use (even) Individually mode! Strata is in this category.
In addition to the above considerations, the sandboxing mode might impact the allocation of plugin instances to CPU cores. However, we are in deep tech territory here and I am reluctant to make any pronouncements.
Once you've set Bitwig's main sandboxing mode, Bitwig then allows you to turn on "Individually" mode for a set of plugins you nominate. So, for example, if you had selected the sandboxing mode "Together" but had marked FabFilter Pro-Q4 as "Individually", then all the instances of all your plugins would be in one process, except for all the instances of FabFilter Pro-Q4, each of which would reside in their own separate process!
Strata has been engineered not to crash, or at least to crash rarely so sandboxing it might not matter. This said, Strata is not perfect, and the cost of sandboxing is so low nowadays that it's prudent to deploy sandboxing at some level. For Bitwig, I generally recommend "by Vendor" as an overall sandboxing mode because then iZotope Visual Mixer (and other plugins like it) will still work. :-) Once you've done this, I then recommend marking Strata Vision (but not Strata Track) as to be hosted "Individually" because Strata Vision can be heavy on CPU (depending on the number of tracks it is monitoring) and I've found that it's best to dedicate a whole operating system process to it. Note that there is no problem with placing Strata Vision in its own operating system process, as instances of Strata Track and Strata Vision communicate by TCP networking, not via memory.
— Ross Williams, 26 October 2025.
Strata Back To StrataMmmmmmm! Cookies! This site uses cookies.