我已经是 Studio One 和 Studio Pro 的资深专家了，从 S1 2.0 版本开始，我几乎就没有离开过这款 DAW。即使它现在变成了有点令我讨厌的新名字 SP，但我也没办法离开它的独特生态。

当然，它也有非常离奇怪异的 Bugs，由于我已经脱离其他 DAW 太久，我无法确定这是不是大多数 DAW 共有的现象还是仅仅是 SP 独有。但今天我们主要说下 SP 的待机或设置时容易崩溃的问题。

首先是待机模式引起死机。应该就是从 SP8 开始，我的某些大型工程在待机静置几小时后会出现死机现象。比如我需要休息几个小时，或者需要离开工作室，但我不希望关闭工程，希望回到工作台前就能立刻重拾工程状态，因此我大部分时候都放着工程文件不动，直接离开。但等我几小时后回来，发现工程文件死机。这和我的 Windows 优化基本无关，因为我以前的各代版本几乎都是这么做的，晾在那里大半天，回来拾起是热茶，但 SP8 屡次出现走时热腾腾，回来冷屁股。好，这是问题之一。

另一个是复杂工程内的临时设置。Studio One 或 Studio Pro 有一个内部的优化方案，即当我们编曲或录音时，需要 DAW 更快的零延迟的响应，因此我们可以将 Dropout Protection（丢帧保护）设置为 Off 或 Minimum 最低。这时我们录音或是编曲完全没有延迟感。

但当我们完成了编曲或录音，开始进入混音阶段时，我们需要将 Dropout 设置得更高一点，比如 Medium 或 High，以将系统资源以及多核能力更多的分配给大量的效果器处理。这时 DAW 将会产生明显的延迟，这和你在左下角看到的 Latency 无关，SP 将会在这个 Latency 的基础上，再加入它觉得适合的延迟，来舒缓大量处理器的压力。

OK，这完全可以理解，而且这是非常科学的做法。

但是，在一个稍大型一点的工程中，进行 Dropout 操作却有着致命的缺陷。当我们在当前工程开启的状态下对 Dropout 进行操作，有很大很大的几率，会导致工程崩溃，DAW 死机或退出。

我的猜想是，改变 Dropout Protection 的设置，可能会同步的对全部的效果器（大型工程至少有几十上百个效果器）进行处理方式的在线变更，而这就导致某些效果器无法顺利的应变，像 Kontakt 这样的采样资源大户，极容易因为这种实时操作而崩溃，然后牵一发而动全身，整个 DAW 死机。

但是！！！

我发现，有一种方式可以绕开以上提到的两种危机。

新建工程。

在我们当前开启着工程的状态下，新建一个工程，然后在新工程的设置中，对 Dropout 等其他音频相关的参数进行设置，然后通过右上角的工程切换图标再切换回原工程，能有效的避免工程死机。

同样的方法，也可以运用于临时离开工程。由于新开工程的资源占用极低，长时间放置不会引起系统对 DAW 的资源管理，因此会一直保持低功耗的稳定状态，等回到工作室时，选择切换到原工程，几乎一两秒就回到热茶状态。

虽然我不理解为什么用这种方法就可以成功的更改设置而直接在工程中修改却不行，但我猜想的是，Studio One 或 Pro 有一种非常好的全局工程的封存能力，即将工程的状态存储在内存中，然后上了把锁，而这是一套很完美的编程语言，因此当我们新建工程并更改设置再切换回来后，原工程会非常安全的从解锁，到读取新的设置并套用在工程全局里，有一套非常完美毫无逻辑漏洞的处理序列。

但是，在工程内部直接执行这一套操作时，Studio One 或 Pro 并没有写出完美的程序逻辑，它可能将参数分批写入效果器时，会出现错误的并发而引起内存溢出等问题，而导致工程崩溃死机。

当然这只是我的个人猜测。但不论如何，我们现在有了新的应对临时更改工程设置的新方法了。我目前用这个方法测试过十几次，没有一次出错，希望这个思路对所有 S1 的用户有所帮助。

待解决：WebView2 ？

目前，Studio Pro 的潜在问题还不仅限于此。Studio Pro 及多个插件开发商现在都开始支持以 WebView 为载体的界面设计。它的特点是，插件界面中有独立于 DAW 以外的内置网络交互信息传输。比如直接可以在界面内进行账号登录，或是数据上下传输等。

像 Studio Pro 现在在右侧的浏览器中内置了大量的第三方辅助工具如 Splice、Moises、Tonalic 等，这些第三方工具在我们点击到它们各自的标签时，就会在 Windows 后台开启一个 WebView2 的独立网页加载，用于传输我们在这些网站中不同的登录信息。

一些插件开放商也在使用 WebView 的方式设计插件界面，比如大牌 UAD 和 Waves 等。

一般来说，这些 WebView 只是用来提供了多一层的用户信息交互，和更加细腻的界面设计，它们本身并不会特别占用资源和安全危害。

但是，如果由于设计缺陷，比如在加载插件或第三方应用时，网络连接不畅或界面卡死，它会带来一个对 DAW 足以致命的缺陷，就是导致 DAW 假死。

由于一部分 WebView 会在 Studio Pro 的界面之前，像一层玻璃一样的挡住 Studio Pro，如果 WebView 偶然的挂起或死机，将会导致我们无法用鼠标对 Studio Pro 进行任何操作。它就像一个始终在最前但是我们又看不见的前台，牢牢锁死整个 Studio Pro 的前端界面。

我的某个工程文件就出现过多次被前台遮挡的情况，导致我无法对 SP 进行操作，不得不手动关闭它，这也导致没有及时保存进度而不得不重新进入 SP 进行返工。

一种方法是在 Windows 任务管理器中手动对这些 WebView 进行关闭，但问题是，某些 WebView 如果极限的锁死了进程，关闭它也无济于事，因为 SP 在这时候已经被打开了一个错误的缺口，它依然会依法 SP 的崩溃。Waves 令很多用户诟病的一点就是它的插件安装和激活方式，如果激活不当或网络错误，它就会出现 WebView 锁死，从而引发 SP 无法操作不得不强制关闭。但是当我修复了 Waves 的激活和界面错误问题后，最近的工程又再次出现了类似的情况，这次不是 Waves，但我无从得知问题出在哪儿。

所以，提出 WebView 的潜在缺陷，有助于我们后期排查这类情况，一旦遇到 Studio One 或 Pro 假死（即左下角的 CPU 占用一直在跳动，或持续有 MIDI 信息在刷新，说明 SP 并未真正死机），那么我们先回忆一下是否点击了 SP 浏览器中的第三方工具，或某些特定的插件，同时打开任务管理器对 WebView 进程进行观察，有必要的话就关闭它们，看看假死问题是否得以解决。