HRA's note

[MID-Play2 開発状況]

最新版
・Windows2000/XP版を作成中
・WindowsCE版はWindows2000/XP版の後に制作する予定

・MIDIエミュレーション....ほぼ完成(WinCE版含む)
・SMF演奏エンジン.........完成(WinCE版含む)
・RCP演奏エンジン.........デバッグ中(WinCE版含む)
・メイン画面..............一部完成(Win2K版のみ)
・設定画面................一部完成(Win2K版のみ)

[2004/9/9]
だいぶ放置気味ですが、既存のライブラリをいっさい使わず、全て自作しようとしたためにパンクしました。
やはり、利用できるモノは利用して、作り込むべきロジックに専念した方が良いですね。
少し前から、WTL を使い始めました。すでに別の創作で何度か使ってみて、だいぶ慣れてきました。
WTL7.1 は、WindowsCE をサポートしている（一部WindowsCEで使えない機能もある）ので、これで記述すれば
GUI 部分も比較的簡単に作れそうです。
いま、いろいろ忙しいので、また落ち着いたら整理して再利用＆作り直します。

[2004/6/6]
・WinCE.NET 向けの VB.NET はだいぶ違う？

DLL関数の宣言に Declare Sub Unicode xxxx などと書いていると、「Ansi, Auto および Unicode の指定には対応していません。」
というエラーになる。でも、入力中はしっかり選択肢として出てくる (-_-;;
とりあえず、VC++ からは呼べるはずなので、eMVC++4.0 でビルドした ARM4I Releease 版を最新版としてパックしてみた。
動作は未確認。WinXP版をそのままビルドし直しただけなので、動くかもしれないし、動かないかもしれない。
[2004/6/3]
・WinCE.NET 版 SoftMidi.dll ビルド完了

とりあえずビルド完了。全てリビルドすると、２駅くらいかかる模様 (-_-;
Win2K/XP版を _UNICODE でリビルドして、VB の定義を ansi から unicode に変更すれば UI部分はバイナリレベルで
WinCE と Win2K/XP で同じモノが使えるようになるはず。
[2004/6/2]
・WinCE.NET 版 SoftMidi.dll ビルド

相変わらず、通勤電車の中で作業。
eMVC++4.0 を起動して、新規プロジェクトを作成し、必要そうなモジュールを追加していく。
一通りいれたつもりでビルドを開始するが、いくつかリンクエラーが出ていたのでまだ不足モジュールがありそう。
CPUの種類が多すぎてビルドに時間がかかる。使ってるマシンが速くないのもあるが・・・。
その辺は、Win2K/XP版のプロジェクトと見比べればすぐわかるが、最近睡眠不足気味なため、ビルド中断して睡眠 (-_-;
ということで、まだ DLL ビルドさえできておらず。
[2004/5/29]
・動作確認と VBソースの整理

再度動作確認すると、やはり VB でハングアップする。
どうやら、THREAD_DETACH に撤収処理をおいたために、無関係のスレッドが終了したときに、演奏中にもかかわらず
演奏用のリソースを解放して死んでしまうという間抜けなバグが原因だった。
初期化と後始末のうまいタイミングが見つからないので、それらを関数化して解決。
使う側は、明示的に「初期化」と「後始末」を呼ばねば正常に動作しなくなったが、私個人的にはこの方が好きなので良しとする。
とりあえず、現状のバイナリをおいてみた。UI部は VB.NET2003 で作成してあり、ソース付き。
必要最低限の機能しかない UI だが、ソース付きなので気にくわない人は勝手に改造して使ってください (^^;
[2004/5/28]
・動作

DLLを修正して、再びVBで動作確認。
ファイル選択ダイアログも固まらなくなった模様。
[2004/5/26]
・VB.NETからの演奏ができるようになりました

DLL内部で、WAV再生ルーチンから定期的に呼ばれるコールバック関数を、演奏の時間基準にしているが、そのコールバックの中で MusicPlayerインスタンスを生成する前にMusicPlayerへアクセスしに行っていたのがハングの原因。
VC++で作成したテストは、連続的に流してしまうために、コールバックが呼ばれる前に曲データを読み終えて、MusicPlayer
インスタンスを生成できてしまうので、偶然ハングしなかっただけ (-_-;
VB のテストの方は、関数を１つ呼ぶボタンがたくさん並んでいて、順番にクリックする形にしたために、MusicPlayerインスタンス生成までに時間がかかる。そのおかげで、このバグが見つかった。
その辺、他にもあちこちガード不足な点があって、VBの関数としては、まだまだ不安要素が多いモノの、なんとか VBで演奏できる
ところまでこぎ着けた。
ただ、まだバグがあるようでファイル選択ダイアログが操作不能になる場合がある。今までWinアプリを作ってきて、そんな現象は
初めて。いったい何が起きてるのか・・。もう少し調査が必要なようだ。
[2004/5/25]
・VB.NET からの呼び出し

サウンドフォントの読み込みの後、SoftMIDIインスタンス生成関数を呼び出し・・・不正アクセス（｀Д´;）
朝の電車の中で、イヤホンまで装備して準備してたのに、音が出る前にゲームオーバーですよ。
VC++ から呼び出したときはうまく動いていたように見えていたモノが、まだ不完全らしい。
[2004/5/20]
・VB.NET からの呼び出し

DLL化した演奏エンジンを VB.NET から呼び出し。
サウンドフォントの読み込みまで動作確認。特にエラーもなく動作。うむ、順調 (^^;
現状、ファイル名などは ANSI 定義にしてあるが、WindowsCE のことを考えると UNICODE 定義にした方がいいかもしれない。
というのも、VB.NET の DLL 関数呼び出し宣言の頭に書く Declare XXX の XXX に auto と書いても正常動作しなかったため、
明示的に Ansi と書いているが、WinCE版でも同じ宣言ファイルが使えるようにするには UNICODE にするのが一番負担が少ない（使う側も作る側も）ため。
その辺も含め全体の動作確認をして、SigIII版DLLもできたら公開ですかな。SigIII版は無修正でコンパイルできるはず (^^;

[2004/5/19]
・バグ追跡

後しまい処理の一番最後にやるべき処理を DLL のプロセスデタッチのところへ移動しただけでデッドロックするようになりました。
MSDN Lib を見ると、１度だけ行えば良い初期化はプロセスアタッチ、後しまい処理はスレッドデタッチにおけばいいと書かれているのでそのように修正。あっさり動作・・(^_^;
最初から MSDN 見れば良かったと後悔。
[2004/5/18]
・バグ追跡

DLLのデタッチ時に行っている後しまい処理をコメントアウト。
等価処理を、export して DLL呼び出し側の終了時に明示的に呼んでみた。
DLLのプロセスデタッチイベントの発生タイミングの認識が誤っている可能性を考慮してのこと。
で、実際に動作させると正常に動作する。デッドロックしない。
でも、明示的に後しまい処理を呼ばねばならないのは面倒だし、呼び出し忘れてデッドロックされたりしたら使いにくい。

ただ、どうしても解決できない場合は、呼び出し用クラスの中でデストラクタに記述しておく等の方法で対処して、
利用者側の負担がなるべく少なくなるようにしたいと思う。
とりあえず、明日は後しまい処理を分割して、少しずつプロセスデタッチイベントへ追い出してゆき、具体的な原因を追及するつもり。
[2004/5/16]
・謎

同様の処理を exe で組んでみるとうまく動く。
dll との違いは、後しまい処理が main() 抜け後か、main() の最後か。
この違いに原因があるかどうかを調べるには、後しまい処理をするAPIを暫定的に作って、これをmain()内で明示的に呼ぶことで exe と同じ状況を作り出してやればいいかな。
今日は疲れたので、明日にお預け。
[2004/5/11]
・デッドロックしているのが waveOutReset() であるところまで判明

exe として作っていたときはデッドロックなんかしなかったのに、dll にしてからロックするようになってしまった。
なんか手順を間違えてるんだろうけど、WindowsAPIの中でロックしないでほしいな (T_T)
waveOutReset() を試しに取り除いてみても、その直後の waveOutClose() でロックする。ハンドルがすでに無効とかそんなレベルかもしれないな・・・ぐむむ

[2004/5/9]
・落ちるバグを修正

内部のインスタンスの管理方法が腐ってました。
修正して音が出ることも確認したモノの、使い方によってはアプリ終了時にデッドロックすることが判明 (T_T)
結構根が深い部分なので修正困難。ぐむむ。
[2004/5/8]
・落ちるバグがDLL内部に原因があることを突き止める

具体的には、DLL内部で MIDIエミュレーションオブジェクトのインスタンス生成部で不正メモリアクセスが発生して落ちてます。
ただ、単純に使い方を間違えてるだけかもしれません・・・いろいろ手続きがアルのですが、そのどれかが抜け落ちてるのでしょう。
抜け落ちてもエラーで弾く仕様なので、これは「使い方を誤っているバグ」と「エラーを正常に検出できていないバグ」の２つが混在していることになります。

本気で調べればすぐにわかるような気がするけども、どうも最近電子工作に凝ってましてついそっちをやってしまうという・・(^_^;
[2004/5/7]
・VisualBasic.NET用の module を作成

DLL呼び出し用のmoduleを作成。
SoftMidi.XXXX() のような感じで呼べる・・けど、サンプリングレートなどの設定関数を呼ぶと例外が発生 (^_^;
VisualBasic.NETは初めて使うので、moduleの記述ミスなのか、DLLのバグなのか謎。
切り分けるために、純粋にVC++だけでDLLをテストしてバグの在処を切り分けないとダメですね。たぶんDLLのバグだろうけど。
[2004/5/3]
・DLLのインターフェース関数の実装

基本的な機能を全て実装、コンパイルも通りました。
でも、DLLを呼び出すアプリを作成していないのでまだ公開できません。
[2004/5/2]
・DLLのインターフェース関数の実装

久しぶりに作業、でも体調が優れないためほんの少しだけ (x_x)
インターフェースモジュールを、とりあえずコンパイルが通るレベルまで修正。
ただ、まだ中身が空っぽの関数が多数あるので使い物にならない。
[2004/4/27]
・DLLのインターフェース関数の実装開始

MID-Play2演奏エンジンの内部ルーチンは自由度重視のため、結構細かくて使いづらいところがあるため、DLLインターフェース用に使いやすさ重視で細かい機能を割り切ったインターフェースとして新規実装することにしました。
とりあえず、最初は MID/RMI/RCP の再生ができればいいかな程度で。
オーソドックスな MIDプレイヤーの他に、ゲーム等の BGM なんかにも使えるんじゃないかなと。
ゲームとなると曲数が多くなって、MP3等ではPDAに優しくないサイズになってしまいますからね、まだMIDは有効かと思います。
細かい機能は割り切ったと行っても、MIDIの状態変化をポーリングできる程度の機能は付けようと思います。
ポーリングなので鍵盤表示などは辛いかもしれませんが、単純な関数になるので VB 等からも簡単に呼べると思います。
[2004/4/26]
・DLL化に向けて再構成

VC++のプロジェクトファイルを新規に起こし、そこに MID-Play2 の演奏エンジンを詰め込みビルド。
ソースは特に変更無しにビルドできました。後は、外から呼び出せるように必要な関数を DLLEXPORT するだけでOK
これができあがったら、WinCE版もビルドして VB で UI作成ですね。
[2004/4/21]
・モバイル環境に苦戦

先日、eMVC++4.0 の環境を整えた PCG-U101 だけど、今朝電車の中でステップ実行を試してみると exe の転送がタイムアウトになってしまう。
試行錯誤の結果、exe の置き場を /Storage Card （ホストとの共有フォルダ）にしてるとダメっぽい。というか、共有フォルダの挙動が怪しい。
結局、コーディングは進まず。
[2004/4/20]
・CC#10 のパンの振り方を確認

MID-Play v1.0.6 ってステレオ低位の左右が逆じゃない？・・という指摘を受けたので、確認データを作成して早速確認してみました。
見事に逆です (^_^;
MID-Play v1.0.6 の仕組みをベースに作っている MID-Play v2 ももちろん逆です。
直して、MID-Play v1.0.7 としてリリースしました。Win2000/XP版は VC++.NET2003 でコンパイルできなかったので廃止です。
[2004/4/19]
・eMbeded Visual C++3.0 のインストール

MID-Play v1.x.x 系のメンテナンスを復活させようと、ソース一式を引っ張り出してきた。
しかし、ここで問題発生。先日ＰＣを新調してから、eMVC++3.0をインストールしていなかったため、プロジェクトファイルさえ開けず (T_T)
インストールから始めました。
eMVC++3.0のインストール、HPC/Pro SDKのインストール、PalmSizePC SDKのインストール、PocketPC SDKのインストール、 HPC/2000 SDKのインストール、BE-500 SDKのインストール、PocketPC 2002 SDKのインストール・・・(x_x)グッタリ。
SDK 多すぎです。

WinCEはプラットフォームが膨大で、しかもそれぞれで微妙にUI系のAPIが違っている（APIの挙動が違っていたり、そもそも存在しなかったり、画面サイズが全く異なったり、固有のプラットフォーム専用のルールのようなものがあったり）ので、 UI 系のコーディングは非常に疲れますし、全く面白くないです。
音源ロジックや演奏ロジックだけをDLLにまとめてしまって、UI部分は MFC, C#, VB といった気楽に使える環境で用意して UI部分のソースを公開するのがイイかなと思い始めました。
その方が、私が手抜きで作った変な UI に縛られずに済むし、UIの制作効率も上がるし、気合いのある人はUIを自作したり、自作ソフトにMIDI演奏を組み込んだりできます。
MID-Play1 の時も、DLL版を用意していましたが、APIを構造体渡しにしていたため、PocketC や VB から利用できなかったりして意外と制約が多かったです。その辺をふまえて、まずDLL版を用意したいと思います。
公開後も、改善のため API-I/F はころころ変えると思います。
[2004/4/17]
・eMbeded Visual C++4.0 と格闘 (^_^;

私の Sig3 は常に開発マシンに繋がっているわけではないので、WinCEエミュでデバッグできるようにするために奮闘してました。
eMbeded Visual C++ 4.0 JP に付属の StandardSDK (CE.NET4.1用) の CEエミュではファイル転送の方法がわからなかったので、StandardSDK（CE.NET4.2用）をダウンロードしてきました。
これに付属のエミュは、システムメニューに「ファイル共有」というのがあり、これで共通したホストＰＣのフォルダは、エミュから "\Storage Card" として見えるようになります。
[2004/4/15]
・WinCE版の細かいコンパイルエラーを修正して Sig3, WinCE.NETエミュで起動できるのを確認

主にWinCE.NETエミュで動作確認できるようにするのを目的として、いろいろいじりました。
なんとか WinCE.NETエミュで動作するようになったので、Sig3 版もリビルド。エミュと同じ動きを確認。
今度はツールバーは正常に表示されるものの、左上に変な四角が・・メニューモドキの残骸かも (^_^;
メニューモドキの残骸のおかげでボタンが押せないかと思いましたが、レバーバンドにしていたのでドラッグで移動。ファイルオープンまで動きました。
ただ、音色データを正常に読めていないらしく、再生できず・・。いろいろ調整が必要ですね。
[2004/4/14]
・U101にeMbeded VisualC++4.0をインストール

昨日インストールしたのは eMVC++4 の英語版。しかも、Platform SDKを入れ忘れたために、起動さえできず・・。電車の中で呆然としてしまった (T_T)
ということで、入れ直し。日本語版を入れて、SP2をあてて、Standard SDK と Sig3 SDK をインストール。念のため、起動できることを確認 (^_^;
なんか、無駄なロスタイムが多い (x_x)''

[2004/4/13]
・SigmarionIII版のリソースファイル編集
・U101にeMbeded VisualC++4.0をインストール

eMVC++4 を入れたのは帰宅後。リソースファイル編集は今朝の電車の中。
ということで、テキストエディッタでちまちまとリソースファイルを編集しました (T_T)
非常に効率悪いし、あってるかどうかも怪しいです。

とりあえず、数日前の Sig3版の状態を・・。
コンパイルが通ってましたが、UI上の表示あやしく、「メニューがない」「ファイルを開くボタンがない」という状態で音が全く出せず (^_^;
まず、その辺の必要最小限の操作系は確保しないと動作確認もできないので、明日からはその整備に取りかかる予定。

Windows標準の UI って、割とAPIが統一されていなくて使いづらいです。
MID-Play1 のように、自分で UI描画した方がよっぽど楽でした。PocketPC版は MID-Play1 のようにグラフィックで書いちゃおうかな・・（未定）
[2004/4/12]
・メンテしていなかった SigmarionIII 版を少しだけメンテ

朝の通勤電車の中でソースメンテ・・・ラッシュ時でないので迷惑はかかっていないはず (^_^;
ソースをメンテしたものの、モバイル開発環境 U101 に eMbeded VisualC++ 4.0 をインストールしていなかったため、コンパイルはできず。
先日の HDD内容クラッシュ後にインストールしわすれていた。でも、今日はもうインストールする時間なんて無い。

[2004/4/11]
・RCPプレイヤーのデバッグ
　　・いきなりループ開始から始まるトラックで最初のループ開始を無視してしまうバグを修正
　　・タイでつながれた音符をつなげて演奏する処理を追加
　　・コード 0xFC, 0xFD の挙動を誤解していたのを修正

タイの処理がまだ微妙に怪しいかも。つながらなくても良い音がつながったり、音が鳴りっぱなしになったり。
あと、ExclusiveMessage等は無視して捨ててしまっているので、その辺で鳴り方がおかしくなる曲もある。
[2004/4/10]
・RCPプレイヤーのデバッグ

機能Ｒと呼んできたのは、RCP/R36 ファイルの演奏ルーチンのこと。
いまどき？・・と思うかもしれないが、手元に RCPデータがたくさんあるのだから仕方がない。

何とか音が出るレベルまでこぎつけたが、ループ処理がおかしい。
演奏中のテンポ変更を組み込んでみるとうまく動かない。というか、資料不足でテンポ変更データの構造が思っているモノと違うらしいことだけわかった。
とりあえず、上の写真をクリックすれば最新版を得られる。RCPの演奏は期待しないように！

[2004/4/9]
・機能Ｒの基幹機能を実装

機能Ｒは、SMFでない某MIDIファイル形式の再生機能です。
私の手元にあるMIDIデータは、SMFのものよりもこちらの形式の方がお気に入りが多いので、気合いが入る。
やっとNoteOn/NoteOff/ProgramChange/ControlChange の制御を実装したので、リズム音以外はそこそこなり始めた。
一応、ループ制御やループのネスト機構も含まれている。
ただ、曲によっては 0:00 の長さと誤認したり、音が鳴りっぱなしになってしまうこともあるみたい。
まだまだバグが多くて人に見せられるレベルじゃない。
そのファイル構造に関する情報が少ないので、数値の具体的な意味などはトライ＆エラーで調べるしかないところもあり、手間取ってしまう。
Windows なら、SMFへ変換する DLL などもフリーであるみたいだが、MID-Play2 の主なターゲットは WindowsCE なのでそんなモノは使えない・・・使いたくても使えない (T_T)
[2004/4/7]
・とある大きな機能（以後Ｒ）の一部を実装

難解と思われる部分が２つあるのですが、そのうち１つを実装。既存のモノをほぼそのまま流用できたので意外と短時間で実装完了。
まだ未テストだが、元にしたルーチンが充分テスト済みであるため、テストは後回し。
もう一つの難解な点もおおかた実装方針が決まり、後は実装するだけ。
ただの移植よりも、こういった新しい機能の方が作っていて楽しい。

[2004/4/5]
・コントロールパネルのボタンのコードを追加
・とある大きな機能の実験的実装を開始

予想外に発生したU101のHDD内容破損の復旧作業によって開発が中断させられていたが、それも落ち着いたので久しぶりに再開。
完成する保証がないから内容についてはまだ公表しないが、MID-Play1 には無い機能の実装を開始した。
いろいろ調査しながら、設計を行うためのプロとタイピング実装。
MID-Play1 の時は、資料が集まらなくて実装できなかったが、資料を入手したので作り始めた。
個人的に欲しい機能なだけに気合いが入る。
[2004/3/29]
・コントロールパネルを追加

右上にコンボボックスを配置して、そこで表示するパネルを選択できるようにした。
プレイリストだけでは切り替えの感覚がわからないので、とりあえず暫定的なコントロールパネルを配置（まだクリックしても反応しないし、デザインももう少し変える）。
いずれほかのパネルも増やすが、とりあえず切り替えに関してはうまくいっているようだ。
[2004/3/25]
・調査

昨日からいくつか細かい情報集め。
コーディングはしていない。

ファイル選択ダイアログは今のところ標準のモノを使っているが、「１つずつしか選択できない」のは明らかに使いづらい。
Windows2000/XPのモノは、フラグ OFN_ALLOWMULTISELECT を追加すれば複数選択モードになるが、 WindowsCEのファイル選択ダイアログは OFN_ALLOWMULTISELECT をサポートしていない。
フリーの置き換え版ファイル選択ダイアログで複数ファイル選択に対応しているモノもあるようだが、どうやって対処しようか思案中。
MID-Play1 のファイル選択ダイアログは不評みたいだし。
[2004/3/23]
・ツールバーの隣にコンボボックスを配置

今日は朝の通勤電車で組んだ分だけ。あまり進展無し。
レバーバンドに新しいバンドとしてコンボボックスを追加したので、ツールバーとコンボボックスは自由に配置換え可能な状態で配置された。配置換えしてもあまり意味がないが・・・
このコンボボックスは表示内容の切り替えに使うもの。デフォルトではプレイリストが表示されるが、切り替えることによってエフェクト表示や大きな操作パネルなどに対応するつもり。
[2004/3/21]
・プレイリストの表示フィールドに演奏開始時に演奏時間を表示する処理を実装
・RMIファイルが正常に読めなかったバグを修正
・モノラル再生がおかしかったバグを修正

プレイリストの時間フィールドは、演奏開始前は --:-- と表示され、演奏開始時に計算した時間を表示するようにした。
表示ルーチンは曲名表示部分も実装したが、曲名抽出ルーチンが未着手のため何も表示されない。
RMI の方は、ちゃんとテストしていなかったためにヘッダの解析ミスがあったことに気がついていなかったのが原因。
２カ所ほど誤りがあり、「不正ファイル」と誤認して弾いていたのを修正。
モノラル再生は、ドラム音の生成ルーチンの「加算合成処理」が「上書き置換処理」になっていたため、ドラム音よりも先に生成された音色が消滅していたのが原因。「=」→「+=」というまさに１文字足りないだけのお粗末なバグだった (-_-;
[2004/3/19]
・シーク関数のバグを修正

MID-Play内部ではいろいろな時間軸があって、それらは進みの異なる源により進行する。
そして曲データ再生は 10msec（仮想時間）単位で進行するようになっているが、SMF内の usec 単位の音符長指定が（時間的に広義に見て）ずれないように誤差を拡散している。
高速処理を実現するために整数演算を採用しているため、誤差拡散で拡散する誤差自体にも誤差が発生するがその「誤差の誤差」を軽減するために左シフトにより精度を上げて計算している（固定小数点）。
このとき、早送り演奏時の時間単位 30msec でギリギリまで高精度になるようにチューニングしていたためそれより大きな時間を指定すると桁あふれが生じて、思っている位置とは異なる時間へシークしてしまうのが原因。
ということで、精度を落とすわけにはいかないので、「1000msec後にシーク」ではなく「10msec後にシークを100回」のような処理を実施して回避。
カスタマイズ画面で OK をクリックしたときにも OKをクリックする前とほぼピッタリ同じ時間までシークするようになりました。
[2004/3/18]
・ステータスバー操作関数に思い通りに操作できないバグがあったのを修正
・ステータスバー操作関数を含むモジュールの単体テストに上記バグを検出できるテストケースを追加
・ステータスバーにファイル名、演奏時間、演奏した時間を表示するようにした

シーク関数の動作が怪しいようで、指定した時間へシークしないケースがある。
その副作用で、演奏中にカスタマイズ画面で OK をクリックすると演奏した時間が演奏時間以上に進んでしまうバグがみつかっているが、その対処は明日以降へ。
[2004/3/17]
・演奏時間取得関数とシーク関数を実装
・それらを使って演奏中にカスタマイズ画面で変更結果を反映するときに演奏がおかしくならないように修正

シーク関数・・もともとそういう機能を想定して作っていたこともあり、たったの４行で実装完了 (^_^;
スライダなどを配置すれば、マウス操作で曲の好きな位置から再生できるようになりますが、その辺は面倒なので後回しです。
さわってみたい人は上の写真をクリック（※Windows2000/XP版のみ）。
[2004/3/16]
・カスタマイズ画面で変更した設定を即時に反映するように修正。
・サウンドフォントデータを MidPlay.exe のある場所にある SoundFont フォルダ内から検索するように修正。

即時変更を入れたのはいいものの、現状では不都合がある。
わかりやすく言えば、MIDI音源を２つ用意して一方で再生中に MIDIケーブルを引っこ抜いて他方へさし直すような状態になるので、後に接続された MIDI音源は、それまでの演奏情報を知り得ず、たとえばすべてピアノ音になってしまう等の不都合が発生する。
ただし、演奏停止中に切り替えた場合はこの問題は発生しない。
この辺は、いずれ実装する現時間取得・一時停止・シーク機能を使って改善する予定。
サウンドフォントは、検索パスを変えただけで、現状では standard.mpf に決めうち。
[2004/3/15]
ソースの書き方を一部変更。
モバイル環境でも開発が行えるように環境整備。
[2004/3/14]
モジュール構成を見直し一部修正。すべてのテストプログラムをかけ直し。
相変わらず、本質的な進展はなし (^_^;

[▲上へ]