Vienna, Viena, サウンドフォント編集, 及び作成

Vienna ヴィエナ (ドイツ語:Wien ウィーン) 音楽好きなら、誰もがこの言葉にある種の想いがあるのではないでしょうか？
ピアノ好きならベーゼンドルファー(Bosendorfer)のウィンナートーンは有名ですし、googleの検索エンジンにウィーンと入れれば、ウィーン少年合唱団が入力候補に挙がります。DTMの分野なら、Vienna Symphonic Libraryが開発しているオーケストラ音源やピアノ音源がよく知られているはずです。

またロック好きの人は、以下の詩が思い浮かぶかもしれません。

LITTLE VIENNESE WALTZ

In Vienna there are ten little girls,

a shoulder for death to cry on,

and a forest of dried pigeons.

...

Poeta en Nueva York(1929-1930)  より

Federico Garcia Lorca

Translator: Greg Simon & Steven F.White

もう少し気に入っている部分を抜粋させてもらうと、

There is a death for piano

that paints the little boys blue

...

seeing sheep and irises of snow

through the dark silence of your forehead. 

前置きが長くなってしまいましたが、midif0nには、音を作成するどころか、音色を調整する機能もありません。これを行いたい場合、サウンドフォントファイル自体を編集することになります。編集用の有名なソフトウェアには、以下のようなものがあります。

Windows

• Vienna SoundFont Studio (version 2.4 2006/5/29) ※Creative Sound Blasterが必要

• Viena  (version 0.8 2010/9/10) ※ベータバージョン、寄付ウェア？

Linux (マルチプラットフォーム想定?)

• Swami  (version 2.0 2010/10/25)　フリーソフト

ここで、ViennaとVienaが出てくる訳ですが、僕の開発環境は当然macなので、Swamiを使えるのがベストです。しかし、現在のところ、動作させるに至っていません。そんな訳で、Vienaをメインで使用しています。この名前はどこかしっくり来ないもので、Web上でもVienaは、Viennaと間違えないようにと、度々注意書きを見かけます。ついでにmidif0nは、midi-f-zero-nなので間違えないようにして下さい(読み方は自由でいいけど...)。

さて、そのVienaですが、基本的にサウンドフォントのデータ一覧が可読性の高い形で表示されるので、パラメーターの意味さえ理解していれば、編集は難しくありません。しかし、ベータバージョンであるせいか、プレビュー時に反映されないパラメーターがあるので注意が必要です。実際、Initial Attenuation（音量の減衰）の値を変更してもプレビュー再生に反映されませんでした。ついでに書いておくと、Attenuation(減衰)と書かれていると、正と負どちらの数を指定すべきかわかりにくいため、入力制限が欲しいところです。

兎に角、これで音の調整は簡単にできると思います。ところで、サウンドフォントの作成自体は難しいのでしょうか？これは、ケエスによると思います。調律が正確ではないアップライトピアノからマイクでサンプリングするのは大変な作業になるでしょうし、コンバートソフトウェアを用いてディジタルシンセサイザーからサンプリングする場合はそれほど難しくないでしょう。後者の場合は、特にノンループであれば、複数のサンプルとキーの割り当てを設定し、音量エンヴェロープのリリース時間の調整ぐらいで済むでしょう。実際に、あるグランドピアノのサウンドフォントのデータを見たところ、リリース時間の指定しかないものもありました。リリース時間だけは、Note Offを通して、音を消音に向かわせるために必須になるのでしょう。
※midif0nでノンループ波形を使用する場合、使用メモリに注意して下さい。

僕自身、音源のコンバートはしたことがありませんが、もし機会があれば、手順を含めて報告したいと思います。ちなみに手元にある音源で、最もコンバートしておきたいのは、KurzweilのK1000のピアノの音です(本当は、Kurzweilのソフトシンセが欲しいのだが、メーカーにはあまり期待できそうにない) 。ちなみに、Kurzweilのピアノサウンドのデザイナーは、現在、SynthogyのIvoryを手がけている人だそうです。

最後にもう一度まとめると、midif0nには音のシンセサイズ(作成、編集)機能はありません。これを行いたい場合、PC上で各種ソフトウェアを使用する必要があります。

ところで、ロルカの詩の元のバージョンは、スペイン語のはずなので、これを探してみたところ、英語のViennaがVienaの表記になっているのに気が付きました。Vienaのソフト開発者がスペイン語からとったのかどうかは知りませんが、個人的にしっくりと来た瞬間でした。

