打通音频工具之间的通信：Unity-Reaper-Wwise音频回放工具链

工具开发者：@nsmTech @张嘿嘿_@吉了个吉个了

前言

我们曾经有过这样的经历：

搭建好了新版本的wwise工程，现在要进boss战测试实机效果；

然而，

进了游戏发现，已有的GM指令并不是十分易用;

账号只有一级，进不去特定关卡的特定boss战啊？行，从第一关开始打过去；

开了挂打boss这么快，两下就没了，boss技能都还没放完啊？行，找策划调数值；

最后的大招怎么也搓不出来...门槛太高了...

(让程序更新一下GM指令需要排期，实在等不了...)

最终，只能用三分钟的战斗记忆，调整工程里各种各样的问题。

还有另外一些令人头大的情况：

•        开大型测试，服务器只能允许测一次

•        测多人战斗，人手只够测一两次

•        等等...

可不可以像电影一样，把游戏流程录制成wwise声音胶片存起来，以后可以无限次回放呢？

当然可以，我们尝试开发了URW（unity-reaper-wwise）回放工具链，只需将一次流程录制下来，就可以生成一个reaper工程，在reaper中触发wwise event，满足之后无限次的联调与测试。

生成的reaper工程就是独属于你的wwise声音胶片，在reaper这个放录机上，你可以自由回看自己的胶片，这样，Wwise就成为了Reaper的混音台，允许声音设计师反复打磨声音表现。

此外，将游戏流程录制成声音胶片（reaper工程）还意味着，设计师可以在工程中随意调整播放进度，定位到游戏流程的某个特定时间点，针对某一帧或某一小段游戏流程反复打磨。

Unity录制音频信息

既然是回放wwise的声音，那么这部分需要回放的声音数据数据，1、形式是什么？2、声音数据该怎么抓取？

关于数据形式

因为是1.0版的工具流，所以当前的数据形式还比较简单。一句话来说，只是知道在什么时间？播放了哪些声音事件即可了。如下图。

前期思考过两种抓取方式：

1、unity runtime 阶段嵌入抓取逻辑。

这种方式我们构想的理想实现方法是：项目中所有的播放声音行为有一个统一的入口。然后在这个入口处嵌入抓取逻辑，来一个声音，便抓取一个声音，存储一个声音。但考虑到不同的项目有不同的逻辑，或许就有项目不会有这样的统一的播放入口。我们给这套工作流的首要要求就是通用性，即做到任何项目都可拿来即用。因此如果后续存在在不同的项目去改造逻辑适配这套工作流的情况，这是不可接受的。另外，我们要求可以在Editor模式下也可使用。最后，在实现层面还有一个尚未验证的担忧，考虑到游戏跑起来之后的时间稳定性，或许会导致本该是同一时间触发的声音，最后数据记录下来的时间数据有所差异。所以，综上我们采用了以下第二种抓取方式。

2、Waapi

Waapi中有一个订阅接口：

这个订阅函数会在新的日志条目添加到wwise中时，执行你定义的回调函数。我的处理是在这个时候存储新的条目的信息，然后在录制结束之后，通过另外一个函数将条目信息列表生计算出所需的可供播放的数据。

需要注意的是

1.wwise条目时间单位是毫秒，且存在同一时间触发多个event的情况。因此，不管是在存储还是在播放都应该针对这个做出相应的应对操作。

2.wwise条目时间是声音引擎初始化开始所经过的时间，因此有可能录制的第一个数据触发时间量级很大。（或许你在声音引擎初始化了1小时之后才开始录制，那么第一个声音数据的时间就要>=60*60*1000）。所以，不管是为了录制完成之后及时回放，还是为了把录制的数据能在后续生成的reaper工程中能顶头播放，都应该把所有的数据时间等比例前移，我的做法是把所有的时间最后都从0秒或0.5秒出开始。

其他便是播放的时间控制逻辑、用户界面的逻辑以及保存加载逻辑编写了，不多说。

第二步：Json To Rpp

在生成rpp（即reaper工程）这一环，我选择了用Node.js来编写脚本。因为对于技术音频来说，我认为基于Node.js的JavaScript语言是一种相对来说比较轻量级的选择，可以快速地达到“写工具”的目的，从而将更多的时间用在“设计”上。

