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のアプリは、バージョンアップ無料が一般的ですので、基本的に最初に購入する分だけの負担となります。そんな訳で、あまり安売りしたくないと考えています。

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

OpenSL ES

当blogは基本的にHimawari Studio開発アプリに関わる部分の情報を扱いますが、開発日記のような側面もあります。開発者として、かなり気になるニュースがありましたので、今回はこれを取り上げます。

話題は、GoogleのAndroid 2.3 "Gingerbread"です。オーディオAPIが低レイテンシになるという話はすでに聞いていたのですが、改めてチェックしたところNDK にOpenSL ESが追加されるそうです。

Audio APIs based on the OpenSL ES standard that support playback and recording as well as control over platform audio effects

 http://developer.android.com/sdk/ndk/index.htmlより

OpenSL ESは、Khronos Groupが標準化を勧めるオーディオライブラリです。MIDI, 再生、録音、エフェクト, 3D等、オーディオに必要なものはほとんどカバーするAPIです。
しかし、現在のところMIDIに関しては実装されていないみたいです。
android-ndk-r5/docs/opensles/index.htmlの記述から判断

Java, OpenSLと続けてMIDIのサポートを外しているのは何か理由があるのか気になるところですが、今後の対応に要注目です。どちらにしろ、これを機に、Androidの音楽アプリが盛り上がることになるのは間違いありません。もちろんAppleサイドもCoreMIDIのサポート等ありましたが、こちらはAPIが分野ごとに独立している印象があります。また、今後の標準化を考慮するとちょっと弱い印象があります。(でも、現状からOpenSL ESをサポートというのもね...、僕は支持しますが。)

そして、ふと、OpenAL(iPhoneもサポートしている3次元のオーディオライブラリ)って、今どこが管理していたっけ？と思い、調べてみたら、Creative Technologyのページに...。
(SoundFont絡みで良く来ていました。)

ちなみにmidif0nは一番低レベルのAudio Unitのみ使っています。

サポートするデバイス, iOSに関して

12/6付で初めて１本の売り上げがありました。買ってくれた人、ありがとうございます。midif0nの開発、動作テストは、iPod touch 2Gで行われていますので、特に初代を使われている方は、動作報告を頂けると嬉しいです。（本当は、開発者が初代でテストをするのが筋ですが、このあたりの事情は察して頂けるとありがたいです。）

さて、midif0nの動作対象デバイスは、一応すべてのiPhone/iPod touchが対象になっています。ただし、サポートするiOSのバージョンは3.1.3になっています。これはあまり深い意味はなくて、マイナーバージョンは安定版であれば、基本的に上げておくのが良いとの考えからです。

第１世代を使っている方に注意しておくと、テスト環境のiPod Touch 2GはCPU 533MHzですので、初代iPhone(CPU 412MHz iPod touchの場合、400MHzもあり)では、音切れ等の問題が起こりやすい可能性があります。これに対する簡単な対応策が、同時発音数のオプションを細かく入れておくことですが、現状は入っていません。あまり、細かくするとユーザーが何を選ぶべきかわからなくなる可能性もあるので、そのあたりも考慮したいと考えています。

また、特定の機種向けの最適化ですが、当面考えていません。第３世代以降は、NEON(SIMD)が使えますので、使えばかなりパフォーマンスが引き出せそうです。（理論値では４倍。サウンドプログラミングは並列化がしやすいので、かなり改善できると思います。）まあ、これをしない理由は、単純に僕が実機を持っていないということもありますが、他に優先して実装すべきことが多いからです。

サウンドフォント、著作権、推奨音源に関して

※長文です。
midif0nは、サウンドフォント対応ですが、音源を内蔵しておりません。配布可能な条件とメモリを考慮すると、適切なものがないからです。
ちなみにサイン波に関しては、初期状態で何も音が出ないと困るので、実装しています。

まずサウンドフォントですが、詳しくはwikipediaを参照して下さい。
簡単に言ってしまうと、E-mu Systems, Inc.が作ったオープンな音源フォーマットで、現在は、Creative Technology, Ltd.が権利を持っています。音源フォーマットの具体的な中身は、サンプリングデータと各種パラメータから成る楽器データのセットです。このファイルを対応するシンセサイザが扱うことで様々な音色を発生させることができます。midif0nがサポートするファイルの拡張子は.sf2で、これは、サウンドフォントのバージョン2.xを意味します。

