T's Weblog

約1年半ぶりに、お絵描きしぃちゃっとの接続監視ツールであるPaintChat Monitorをバージョンアップ。

「切断されたときにサウンドを鳴らせるようにしてほしい」という要望をもらっていたので、その機能を入れた。最初は、WAVEファイルだけ再生できればいいと思って作っていたけれど、mciSendString()でいろいろなファイルが簡単に再生できることがわかったので、それを使った。動画も再生できてしまうことに、ちょっと驚いた。

見た目も少し変わって、バルーンヘルプをアイコンつきに変更した。あと、表示時間が以前より長くなっているはず。

5年近く放置していたJKViewをバージョンアップ。きっかけは、たまたまバグを見つけたから。履歴が10個たまった状態で、さらに別のファイルを開いてから、戻る操作をくり返すと、エラーが出てしまっていた。

その問題はすぐに直した。これだけではナンなので、ファイル選択ダイアログを新しいタイプのものに変更して、設定ダイアログで使っているフォントをMS UI Gothicにした。Windows 95にはないフォントだけど、MS UI Ghothicパッチがあるから大丈夫だろうと判断した。

それと、改行マークを変えた。9ポイントのフォントのとき、矢印の片側が欠けてしまっていたのと、少し長いと感じていたので。

ほかにもやりたいことはたくさんあるが、根本的に作り直さないとうまくいかないことばかりなので、今回はバグ修正と、ちょっとした変更だけで済ませた。

そういえば、HelpDesignerを使ったのも久しぶりだ。使い方をほとんど忘れていたけれど、内容をちょこちょこと書き換えて、[ヘルプファイルの作成]を実行するだけだった。

数日前に1.10を公開したばかりだというのに、またバージョンアップした。お絵描きしぃちゃっとのVer.2系にも対応させたのが今回の目玉となる。このバージョンは、テキストとラインで異なる2つのポートを使用しているので、新たな処理の追加が多かった。とはいえ、たいした作業量でもないから、やる気のあるうちに一気に作った。これで、現行のお絵描きしぃちゃっとすべてに対応できたはず。

お絵描きしぃちゃっとでは、まれにキャンバスかチャットの片方だけ接続が切れることがある。このときもバルーンヘルプでの通知がほしいと思って、バージョンアップした。実は、最初からそういう作りにしていたのだけど、きちんと機能していなかっただけだったりする。

実際に絵チャを使っての動作テストは難しいので、簡単なテスト用のツールでも作ろうと思った。しかし、それに時間をかけるのも面倒になってきて、TIDTというソフトを使った。

ところで、このソフトをバージョンアップして公開すると、OnlineSoft VersionUp.infoに載る。公開してから数時間で、もう載っていることもあって驚く。

PaintChat Monitorを使っているとWindowsが終了できないという報告を受けた。再現するか試してみると、たしかに終われないときがあった。直さねば。

このソフトは、設定のダイアログボックスがメインフォームになっている。これを閉じると、通常はアプリケーションが終了するが、タスクトレイのアイコンのメニューからしか終われないように細工してある。それが原因で、Windowsから終了要求があっても終了せず、結果としてWindowsの終了処理も止まってしまうのだろう。終了できるときもあるのが謎だが、とにかくきちんと終われるように修正した。

これとは別に、タスクトレイにアイコンを出すコンポーネント自体にも、条件によってはWindowsが終了できない制限があることを知ったので、その条件に当てはまらないようにしておいた。実はその影響で、PaintChat Monitorの終了時に、一瞬タスクバーに出てしまう。実害はないものの、ちょっと気になるので、次の機会にはこの処理をやめたい。もちろん、Windowsが終了しない問題が再発しないことが前提だけど。

GuruGuruSMFを利用したVisual Drumsは、Windows 98/NT/2000でも問題なかった。表示のタイミングもぴったり。気をよくして、テンポと演奏時間の表示を加えた。まだいろいろやれそうだけれど、まずはWindows NT系に対応したということで区切りをつけたい。

それにしても、実に1999年の2月からずっと、時間を見つけては修正作業をしてきたので、やっとできたというのと、しぶとくMediaPlayerコンポーネントを使っていたことが原因だったのかよと、いろんな意味で泣けてきた。

ところで、KBGMの作者さんから返事が来た。もう開発環境がないそうだ。うむむ…。でも、回答がもらえてよかった。そういえば、フリーソフトの作者とやりとりしたのは何年ぶりだろう。残っているメールからすると、1998年が最後ではなかろうか。今は、こういった交流がなくなってしまっているなぁ。

あと一歩というところで詰まってしまったVisual Drumsの開発は、あきらめずにまだ続く。次に見つけたのは、GuruGuruSMFというDLL。必要な機能は実装されているので、あとは問題なく動作するかどうかだ。

