Second Music System 是一个专注于动态音乐的中间件库。它为作曲家提供了很大的灵活性，同时尽可能容易地集成到现有的游戏引擎中，部分原因在于对音频输入或输出的细节没有意见。

Second Music System 目前还处于开发早期阶段。 文档和工具相对较少。性能良好，但还不是最佳状态。API 和音轨格式可能会发生变化。

对于作曲家

使用 Second Music System，您可以创建复杂的音轨，这些音轨可以根据游戏中的条件和事件进行转换和分支，而无需程序员或脚本编写者的太多支持。遗憾的是，目前您需要直接在 SMS 的 音轨语言 中工作，因此需要一点“编程”知识。未来的工具可能会使这个过程变得容易一些，但 SMS 音轨的基本核心始终是这个语言。

对于脚本编写者

使用 Second Music System，您可以向音轨公开您喜欢的任何关于游戏状态的信息。作曲家可以使用这些信息的任何部分，而且所有这些功能几乎不需要引擎本身的工作。

对于程序员

使用 Second Music System，您只需

• 提供加载音乐文件的钩子，格式和结构可以是您引擎的自然选择。
• 定期从 SMS Engine 接收样本并将它们发送到输出（“转动把手”）。
• 向 Engine 发送命令以加载音轨、开始/停止流、设置流/混合控制等，无论是通过编写直接执行这些操作的代码，还是通过将这些调用公开到您的引擎的脚本环境中。

您 不需要 编写代码来处理淡入、淡出、分支、多线程加载的逻辑或任何其他类似操作。SMS 会处理所有繁琐的工作。您只需提供一些基本设施，SMS 就会完成剩下的工作。

常见问题解答

功能有哪些？

您可以在相关的声音之间进行淡入淡出（例如 光速超越），在动作之间分支（例如 星舰学院 或 光环），叠加多个独立流程（例如 光环 最后一关中某个臭名昭著的bug），以及将不同长度和重复次数的声音交织在一起。

您不能：应用复杂的过滤器或实时合成，包括但不限于速度和节奏的改变。（某些过滤器，如均衡器，可以通过提前进行一些过滤，然后在不同比例下使用 SMS 混合同一声音的不同过滤器版本来实现。）

您目前不能但将来能够：暂停一个流程，然后从暂停处继续。

Rust?

第二音乐系统是用 Rust 编写的，这是与它接口的最佳语言。然而，几乎*所有功能都以 C 绑定的形式提供。如果您的游戏引擎是用另一种语言编写的，您可以使用 C 绑定作为基础。

基于 C 绑定的 C++ 绑定计划中已有，但尚未编写。

*(某些复杂的状态查询尚未绑定，但我们希望很快就能解决这个问题)

查询？

SMS 是在假设音频处理在“后台”进行的情况下设计的，与游戏逻辑的其他部分分开。它被设计成确保这些方面从不互相等待。音频线程永远不能阻塞等待另一个线程完成某个操作，反之亦然。不幸的是，这使得在音频线程之外“读取” SMS 引擎的状态比预期的要复杂。

对于您经常且持续需要读取 SMS 音轨当前状态信息的罕见情况，有一个简单的办法。每次检测一次

• 如果您尚未发送此查询，请发送一个。
• 如果您至少发送过一次此查询，并且已收到响应，请缓存该响应并发送一个新的查询。
• 使用缓存的响应来完成此轮检测。

录音？

SMS 设计得既适用于实时播放，也适用于离线录制。它的性能针对实时情况进行了优化，但也适用于离线使用。为了获得一致的录制结果，您应该要求 SMS 执行“前台加载”，这意味着它将始终同步按需加载所需的内容。对于实时使用，这可能会导致小故障，但对于录制，这意味着音轨将始终可用，不会有因录制而变化的延迟。

• 如果使用 Rust API，则在录制时使用 new_with_runtime 并带 ForegroundTaskRuntime。
• 如果使用 C API（该 API 不公开 Runtime），则在录制时，将 SMS_Engine_new 的 background_loading 参数传递为零。

延迟！

SMS 喜欢在后台加载事物，并且它不喜欢让任何事情等待任何事情。当您开始播放一个流程时，它将开始加载/预充电该流程所需的全部组件，并且播放实际上不会开始，直到它们准备就绪。这对于关卡背景音乐等是没问题的，但对于需要随时准备好的串行，以及其他事物来说，这是一个大问题。

您可以通过使用 precache 来避免延迟，保持那些流程随时可用。只需简单地将您“很快”将需要的所有音乐进行预加载，它就会在您需要时准备就绪。

如果您的游戏有加载屏幕，并且您想在加载屏幕上等待 SMS 加载某个特定集合的流程完成，请预加载所有这些流程，然后定期查询 SMS 以查看这些流程是否已加载。

内存？

SMS对内存的需求并不大，除了一个微不足道的问题，即默认情况下声音会完整地预加载和预解码。这减少了加载相关的问题和CPU使用，但代价是需要将每个音轨组件的解压缩版本存储在内存中。单个声音可以请求以流的形式传输。它们仍然会在后台“预充电”，但大多数的实时IO和解码现在将在音频线程上进行。对于非常复杂的流程，或者包含非常长声音的流程，这可能值得为了节省内存而这样做。

CPU?

第二音乐系统在后台线程中执行所有加载。如果可用，它将自动使用多个硬件线程并行进行加载。目前，流式声音仅在单个线程中解码，但未来的版本也将在此处使用多线程，而不会更改API。

FMOD。

是的，FMOD更为人所知且受支持，可能更容易使用且性能更佳于SMS。它还具有一些SMS没有且永远不会拥有的优秀功能。但FMOD是闭源的商业软件，使用专有的、保密的格式；第二音乐系统是——

法律声明

第二音乐系统版权所有©2022和2023年Solra Bizna和Noah Obert。它许可在以下两者中选择：

• Apache许可证，版本2.0 (LICENSE-APACHE 或 http://www.apache.org/licenses/LICENSE-2.0)
• MIT许可证 (LICENSE-MIT 或 http://opensource.org/licenses/MIT)

任选其一。

除非您明确声明，否则您提交的任何有意包含在第二音乐系统crate中的贡献，如Apache-2.0许可证定义，将按上述方式双重许可，不附加任何额外条款或条件。