首先，Node.js有npm包管理工具，可以将脚本所需的依赖包粘合在一起，使脚本开发过程变得相对流畅。比如FFmpeg是一个非常强大的音视频处理工具，支持多种音视频格式，提供了丰富的功能和参数选项。而在Node.js中使用它也相对便携，只需使用npm命令进行安装：

安装完成后，就可以在Node.js代码中引入fluent-ffmpeg模块，然后使用其提供的API进行音视频处理了。在我之前给音频部写的打metaData标签的工具中，也是调用了FFmpeg中相关的API：

相比于其他编程语言，Node.js在处理IO密集型任务上表现更为优异，这意味着Node.js脚本能够更快地读取和写入大量的音频数据，而不会因阻塞而导致程序运行缓慢。另外，Node.js还提供了异步编程模型，可以使脚本在进行IO操作时不会阻塞主线程，从而保持应用的高响应性。

更加令人惊喜的是：JavaScript有相关的Waapi接口，你可以在网页中、桌面应用程序中和Wwise做相关的交互。这也为技术音频在设计工作流的过程中提供了很多的思路。通过Waapi接口，可以方便地使用JavaScript与Wwise进行通信和交互，实现对音频资源的实时控制、管理和自动化处理。例如，可以通过Waapi接口实现动态更改音频事件、创建和管理游戏中的声音对象等操作，从而为游戏音频设计提供更多的可能性。

在当前这个回放器工具中，我就是通过Waapi来获取实践中音频样本的最大长度，从而将其转换为rpp中item的长度的。我使用的uri是ak.wwise.core.object.get，options为'maxDurationSource'，以WAQL的形式向Wwise发送http请求，从而获取信息。

至此，结合Unity中录制的Json、mp4和从Wwise获得的信息，我已经能完完全全地生成一个rpp的文本文件作为这个工作流中的reaper工程了。

Reaper To Wwise(ReaWwise Caster)

-概述

    在reaper端实现重放的初衷，是为音频设计师提供一个能够在DAW中配合视频调试wwise工程的环境；更加贴合DAW使用者的操作习惯，播放方式能够与制作视频贴片时的播放方式相同。

    我把脚本设计成小UI的形式，相当于是个小遥控器——开关开启，遥控器丢在一边就不用管了(当然报错了还是要管一下0 0)

    为了实现这个设计目标，工具需要实现这些功能：

1.基于播放光标位置捕捉item的event触发器

2.连接Waapi并调用API的通道

3.播放视频的同时低延迟post event

4.操作者自由开启或关闭capture功能, 无感化Wwise通信

-前置扩展

ReaWwise：

ReaWwise是Wwise中的一个插件，它允许用户将Reaper中的音频和音乐资源集成到Wwise中，以便在游戏中使用。因此，ReaWwise插件提供了一些API，用于在Reaper和Wwise之间进行交互，开发人员可以将Reaper中的音频资源快速有效地转换为Wwise项目，并在游戏中使用它们。

UI界面：

-reaper端Waapi调用的实现

今年一月份AK官方扩展了ReaWwise的功能，提供了在ReaScript调用Waapi的API：

相关API：

    使用ReaScript相关API，可收集reaper中item、track所包含的相关信息，最终通过reaper.AK_AkJson_Map_Set()转化为调用"ak.soundengine.postEvent"所需要的格式。

-基于播放光标位置捕捉item的event触发器

    由于ReaScript API中没有提供捕捉item的trigger功能，所以只能自己写啦。基本思路是收集各轨道item起始位置数据，实时刷新播放光标位置坐标，当判定与起始位置重合时，post event；

    然而在实际码代码时遇到两个问题：

1.刷新函数时间间隔（用while do秒崩）

2.判定点精确度

    在献祭头发后，问题解决：

1.ReaScript中提供每帧刷新函数

    运行流畅没烦恼。

2.由于播放的声音是给人听的，所以将起始位置数据精确到1ms，兼顾延迟与判定准确度。

后续功能展望

    打通reaper-Waapi通道意味着，reaper中更多的参数可转化为wwise相关参数，实现reaper控制wwise播放行为的目标。我们希望最终可以实现的是Wwise可以作为Reaper的拓展辅助调音台。

    功能展望：

1.轨道包络控制rtpc

2.item控制switch、state切换

3.为轨道分配GO，根据Unity回放器记录数据，实时更新GO坐标信息

4.结合ReaWwise原生功能实现reaper item、wwise audio clip无感化自由替换，实现在reaper中还原wwise中听感并直接挂插件调整素材，一键导回wwise工程