CapyとTC/Nearの共存に関して。

コンフリクトの発生によりアプリが両方落ち、同時展開は不可能。　それぞれのアプリ単独の起動は行えるものの、同一のFWルーティンに接続すると動作が不安定になる。　よって、残念ながら物理的な共存の可能性も怪しい。　

また、Windows7環境下でのTC/Near単独起動時には、PCとハードウエアがLockしない案件が発生している。XP環境下ではとりあえず稼動しているものの、こちらも動作が不安定。　

Macではどうなんだろうか？と、VMWareFusion経由で試してみたが、VMはFW接続には対応していない模様。まあ、Macを使っていてVM経由で音を出そうなんて奇特なことは普通考えないか。　ということで、手詰まりが確定。　別PCで駆動するほかはなさそう。

Virtual Machineに関しては、Parallelsも一緒の状況みたいなので、「同一PCから複数OS立ち上げてコントロール」という可能性は無くなった。

ちなみに、Mac上でFWリンクしてCapyとSK48をチェインすると、何故かPacarana上のUSB/midiデバイスを見失う模様。　PacaranaとCapyをリンクした環境でSK48絡めるのは不可で、これも確定事項となった。

TCのMLでは、Mac上でも結構な確率で食い合せの問題が発生しているみたいで、トラブルの報告が一杯あった。　卓として使うには安定度というか信頼性が低いと思われる。　

おまけ：　VMwareFusionとParallelsの比較

monome/arc4をkyma用端末として使用する

そもそも、このデバイスを購入した動機は、マルチチャンネル音源のパン・コントロールを、巨大なポーテーションメーター4基というとても判り易い形状で、行えそうだということにあった。



しかし、OSC準拠のプロトコルに不案内な旧世代な人間なので、ここはとりあえず「他人様」のMaxPatchを拝借することにして、それをチョコっと改造。OSC/MidiCCを吐き出す機構を追加してみた。



Patchの中身を精査すると、FM音源コントロール用の信号が、音源とArc4の「表示用OSCコマンド生成部」に分岐しているポイントが利用できそうだ。結果が原因となるのは本末転倒だが、Arc4の状態をPANコントローラーに反映させることになる。　midi送信用の回路は、ここから分岐点を作ってctloutというオブジェクトを介在させ、コントロールチェンジ信号を出力する方法を取った。



また、折角のFM音源を使わない手はないので、４つの音源をそれぞれ8chアウトに振り分けられる機構にDACオブジェクトを変更。その際、何故か音声アウトが1chに反映しない現象を体験したので、ひとまずDAを10ch仕様にして、2〜8chから音声を出力している。これでPatchを稼動させているPCに外部ADを接続した場合、パラで信号を送ることが可能となった。

一方のmidi信号の取り扱いだが、外部への接続にはOsculatorを介在させることになる。ただし、Note情報を送ろうとするとイロイロとややこしいことになるようで、この件に関してOsculatorのMLを検索しても簡単に解決できる方法はなさそうだと判断。そこで、ひとまず行って見たのは、Pan情報を送信しているcc信号のハンドリングで、ご覧のように8ch分のデータを連番で吐き出すことを確認している。



ただ、Osculatorが介在することで、どうしても「遅れ」と「データの欠損」が生じて仕舞うようで、Capybaraを使用した場合にはPan動作中に結構な確率で音飛びが生じていた。　後ほど「発見」した解決法は非常に単純で、Pacaranaにルーティンを直結するだけ。これにより、データの欠損は大幅に改善されている。



その後に実装した機能は、個別の音源毎に配置したディレイ・エレメント、PanOutのデータ幅を制限するプリセット機構、コントローラーの角度情報（固定値）の出力、音源毎のnoteNumberの並列出力といったところで、特にkymaとの併用に特化している。　