その前に、少し考えることがある。このDLLは、現時点で0.2.9と0.3.3のバージョンが作者のサイトでダウンロードできる。0.2.9はDirectMusicを使用しないバージョンで、最終更新が2003年の安定したものらしい。一方、0.3.3はDirectMusicを使うこともできて、今も開発が続けられている。0.2.9で事足りると思ったが、もう少し検討することにした。ヘルプを見比べると、思ったより違いがたくさん見つかった。関数が統合されていたり、それに伴って引数が増えていたりと、いくつか仕様変更がある。今後のことも考えて、最新のを使うことにした。ベクターに置いてあるのも0.3.3だったし。

演奏処理をGuruGuruSMFにやってもらうので、Visual Drumsが動作する上でGuruGuruSMF.dllは必須になるわけだけど、DLLがバージョンアップした際に差し替えができるように、LoadLibrary()を使った動的リンクにしておいた。というか、いつもその方法だけど。

GuruGuruSMFでの演奏位置の取得は、ミリ秒の時間と、デルタタイムの累積の両方でできる。また、KBGMと同じく、テンポの取得もリアルタイムでできる。要領がわかってきたので、KBGMからの差し替えには、たいして時間はかからなかった。

今度は特に問題なく演奏できているようだ。とりあえず、Windows XPで確認した。ほかのOSでの動作確認は明日にしよう。

Visual Drumsで、C++Builder 4のMediaPlayerコンポーネントを使うのは、もうやめることにした。これにこだわっていると先に進めない。MIDIデータの演奏をしてくれるコンポーネントかDLLを使うことにする。演奏中に、演奏位置が取得できるものならたぶんいける。

MIDIデータ演奏用のライブラリで、KBGMというものがある。前から存在は知っていたものの、いざ組み込むとなると、それなりに修正が発生するので保留にしていた。今回は、もうやるしかないということで作業を始めた。DLLの使い方は、RCPCV.DLLのときに一度調べたので、似たようにやればいい。あとは、MediaPlayerコンポーネントを使っていた部分をKBGMの関数に置き換える作業となる。

思ったよりすんなり移行できた。こんなことなら、もっと早くやればよかった。そういえば、演奏位置を表す赤い線の動きが、明らかにスムーズになった。今までのテストでは、Windows NT系は表示がぎこちなかったのだ。で、表示と演奏がぴったり一致した。今まであれこれやっていたのがアホらしくなってきた。KBGMが返す演奏位置の値は、ミリ秒の時間ではなく、MIDIデータに埋め込まれているデルタタイムと同じ単位なので、ややこしい計算をしなくて済むのもありがたい。

これで解決と思ったら、そうはいかなかった。演奏中に、演奏位置の情報がリセットされてしまうことがある。どうもこれは、フォーマット1のデータばかりで起こるようだ。使い方を誤っているわけではなさそうなので、MIDIデータの中身を見て原因を調べた。あ、わかった気がする。各トラックの長さに違いがあるデータの場合、短いトラックが終わった時点で演奏位置が0になっているようだ。この情報を頼りに表示を更新しているVisual Drumsは、まともにその影響を受けてしまう。

KBGMのバージョンは0.08で、1999年に公開されて以来、バージョンアップはされていない。まだ開発を続けているのかどうかわからないけれど、いちおう報告しておこう。

Visual Drumsの、表示タイミングを計算する処理を見直した。おかしいところは見つからなかった。先日の、計算式を変えたら一部のデータでうまくいったというのは不可解で、本来は今までの処理できちんとタイミングは合うはずだ。

前から気になっていたのだけど、MediaPlayerコンポーネントのPositionプロパティの値が、Windows NT系だと正確ではなさそうだというのが原因に思える。Windows 98とWindows XPのマシンで同時に演奏させて、Positionプロパティをリアルタイムに表示させたら、演奏は同じなのに、明らかに値がずれていくデータがあった。

開発に使っているのはC++Builder 4で、もうずいぶん昔の製品だ。発売されたのは1999年3月だそうで、Windows 2000が出る前ということになる。でも、Windows NTはあったわけだから、少なくともこれできちんと動作しないのはおかしい。

現時点の最新はC++Builder 6なのだが、これでも2002年3月発売ということで、さほど新しくもない。Personal版なら1万円なので、買い換えようかとも思ったけれど、あまり変わりはなさそうだし、MediaPlayerコンポーネントがどうなっているかは、使ってみないとわからない。

なんにしても、今のままでは直せそうにないので、別の手段で演奏処理をさせることを検討中。

お絵描きしぃちゃっとの接続監視ソフトは、それなりのものができたので、PaintChat Monitorという名前で公開することにした。公開するとなると、ドキュメント類が必要になって、コーディングよりもそっちのほうが大変だったりする。