まず音の著作権はどうなっているかというと、これが何とも曖昧です。ましてや国ごとの法律やその変更を考慮すると単純な基準を示すのは難しそうです。サンプリングに関しては駄目な範囲がいろいろと言われていますが、予断はよくないので、著作権の主旨に戻ろうと思います。とはいえ、僕は法律の専門家ではないので、ごく簡単な言葉でしかこれを言い表せません。


著作権とは、著作者の著作物を保護するものです。ここでは、人が苦労して作ったものをコピーしたり、アレンジしたりできないようにしていると解釈します。仮に楽器の音に著作権があるとすれば、コピーの安易さは違くても、電子、電気、アコースティックに関わらず適用できそうな気がします。


ここで明確にしておかなければいけないのは、楽曲に使用する音と楽器を作成する時に使用する音では、その扱いが違うということです。つまり、楽器は演奏するためにあるので、楽曲を作る分には、著作物のコピー、改変にはならないということです。（インタラクティブメディアのSEの扱いとか、よくわかりませんが。）しかし楽器を作成する側は違います。そのため、僕としては、楽器ソフトウェアを作成するにあたり、サンプリング音源を内蔵するつもりはありません。プログラムによる生成が一番良いでしょう。あとは単純にWAVやSF２等のフォーマットのみのサポートに停めます。


サンプリング問題がどうであろうと、企業から問題とされるようなサウンドフォントを使用することは、気分的にあまり良いものではありません。ただ、一方でオープンフォーマットはユーザーが音源を細かに調整できる優れた利点を持ちます。また、著作権がどうであろうと、ユーザーが購入した音源をコンバートしたり、自分でサンプリングした音源を楽曲に使用することは何ら問題にならないはずです。

結局、サウンドフォントというフォーマットをどのように扱うかは、ユーザー自身の手に委ねられていると言って良いでしょう。しかし、あるサウンドフォントがあり、その音の元のソースを確認するのはどうすれば良いでしょうか？音のソースが明確になっているものは稀です。場合によっては、プリセットやサンプルについている名称がヒントになるかもしれません。

結局、この問題を完全に回避したい場合、疑わしきは使わないと言うことになると思います。つまり、個人が作成したものは、ソースを明らかにしていない限り、選択肢として除外するということです。企業なら、100%大丈夫だとは思いませんが、それを言ってしまうと、既存のハードウェア音源も同程度の著作権問題が存在することになります。結果的に、信頼性のある企業が作ったものであれば、それを信頼しましょう。あらかじめ企業間でライセンスの問題が解決されている場合もあるかもしれません。（僕は、楽器、オーディオ業界と一切縁がないため、はっきりしたことはわかりません。）


さて、最後に推奨音源を載せておきます。ライセンス的に商用に使えるかどうかは確認していませんが、私的に使う場合は問題ないでしょう。そもそも、midif0nにオーディオコンバートの機能がないのは、そのためでもあります。

まあ、著作権以前の問題として、メモリが少ないiPhone/iPod Touchの環境下では、大きなサイズのサウンドフォントは使用に適しません。僕は、iPod Touch 2Gでテストを行っていますが、空きメモリが20-30MBの状況はざらです。これにmidif0nは、16MBぐらいはメモリを常駐させるので、メモリがいかに厳しいかは、明らかだと思います。

（アプリがメモリを取り過ぎだよと言われると、それは厳しく受け止めておきます。現在、修正を試みています。）

Creative Technology社の開発者向けページから

"SYMTHGMS.SF2" 1.1MB

"GMGSMT2M.SF2" 2.1MB
http://connect.creativelabs.com/developer/SoundFont/Forms/AllItems.aspx
表の一番上のenablerのリンクから、enabler.zipがダウンロード可能。
解凍すると、DATAの中に入っています。


Digital Sound Factory社から
"8mb General MIDI.SF2" 7.6MB
http://www.digitalsoundfactory.com/dsf_examples.php
SOUNDFONTの欄の３つめのリンク　※ダウンロードには登録が必要