En Viena hay diez muchachas,

...

midif0n MIDIシーケンサーの実装コンセプト

さて、midif0nの実装コンセプトについて、書いておきます。
バージョンアップにおける追加機能は、基本的にこのコンセプトから外れない範囲になると思います。

まず実装に限らずに言えば、基本的なコンセプトは、手軽に使用できる携帯用のMIDIシーケンサーです。編集機能は基本的にメモ、あるいは作曲のスケッチを想定して最低限の機能になっています。それ故に、初心者に取っ付きやすくしたいと考えています。
※MIDIとサウンドフォントというオープンフォーマット採用により、敷居が上がってしまうのは確かですが、なるべくパラメータは意識させないようにします。
逆に再生機能に関しては、複雑性に影響を与えないため、ある程度MIDIファイルを忠実に再生できるようにします。

もう少し、編集機能に関して詳しく述べます。音源の話同様、編集機能に関してもピアノをメインに想定しています。アレンジに関わらず、名曲はピアノのみで聞いても名曲に違いないでしょう。ピアノは奏者がコントロールできる範囲が比較的狭い楽器です。MIDI仕様に従う範囲では、ノートオン、オフとそれに付随するベロシティ、加えてペダルの操作になります。ダンパー、ソステヌートペダルは、音源側の処理の実装上ノートオフを遅延させるだけの場合もあり、その場合は、ノートオフの設定で置き換えが可能と言う事になります。ソフトペダルは実際のところは、音色にも影響しますが、主な変化を音量と捉えれば、これもベロシティの変化である程度の置き換えが可能でしょう。つまりMIDIにおいて、ピアノの演奏の表現力は、ノートオン、オフのタイミングとベロシティの大きさが主な要素になります。このことを重視して、midif0nでは、ノートオン、オフとベロシティの編集に特化することにします。

次に再生に関して詳しく書きます。結論から書いてしまうと、GMの仕様上、パラメーターがどのように作用するか明確にかわかっているものはサポートし、そうでないものはサポートしていません。元々制作者が意図するMIDIデータの再現性は、音源により少なからず影響を受けるという事実があります。そのため、仕様が不明確なデータは、再現性を重視する場合には、重視されないものと推測されます。例えば、CC7ボリュームやCC10パンのパラメータは、GM2の仕様書に以下のような推奨式が載っています。

cc7(ボリューム)

Gain[dB] = 40log10(cc7/127)

cc10(パン)

GM2_Japanese.pdfより

L Gain[dB] = 20log10(cos(PAI/2*max(0, cc10-1)/126))

R Gain[dB] = 20log10(sin(PAI/2*max(0, cc10-1)/126))

これに対し、CC5ポルタメントタイムは、推奨例のグラフはありますが、具体的な式は存在しません。

GM2_Japanese.pdfより

さらにcc72リリースタイム、cc73アタックタイムのように基準値と値の増減の意味だけが記述されているようなデータも多くあります。まあ、ポルタメントタイムはグラフからだいたいの式は導けますが、他のパラメータは実装しても音源依存ということになってしまいます。そうでなくても、他のソフトウェアが推奨式に従っている保証はありません。この点を踏まえ、実装するパラメータ、実装しないパラメータを切り分けています。

音源依存という問題を考える時、最もポピュラーな音源に合わせるという方法があるかもしれません。つまり、DTMの代表的な音源として、RolandのSC-88Proが挙げられると思いますが、これを基準にするという考えです。しかし、これについてもCCに対する実装部分は仕様が公開されていないので、確認作業は大変なことになりそうです。

以下、余談ですが、panの推奨式のmax(0, cc10-1)/126の部分が引っかかりますよね。panは、cc10の値64をcenterとし、0をLチャンネルのみ, 127をRチャンネルのみとするわけですが、2進数において分解能が左右非対称になります。そこで、1もLチャンネルのみとする訳です。高速化には向かないのが悩ましいですけど。ちなみにサウンドフォントのパンの仕様は、sin, cosを使わずに単純な線形補完です(一般的には、sin, cosの方が望ましいとされる)。これもMIDIと仕様が違っていてしっくり来ませんね。MIDIとこのような中央値を含む値の扱いは、各社でいろいろとおもしろい記述が見つけられます。

例えば、RolandのSC-88Proはマニュアルによると、以下の記述が見られます。

PAN(パン) Rnd, L63-0-R63