自宅にある環境は、Windows 95/98SE/NT/2000/XPで、だいたいはチェックできる。Windows Meのマシンも以前はあったのだけど、Windows 2000にしてしまったので、再セットアップしないと使えない。Windows 95のマシンは、PC-9800シリーズの古いノートPCで、起動させるだけでも時間がかかってめんどくさい。今回は、Windows 95では動かない機能を使っているので、最初から対象外にした。

汎用的なポート監視ソフトとして設計することもできたけれど、目的を明確にしたかったので、あれこれと手を広げるのは、とりあえずやめておいた。

Visual Drumsの修正に疲れたので、気分を変えて、お絵描きしぃちゃっとの接続監視ソフトを作ろうと思い立った。それで気分転換になるのかというと、これがけっこうなる。新たにソフトを作るのは、実に5年ぶりになるので、あれこれ考えて作るのが楽しい。

サクサクと作っていき、順調だと思っていた矢先に、ちょっとミスってC++Builderが固まってしまった。こういうときに限ってファイルを保存していなくて、ソースもフォームもほぼ初期状態に戻った。あぁ、やってしまった。まだやる気はあったので、すぐに作り直して、できていたところまで復活させた。こういうときの勢いは大事だ。で、同じ失敗をしないよう、自動保存の設定をしておいた。

自作のWindows用ソフトを公開するようになったのは、いつからだっけと思って調べたら、1998年だった。そこそこ長いわりには、意見やバグレポートをメールでもらったことが非常に少ない。知名度が低くて、使っている人が少ないからだろう。それと、そういうことをわざわざ報告してくれる人が減ったのではないかという気もする。というのは、2001年8月を最後に、全くそういうメールが来ていないからだ。まぁ、サポートに手間がかからなくて、それはそれで助かる。

雑誌への収録依頼は、頻繁に来る時期があったけれど、2005年になってからは一度もない。もう、オンラインソフトを大量に集めて、雑誌に収録する時代は終わったなと思う。

Visual DrumsのWindows NT系への対応中で、演奏と表示がずれると何度も言っていたけれど、テンポが途中で変化するデータで問題が起こることがわかった。計算式を変えてみたら、ぴったりになった。ただ、こうすると今度は、フォーマット0でテンポが変化するデータや、Windows 98を使ったときにずれてしまう。ちなみに、フォーマット0のデータは、変更前の処理ではうまくいっていた。

つまり、どの環境、どのファイルでもずれずに表示できる処理にはなっていない。なんでOSを変えるだけで結果が違うのかは、相変わらず疑問が残るけれど、どうやら根本的に、表示タイミングを計算する処理を見直さなければならないようだ。おそらく、フォーマット1のデータに対する処理が怪しい。うーん、今日はもうくたびれた。

Visual DrumsをWindows 2000やXPでも使えるようにと修正しているけれど、ちっとも演奏と表示が同期しない。何年やってるんだろう、これ…。

Visual Drumsで使っているマルチメディアタイマの代わりに、C++Builderに付属しているただのTimerコンポーネントで試してみた。演奏と表示がずれるような作りにはしていないつもりなので、表示がもたつくだけだろうと思っていたのに、これでもずれる。MediaPlayerコンポーネントのPositionプロパティおかしくね?

Windows NT系では、ファイルの扱いが少々違うようだ。Visual Drumsでは、RCPファイルの場合はSMFにして演奏しているのだが、そのテンポラリファイルをきちんと開放しないと、次に変換したデータを同じファイルに書き込めない。これは、MediaPlayerコンポーネントを一度Close()することによって解決した。しかし、ずれが直らないことには使いものにならないな。

Windows NT系でもVisual Drumsの画面が動くようになったものの、演奏と同期しないことが多い。だんだん表示が遅れていくものや、はじめから表示のタイミングが早すぎたり遅すぎたりするものなど、さまざまだ。

今週はずっとマルチメディアタイマの精度について調べているが、だんだん疲れてきた。ちなみに、Windows 98だとぴったり。くそ。

マルチメディアタイマのコールバック関数内では、使えるAPIが限られているらしい。なるほど、これが原因か。熱中していたら、朝の5時になってしまった。

Windows NT系でVisual Drumsの画面が動かない原因がわかった。MediaPlayerコンポーネントの、Modeプロパティの値の変化を契機にタイマを動かしているのだが、それが正常に取得できていないので、いつまで経ってもタイマの開始が呼ばれないのだ。呼ばれたとしても、今度はPositionプロパティの値が不正なので、演奏と表示を同期させることができない。まるでだめだ。この件に関しての情報は、Webにはなさそうだな。

もう世間でも、Windows 2000やWindows XPを使っている人がほとんどだと思う。となると、多くの人はVisual Drumsを使えないことになる。何とかしたい。

…うーん、だめだ。タイマイベントが発生してくれないので画面が動かない。単純にMediaPlayerとマルチメディアタイマのコンポーネントを使っただけのものでテストすると大丈夫なので、何かが干渉しているような気がする。