Digital Sound Factory社は、E-muやEnsoniqのサウンドデザイナーが関わっているみたいです。結局のところ、すべての推奨音源は、本家のE-mu関係になってしまいました。でも、メモリ、パフォーマンス、著作権を合わせて考えると、iPhone/iPod Touchで鳴らすには、理想的なサウンドフォントと言えます。また素人目にも、パラメータは細かく調整されていると思います。

尚、同様の観点から、お勧めの音源がありましたら、お知らせ頂ければ幸いです。ちなみにmidif0nの通常のテストは、ほとんどSYNTHGMS.SF2で行われています。開発において、トライ＆エラーが早くなりますから、当然と言えば、当然ですが。


それでは、長文読んで頂き、ありがとうございました。

MIDIとSF2の対応状況

※2011/4/28追記
バージョン1.4において、MIDIインプリメンテーションチャートを修正しました。詳細はこちら。

MIDIインプリメンテーションチャート(正式な形式ではありませんが...)を載せておきます。現状では、外部ハードウェアには対応していません。あくまで、MIDIファイルに関する対応表になります。コントロールチェンジ(CC)の14ビット値は、実装として盛り込んでありますが、確認用のデータを出力できるソフトがわからなかったため、動作確認はしておりません。

	編集	再生	表示
Note Number	0-127	0-127	0-127
Velocity Note On	o	o	o
Note Off	x	x	x
After Touch	x	x	x
Pitch Bend	x	o	o (pitch)
Control Change
0, 32	o (1)	o	o (pitch)	Bank Select
1, 33	x	o	o	Modulation
7, 39	o (1)	o	o (amp)	Volume
10, 42	o (1)	o	o (amp)	Pan-pot
11, 43	x	o	o (amp)	Expression
64	x	o	o (pedal)	Hold
66	x	x	o (pedal)	Soft
67	x	x	o (pedal)	Sostenuto
100, 101	x	o	x	RPN
120	x	o	x	All Sound Off
121	x	o	x	Reset All
123	x	o	x	Controller All Note Off
Program Change	o (1)	o	o
Exclusive Master Volume	x	o	o (amp)

※AfterTouchの情報は読み込み時に破棄されます。
※(1): トラックにつき、１イベントに固定(編集時)

Soundfontは、バージョン2.0対応で、エフェクト以外は対応しています。バージョンの違いは、仕様書によると2.1でMIDIコントローラー対応、2.4で24ビットのサンプルに対応だそうです。当然、このどちらにも対応しておりません。またバージョン2.2, 2.3は存在しないそうです。

※仕様書では、2.00, 2.01, 2.04の表記になっています。

仕様書を見る限り、下位互換性は保たれているので、2.4も読み込めるはずです。24ビットのサンプルは、上位16ビット、下位８ビットに分割する方式になっています。これにはちょっと驚かされました。

App Storeに新着表示

 12/4の午前中には、App Storeにmidif0nがリリース日の並びで表示されるようになりました。左の画像はタイトル画面になります。デザインはシンプルすぎると思っているので、後で直すかもしれません。基本的に、僕はプログラマーなので、デザインは後回しです。

発売日にもかかわらず、Storeもブログも、やたら静かな感じがします。ちなみにmidif0nは、とりあえず国内だけの販売となっています。これは、バグ対応、ローカライズを考慮してのことです。

リリース日は、12/3ですが、この日はKORGのM01が発売になっていることに気付きました。M01が12月中に発売されるのは知っていましたが、発売日は覚えていませんでした。偶然の一致ですね。インターフェース設計者としては、基本的にタッチペンによる操作の方が、小さい画面に機能を詰め込めるので、羨ましくもあります。いろいろ興味はあるのですが、いろいろと忙しいので、見送ることにします。

※amazonのリンクは、基本的に画像を引っ張ってくるために使います。画像の著作権を気にせずに、少しブログを賑やかにしたいぐらいの意味です。

midif0n Ready for Sale

midif0n

ここ最近、メールをチェックしていなかったら、いつの間にかmidif0nがReady for Saleになっていました。ここには書いていませんが、バグ修正とiOS SDK4.2でビルドするために、11/23に再アップしています。リリース日は決めていませんでしたが、結果的に12/3になっていました。これは覚えやすくて良かった。
現状、iTunes Storeは検索だけ引っかかる状態です。