ついでに、他に接続したmonome128のデータ入出力ポートを追加している。　今までは、MonomeSerialというスタンドアロン・アプリが存在していたが、OSXの10.6.8環境では動作が不安定になっているという噂があった。　実証のためにmonomeを接続してみたところ、アプリのクラッシュが再現されたため機能の追加を試みた。　現在これのフラッシュ機能（kymaから送信される店舗情報を表示するコケ脅かし用のおまけ）の受信chを#15で固定しているが、これも汎用性を考えて変更可能な仕様とした方が良さそうだ。

音響システムの再構築

monome/arc4の到着を機に、Kymaを包括した音響システムの再構成を行った。



これは、その時に経験したTipsの覚え書き。

Kymaとは、広義にはDigitalAudioWorkstation、略してDAWにカテゴライズされる楽器だが、どちらかと言うと「楽器」寄りの音響制作支援システムといえる。　ここは、「音楽制作寄り」でないことに注意しよう。

今回の目的は、Kymaを主幹としつつも「弱い分野」をヘルパーアプリケーションで補完できる統合的な環境を構築することにある。

作業に入る前にKymaの具体的な欠点を抽出してみた。　

まず、弱いのがリズムシーケンスや音楽の小節単位の展開で、シーケンサーとの対局にあるような不便さが目に付く。　KymaにはTimelineという機能があって、これは一見するとMusicalSequencerに非常によく似たトラック別にデータを貼り付ける形をとっている。　注意すべきポイントは、貼り付けられるデータが、Midiや音声ファイルのような「音楽情報」ではなく、音楽情報を含めた、音響的な要素を構成するオブジェクトそのものであることだ。



例えば、エコープレックスのようなものを想像して欲しい。通常この手の機材から想像するのは筐体を持った「現物」であるのだが、Kymaでは動作をシミュレートしたオブジェクトを時間軸沿ってに展開していく。　これは、プロセッシングパワーの消費を抑える意味もあって、喩えるならばシーンごとに機材を「作っては壊す」という行為を仮想空間で実行していることになる。

この方法には色々と利点があって、その一番のポイントは、音声データ・Midi等の制御データ・音響オブジェクトそのものを生成するコンパイル用のデータ、それぞれを全く同じ土俵で扱える点にある。　つまり、エフェクトボードにエフェクターを並べるよりも遥かに自由度が高いレベルで、実装した機能を相互乗り入れで統合できる点が「売り」なのだ。

ユーザー側に、ある程度の電子/音響工学の知識がある場合、直感的に回路の構成を行いつつ、まとめを巨視的に行うことができるのだが、それなりに知識が必要だという敷居の高さも意味している。

一方、一般的なシーケンスソフトのようにGUIを駆使してMidiや音声データ等を手軽に扱うことは苦手で、どちらかと言うと、「機材」や「楽器」を製造する感覚に近いキャラクターを持っている。　故に音楽家、特に演奏家には敬遠される傾向がある。

今立ち上中のシステムは、これらの弱点をカヴァーしつつ、音響や操作面で出来るだけ妥協を行わずに、ライヴシーンにおける操作性と即興性の向上を狙っている。

まず最初に問題となるのは、オーディオ系の結線（仮想を含めた）で、構造がシンプルであるほど、現場のサービス性と信頼性が向上する。手持ちの駒の中では、RME系インターフェイスとT.C.のデジタル・オーディオ・ハブの組み合わせが有力な候補である。





あと、システムを構築する上での制約事項として、時代遅れのDSPボックスを有効利用することが挙げられる。制限された機能の中で、シンプルな構成で有用な仕組みを構築しなければならない。

KonnektX32はSPDIF,AES,ADAT,Firewireと、現存する殆のオーディオ伝送フォーマットに対応していて、拡張性が高い。このハブを中心にデータのやり取りを行なっていく。　想定される使い方は二通りあって、Capyを使用する場合は、単なるデータ変換器として、Pacaranaを使用する場合は、Kymaの直接的な端末となる。



