KORG M01 の後継として、KORG M01D がダウンロード専用として 3DS 向けに発売されるらしい。発売は 2013/5 とのこと。
最大の特徴は２点。１点目は最大同時発音数が 12→24 音へと強化されているということ。２点目は MIDI データとして SD カードへのセーブが可能になったこと。
基本的な機能は KORG M01 と同じということで、最大 8 トラック、64 ステップ×99 シーンなどの基本機能は変わってない模様。どうせなら、この辺も拡張して欲しかったなぁ。3DS ならメモリも増えているだろうし…。
入力画面において、三連譜とかが入力しにくいのは否めない。また、シーケンスエディット画面の拡大縮小や、タッチペンによる自由スクロールなど、改善して欲しい部分は結構ある。まぁでも、ニコニコとかで新しい作品がいろいろと出てくるのもちょっと楽しみ。
というわけで、気になったので計測してみた。DSi + DSTT 環境である。
２種類の microSD カードで、ひたすら read を行ない、１秒毎にトータルでの
read 量を表示して確認したものである。多少の測定誤差はあるかも。
読込単位 <8GB/class6> <32GB/class10>
--------------------------------------
2KB 0.77 MB/s 0.76 MB/s
4KB 1.2 MB/s 1.15 MB/s
8KB 1.6 MB/s 1.6 MB/s
16KB 2.0 MB/s 1.95 MB/s
32KB 2.2 MB/s 2.2 MB/s
64KB 2.4 MB/s 2.3 MB/s
read 単位が大きいほど帯域も大きくなるが、PCM データの読込みに使うことを
考えると 4～8KB 単位で read するのが妥当かなぁ。そうなると、18～25チャンネル分
ぐらいをランタイムリードできるのか。かなり現実的かもしれない。
ふと、↑出来るのではないか？というアイデアが浮かぶ。NDS_BGMFILER で MIDI 演奏する上で最大の課題は、PCM 波形データでメモリ不足になることだ。16ch というチャンネル数に加え、途中で音色変更する分も考えると全ての PCM 波形をオンメモリに置いておく方法しか思い付かなかった。
SDカードから随時読込みながら演奏するのって、mp3 や wav ファイルでは良くあることだが、これを 16ch 分の MIDI 演奏に応用するとどうなるか。そもそも、SDカードやメモリの帯域、CPUパワー的に行けるのか？という疑問が残る。
ただ、256×192 16bit の bmp 画像垂れ流しで、22～30fps の動画再生が出来ていることを考えると、SDカードの読込み速度は、およそ 2～3MB/sec 程度あるはず。32KHz、16bit、１秒分の読込みを考えると、逆算で PCM 30～45 ch 分の読込み帯域はあるのかな。
オンメモリに Note-On 直後の１秒分ぐらいの PCM 波形データは常に置いておき、１秒以上の PCM 波形はランタイムで SDカード から読むようにすれば、PCM波形でメモリ不足になる問題は少しだけ回避できるかもしれない。
これを実現しようとする場合、ARM7 で PCM バッファ充填用の周期割込みを発生させ、FIFO 通信で ARM9 に割込みを入れる。ARM9 の割込みから isnd_dtq() で SDカード読込みタスク へ通知し、実際の read 処理はタスクで行なう。read 中に次々に要求が来ても、データキューにキューイングされ、各チャンネルの PCM バッファが枯渇するまでに read が完了すれば問題はない。
重要なのはこの SD カード read タスクの優先度だ。DLDI パッチが当たった DSTT 対応のドライバは OS 非対応だからポーリング的に処理せざるを得ない。優先度を高くすると他の処理が何もできなくなるし、優先度を低くすると、read のための CPU 処理が滞ってしまう。う～む。
DMA 的な read 転送コマンドを発行するタスクの優先度を高くして、コマンド転送と同時にスリープし、転送完了割込みで起床できれば一番いい設計なのだけど、DSTT 用の DLDI パッチってどんな風になっているのだろう。
現時点で最新の devkitPro1.5.0 をインストールすると libfat-nds-1.0.10 がインストールされるのだが、先代の WinXP 環境のときに使用していた libfat-nds-1.0.7 とは大きく異なっている。
まず違うのがディレクトリ系の API。より POSIX に近くなり、opendir, readdir, closedir を使う必要がある。また、そのせいもあってか、libfat 内部でのメモリ使用量が増えているようで、最終実行形式の nds ファイルの本体部分のサイズを少し切り詰めないと NDS 実機で起動してくれない問題が発生。
PSRAM 終端の 0x023F_FFFF に対して、128KB ぐらいは空けるのが良さそう。NDS_BGMFILER での __end__ シンボルが 0x023D_194C だと起動できた。
もう１つ NitroFS も修正。eris 氏のホームページからダウンロードしたやつではなく、libfilesystem-0.9.9 に収録されている nitrofs.c を使う。nitrofs.h は不要になったが、別途 #include <filesystem.h> が必要になる。nitroFSInit() の内部実装を少し変更したかったので、libfilesystem.a はリンクしない。
起動時の argv 対策もやって、argv に対応しているファイラーから nds ファイルが起動された時はその内容に従い、argv 未対応ファイラーから起動した場合は、自身の nds ファイルを探すように変更。
色々修正したおかげで、今まで何故か出来ていなかった NDS 実機、no$gba、DeSmuME のいずれでも起動できる環境が出来た。これに uITRON と、ダイナミックローダーを基本構成として入れたテンプレートでも作るようにしよう。
Windows7 になったので、NDS 開発環境として devkitPro 1.5.0 を素の状態から再インストール。
WinXP 環境でも一度素の状態から再インストールしたと思ってたけど、Win7 環境で過去の自己アプリを再ビルドすると、ディレクトリサーチ系（diropen など）や OpenGL（gluTexLoadPal など）で未定義シンボルエラーなどが出る。
devkitProUpdater-X.Y.Z.exe の仕組みを正しく理解していなかったのだが、どうやらこのインストーラーは、このインストーラを実行した時の最新の libnds とかをダウンロードしてインストールするらしい。devkitPro の announce のページを見ると、それとなく書いてある。だから、記事を見て devkitProUpdate-1.5.0.exe を実行しても、その人がいつインストールしたのかによって、インストールされる libnds のバージョンが異なる。
さらに、libnds はちょっとしたバージョンアップで、すぐに API を変更するから困る。以前にも書いたけど、機能拡張の仕方に融通性というか汎用性がない。FIFO の ch 割当てとか、フタ閉じの省電力制御とか、ちょっとしたサンプルアプリ作成には便利かもしれないけど、ちょっと多機能なアプリを作ろうと思うと何かと実装上の衝突が起きてしまい、過去に libnds の標準 API を使って作った自己資産ライブラリが使えなくなる。
とういうわけで、この辺で一度バージョンの総見直しを図ろう。どうせ DSi-mode や 3DS の機能を使うことは不可能なので、DS-Lite 相当の機能が使える現時点での最新環境に合わせ、このセットアップ方法を備忘録としてホームページに残そう。過去の公開ソースは使えなくなるものも多々あるけど、必要に応じて修正し、不要なものは削除する。
NDS でちょっと大きなアプリ開発を考えると、プログラム領域が不足するという懸念がある。実メモリ 4MB のうち、ワーク領域に 2～3MB 程度確保しておきたいと考えると、コード領域は 1～2MB 以内に収める必要がある。
そこで新たに欲しくなってくるのが、ダイナミックローダー。Linux カーネルの世界で言うと、ローダブルモジュール的なやつ。配置アドレスは固定でもいいから、ユースケースによって 512KB 程度のプログラムを自由に差し替えられるといい。256KB×2 種類とか、ある程度柔軟性があるとなお GOOD。
このとき厄介なのがシンボル解決だ。本体プログラム内のシンボル（グローバル変数や関数）は、モジュール側から制限なく自由に参照したい。一方で、その逆については、syscall のような仕組みでコールゲートを用意し、公開関数だけを参照できる程度でいいかも。ただ、ELF のようなシンボルのセクションを参照して・・・みたいな大げさな仕組みは非現実的。
構築イメージとしては、まず本体プログラムのリンク結果から、nm でシンボルテーブルを抽出し、Global 属性のあるものについては、アセンブラの .equ 相当のシンボル定義を自動生成し、モジュールと一緒にリンクさせる。これなら、参照されたシンボルについては、正しいアドレスで解決されるし、未参照シンボルについては、モジュール側のバイナリを一切消費せずに捨てられる。
モジュールのビルド環境は、デフォルトの devkitPro 環境にはないだろうから、適当なバイナリイメージを出力するものが必要か。先頭に GOT のようなテーブルを作れるように特殊なセクションを用意し、コールゲート発行用のマクロを、本体側プログラム向けにヘッダファイルで用意すればいい。
あとは、ローダー／アンローダーのライブラリがあれば何とかなりそう。
いや、BGMFILER の進化版としてシーケンサーを作りたいわけだけど、PCM 波形データのことを考えると明らかにメモリが不足する。uITRON もローカルではそこそこ動くやつが完成しているので、ローダーが出来れば開発環境としてはほぼ揃ったことになる。
KORG M01 オリジナルと、めらまん試作鍵盤の出力波形を比べてみた。エミュレータで試すのが難しい気がしたので、NDS 実機で再生したものを TWE でサンプリングして目視で比較してみる。
（図１）KORG M01 オリジナル波形
（図２）めらまん試作鍵盤波形
音色はいずれも Clicker というやつで、Reverb や Release などの効果を外した素の状態で C4 の音を鳴らしたものを比較している。再生周波数は 15,461Hz、元音は 32,768Hz である。
図２の直流成分の偏重は無視するとしても、めらまん波形の方は、波形が細かく上下に振動している部分が多々あるのが分かる。これが恐らくノイズの原因だろう。単純間引きで再生しているわけだから、こういう波形が出ても原理的には仕方ない。
複雑なアルゴリズムを使わずにピッチシフトでノイズを落とそうと思うと、せいぜいこの単純間引きに加えて、バイリニア的に前後２点間の平均値を採用するぐらいが限界だろう。ということで、やってみたのが下の図３。
（図３）めらまん試作鍵盤波形（改善版）
たった数行変えるだけで波形が変わった。変な凹凸がなくなってちょっとだけスッキリ。フィルタを掛けていることになるわけだけど、実際に音を聞く限り音質が劣化したという感じはしない。ノイズは減っていると思われるが、KORG M01 実機の音にはまだかなわない。他の波形でも違いを見てみる必要がありそう。
9/28 の試作鍵盤で、音色を全て KORG M01 のものに差し替えてみた。従来のサンプルとは異なり、各音色によってノート番号毎に波形と再生周波数が個別に定義されているため、オクターブが高いところや低いところでも音質が劣化しにくい。
ただ、本物の KORG M01 と音色を聞き比べてみると、違いが全くわからないものもあれば、明らかに歪み掛かったように聞こえるものもある。つまり、同じ波形データなので音質に違いはないはずなのだが、実際には違って聞こえるものもあり、再生アルゴリズムの違いに起因しているものと思われる。
DeSmuME で動くと解析も楽なのだが、nirtofs の読み込みと相性が悪くてうまく動かない。PC で波形を録音して再生アルゴリズムの違いを見ていくしかないかなぁ。続きは 11/E ぐらいですね…。
さらに調査を深堀りしたところ、音色データは全部で４つのファイルで構成されているところまで判明。公式には 342 音色となっているけど、データ的には 341 しかインデックスがないのは何故（0×000～0×154）？
program.bin … 全 341 楽器音の詳細パラメータ。ソフトエンベロープ値など
mspara.bin.mod … 全 341 楽器音毎のノートレンジと各 PCM 波形との対応表
smplpara.bin.mod … 全 2,035 波形の基準ノート値や波形データへのオフセット情報等
smpldata.bin.mod … 全 2,035 波形の 16bit PCM 生波形データ
中身のデータ形式はほぼ解析完了。細かなパラメータとして、S/Wビブラート制御のためのパラメータなんかもあるっぽいけど、まだ完全には分かっていない。逆にソフトエンベロープや、ノートレンジと波形データの対応関係などは全て解明できた感じ。
ARM7 でのソフト波形合成が 16音 ぐらいが限界だとしても、ARM9 なら CPU 周波数で２倍、キャッシュや TCM の効果も考えれば 32音 は余裕だろう。KORG M01 も演奏中の GUI の反応が少し遅くなる感じがするので、ARM9 は演奏処理だけってことはないんだろうな。
やはりマルチタスクが必要になったきたか。
KORG M01 の波形データはどんな感じで入っているのだろう。
nds ファイルを実機から吸い出して、ndstool で確認すると、
24 0x000CCE00 0x02800E26 41107494 /smpldata.bin.mod
25 0x000C0E00 0x000CCCC8 48840 /smplpara.bin.mod
という２つの内部ファイルが見える。前者が 16bit の生 PCM データ。ADPCM 圧縮とかはしていない。全ての楽器音が連結した１つのファイルになっている。先頭に WAV ヘッダを付けてあげれば、適当な WAV 編集ツールで全楽器音を視聴することもできる。後者は、前者のファイルを個々の楽器音の波形データとして管理するためのインデックス情報が入っている。
後者は１波形データ当たり 24byte で構成されている。インデックス番号やファイルオフセット、リピート開始・終了位置などの情報があることが分かったので、この情報にしたがって、前者のファイルを WAV ファイルとして分割することは簡単なのだが、24byte の情報全てを解析しきれていない。
明らかに note 番号の情報なんかもあるんだけど、１つの楽器音を note レンジごとに分けて複数の波形データで構成している場合のメタ情報なんかがありそうなんだけどなぁ…。先に波形分割ツールを試作して、絞り込んでいくしかないか。