SC-88Pro_j9.pdfより

また、Nordleadで有名なClaviaの、Nord Modularの情報ページには、以下の記述が見つけられます。

Relation between knob positions and units

 (前略)Note that some knobs that control a value between –64 and 64 miss the value of 63. (中略) Clavia chose to simply skip the 63 value and use 64 in it’s place.

http://www.clavia.se/nordmodular/Modularzone/LogicIntro.htmlより

[-64, 64]の範囲に納めるために、63はスキップするそうです。どれも何かがしっくり来ませんが、中央と両端の値を正しく解釈するのであれば、こうなるのでしょう。

最後にmidif0nの実装コンセプト情報をまとめると、以下のようになります。
　編集機能：ノートオン、オフ、ベロシティがメイン
　再生機能：GMの仕様書で、明確なパラメータのみをサポート

※ちなみに、GM2のRPNのModulation Depth Rangeは値の意味が明確なので、midif0nで、密かにサポートしています。

音源の話、もしCoreMIDIが最初から用意されていたら？

サウンドフォントの記事を書いたので、話が前後してしまいますが、音源の話をする旨を書いてしまったので、それに関して書きます。

midif0n開発の目的は、MIDIシーケンサーのプログラミングです。なので、音源にはなるべく手間をかけたくありませんでした。只でさえ、iPhoneのUIライブラリや、ARMアーキテクチャ、プログラミング言語Objective-C、デザイン(Script-Fu含む)など、ほとんど触れたことがない（あるいは忘れている）事柄を多数扱わなければならないことはわかっていました。そんな訳で、iPhoneにMIDI音源が内蔵されていれば、それを鳴らすだけだったでしょう。

しかし、現実は、そうではありませんでした。Appleは、音楽制作ソフトウェア(GarageBandやLogic)に力を入れているので、あっても不思議はないのですが...。

さて、音源をどうするか？GMになるべく対応させたかったので、いろいろな音色が欲しいのは確かです。しかし、１つに絞った場合、王道ですが、ピアノが一番欲しい音源でした。ポピュラーな音源方式は、加算合成, FM(Frequency Modulation), サンプリング音源, VA(Virtual Analog), 物理モデリングなどがあります。この中で、ピアノに比較的向いているのは、FM, サンプリング音源、物理モデリングでしょうか？物理モデリングに関しては、面白そうなのですが、僕の知識が追いついていないのと、パフォーマンスが高そうなのであらかじめ選択肢から外しました。
FMに関しては、広義の意味でのピアノと捉えれば、エレピは有名ですし、悪くない選択肢です。しかしエディット不可能なシンセサイザーを作る場合、プリセット音色を用意しなければいけません。僕は、FMの音作りをあまりして来なかったので、これはある意味難作業です。次にサンプリング音源ですが、著作権の話でもしたように、基本的に自前でのサンプリングは考えていませんでした。またこの方法ですと、品質を追求する場合、確かな耳が必要になるので、自分には向かないと思いました。ですが、この方式を取る場合、外から持ってくることが可能です。世間一般的には、WAVが有名ですが、この場合、音域、容量が厳しくなるのは目に見えていました。そんな訳で、消去法的にサウンドフォントに行き着きました。

さて、サウンドフォントを用いた場合、パフォーマンスに問題はないのか不安でした。しかし、最低ラインをフィルター、エフェクター、モジュレーターを適用せずに、ただサンプリング音源をループ再生(音量エンヴェロープを用いて)することと定めていたため、あまり気にしていませんでした。(そして、結局エフェクターが外されました。)ただ、フィルターに関しては、ある時点でピアノに適用したところ、欠かせないものになってしまいました。これはサンプルにもよると思いますが、使用していたSYNTHGMS.SF2の場合、フィルターがあってこそピアノは、グランドピアノと呼ぶことができる、そんな風に感じました。

さて、そんな感じで開発も終盤になって、ほとんどテストをしていたところ、かなりショックを受けるニュースが。それは、AppleがiOS4.2 SDKで、CoreMIDIをサポートするというニュース。もしかすると音源すら用意しなくても良かったのでは？とか思ってしまいました。実際は、音源のサポート自体はなかったみたいですが、公式に外部音源を鳴らすという手段が取れるわけです。もしSDKにCoreMIDIが初めから含まれいたら、きっと僕は外部音源を鳴らすMIDIシーケンサーを作っていたでしょう。