実はこの機材を購入した理由は単純で、Kyma/Pacaranaが対応していないRME製のAD/DAを導入する目的があった。

実は、RMEの通信プロトコルは特殊な独自仕様のために一般には公開されていない。　故にPacaranaとの直結が行えない。そこで、デジタル音声規格の物理的変換が可能な機材の介在が必要となる。

RMEの特徴は音質の良さだけではなく、コンパクトさに相反した拡張性にあり、デジタル端子を含めた60近い入出力数を誇る。さらに、RMEを使う利点はPC直結の卓として機能することで、音声終端回路としてオーディオ回路を纏める役割が期待される。　



Fireface800をコントロールするFirefaceMonitorは外部からmidi制御を行うことが可能で、データ形式はMackie/HUIのプロトコルに準拠する。　ただし、これは卓モニター中段のSoftwareAudioの先頭8chのみの対応なので、FirefaceMonitorのポテンシャルを使いこなすには役不足である。　

他にSimple MIDI Controlというモードがあって、kymaとのコンビネーションではこちらのモードを推奨する。　各フェーダーに対応するmidi/cc#は以下のとおり。　

上段から、ch02/cc102〜cc117、ch03/cc102〜113、中段が、ch05/cc102〜cc117、ch06/cc102〜cc113、下段が、ch08/cc102〜cc117、ch09/cc102〜113　となっている。

その他、コントローラーへのアサインは、midi/noteNumberを使用する。以下、そのラインアップを列挙しておく。

Monitor Main: 3E / 62 / D 3
Dim: 5D / 93 / A 5
Mono: 2A / 42 / #F 1
Talkback: 5E / 94 / #A 5
Monitor Phones 1: 3F / 63 / #D 3
Monitor Phones 2: 40 / 64 / E 3
Monitor Phones 3: 41 / 65 / F 3
Preset 1: 36 / 54 / #F 2
Preset 2: 37 / 55 / G 2
Preset 3: 38 / 56 / #G 2
Preset 4: 39 / 57 / A 2
Preset 5: 3A / 58 / #A 2
Preset 6: 3B / 59 / B 2
Preset 7: 3C / 60 / C 3
Preset 8: 3D / 61 / #C 3

残念ながら、使用頻度の多そうなSolo/Muteスイッチには対応していない。よって、kyma側でMute/Solo機能を実装する必要がある。



旧モデルのCapybaraとは違って、最新型のPacaranaはオーディオインターフェイスを内装していないため、外付けのハードウエアが必須となっている。

ところが、このハードウエアには「食い合せ」が存在するため、選考には神経質にならざるを得ない。Kymaの特殊性はこのインターフェイスの運用ルールで、通常必要な「端末とPCとの通信」を禁止するところにある。　つまり、AD/DAはPCと切り離された状態、つまりハードウエアとして認識されないことが大前提なのだ。

先述したように、RMEはKyma側のデータ通信プロトコルとの互換性がなく、それ故に、独立したAudioMixerとしての使用が可能だ。PCでコントロールされるDigitalドメインのAudioMixerの利点は、PCのからの音声データを直接卓に送り込めること、つまり、PC上のヘルパーアプリケーションとの連携を行うために複数の回線を確保できる点にある。



ヘルパーアプリ側では、予めトラック毎に出力ソースの要素を分解しておき、それをマルチパスで連携する。Kyma側に送り込みたい音源を並列化することで、ヘルパーアプリが不得手なパン・コントロールを容易に実現できるのだ。

具体例として、今回試験的に採用した音声ルーティンを挙げておく。

PCからFirewire800規格でRME・Fireface800に接続：FirefaceからKyma/CapybaraにFW400規格で接続・CapybaraのAES端子とT.C.KonnektX32を接続（キャノンコネクター8本による）KonnektX32とFireface800をADAT規格（TOSLINK）で接続・　といった布陣となった。　今回、KonnektX32は、PCのデータバスからはフローティングされている。

