lib pd 是世界上最强大的免费开源软件之一，广泛应用在各个领域，为原始声音和音乐创作提供了极大的便利。从手机到电脑都可以使用。
作者：瓦伦·奈尔
原文：http://designingsound.org/2013/09/interview-peter-brinkmann-libpd/

Pure Data（Pd）是音乐和声音创作的最强大且最常用的开源软件之一。它是由米勒·普克特开发的完全免费的软件。而大约三年前，libPd被发布了——它是Pd Vanilla（Pd基本版）的资料库，可使Pd几乎能在任何地方运行。从那时起，由libPd驱动的各种应用程序便层出不穷，横跨PC，OSX，IOS，Android，Unity3D及其他的平台。有了libPd，你可以轻松使用常规Pd“补丁”来进行体验——无论是音乐应用程序，声音设计工具，游戏或安装程序。
彼得·布林克曼统领libPd的开发，还得到了广泛的社群支持，这在接下来的采访中会屡屡提及。看到这样伟大稳定的产品被进一步扩展并在大量产品中使用可谓一大创举，更别说它们还是免费的。他最近发布了一个新的项目——Patchfield的代码，它可以在Android应用程序之间分享音频，就像Audiobus在iOS平台上做的一样。
DS：彼得，非常感谢你接受采访，如果你能先给我们讲讲你的背景就太好了。
PB：我的专业是数学，我曾经是一名大学教授，研究几何和代数。但是我一直对软件开发有着浓厚的兴趣。我曾经写过很多理科方面的软件。然后有一天我离开了学术界，变成了一名软件工程师，现在我正在研究语音识别工作。开发libPd是一种爱好。
DS：是什么让你开始libPd的呢？
PB：它基本上是一个巧合。在2010年的夏天，我辞职离开学术界在软件行业开始新的工作，结果我的学术H1B签证并不被商业世界通用，所以必须等上三个月才能得到一张新签证。我发现自己有整整三个月都空着，又没什么事情可干。这还真是意想不到的奢侈啊！然后正巧我去了汉斯·克里斯托夫-施泰纳办的一个派对，他在Pd的世界是一位领军人物。我们聊天时他建议我尝试建立一个可链接到Android平台的Pd端口。这主意看起来很棒，而且那个时候我觉得自己需要学一点手机开发的事情，我想学之前从来没有用过的git。我猜商业软件开发和学术黑客之间的差异是，你做商业开发时会花很多时间阅读别人的代码并修改遗留代码等等。我以前不大做这样的事情，所以想做一个项目来研究别人的代码，养成这种（商业开发的）习惯。把Pd与Android对接似乎是个不错的选择，所以我就开始了这个项目。因此，它基本上是一个练手项目。
DS：对一个练手项目来说，这是相当惊人的！
PB：巧合有时候也会让人大吃一惊...
DS：你开始时有没有遇到什么障碍，过程大概是怎么样的？
PB：我开始时是从研究现有代码入手的。汉斯·克里斯托夫-施泰纳，彼得·基恩和纳伊姆·法兰迪诺已着手Pd与Android端口对接工作，他们到了基本可让Pd在Android应用程序内运行的地步。但是根本上来说，它是无法正常运行的——它有定时问题，而且没办法发出任何声音。好消息则是，我可以利用现有的代码。我非常感谢他们在之前做的所有基础工作，给了我很好的基础。我看过代码之后发现，普通的将Pd对接到其他平台的方式在这个环境下是无法运作的。因为Pd会掌管一切，但是，Android应用的构造方式和Pd的运作方式无法兼容。有件事情显而易见：Android
OS必须占据领导地位，Pd必须在Android之内求得生存。要创造这种结构设置出奇困难——Pd生来便不以这种方式工作。我在Pd里寻找类似的音频处理功能——就从精神上来说也得有这种功能，所以唯一的问题是怎么把它弄出来。我花了几天分析Pd的源代码，直到我想出信号处理在哪里发生，缓冲区又在哪里等等。一旦我对Pd有了整体认识，我就能分割各种调用，使音频合成成为音频处理回调。这是最困难的部分，一旦我完成了音频处理回调，剩下的都是相当常规的工作。
DS：自libPd推出后已经过了三年了，使用libPd的应用程序如雨后春笋般纷纷萌发。作为这样一个项目的带头人，你有什么感觉？
PB：这是一次使我受益匪浅的经验，我很高兴能献出自己的一份力量，不知道还能说什么！我在这方面工作时获得了极大乐趣，能看到人们正在做什么是十分令人快意的。
DS：一直以来都有大量从libPd而来的衍生物——如libPd与Unity，WebPd。你觉得自己会带领libPd超越iOS和Android吗？
PB：有两个相关的方面让我感到很兴奋：整合libPd进入openFrameworks，这是丹·威尔科克斯已经完成的，还有将libPd整合进入Processing，这是彼得·基恩和我一直在努力的，它打开了许多可能性[编者注：采访结束后彼得写信给我们要求特别提及里奇·依金的工作，尤其是他在Cinder内处理音频和为Cinder改进libpd]。特别是，它扩展了我们已有的iOS和Android，因为你可以在Processing与openFrameworks里创建应用程序，将它们分配到这些手机设置。因此，更加紧密地集成libPd进入富有创造力的编码框架正在进行，我对此有很高的期望。
DS：移动设备都有自己的挑战——无论从创意和技术的角度来看。你认为易于使用的Pd（与“真正的”编码语言相比）会不会过度简化这个过程呢？
PB：我不认为易用性与这件事有任何关系。一旦Pd翻译了声音设计师创造的信号处理链中的图示，Pd就将执行该代码本身。在这一点上，你没有任何从用户界面或补丁解读处得到任何延迟。它的速度不是因为本身的用户友好性而减缓下来的。让我们放缓速度的部分原因是，所有代码都可以完全可以移植到任何有一个合理的C编译器的系统上。它的后果是，虽然它到处都有，但却到处都没有得到优化。在某些处理器上会有向量和信号处理操作，你也可能拥有只是因为代码是分类的，而各种现在Pd无法应用的可以提高表现的优化。所以，问题是这要怎么办，相关的问题是谁应该来做这件事？很多人曾试图在Pd内整合向量优化，我不太清楚他们已经做到什么程度了。我到目前还不愿涉足的原因是不想创建一个Pd的分支。我的目标一直是尽可能少接触代码库，并建立基于Pd之上的东西。优化Pd的向量运算将需要改变Pd本身的代码基础，在这一点上，会有可能创建Pd的分支，这就是为什么我迄今为止远离它的原因之一。另一个原因是，它需要时间，我现在又没有！
DS：这是你博客上写过的东西——Pd的局限性在于它是什么，又有什么地方可以去。你认为，会不会因为它是社群的努力，而且被用于各种各样的应用，在未来的某些时候，它将需要检修以匹配移动性？
PB：有可能。这是我一直在与米勒·普凯特和Pd社区的其他成员讨论的问题。我问的另外一个问题是——Pd到底是什么？它是现有的代码，或还是恰好被现有的代码实现的规范？不管它的答案是什么，问题是答案应该是什么。我的信念是，我应该确定Pd的一般定义，然后应该实现它——超过它。在某种意义上，我们已经迈上征途了。除了Pd本身已有的马丁·罗斯的Zen Garden——他一直致力于Pd的新改进而且做了不少有意思的工作，克里斯·麦考密克也一直致力于WebPd[编者注：现由塞巴斯蒂安·匹克马尔管理]，它本质上是Pd的一个Java脚本版本。不管Pd是什么，它已经变成一个实施方式各不相同的规范，我认为这是正确的方式。我们真正需要的是有个人愿意花时间，真正把这个规范变得官方。现在，它还是非正式的——如果它像米勒的原代码一样工作的话它就是Pd。我认为我们需要一个正式的Pd的定义。这可能对一个有兴趣的学生来说是个硕士项目或学期项目。还是有办法做到这一点的。
DS：最近你展开了对Midi和蓝牙的支持，并已在探讨Android上的openSL问题。你觉得libPd目前的状态怎么样？
PB：libPd是由许多移动的部件构成的。它有个长期不变的核心库。只要Pd本身并没有太大的改变，我认为C的核心库就已完成。此外，在一年半左右的时间里适用于iOS的ObjectiveC的组件没有太大的改变。我认为这是一个很好的迹象，意味着我们还没有真正的bug报告。因此，看起来所有这些部件似乎都相当稳定。还需要做的是更加紧迫的事情——与其他软件包，比如Processing，openFrameworks和Unity3D的集成。我一直在思考Android开发的最佳实践，最近的一个结果是，我研发了一个为Android改进的音频流层，它位于openSL之上，正被libPd使用。它比我们以前的版本更稳定，由于我想出了一个更好的启发式算法以同步输入和输出，往返输入到输出延迟也得到了改善。另外一个较大的变化也很有必要，但主要应该由我完成，那就是我们需要Pd支持多个实例。现在Pd全球性的状态就是，在一个过程中，你只能有一个Pd实例。这是不幸的，因为没有多个实例，就意味着基于Pd的VST插件等非常理想的应用现在都无法使用。
DS：这也在前进路线图上么？
PB：Pd所有的维护者都意识到这一点，基本上大家都同意这个问题一定要解决。在一定程度上，这是一个时间和美学的问题。有一个明显的解决方案，但它相当没有吸引力，弄得没有人有兴趣实现它。如果你去看看Pd开发者列表，会看到我们讨论一些解决问题的新思路。到目前为止，我们结论很一致：丑陋的解决方案看起来才像正确的解决方案。为什么没有人这么做呢，就是因为太丑了（笑）。我希望这个解决方案能够产生，因为它确实是一个很大的限制。没掉这个限制以后，我们会立即看到许多libPd的新应用。
DS：除了libPd之外，你有没有任何其他的宠物项目（指因个人爱好而非大众需要而发起的项目）？
BP：如果你看看我在Github网站上的数据库，你会看到一个相当新的openSL层兼容性的重大修订。实际它使用了最近的谷歌I/O讨论中的想法。这给了我很多思考空间。openSL库完成时，我和几个同事讨论了下一步该怎么做。有了他们的帮助，我把一个层放在opensl_stream之上，使其支持多进程，平行运作多个音频模块。一旦完成，我便意识到只需添加一点点的共享内存就可以让跨应用程序的音频路由工作，这就是Patchfield项目的起源。
[DS编者注：这次采访是在Patchfield正式公布前进行的，因此彼得的答案会较为保守。你可以在这里和下面的视频找到更多信息]