Native Instruments Reaktor 6 快速评测

2015-9-20 14:58 | 发布者: 梒小婵

在Reaktor6发布之前，我一直还在期待着Native Instruments公司什么时候能把它给升级了，可这一盼确实盼的时间有够长的，从5.1到5.5再到后面一系列的小升级，每次总以为Reaktor6快到了，但每次都被吊了胃口，而这次Native Instruments公司却来个大突袭，把我这期待已久的盼望落实了——Reaktor6终于来了！！！（图A)

图A

这次升级一个最直接的改变就是界面风格，可能是现在都比较流行扁平化设计，于是乎NI也觉得应该跟风下，不过改完后个人觉得真心比之前的好多了，当然5.5之前的在现在看来确实太矬了；说到扁平化，有些DAW也开始走这路线，像Reason8、FL Studio12，不过它们都不是完全彻底地扁平化，毕竟要重新设计的东西太多了，你能想象Reason的Subtractor扁平化是个什么样的吗？说到这里，Ableton Live笑了，老子都扁平化了多少年了！！！
那么到底变了什么？
请看下面这张图（图B）

图B

很明显6不再像5.9.2那样紧凑的排列方式了，而是以列表方式排列，这样的视觉布置对于长期适应5.9.2的用户来讲又是一个新的开始和新的习惯过程，我不排除会有抱怨的声音，但我相信这应该也是经过认真考量才这样设计的，很多人认为软件开发应该从消费者方面进行思考，这点确实没错，但消费者有个很大的问题是，他们很容易以自身的需求出发，而软件开发者考虑的是整体，倘若消费者需要很多功能，软件开发者就加入消费者需求的功能，那么结果就是这个软件的维护性就会变得越来越差，软件的主导方向也会发生质的变化，所以个人认为抱怨是可以理解的，当然选择软件的主导权在于每个消费者手里，你可以选择最适合你的软件，倘若你热衷此软件，那么你就只能热爱般地适应它。
其实Reaktor6这次升级主打的方向是Blocks，听到“Blocks”这词让我想到了Reason的Block功能，当然这两者一点挂钩都没有，那么究竟什么是Blocks？
请看下面这张图。（图C)

图C

首先看到Blocks，真心会让我有种欣喜的表情，欣喜过后，我便想这又是个什么全新的功能，不会是Reaktor6一种全新的模块吧？带着这样的疑问，我认真琢磨了Blocks，结果让我大失所望，原来Blocks就是Instrument。
一开始我不明白为什么Reaktor6要搞这个Blocks，因为它本质就是Instrument，不一定要在6才来提倡这样的做法，应该在6之前就可以提倡这样的做法了；后来我想了想，它这个Blocks确实是很迎合它现在的设计，首先我很高兴看到了Reaktor一直以来很困扰用户操作的连线已经经过重新设计了，也就是说它现在不是那种粗劣的带有锯齿的线条，而是那种平滑且能小幅度弯曲的线条，这点设计确实很得心，我相信很多老用户对这一改动应该会泪盈满眶；当然有了这点还不足以构成Blocks的动机，也就是说模块传达的信息要够直观，不够直观的模块会让用户摸不着北，那么究竟这次Reaktor在模块显示上下了什么样的功夫呢？
以前我们在创建Instrument或者Macro，为了更好地去知道自己创建的模块的一些属性，我们需要重新命名好每个输入端和输出端的名称，而命名的名称就是直接表达该模块的某个属性，比如拿Instrument来说，我们想创建个简单的合成器，我们给它自定义了一些属性，像可选波形的Waveform属性，还有Pitch和Gate属性，模块结果显示如下（图D）：

图D

对于上面创建的Instrument，属性不是直观，可以看到一旦属性的名称过长的话，它仅能显示的只是一小部分，如果这个Instrument仅仅只是对于个人来使用的话，由于熟悉自己的搭建，自然明白那些属性的意思，倘若这个Instrument是要分享给别人用的话，那么可能别的使用者不知道你这些属性是什么意思，或者需要打开提示功能，显然这对于Blocks要表达的意思不相符合，于是乎Reaktor6这次干脆就来点不同的，提供了模块两种显示的方式，一种是Compact，一种是Flexible。（图E）