リンクは、monome/arc4でkymaをコントロールした音声データの記録。Fireface800の導入によって、midiデータでkymaの音源を直接コントロールするだけでなく、MacBook上で稼働するアプリケーションの音声をルーティンすることが可能となった。



Pacaranaを導入する場合、KonnektX32がKymaの直接的な端末となる。Fireface800との結合はADAT規格で行う。他のPCとKyma系の処理を分担する場合、2つ目のADAT端子を使用する予定。 KonnektX32単体には、Midi I/Oが付属しないところに注意すること。Pacaranaの背面にはmidiポートが実装されているので、ここにM-Audio等のUSB/midiインターフェイスを接続するとよい。

作業の過程で、Konnekt48を簡易卓としてCapybaraと組み合わせることを思いついた。



この場合、Konnekt48はkymaからスタンドアロンなデバイスとして使用するので、Mac側に外部機器として認識させる必要があるが、認識に必要なkextファイルの扱いがネックで、Pacaranaとの混用を行う場合には起動時に読み込むkextファイルを変更しなければならない。Terminal駆動用の簡単なマクロを組むとしても、機種を変更する場合は、必ず再起動を要求される。　従って、Capybaraの運用そのものをWindowsに限定して行うことが解決策だと思われる。　　Windows側では、OSの変更が容易なので、OS毎に対応機種を設定しておけば問題は生じないだろう。

米軍のNOSスピーカーをいじっていて思ったこと

何故デジタルアンプに軍用防水スピーカーを採用したのかというと、正直に言って「ネタ」だった。　完全防水構造のアンプって格好良さそうでしょ。





もともと、このスピーカーはAN/GRR5等の野戦用受信機に使用されていたものと思われる。AN/GRR5は水に浮くラジオとしても有名。



スピーカーの仕様は、3インチ径で、コーンはマイカっぽい光沢のある赤いプラスティック製。　コイルはショボそうなのが付いているんだが、マグネットがやたらとデカイ。ユニットは、ゴム製のブッシュを介してパネルに取り付ける防水構造となっている。



音を出し始めた当初は、低音のカットが足りずにユニットから変なビビリ音が発生して往生したが、ラジオの出力のように低域がカットされた音源を再生した場合、意外と了解度の高い音が得られることに気付く。　そのまま数日間エージングを行ってみたが、楽器を繋いでみてもソコソコの音質が確保できていた。

ビックリしたのは、予想外に音の解像度が高く、カーステでの再生では気付かなかった細かい音が聞き取れること。Jazzやテクノ系のソースを聞くと新しい発見がある。



このスピーカーの弱点は、低音を突っ込むと飽和してしまうこと。そもそも、殆ど再生できません、、、というトホホな仕様ではあるものの、守備範囲というか再生目的の「ヴォイスレンジ」に関しての情報量は侮りがたく、音が「聞こえてくる」現象に驚かされることになる。　

必ずしもHiFiとは言えない出音なんだが、なんか説得力があるというのか、音に対して無意識に集中させられる、そんな感じの音色。

今回は、最盛期のアメリカの底力というか、無駄にハイスペックな製品を乱発していた時代の残滓を体感するという、得難い経験をさせてもらえたと思う。

ちなみに、80年代以降の米軍製通信機の音はクソである。国力の低下が「スピーカーの出音」にも如実に現れているといったら良いだろうか。デジタル化以降のそれはことさら酷いんだが、これがライン出力となると途端に状態が改善されるところが不思議といえば不思議だ。　

技術屋にも「譲れない線」っていうのが、存在するのだろうか。

ちなみに、日本製のDSP機の音は「鳴ってりゃいい」ってレベルで聴くと疲れることで有名だったりする。

Capyにトラブルが発生

昨日は、半年以上放置していたCapy系音響システムに久々に火を入れてみるも、頻発するDSP側のクラッシュに悩まされる。



