就音频插件开发来说，Wwise 与数字音频工作站 (DAW) 有很大的不同。Wwise 插件具有交互的特性，而且需要支持各种不同的平台，所以新手很难一下子掌握所有的东西。即便拥有我们团队内部开发的工具，其插件开发管线还是太过难以理解，这让新插件的构建显得有些劳心费力。因此，我们决定适时地简化或重写其中的一些工具，这样插件开发人员使用起来会更加地便捷高效。下面我们就来详细说说实施了哪些改进，看看如何使用其为 Wwise 轻松构建音频插件。
单个入口，统一访问
Wwise 2018.1.3.6784 中推出了多款插件开发工具，如今全部都可通过 Wwise Launcher 进行下载。倘若您想按照本文所述来构建自己的插件，建议随 Wwise 一并安装 Windows_vc140 SDK 平台。除此之外，还需安装 Python（任一版本均可）和 Visual Studio 2015。在此之后，便可通过 /Path/To/Wwise 2018.1.3.6784/Scripts/Build/Plugins/wp.py 中的单个入口来统一访问所有工具。为简单起见，全文将以 wp 来指代 wp.py 的完整路径。
嵌入基架，提高效率
示例是个好东西。它们直观地展示了如何将给定框架应用到实际场景中。这对刚刚开始使用这种框架的人来说极为重要。可是，在看完所有示例之后要怎么做呢？有人可能会说，可以选一个最为相符的示例，然后直接删掉那些无关紧要的部分，据此来构建自己想要的插件。不过，我个人觉得这样的流程比较容易出错，所以最好能换一种方法。为了解决这一问题以便更加轻松地构建新的插件，我们专门创建了一个插件生成器，并在其中嵌入了常用插件类型（效果器插件、源插件、Sink 插件或混音器插件）所需的各种基架。
生成的工程中包含各种必要的文件，方便您以此为基础快速构建自己的插件。里面有声音引擎和 Wwise 设计工具插件正常工作所需的基本代码，另外还有一些配置文件（稍后我们会说到）。
多次构建，普遍适用
Wwise 可以广泛地支持各种不同的平台，这对开发人员来说既有好处也有难处。一方面，它让游戏开发人员可以非常轻松地将 Wwise 整合到游戏引擎中，而不用担心目标平台不受支持。另一方面，也让插件开发人员很难保证支持所有这些平台，尤其是其中一些还需要获取授权。当然，您可以先创建一个 Windows 专用插件，然后再用到 Wwise 中来对效果器进行预渲染。但是，这样的话插件就没有了交互性。
在对开发工具实施改进之后，不管 Wwise 支持怎样的平台，管理和构建起来都轻松多了。虽然仍需针对特定平台安装开发工具，不过之后只要调用 wp 就可以了。
构建的结果会直接输出到 Wwise 目录中以便调用 wp，与之前相比大大加快了“构建-测试-调整”流程。
自动处理，统一打包
在我看来，打包作为开发流程的一部分，理应自动完成。其关键在于自动处理各种相关任务，而无需让用户去学习我们的打包系统然后每一步都亲自动手。
首先，package 子命令会针对给定平台从已知位置自动检索构建工件，并以 .tar.xz 格式进行存档。最后，generate-bundle 子命令会在打包所有平台后统一地进行捆绑。它会通过插件根目录中的 bundle_template.json 生成 bundle.json 文件。其中，bundle_template.json 会根据备注自动存档。您可以在运行命令之前加以编辑来填入有关插件的一些信息（比如图像、描述、文档链接）。在此之后，这最后两步中生成的文件便可通过 Wwise Launcher 进行分享和安装。
宿主不同，架构通用
归根结底，无论目标宿主是 Wwise 还是 DAW，音频插件的基本架构都是一样的。抛开目标宿主的个别细节不说，每个音频插件肯定都有用户界面，其中包含可实时编辑以驱动某些数字信号处理代码的参数。也就是说，您可以使用几乎相同的代码库来为 Wwise 和 DAW 构建目标插件。
我最近使用 JUCE 音频插件开发框架探讨了这种可能性，并在今年的音频开发者大会（ADC’18）上发表了我的发现。
在这里 获得演示稿 。
如果您有兴趣使用JUCE为Wwise制作音频插件，建议您看一下我所介绍的案例研究Voluminous，可以在我的Github上找到。
有兴趣在Audiokinetic商店中推出您的插件吗
评论