图E

Compact是紧凑型的显示，而Flexible是灵活型的显示，默认情况下是Compact，为了更好地显示属性，必须选择Flexible显示模式。（图F）

图F

有了改良后的连线和模块显示，Blocks就一点也不奇怪了，只是在分享你的Blocks之前，你最好做张图，就像预制的那些Blocks一样，一眼就能区分Blocks的类型，好比我这里比较简单地制作。（图G）

图G

好的，上面只是从最直观的改变讨论，接下来我们来看看一些小细节或者新的功能改变；我们知道Reaktor有两个编辑层，一个叫Primary Level，一个叫Core Level，Primary Level是大家比较熟悉的层面，而Core则是更底层运算处理，那么先从Primary Level开始。
Primary Level
其实在上面我们看到了Blocks属于Primary Level上的编辑，也很直观地看到了模块显示上的不同跟连线上的改良，当然除了这两个以外，Reaktor6这次还改良一个小地方，那就是双击直接编辑，比如添加一个常数模块，那么你不用每次要点击模块，然后再到它属性栏里设置数值，而是可以直接双击常数模块进行数值修改。（图H）

图H

这个小细节的改变个人觉得比较实在，就是比较纳闷的是在之前的版本里为什么迟迟不加入呢？不过现在可好了，因为这个快速编辑修改对模块的测试非常重要，当然这个双击的功能不单单只是运用在数值上的改变，同样它也适用于名称的改变，比如你想改变某个输入端的名称或者输出端的名称或者Macro或者Instrument的名称，你可以双击名称然后进行编辑，显然有了这个功能，对搭建的效率会提升不少。
接下来是Reaktor6这次引入了一种新的类型，叫Table Reference（注意小四方格的端口）。（图I）

图I

其实经过这几天的稍微研究下，我发现这种类型是跟Core Level挂钩在一块的，也就是说我们添加的采样可以直接被用到Core里面去，比如下面这个我是利用Sample Map加载采样，然后通过Core Cell去读取，在上方的Core Cell搭建内，我们可以看到Core提供了处理Table Reference类型的端口，它叫TableRef。（图J）

图J

当然上面只是一个简单的测试，实际上我们可以通过Reaktor6自己提供的几个关于Table Reference的Macro来进一步了解这种类型，比如你可以载入TF 1Sample Drop来理解拖拉采样，这个Macro告诉了我们Mouse Area已经是个全新的模块了。（图K）

图K

除了上面两点，Primary Level还有一些小变化，比如Macro模块的图标变了，这点的意义不是很大，反而会让用户要重新认识，当然这需要一个适应的过程，基本上除此之外，模块方面就再没有太大的变化了，倒是对于Panel有个非常好的改变，第一是图形模块的变化，由于整体风格的改变，图形模块避免不了跟着变的命运，当然改变了是很好的，个人感觉更精致了。（图L）

图L

第二是加入了Snap to Grid功能（图M）。

要知道这个功能对于我来说真的是非常渴望，就像渴望连线精致一样；以前在编辑Panel里的图形，由于移动每个图形，它都是会按照4个像素的大小在移动，这样会出现的问题是界面上的图形难免会有对不上，而且有时候用户可能需要自己制作图形，为了整体效果，尺寸距离的把握显然非常重要，一有差错立马就能看出来；比如我常常会在PS先设计一个合成器的界面，并根据相应的设计再去设计旋钮或者按钮的部分，在这之前，我可能需要在PS通过参考线来认真作图，以确保在某个位置放置旋钮或者按钮，而这个旋钮或者按钮的像素大小必须是4的倍数，如果不是的话，很有可能在Panel界面调节的时候出现差错，这样一来我可能又要重新再设置图形的大小，但现在不同了，Snap to Grid真的解决了我这个难题，比如举个简单的例子，添加一个旋钮Knob和一个Button按钮，结果显示如图N所示。