明けた今日昼過ぎ、筐体をバラして内部コネクターの接点のチェック（実は抜き差しするだけ）を行った後、起動にトライしてみた。　当初は問題なさそうな雰囲気だったのだが、1時間余りフリーランさせたところ、熱ダレが原因？のクラッシュが発生。　現在、イニシャライズ後に再起動を行ってテストを継続中だ。



現在、iPad導入の関係で、OSC系コントローラーがいろいろとヤヤコシイことになっているので、ついでにCapy系システムの設定をおさらいしておく。

Capyは旧タイプのDSPユニットなので、OSCサーバーとしての能力は無い。iPadベースのDelora系及びSymbolic純正アプリの直結は行えない。　よって、CapyでOSCを扱う場合は、Osculatorを介在することになる。　

ちなみに、Deloraが発表しているCapybara用接続アプリ　”CapyLink”　は、Pacarana使用時にのみ稼動状態になることに注意。　このアプリはあくまでPacaranaにCapyを接続するためのツールである。

また、システムのより深い理解のために、Capyの物理的な接続環境を、ついでに整理しておく。

手持ちのCapyはFirewireInterfaceを内蔵させる改造を行ってあるので、Capy本体にFWを直結しできる。FWはここからRMEのAD/DAユニット、Firefaceにチェインしてある。　FirefaceはMacbook側でコンフィグ設定及び、ヴァーチャル卓によるルーティンアサインメントを行っている。　RME系オーディオインターフェイスはFWを採用しているものの、特殊な通信プロトコルを使用しているために、Pacaranaとは直結できない。従って、デジタルデータの翻訳を行うために T.C.Electronic の digitalkonnekt x32 を介してデータのやり取りを行っている。Fireface との間は、ADATプロトコルのトスリンクでチェインしている。

一方、Capyの方は、AES規格のデジタルアウトを選択、これを digitalkonnekt x32 のAES・I/Oに接続している。　マスタークロックは、Capy側のInternalで、これを digitalkonnekt x32 側で受けたものを、Firefaceに流している。　本来はクロックソースが優秀なFirefaceを親機とすべきなんだろうが、何故かロックが安定せず、実験の結果、比較的安定度が高いこの方式の採用となった。

OSCのチェインに話題を戻す。　OSCはOsculatorをサーバーとしてデータストリームをまとめている。サブ機能として物理MIDI系との信号のやりとりが必要になることがあるので、ヘルバーアプリケーション、MidiPatchBayを同時に使用して、FirefaceのMIDI端子をデータストリームに組み込んである。これは、キーボードなどのレガシー系コントローラーの使用を目的としている。　　

TCP/IP系のコントローラーLemurの同時展開も可能だが、こちらは、Pacarana系ハードウエアシステムに組み込んでしまったので、今回は接続実験を割愛した。

Osculatorでは、iPadのOSCアプリ毎に設定ファイルを製作しておくと、混乱が少なく便利だろう。OSC系アプリの中では、TouchOSCが比較的安定していて、使い勝手が良さそうなので、このアプリベースで専用インターフェイスの製作を考えたほうが良いだろう。

箱はチューンが難しい

アコースティック・ギターとかヴァイオリン等の箱楽器は繊細に設計されていて、箱の構造イコール楽器の歴史みたいなところがある。　

で、同じ箱物でも数段格落ちのプリミティヴな楽器「親指ピアノ」でも気になりだしたら予想外に大変なことになってしまった。

最初に気になるのは、パーツのビビリ。特にエレキ系の基板が悪さをする。これを防止するには、、、

１）基板のサイズを小さくして
２）マウント方法を、共振を抑えた方法に、例えばゴム部品を介して行う

という、大雑把には２種類のアプローチがある。　自分が、電気的な音質がイマイチしょぼい表面実装パーツを多用する理由は、基板のマスを極力小さくすることが目的なのだ。

次に気になってくるファクターは配線材の共振と干渉。これは出来るだけ細かい配線材を使ったり、逆に極太の線を使ったりと、カットA&トライを行って最適値を探りだしていく。