そんな訳で、Appleに言いたいのは、あまりSDKを頻繁に変更しないで欲しいということ。ましてやCoreMIDIはOSXには普通にある訳で、今更サポートされるとは...。(Line6のMIDI mobilizerに影響されたのかな？)

midif0nスクリーンショット集

midif0n version 1.0のスクリーンショットを載せておきます。
※他、MIDIやサウンドフォントの読み込み画面がありますが、だいたい似たような感じです。UIの変更は納得できるまで、頻繁に行う予定です。それ故に、説明書は詳細を省いている所もあります。もし、詳しく説明してほしい箇所がありましたら、お知らせ下さい。

タイトル

メイン画面

五線譜ライク(like)

上から　システム画面

ノート選択画面

インターフェース表示(ドラムパッドもあるよ)

ベロシティはVer1.0では、グラフ編集

編集画面

Amp情報(編集不可)

16トラック詰め込みました

こちらは4トラック表示

ボリュームは縦にするべきか？

プリセット表示　SYNTHGMS.SF2のはず

ドラムパッド割り当て

MIDIファイルから自動で割り当てることもできます

メトロノームは、MIDIノートを送る方式

メモリ問題のため、自作UIへ変更予定

何回かのエントリでメモリのことを書きましたが、正式に問題点を書いておきます。

まず前提として、僕の開発環境(iPod touch 2G)では、iOS4を入れて、空きメモリ20-30MBに状況によくなります。次にアプリの使用メモリを調べたのですが（状況によって変わってきますが）、だいたい以下のようになります。

 アプリ13MB + 展開したMIDI 1-6MB + Soundfont 8MB(推奨音源の最大値) = 22-27MB

推奨メモリ 24MB超えています。MIDIも展開して効率重視でデータを持っているので、200KB越えのデータになると、結構膨らんできます。この部分は減らせるかもしれませんが、今は考えないことにします。兎に角、今後の拡張することを考えると、これ以上メモリを使用することはできません。

ここで問題にするのは、最初の13MBです。このうち4MBぐらいが、アプリ起動時から増えていきます。これは、サイドメニューのUIを開いたときに起こります。この部分は応答性を向上させるために、メモリに常駐させているからです。では、UIのどこにメモリを使っているのでしょうか？
結論から言ってしまえば、midif0nのメモリ消費量を不相応に増大させているのは画像ファイルです。もっと言ってしまえば、ボタン(UIButtonクラス)の状態ごとの画像データです。
iPhoneのUIを作成するIB(Interface Builder)というツールがありますが、画像を貼付けたボタンを作成する場合、この画像は、内部的に32bitのフルカラー画像として扱われます。
※公式ドキュメント等を調べたわけではありません。メモリの増減を測定した結果です。

※編集画面です。開発中の画面なので、デバッグ文字列が表示されています。

では、上の画面あたり、どのぐらいメモリを使用しているか具体的に計算してみましょう。まずボタンには４つの状態があります。通常、ハイライト、選択状態、無効の４つの状態です。しかし、ハイライトと選択状態は同じ画像を割り当てていますので、データとしては3つ分です。UI設計は、操作の快適性のため、大きめのボタン(64x64)を採用しています。

縦5列、横4行、サイズ64x64のボタンが3つの状態を持ち、32bit(4 bytes)カラーなので
5x4x64x64x3x4=960KB
だいたい1MBです。この画面が複数あるわけですから、かなりのメモリを使用することになります。

対応方法として、IBを使わずに画像の内部フォーマットを変更できるかもしれませんが、とりあえずこの問題を置いて、もう一つの問題を見てみます。それは、UI変更のリアルタイム性です。これは多くのアプリでは問題になりませんが、音楽アプリにおいては、高負荷の処理中に、リアルタイムで何らかのデータをユーザーにフィードバックさせることは良くあります。実際に開発中に、ミキサー画面のVolume, Pan変更をタイマーを用いてリアルタイムに変更してみました。結果は、負荷が高い場合に、UI更新時に音とびが発生して使い物になりませんでした。

結論として、Cocoa TouchのUIクラスはメモリとパフォーマンスを考慮とすると必ずしも優れた設計になっているとは言えません。
有名な音楽制作アプリのNanoStudioは、この点を考慮して、自作UIを採用している訳ですね。ここで、UI自作のメリットをまとめてみます。

• 高速化（パフォーマンスが見積もりやすくなる）
• 省メモリ
• 可搬性の向上（移植性が高くなる）