图N

其实对于上面，很多人可能认为旋钮的底部跟按钮的底部是在同一个水平上，但实际不是这样，我们可以把Panel解锁看下，你就会发现它们底部并未持平，这个时候你可能想要移动下让它们底部对齐好，可无论你怎么移动你总是对不上，原因是我们一直激活着Snap to Grid，也就是说按钮的移动会对齐网格，默认移动的像素大小是4，由于没对齐上，所以无论你怎么移动都是无法对齐的，因此必须要把Snap to Grid关掉，然后再来移动按钮，这样你就可以对齐上了。（图O）

图O

Core Level

Core Level在这次升级也改变了不少东西，像Core Cell不再分为Event Core Cell和Audio Core Cell，而是统一成一个叫Core Cell，当然Core Cell的图标也发生了改变，只可惜Core Cell没能像Macro或者Instrument那样支持两种模块显示方式，也就是说在给Core Cell自定义一些属相端口的话，名称命名无法全部显示出来，这个是我觉得比较可惜的一个，当然我们可以在Macro里包含Core Cell，这样我们就可以利用Macro来实现。

对于Core Cell最大的改变是Scoped Bus和Bundle的引入（至于其他的真心都没啥变化），首先我们来先来说说Scoped Bus。

其实一开始Scoped Bus很容易跟QuickBus混淆在一块，但相比QuickBus，Scoped Bus就功能强大很多了，QuickBus只能在同一层里应用，而Scoped Bus可以在不同层里应用，也就是说如果你在Core Cell创建两个Macro，每个Macro只能用自己设定的QuickBus，但Scope Bus就有所不同了，它可以跨层应用，这作用跟Primary Level的Send和Receive模块是一个意思的，可它又比Send和Receive模块灵活许多，在应用Send和Receive模块，对于Receive模块你还需要自己手动选择哪个Send模块，而Scoped Bus只需要通过命名相同便可实现，比如现在我增加一个发送端的模块，结果如图P所示：

图P

为了更好地接收发送端的数据，我们需要一个接收端，正确操作如图Q所示：

图Q

这是在相同层处理，如果在不同处理，也就是我可以把pi放到一个Macro，并命名为Math Const，但这里需要注意的是，必须要把Macro的Solid属性关掉，结果如图R所示：

图R

这是Scoped Bus一些简单的实现，个人认为这个功能确实很实用，要知道对于像Max或者PureData这样的软件，人家早已经就具备这样的优势了，如果Reaktor6再不支持这样的功能，估计会把人折腾；当然我还是觉得Reaktor6应该要有个搜索模块的功能，因为一旦搭建越来越复杂，工程的可读性就会越来越难，具备搜索功能可能会有利于后续的改进。
在Primary Level的部分我们讲到了一种新的类型引入，同样Core Level也有新的类型引入，它就是Bundle。
Bundle是捆绑的意思，在Core Cell里就是把你想要的所有端口捆绑在一起，它就像电缆一样。(图S）

图S

其实对于Bundle你不能做运算，也就是说，像上图A输入只能到A输出，名称要一一对应，如果不一一对应，就会产生错误，而且对于Bundle的内部，每个端口不能做任何运算，也就是A输入多少，在A输出就是多少，你不能在Bundle里对A做四则运算，它纯碎是一种端口的定义，那么它有什么作用吗？如果单纯从上面来看，似乎看不出有什么作用，但对于Bundle它同样也有自己的Scoped Bus，比如如图T所示：

图T

实际上从上面的简单例子我们可以看出，Bundle的Scoped Bus跟单一数据传输的Scoped Bus是一个道理，只不过一个是单一，一个是多个，这样一来，我们可以把所以运算或者自己想要的属性先用Bundle定义，然后再利用Scoped Bus来访问，这真的一个很不错的设计。
最后补充
除了上面那些大大小小的改变以外，Reaktor6还有一些小小的改变。

第一、Reaktor6提供4种界面风格显示，如图U所示：