Ableton Midi Remote Script Framework Research - 1
原文地址：remotescripts.blogspot.tw/2010/03/introduction-to-framework-classes.htmlIntroduction to the Framework Class对于ableton midi控制脚本的简介
Backgroud——背景
（前两段略） Live利用了Midi控制脚本为midi控制器提供了“即时映射（instant mapping）”的功能。Midi控制脚本是用python语言写的，实质上是用于转换midi数据为可控制live程序各方面的指令。Live支持的设备都会有专用的脚本文件夹和专用脚本。我们之后会讲到这些细节——现在，首先来一段小历史。 Emulation——仿真器自此已经有一段时间——那些充满好奇心和创造性的live用户发现（当然是那些不被live支持的设备）可以通过仿真一些受支持的设备来利用live的“即时映射”功能。其中最有名的仿真模型就是“Mackie emulation”。 仿真器主要用于告诉Live你已经插入了某一件midi硬件——当然实际上你没有。需要说明的是，你的硬件必须能够提供给live希望从中模拟的控制器传来的midi信息。你可以重新配置你的控制器，或者通过一个中间应用来过滤信号（例如MIDI-OX）。这种类型的仿真基本上来说是黑盒仿真，因为不需要修改midi控制脚本（而且也不需要知道脚步如何工作就可以使用）。黑盒仿真有些限制——下一步就是去研究调查脚本本身。 Script Files——脚本文件控制脚本是随ableton live一起安装的，如果你的操作系统是windows，你可以在一下目录找到它们：
C:\Program Files\Ableton live 8.x.x\Resource\MIDI Remote Scripts\
如果你的系统是Mac OS X： /Applications/Ableton Live 9 Suite.app/Contents/App-Resources （*打开.app文件的时候右键，选择“显示包内容（show package contents）”就可以进到下一层目录） 一个典型的MIDI控制脚步目录里会包含一些的文件夹，它们的命名类似于： 在每个文件夹，都会有一个 __init__,pyc文件，一个以控制器命名的.pyc文件，和一个或多个补充的.pyc文件。例如Vestax VCM600的文件夹中，就有以下几个文件：
最开始的几个目录是以下划线开头命名的，它们不会出现在Live的MIDI preferences control surfaces下拉菜单中（因为这些大部分是私有的辅助脚本）。其他的文件夹会包含一些受支持设备的python编译后的脚本文件（.PVC)。这是文件夹命名是用于显示在control surface下拉菜单中（更改文件夹命名的话下拉菜单不会立即刷新，需要重新启动live）。 __init__.pyc VCM600.pyc ViewTogglerComponent.pyc PYC文件不是用于给人阅读的（都是一些经过编译的代码），然而人们很快发现，通过反编译这些脚本文件，可以得到能够用于分析的源代码——它提供了一个方便的地图来寻找默认的MIDI映射，和察看这些MIDI控制脚本是如何实际工作的。
- _Axiom
- _Framework
- _Generic
- _MxDcore
- _Tools
- _UserScript
- APC40
- Axiom
- AxiomPro
- etc...
Sources——源代码
Python的PYC文件是相对容易进行反编译的，而结果是PY文件也有不错的可读性——实际上，它们本质上是相同的原始源文件。 Python代码有多种方法进行反编译。Sourceforge上的Decompyle（没有拼写错，后四个字母是pyle）在2.3版本之前的运行效果都不错。在线的“depyhton”服务对于大多数的python文件也有效，然而，现今仍未有可以用于2.5版本的非商业的反编译服务。 PYC文件的版本可以在提供16进制功能的编辑器上检查前4个字节来确定。这些“magic numbers”如下：
Live 7.x.x版本的脚本一般都是2.2版本的python文件，而8.x.x的脚本则一般（不幸地）是2.5版本。（to be done——提供地址下载） 早期对反编译脚本的研究焦点都是在最常用到的const.py文件。这个文件在很多初代脚本中用于定义常量——包括为控制接口和MIDI音符的映射。这就不再需要去钻研MIDI执行图表，或者手动地进行MIDI音符映射赋值——这些全在文件中。修改const.py文件是一个方便的方法来调整仿真器，也有很多人从头开始创造一些新的定制脚本——一些非常复杂的脚本。 （原网页）的右边链接是一些网站——那里有很多珍贵的源代码，文档和对脚本的研究——所有这些都值得去探索。同时也出现了很多人去研究LiveAPI的运作，这是非常重要的（写脚本的“阴暗面”）。但是至今为止，未有许多对关键部分难题的研究——有ableton开发的框架类（the framework classes)。 _Framework Scripts——框架脚本 过去，写脚本似乎是一个“人人为己”的事情。OEM们若希望它们的产品可以有“即插即用”的支持想必要自已编写python脚本，这是一件有太多冗余且没有交流分享的事情。对于简单的脚本，这不算一个大问题，但是，那些有高级功能的脚本往往包含许多文件和数百万行代码。当控制器市场发展成熟，一套统一的辅助脚本的需求是显而易见的。看来Ableton公司解决这个问题的办法就是这个Framework脚本。 现在新款的控制器使用了大量（有些是独家的）框架类（Framework classes）。这个名单里面有Akai APC40，Novation Launchpad，M-Audio Axiom Pro，开源实验室的产品，Vestax VCM600，当然还有更多。这个框架脚本基本上是一个工具类——一个类和对象的模块库——用于处理那些繁重的工作，和减少对LiveAPI的直接调用。 框架类代表了LOM（Live Object Model）的“另一半”——正如Max for Live参考文档中所说名的。Max for Live的文档中对于LiveAPI中的一半有详细的叙述，也包括了对框架类（control surfaces）的简介参考。 在Max for Live文档中曝光的Component和Control（element）的命名和框架组件（Framework modules）的命名几乎一一对应。在MIDI控制脚本文件夹（这里根据类型分类）的_Framework目录下的脚本名： Central Base Class: ControlSurface Control Surface Components: ControlSurfaceComponent TransportComponent SessionComponent ClipSlotComponent ChannelStripComponent MixerComponent DeviceComponent CompoundComponent ModeSelectorComponent SceneComponent SessionZommingComponent TrackEQComponent ChannelTranslationSelector Control Elements: ControlElement ButtonElement ButtonMatrixElement ButtonSliderElement InputControlElement NotifyingControlElement PhysicalDisplayElement SliderElement Other Classer: DisplayDataSource LogicalDisplaySegment 现在是时候来探索一下这些框架脚本的内部运作了。我们通过搭建一个合适的编辑环境（开发环境）来开始。
- 99 4e 0d 0a - python 1.5
- Fc c4 0d 0a - python 1.6
- 87 c6 0d 0a - python 2.0
- 2a eb 0d 0a - python 2.1
- 2d ed 0d 0a - python 2.2
- 3b f2 0d 0a - python 2.3
- 6d f2 0d 0a - python 2.4
- B3 f2 0d 0a - python 2.5
Editing Scripts——编辑脚本
（原作者关于Python代码编写环境的描述，大概是推荐大家用IDE和一些软件的推荐——Wing IDE，Stani's Python Editor-SPE，还有搭建python语言环境）。 严格地说，要使脚本能运行的话不需要另外安装python——因为Live已经有一个内建的python编译器（如果python在脚本文件夹里发现一个.PY文件的话，它会在启动的时候来尝试编译它）。不过，也只有安装了python才能发挥使用IDE的好处（例如自动完成代码）。 虽然有过编程经验（任何语言）是一大优势，使用python的一个快速入门的方法就是play around。从一些示例代码开始（例如新建一个文件夹，复制一段简单的代码进去），试一试剪切和粘贴代码，运行调试一下，看看哪里出错。通常情况下，有错误的脚本根本不会编译，仅此而已。当然一段糟糕的脚本也有可能玩坏你的live，但直到你有足够（危险）的技术和实力为止，这是极不可能的。 Debuggin——调试Live提供了几个内建的机制来简化调试。我发现的第一个关键是利用日志文件（log file）。日志文件是一个简单的文本文件，可以在Ableton live的编号设置目录中找到： C:\Documents and Settings\username\Application Data\Ableton\Live 8.x.x\Preferences\Log.txt 每当live遇到错误的时候，它会记录在这个文件里。这包括python编译错误和执行错误。如果你修改脚本后发生了一些意外情况（或者这段脚本干脆就不运行），去查看一下日志文件——这个方法通常可以找到问题所在。 例如这是一些有问题的代码： transport.set_foo_button(ButtonElement(is_momentary,MIDI_NOTE_TYPE,CHANNEL,89)) 然后日志中就会出现：
相同的日志文件还可以用于代码追查（通过Framework log_message方法）。几乎任何东西都可以被追查到。例如： self.log_message("Captain's log stardate "+str(Live.Application.get_random_int(0,20000))) 然后日志中就会出现： 255483 ms. RemoteScriptMessage: Captain's log stardate 5399 当我修改python脚本时，我会经常地重新编译来检查功能性（即，以确保我没有破坏任何东西）。我通过设置控制器为“none”在MIDI preference下拉菜单，然后马上重新选择我自定义的脚本。这可以让Live重新编译修改过的脚本——无需每次都重新加载整个live程序。 现在，利用框架类来创建一个简单的走带控制器（transport）脚本，作为范例。 Example Script——示例代码 我们需要在MIDI控制脚本文件夹中新建一个文件夹，你能够任意地命名（但要注意，如果名字的开头是下划线的话，它是不会在下拉菜单中出现的）。我们命名为AAA。 然后，在这个文件夹中新建两个文件。第一个命名为__init__.py。这个文件标志着我们的目录作为一个Python包（对于编译器而言），文件包含下列几行代码： #__init__.py from Transport import Transport def create_instance(c_instance): returnTransport(c_instance) 接下来，我们创建一个Transport.py文件，这是我们主要的脚本文件（注意这个文件名不会出现在下拉菜单中——重要的只有文件夹的命名）。以下是代码：
现在，如果我们打开live并在MIDI preferences下拉菜单中选择AAA，Live会编译我们的.PY文件，在脚本文件夹中生成对应的.PYC文件，然后运行脚本。 通道1（channel 1）上的MIDI音符60，61，63会自动地分别映射至Play，Stop和Record。当然，我们可以更据这个简单架构来进行更多的midi映射。例如，如果我们想将Tap Tempo映射至某一个键，我们只需要简单地添加一条语句： transport.set_tap_tempo_button(ButtonElement(true, 0, 0, 68)) 上面的脚本使用了基础框架模块中的一个——走带组件模块（the TransportComponent module)。除了在脚本中的三个方法，其他的公共（public）Transport Component方法包括一下内容：
（需要注意的是set_metronom_button在live7.x.x框架中是拼写错了的，但在8.x.x中是拼写正确的set_metronome_button。这说明了使用这个方法的脚本只能在其中一个版本运行，取决于你的拼写。。。！） 大部分的框架文件和函数（即是类和方法）的命名都是不言自明的，通过浏览这些类和方法的名称足以了解他们的作用。有的比较复杂，最好参照示例代码畸形理解。VCM600，launchpad和AxiomPro都使用了框架类，所以APC40也（理所当然）使用了。这些都是一些很有参考价值的脚本。 但使用反编译的源代码工作时，值得一提的是很多脚本都是“老派（old-school)”，预建发展的框架类。虽然它们能确实地运行，它们往往要比新的脚本更复杂。复杂性由框架类进行处理，使得大多数的脚本变得简单得多。 另一方面，有些基于框架的脚本也可以很复杂，特别当需要开发更多的类来执行特殊的功能（而框架没有提供的）。从这来看，APC40的脚本是进行复杂脚本编写的一个好示例。 现在，让我们来尝试编写脚本，干些新一代控制器能够完成的有趣功能吧（例如apc40在session界面的红框）
- set_stop_button(button)
- set_play_button(button)
- set_seek_button(ffwd_button, rwd_button)
- set_nudge_button(up_button, down_button)
- set_record_button(button)
- set_tap_tempo_buton(button)
- set_loop_tempo_button(button)
- set_punch_buttons(in_button, out_button)
- set_metronom_button(button)
- set_overdub_button(button)
- set_tempo_control(control, fine_control)
- set_song_position_control(control)
ProjectX
我们不需要精确地仿真APC40或者Launchpad，因为它们的功能跟硬件布局是紧紧联系在一起的——虽然要承认仿真APC40会是一个有趣的探索（这不会对大多数人有意义，除了那些apc40的用户——想要定制化它们的控制器）。相反，我们会将一个标准的midi键盘编成一个二维网格控制器，通过利用框架类。 MIDI键盘一般是一维的，而我们希望去利用它完成二维控制能做的事情。为了解决这个限制，我们使用两组按键——一组用于垂直（scene）另一组用于水平（tracks）——一个可以移动的X-Y网格按键。我们将它称为 ProjextX。 ProjextX脚本由两组键盘映射组成，可以一起或独立地使用。Part X是一个水平session component（“red box”），Part Y是一个垂直session component（“yellow box”）。我们将它保持得相对比较简单（毕竟这是用于标准MIDI键盘），但我们将用于演示如何使用一些框架类和方法——主要是Session，Mixer和Transport组件。
以下是键盘的映射表，这演示了我们将如何对这些MIDI音符进行映射。
APC40，LaunchPad和Monome都有网格按键；我们在这里将二维网格分为两个session框。红色框高度为1个track，宽度为7个scene，黄色框宽度为7个track，高度为1个scene。红色框代表以7个scene（或者为clip slot）为一组，黄色框则为7个track一组。在一起使用时，他们组成一个虚拟的7*7网格，每一个有一组独立的7个白键控制。
以下是ProjectX的脚本（红色框），脚本中使用了一些框架提供的功能：
Conclusion——结论
框架类应该会随着Live的版本更新而更新，而且一些函数方法也会停止使用。不过，因为所有新的控制器脚本看来都会是基于框架类编写的，很有可能框架类的变化将保持在最低限度（至少，我们可以期望新的方法不会破坏旧的方法）。用这些未公开的函数库工作存在一定的风险，但另一方面，框架类确实能使编写脚本更加容易。希望这种探索对其他人有所帮助。来吧，发挥你的创造性，玩得开心——和其他人分享你的工作成果！Hanz PetrovMarch 2010
没有评论:
发表评论