車輪の再発明をする前に、まず他に使用できそうなライブラリがないか調べる必要があります。検索すると、Clutterの名前がかなりひっかかります。Clutterは、OpenGL/OpenGL ESを用いたUIライブラリです。インテルやノキアのMee GoやGoogleのChromium OSといった大きなプロジェクトで採用されていることから、信頼性は高いと考えて良さそうです。問題はライセンスがLGPLな点、また調べている限りでは、iPhoneのサポートがどうなっているか不明だったため、早々に調査は打ち切りました。

現状では、ビュー(UIView)、ラベル(UILabel)、ボタン(UIButton)、スライダー(UISlider)程度を実装すれば足りるため、ライブラリは使わずに自前で書くことにしました。そんな訳で、バージョン1.1では、メイン画面に重なるUIを全面的に書き換える予定です。デザイン的に多少、劣化するかもしれませんが、ご承知お願いします。

マスターキーボード

Version1.1に向けて、実装をしていますが、8割ぐらいは終わりました。ただ、ユーザーインターフェースを自作クラスに変更する大規模な作業が入っているので、テストはある程度かかりそうです。

midif0nは、12/3にリリースしました。この日は、任天堂DSソフトのKORGのM01の発売日でしたが、他にも気になる楽器の発売日であったことを知りました。
KAWAIのマスターキーボードMP10です。



僕は、ここ数年ピアノタッチの良い鍵盤を探しています(当然MIDI接続可のもの)。緊急性はないので、じっくり検討しています。
余計な機能がないという意味では、海外のSTUDIO LOGICのNUMA NEROなんて魅力的ですが、触ってしまうと、国産の最新機種のものにくらべるとイマイチに感じました。
※タッチの好みは結局人それぞれだと思うので、あくまで個人的にです。

YAMAHAもRolandもタッチには凝っていて、次々に新鍵盤を出してくるので、各社かなりレベルが高いと思うのですが、個人的にはKAWAIが気に入りました。でも使用用途を考慮すると、持ち運びはしないので、電子ピアノで十分じゃないかとも思ってしまうわけです。
そう考えると、KAWAI のCA13も選択肢に入ってきます。



この価格帯で、木製鍵盤、さらにMIDIもついているので、DTM用にはマスターキーボードの代用になると思います。一つ残念なのは、どうせならUSB-MIDIもつけて欲しかったという点。どうしても伝送速度の差と接続の容易性を考えてしまいます。まあ予算とスペースという大きな問題があるので、なかなかすんなりとは決まりませんが...。

これからは、iPhoneや他のスマートフォンと電子ピアノ、ハードウェアシンセサイザーを接続するのは、割と一般的になるかもしれません。この手の商品では、Appleは言うに及ばず、line6のMIDI MobilizerとiConnectivityのiConnectMIDIが気になります。僕の場合は、これらの機器が開発で必要になってくるかもしれません。



MIDI Mobilizerは通常のMIDIインターフェースと比べると高額ですね。

セール期間、通常価格に関して

本当はある程度、意見を貰ってから決めるつもりでしたが、いつまでもセール期間を明言しないのも、良くないので書いておきます。

セール価格は、12/3-1/2でちょうど一ヶ月間とします。
この期間の後、通常価格の1800円となります。

価格に関しては、Nano Studioを上回るとはおこがましいなぁという思いもあるのですが、あまり周りを気にしても仕方がないし（税率も違うし）、比較はあまり意味はないでしょう。1800円は、Tier16の価格帯です。16トラックとかけて、プログラマー的に区切りが良いからと、そんな理由です。
※Nano Studioを挙げましたが、正直アプリのコンセプトは違うので、その点での比較は意味がないと思うのです。これは単にプログラマー的に年期と実力が明らかに違うという意味です。兎に角、僕はこの方面に関しては、ひょっこですから。（いや、どの方面でもか？）

また、アプリ内課金、広告での収入は、僕自身それらの仕組みが好きではないこともあり、考えていません。さらにApp Storeのアプリは、バージョンアップ無料が一般的ですので、基本的に最初に購入する分だけの負担となります。そんな訳で、あまり安売りしたくないと考えています。

今、現在価格に見合うだけの価値がないと思う方がいるかもしれませんが、今後のアップデートで補いたいと考えています。また今後、価格に関しては多小の上下は、あるかもしれませんが、大幅には変えないと思います。機能に見合ったを価格を大切にするつもりです。