特に、ピックアップの感度に直接影響する「センサーからの引出線」には、極力細い材を使わないと、これの振動がモロに音質に影響してしまう。また、取り回すラインを間違うと、線材自体がピックアップに変身してしまうので、配線にも最新の注意を払わされる。

そして、重要なのが箱自体の構造だ。楽器を作り始めて最初に意外に感じたのは、バックがオープンの状態でパーツを配置し、裏板を取り付けて箱が閉じた瞬間に楽器の音質が変わることだった。　

後に、いろいろと試行錯誤をした結果、リジッドな形で箱を形成してしまうと、振動が箱全体に食われてしまうことが判明する。　特に、比重の高い材を使った場合や、箱の強度が高かったりすると、楽器の鳴りが悪くなる傾向が顕著となる。

その解決方法だが、まずは箱のような形のレンガを想像してみて欲しい。レンガに振動体をくっつけて鳴らしてみても、振動体の共振はレンガのマスに食われてしまって、リッチな音にはならない。これが、レンガと同じサイズの「箱」の場合は、箱の容積に見合った周波数が強調されて、リッチな音が出力される。　ところが、箱の共振が強過ぎる場合、ある特定の周波数が強調されてしまったり、逆に振動を食い合う「デッドポイン」トが正じることで、楽器として必要なフラットな音響特性を得ることが難しくなってくる。

今回のようにアルミ製の箱を選んだ場合は後者の現象が強くなる一方、前回作った分厚い材を使ったセミリジッド構造の場合、前者のようにボディーがレンガ化してしまう危険性が生じる傾向にある。

何れの場合も解決法は意外と単純で、機械的に裏蓋を浮かせつつ、空気的には密閉するという手法が有効だった。　つまり、裏板をゴムなどの緩衝材を使って振動からフローティングさせることで、音響的な妥協が行えるのだ。

まあ、音質を突き詰めていくと、コレ以外にも「ブリッジのマウント方法」や「接着方法」、「ボディーの材質」、「ピックアップの取り付け方」、、、などなど、いろんなファクターが絡んでくるので、楽器の製作は難しいのでした。

The Very Fast Live Performance

古い記録ですが、2000年にIAMASの卒業制作で演奏したAudioHologramの記念すべき第一回公演です。

画面左に見える不気味な頭はダミーヘッドマイクです。ヘッドフォンで聞くと360度音が回って聞こえます。

左肘の大怪我上がりなので、演奏はイマイチですが、やる気だけは十分ですね。

当時、卒業制作のインスピレーションで作ったシステムなので、怪談スイッチはその構想さえ存在しておりませんでした。

PAに使ったd&bのクリアなサウンドは一生忘れることがないでしょう。

Mbiraski/WoodBody

今回は、手の小さな人向けに、筐体の厚みを薄く、角に大きなRを付けたデザインを採用。



AnalogDevices製MEMsセンサー、ADMP404を使用している。



振動ピックアップ用のセンサーは、ブリッジ直下に取り付けられたL型金具にセットする。



仮組みした函と、格納用のソフトケース。



アウトプットは、Hirose/6pinとヘッドフォン端子。　左側の充電端子には、専用ケーブルを使ってUSB端子から5Vを入力する。



中央の目玉スイッチには、LEDが封入してある。

MbiraskiTest02.aif

ライン録音したAIFFファイル。



YouTube版はこちら。

目玉スイッチの製作

小型の表面実装白色LEDを目玉スイッチに組み込んでみた。　ベースとなるプッシュ・スイッチは、基板実装タイプのもの。これを楽器の中心に設置する。



ピンぼけだけど、こんなふうに光ります。



暗闇の中ではこんな感じ。実物は電球色に近い雰囲気。



目玉とスイッチとの接着には、強度を増すための補強材として、4ミリ程の長さに切った自転車のスポークを使っている。　

MbiraskiMilitaria