それにしても、レビュー待ちは長かったけど、レビュー自体は２、３時間でした。midif0nは、ツールアプリだし、編集機能もそこそこあるので、通常のアプリよりは、チェック期間はかかるだろうと思っていました。すべての機能をチェックするだけで、そのぐらいの時間はかかると思います。
こちらとしては、何回かリジェクトされることは覚悟していたので、少し拍子抜けかも。

本当はもっと宣伝すべきなんだろうけど、現在、使用メモリの減少に没頭中です。
（これを解決しないと、次のバージョンアップがいろいろと厳しくなりそうだから）
念のために書いておきますが、僕の方でいろいろと問題は把握しています。とりあえず完成しないアプリにならないようにリリースしたので、今後も継続的にバージョンアップしていきます。

一応、価格は1200円で、初アプリリリース記念価格です。価格変更はブログで、事前にお知らせします。現在の価格より低い値下げは予定としてありませんので、安心して買って下さい。

開発の経緯

このアプリの開発は、手段が目的になっているようなところがあります。

平たく言ってしまうと、僕がサウンドプログラミングに興味を持っていて、勉強ついでに何かを作りたかったという話です。

何故、サウンドプログラミングに興味があると言えば、それは音楽＆楽器好きであるため、ディジタル楽器の根本の部分を知っておきたかったからです。また、この分野は高速化が重要になるので、その作業が好きな自分に向いていると思ったからです。

次に、何故、MIDIシーケンサーかと問われれば、主に２つ理由があります。一つは、自分のプログラミングスキルを考え、ある程度難易度が高いものに挑戦したかったということ。もう一つは、シンセサイザを作る場合、音の良さの問題に向き合う必要があるためです。これを避けるためにシーケンサーにしました。

しかし、現状iPhoneには内蔵の音源がないので、結果的に音源部を作ることになりました。ユーザーはシンセサイズできませんが、開発においてはシンセサイザを作るようなものです。兎に角、midif0nにおいて、設計上シーケンサーがメインであり、音源はあくまでサブです。だから音源部にはあまり力を入れていません。音源の話は長くなるので別にしようかと思いますが、一つだけ書いておきたいのは、サウンドフォントをサポートすることにより、音の良さの問題を回避できるということです。つまり仕様通りに実装し、プリセットを作らないことで、音の良さの追求という課題を放り出すことができるわけです。

ちなみに、管理人は作曲はしたいけど、仕上げられない人です。という訳で、何かと足りない点があるかと思うので、ご意見お待ちしております。ただ、一方でシンプルさを重視しているため、機能を盛り込むことはしないとあらかじめ断っておきます。

文字ばかりで読む気がしないと思うので、次からはスクリーンショットとか入れていきます。

審査待ち

midif0n version1.0をアップしました。

この間、ちょっとトラブルがあって、開発のmacの動作がおかしなことに。
いろいろ調べたら、内蔵HDDが怪しい。まだ購入して7ヶ月なのに...。
OSの再インストールもできない状態なので、とりあえず外付けで作業しています。
あとはHDDの初期化ぐらいしかやることはない状態です。
修理は開発に支障がでるので、最後の手段にします。

ある程度、プログラムの規模は大きいので、リジェクトは覚悟しています。
期待している人がいるのかわかりませんが、しばらくお待ち下さい。

開発中のアプリについて

僕が、現在開発しているのは、iPhone/iPod Touch向けのサウンドフォントを音源とするシンプルな16トラックのMIDIシーケンサーです。正確には、デフォルトの音源はsin波で、サウンドフォントはユーザーが指定します。

アプリ名はmidif0nです。 表記上はfを強調して、midi-f-0nにしてあります。

これから、アップする予定です。審査が通りましたら、その旨お知らせします。それまで開発の経緯、仕様などを書き込んでいきます。

初めに

このブログは、管理人myutoが開発するアプリケーションのサポート用のページです。ご意見、バグ報告等、お気軽にご活用下さい。コメントはユーザー間の意見交換等を考慮して、承認制にはしませんが、状況次第では変更するかもしれません。悪意があるコメントはもちろん、感情的な意見もなるべく控えて下さい。
メールを使用する場合は、返信に時間がかかるかもしれません。あらかじめご了承お願いします。

現在は、App Store用にモバイルMIDIシーケンサーを開発しています。販売システム上、すぐに修正を反映させられない点をご了承お願いします。バージョンアップ、価格変更等に関しては、このブログで必ず告知します。