T's Weblog

ワイパーを交換した。今回は、ワイパーブレードごと買った。塗装がかなりはげていて、見た目もよろしくなかったので。ワイパーゴムは、交換してからそんなに経っていないような気がしていたけれど、もう1年以上も前のことだった。

実は、今までワイパーブレードの交換をしたことがない。カレンは、一般的なU字フックタイプで、何も道具は必要なかった。ゴムだけ交換するより楽だ。

ワイパーゴムは半年、ワイパーブレードは1年で交換という情報をよく見かける。ゴムはともかく、あの金属のブレードが1年というのには、少々疑問を感じる。そんな頻繁に交換している人は、ほとんどいないような気がする。

Firefox 1.5をインストールした。1.0.7をアンインストール後に1.5をインストールという手順で、問題なくこれまでの情報は引き継げた。

IMEがONのときにアクセスキーが使えない問題は直っていなかった。また先送りか…。これに一番期待していたのに。

[ブックマーク]メニューにある[ブックマークの管理]のメニュー項目に、アクセスキーがなくなっていた。たぶん、登録したブックマークの先頭文字とかぶってダイレクトに移動しないのを避けるためだと思うけれど、ブックマークの管理ウィンドウを開くのが面倒になってしまった。しょうがないので、猫まねきで[Alt+B][↓][↓][Enter]を[Ctrl+B]に登録して、一発で出るようにした。

最も気になったのは、メニューに立体感がなくなって平坦になったことだ。標準のコントロールを使っておけばいいのに、わざわざこんなことをする意味がわからない。Windows XPのデフォルトのウィンドウスタイルを使っているのなら気にならないのだろうけど、クラシックスタイルを使っている人には違和感ありまくり。どうにかならないものかと調べたら、Classic Menus for Winstripeの拡張機能を使えばいいことがわかった。なぜ標準にするために拡張機能を使わなくてはいけないのか、理解に苦しむ。

「進む」「戻る」が高速化されたのは素直に喜べる。あとは、URLの入力欄でアンダーバーがいつも見えるようになったことや、ダウンロードマネージャがきちんと自動で閉じるようになったことなど、細かい修正もされている。オプションの画面をあんなに変える必要があったのかは疑問だけど。

現在使用中の拡張機能。

• Tab Mix Plus
• Text Link
• Popup ALT Attribute
• Super DragAndGo
• Classic Menus for Winstripe

今まで使っていたSuper DragAndGoが、Firefox 1.5に対応していなかったので更新したら、仕様変更されていた。上向きにドラッグすると、開いたタブがアクティブになり、下向きだとバックグラウンドになる。今までどおり、いつもアクティブにしたいのだが、あいにくその設定がない。くそう。

BH6のBIOSのバージョンを、最新のSSにした。最新といっても、2000年にリリースされたものだけど、今までそれより古いLNを使っていた。

BIOSのファイルは、Download BIOS for BH6のbh6ss.exeで、実行するとBH6_SS.BINができる。

BIOSをアップデートするには、awdflash.exeが必要で、ABIT Utility DownloadのABIT BIOS flash utility v8.23Kを使う。

アップデート方法は、BIOS Upgrade Guideに従ってやればよい。実行するコマンドは、以下のとおり。

awdflash BH6_SS.BIN /py /sn /cd /cp /cc /cks /R

実行後は、何もせずに待っていれば終わる。

19時ごろに、コジマから電話があった。PSXの修理が終わったという連絡だ。店が閉まる前に取りに行った。5年保険を使ったので、修理代はタダ。

今回の修理の受付日は2005年11月24日で、修理日は2005年11月29日だった。やはりHDDが交換されていた。時刻が遅れることの対処については、特に何も書かれていなかった。まぁいいけど、仕様ってことかい?

交換部品・補充部品名の欄には、ハードディスク(S-U9)とホジョザイリョウヒと書かれていた。なんだかよくわからない。ちなみに、最初の故障で修理に出したときの明細書には、ハードディスクドライブとだけ書かれていた。

箱を開けると、本体以外に、入れたはずのない四角い物体が入っていた。何をくれたのかと思ったら、裸のHDDが袋に入っているではないか。詳しいことは別の記事で。

今回も最初から40GBがゲーム領域になっていた。HDDを交換すると、これがデフォルトなのだろうか。必要ないので、ゲーム領域はゼロにした。

ハードディスクのアクセス音が、前のと明らかに違う。きっと種類が違うのだろう。調子が悪かったころ、動作音にはかなり敏感になっていたこともあって、これはこれで大丈夫なのかと気になる。電源が切れたときに、いやな音がするタイプだな。

とりあえず、また使えるようになった。あとどれくらい動いてくれるのだろう。

修理されたPSXとともに裸で入っていたHDDは、おそらく交換前のものだろう。Maxtorの6Y160P0らしい。PCにつないで確認することにした。

Windows 2000の管理ツールで、ディスクの管理を見ると、そのディスクが認識されていた。それに、ちゃんとディスクが回転している。ドライブが物理的に壊れていたわけではないようだ。ただ、不明なディスクになっていて、さすがに中身の状態はわからなかった。もう中のデータにはこだわっていないので、フォーマットすることにした。しかし、パーティションの作成コマンドが淡色表示になっていて使えない。どうすればいいのだろうとしばらく悩んだあげく、メニューに[著名]というよくわからないものを見つけたので実行した。どうやらこれが関係していたようで、種類が不明からベーシックになり、パーティションの作成ができた。

このマシンはWindows 98とのマルチOS環境なので、FAT32でフォーマットしようとしたら、最大容量ではフォーマットできなかった。そういえば、Windows 2000やXPでは、32GB以上をFAT32でフォーマットできないんだった。Windows 98で起動したら、無事にフォーマットできた。逆にWindows 98では、大容量のパーティションの作成ができないらしいけれど、先にWindows 2000で作成しておいたから問題はなかった。ただし、BH6という古いマザーボードなので、128GBまでしか認識しなかった。

フォーマット後に、念のためスキャンディスクでチェックした。Windows 98だと、ほかに何も起動していなくてもメモリ不足と言われたので、Windows 2000でチェックした。いろいろと制約が多いな。結果、不良セクタはなく、ディスクに問題はなかった。ほんとにこれはPSXに入っていたやつなのかと疑問に思えてくる。

これで、OSが3つ入った10GBのHDDと、60GBのHDDという中途半端な容量のマシンに、160GBのHDDが加わった。あったらいいな程度には考えていたけれど、わざわざ買うほどのことでもないと思っていただけに、この増設はうれしい。

CPU使用率が100%の状態が続いたら再起動するソフトを作る必要はなかった。

最初に着目したのは、Windowsの「パフォーマンス ログと警告」という機能だ。これを使うと、CPU使用率の監視ができて、制限値を超えたときにアラームとしてプログラムの実行もできる。[管理ツール] - [パフォーマンス]を実行して、[パフォーマンス ログと警告]のツリーを展開すると、[警告]という項目がある。ここで新規に警告を設定すると、CPU使用率の制限値を超えたときに何かプログラムを実行するようにできる。

さっそく設定してみたが、どうもうまくいかない。というのも、開始直後にCPU使用率が限りなく100%近くになるのを検出してしまい、必ず警告されてしまうのだ。制限値を100にしたら回避できたが、そうすると「100を超えたとき」という条件になり、今度は全く引っかからなくなる。そんなわけで、どうやって使ったらいいのかよくわからないので、この方法はあきらめた。

もう少しオンラインソフトを探してみると、CPU5(ゴー)というソフトを発見した。CPU使用率が一定時間、設定値より高いか低いときに、指定のファイルを実行するソフトで、まさに必要な機能が実装されていた。GUIが少々独特だけれど、やりたいことはこれでできることがわかった。付属の再起動のバッチファイルに書いてあるshutdown.exeはWindows XP用なので、Windows 2000の場合は代わりにVBスクリプトなどを使えば問題ない。

再起動時のログについては、UNIXのdateコマンドっぽい出力をするものをPerlで書いて、バッチファイル内で実行することにした。出力先をファイルにして、SSIでそのファイルを#includeで取り込めば、再起動した日時を絵チャの入り口ページに表示できる。DOSのコマンドのdate /tとtime /tでも日時は出力できるけれど、出力するフォーマットが決められないのでPerlで書いた。

追記:
ログの生成はOS起動時に実行したほうがよさそう。

お絵描きしぃちゃっとのサーバで、Javaのプロセスが暴走すると、CPU使用率が100%になってマシンに負担がかかる。そこで、遠隔で再起動ということも考えていたが、誰かがメールで教えてくれないと、いつ再起動したらよいのかがわからない。

いっそのこと、CPU使用率が100%の状態が続いたら、自動的にマシンを再起動するようにしてしまえばどうかと思った。これなら、外出中や就寝中も安心だ。さらに、再起動時にログを生成するようにして、絵チャの入り口ページで参照できれば、利用者にも状況が伝わって便利そうだ。

では、そういったソフトがあるかというと、探し方が悪いのかもしれないが、見つからない。サーバマシンには有用だと思うのにな。CPU使用率が下がった状態になったら再起動やシャットダウンをするソフトならいくつかあったけれど、その逆の設定ができないようだ。見つからないなら作るか。おもしろそうだし。

19時ごろ、コジマから電話があった。修理代の見積もりの話だ。やはりHDDの交換で、細かい金額は忘れたが、17,000円くらいと言っていた気がする。もちろん、5年保険を使用することにした。この金額なら、全額負担してもらえる。

この週末は、お絵描きしぃちゃっとのサーバを立てていた。ルータがあるおかげで、サーバ専用マシンと、メインのマシンを分けて使えて楽だった。

今回は、wjview.exeを使った。約33時間で落ちた。前回立てたときと比較すると、jview.exeでもwjview.exeでも、そう変わらないようだ。たぶん、人の出入りの量も関係していそうだから、単純に時間だけで判断してもしょうがないかもしれないが、せめて数日程度は稼働してもらいたい。次は、SunのJavaで試してみるか。

プレイヤーズ王国(現在はMySound)でよく音楽を聴いている。ここは、ヤマハが運営している音楽コミュニティサイトで、オリジナル曲だけでなく、コピー曲も無料で公開できる。著作権料はヤマハが払うシステムなので、個人でも安心して既成曲を発表できる。ただし、コピー曲はストリーム方式のみの配信となるので、ダウンロードして保存することはできない。なお、公開できるコピー曲かどうかは、J-WIDで調べて、インタラクティブ配信が可能なもののみとなる。

X JAPANの曲をいくつか聴いた。ギターが生演奏で、その他のパートが打ち込みという作品が大半だ。ギターがマジでうまくてびびる。オリジナルと区別がつかないほどのものもあった。ギターは全然弾けないので、どれくらい難しいことなのかすらわからないけれど、ここまで弾けたら気持ちいいだろうな。もったいないのは、ドラムの打ち込みが単調だったり音色がダサかったりで、全体のクオリティを下げてしまっていること。速いテンポで連打する曲が多いので、ベタ打ちだとリズムマシン丸出しになってしまう。もっとここにも凝ったらいいのに。

ゲームミュージックは、ドラクエばかりだった。配信できる曲が、ほとんどドラクエしかないという事情もあるのだろう。ちょっと調べたら、ロマサガはダメっぽい。その他、知っている曲を中心に、あれこれ聴いてみた感想としては、やはり同じような傾向があって、ギターの演奏はうまいのに、ドラムの打ち込みが単調という作品が目立つ。それはまだいいとして、単音で打ち込んだだけとか、ちっとも楽しめないアカペラも多い。せめてアカペラだけ隔離できないものか。

次のページと前のページの記事の続き。要約すると、「次のページ」や「前のページ」という表現は、新しい順に並べられている記事に対して使うと、少し混乱するという話。今回は、向きの情報を付加した場合のことを考える。

単に、[前のページ] [次のページ]というリンクが並んでいると、どちらが過去の記事に進むリンクのか迷うことがあるのは、前回書いたとおり。これが、[< 前のページ] [次のページ >]となっていると、かなり解消されると思う。一度、[次のページ >]が過去のページへ進むことだとわかると、次も「→」の向きに進めばいいという意識が読み手に生まれて、迷うことがなくなるのではないか。

そこで、[< 新しい記事] [古い記事 >]という表現を考えてみる。「→」の向きに進めばいいという利点は、そのまま受け継いでいるけれど、少し気になることがある。通常、時系列で物事を考えるとき、横方向の場合は「←過去 未来→」という意識が働くが、それとは逆になるのだ。しっくりこないという意見があるのは、このためだろうか。ただ、[次のページ >]でも、新しい順の記事の場合、結局は過去に進んでいることになるのだが。

では、[< 古い記事] [新しい記事 >]はどうだろう。これも混乱しそうだ。なぜなら、「→」の向きが過去の記事になるサイトが多く、それと逆になるからだ。と、書いていて、本当にそうだろうかと少し調べたところ、So-net blog、goo ブログ、はてなダイアリーは、「←」の向きが過去の記事に行くようになっていた。わりとメジャーなところで存在するようだ。「←過去 未来→」と一致するので、理にかなってはいるのだが、「←」の向きにたどっていくのは、ちょっと違和感があった。

興味深いのは、「<< NEXT || BACK >> PAGE[1][2][3][4]」が使われているケースもあることだ。この表記は、お絵描き掲示板に多い。[BACK >>]で過去のページに行くので、次と前の表現が逆になっているが、今までこれで混乱したことはない。ページ数の情報とともに使われているからという理由もあるかもしれないが、どうやら言葉の表現方法よりも、自分が読み進めていきたい向きの表現が明確であればよいのではないかという気がしてきた。

なお、向きを表すときに、「>」と「>>」のどちらが適切かという話もある。「>」よりも「>>」のほうが、向きを表していることを強調できる。ただ、「>>」の場合、末尾にダイレクトにジャンプするという解釈をされる可能性もなくはないので、多少注意が必要かもしれない。そのまま「→」を使えばよいではないかとも思ったが、逆に露骨すぎるからか、あるいはページを切り替えるというイメージとは少し異なる印象があるからか、あまり使われているのを見たことがない。

このブログでは、[新しい記事] [古い記事]だったのを、[< 新しい記事] [古い記事 >]の表現にしている。ベストではないが、悪くもないのではと思った。[< 新しい記事に戻る] [古い記事へ進む >]というのも考えたが、これだとややうるさい。

ふと、[↑新しい記事] [↓古い記事]なんていうのも思いついた。向きとしては、まさにこのとおりなのだが、これもいまひとつか。というのも、「↑」は、そのページのトップへ移動する記号として使われることが多いからだ。「↓」も、これよりさらに下へ行けるような気分になる。どうも上下の方向は、別のページへ移動するというイメージがわきにくいようだ。きっと、本のページをめくるときは、たいてい横方向の動きになるからだろう。

というわけで、最良の表現方法は、よくわからないままだ。新しい順に並んでいる記事を、古いほうへページをめくって読み進めるためのナビゲーションというのは、案外奥が深いものだなと思った。

ブログでよく見かけるのが、記事の途中に「続きを読む」や「more」などがあって、全部読むには、そこをクリックする必要がある記事だ。ネタバレが入っているとか、隠すことが非常に効果的であるという意図でやっているのなら、まだ理解できる。ものすごく長い記事に対してのみ使っている場合も、まぁ仕方ないと思う。しかし、最初に数行だけ書いてあって、すぐに「続きを読む」になっている記事ばかりのブログは、正直なところ面倒で読む気がしない。

ひとつのページになるべくたくさんの記事を表示させたいけれど、長くなってしまうから、読みたい記事だけクリックして読めるようにしてあるのかもしれない。しかし、読みたいかどうかさえ判断できないものばかりだと、片っ端からクリックして読んでいかなければならない。こんなことなら、最初から全部表示させておいてくれたほうが、流し読みができて助かる。全部読むかどうかは、それで判断したい。

ページが長くなるからというのは、もっと別に原因があることも考えられる。たとえば、左右にごてごてとメニューをつけていて、肝心の記事本文の幅が極端に狭いから、縦に長くなってしまっているのではないか。あるいは、記事本文の幅が、ブラウザの幅よりもずっと狭い幅で固定されてしまっているからではないか。

理想的なのは、読み手がワンクリックで、そのページの記事を全部展開できるような手段を提供することではないだろうか。

テクニカルコミュニケーター協会のサイトに、カタカナ表記検討ワーキンググループのページがある。ここにある、外来語(カタカナ)表記ガイドラインは、ゆれが激しいカタカナ表記に対してガイドラインを設けて、表記の統一を図ろうというものだ。

現時点では、カタカナ表記の末尾の長音符号についてのガイドラインがPDFで公開されている。アンケートを盛り込んだ、約80ページものPDFになっているが、要は「コンピュータ」→「コンピューター」というように、伸ばす表記で統一したいらしい。

仕事でも、そうでなくても、伸ばさない表記をよく使うので、そっちかよという気もするけれど、わかりやすいといえばわかりやすい。言葉によって伸ばしたり伸ばさなかったりだと、どちらにすべきか悩むからだ。実際に、この問題にはよく悩まされる。

ただ、今まで伸ばさないほう主に使ってきただけに、全部伸ばす表記に変えるのには抵抗がある。特に、これをIT用語に適用すると、たちまち素人くさくなる。その考えをまず改めなければならないのかもしれないが、たとえば仕事でいきなり自分だけそうしても浮いてしまうだろう。言葉の表記の統一は望ましいので、賛同したいところではあるけれど、一斉に変えようという動きがないと、ちょっとやりづらいというのが実情ではなかろうか。

きっと、次に検討しているカタカナ表記のガイドラインは、「ー」と「イ」のゆれについてではないかと思う。「プレー」と「プレイ」のようなやつ。

今日も動かなかった。このままでは不便なだけなので、さっさと修理に出すことにした。PSXカルテに、時刻の遅れがひどいことも書いておいた。

PSXを購入してから1年を過ぎたので、通常は有償となる。でも、コジマのDVDレコーダー5年保険に入っているので、2年目ならPSXを購入した金額の80%まで補償してくれる。存外な修理代でなければ、全額それでいけるだろう。ただ、この保険は5年間のうちに1回しか使えない。次回また壊れて、有償の修理になるような事態になったら、新たに別のを買うことにするだろうけど。

それにしても、1年ちょっとで、初期不良ではない故障が2回とは運が悪いな。

PSXが全く起動しない。壊れる前兆は8月からあったので、覚悟はしていた。

今まで、おかしくなったときは、電源を何度か入れ直したら復活していたけれど、もうそれも望めないような動作音になった。何度試しても、カシャッカシャッと小さな音が鳴っているだけで、ハードディスクが回転しないのだ。前回の故障とは音が違うけれど、症状は似ている。

ひょっとしたら、ハードディスク自体は壊れていないかもしれないというわずかな希望もあったりするのだけど、修理に出すと交換される可能性が高そうなので、録画してあった番組は消える運命にあるだろう。あーあ。

この前の部屋の片づけのときに、ほとんどのマンガを売って、むやみに買うのをやめることにしたけれど、みなみけは買ってしまう。

2巻もボリューム満点で、期待を裏切らないおもしろさだ。1巻ほどの奇抜なセリフや突拍子もない展開は少なかったけれど。シンプルイズベストな絵には磨きがかかって、眺めるだけでも楽しい。こんなふうにきれいに髪が描けたらなぁ。

2巻では、内田さんの出番が、登場人物の紹介に載っていてもいいくらい多くなっていた。1巻から注目していただけに、これはうれしい。

アニメ「灼眼のシャナ」のオープニングテーマ曲になっている『緋色の空(ひしょくのそら)』が気に入って、CDを買った。ボーカルの川田まみは、非常にいい声をしている。エフェクトがかかっていることを差し引いても、透き通った歌声が魅力的だ。

カッコいい曲なので、インストバージョンも楽しめる。可能なら耳コピして打ち込みたいくらいなのだけど、予想以上にごちゃごちゃと音が重なっていて、やる前からギブアップな感じだ。耳コピも打ち込みも、もう何年もやっていないんだから、いきなりこれは無理だろう。

もう一曲のanother planetは、落ち着いた雰囲気なのはいいけれど、激しくローファイな音は不要に感じた。特に最後のは、くどくて曲を壊しているような印象さえ受けた。何かを表現したかったのだろうけど、変なことをやらずにまとめてほしかった。そんなわけで、twilightバージョンのほうが聴きやすくて好きだ。

初回限定版のDVDの内容は、緋色の空のプロモーションビデオ、メイキング映像、灼眼のシャナバージョンとなっている。プロモーションビデオは、この手の映像に興味がないのでノーコメント。演奏している映像なら見たいと思うのだけど。メイキング映像は、灼眼のシャナのインストバージョンをBGMに、プロモーションビデオの撮影中の映像が流れる。寒そうというのが率直な感想。灼眼のシャナバージョンは、アニメのオープニングの長さで、オープニングの映像とは少し違ったものが流れる。初回限定版しか置いてなかったので、しょうがなくこれにしたのだけど、やっぱりDVDは必要ないなと思った。

ベランダが東向きということもあって、冬場は、ふとんを外に干せる日が少ない。そんなわけで、ふとん乾燥機を買った。三菱電機のAD-P60LSというやつ。半額以下で買えた。ブーツの乾燥機能をウリにしているようだけど、上位機種のAD-P80LSと機能は大差ない。

さっそく、ふとんに使用した。動作音は、まぁこんなものだろうか。エアコンよりは大きい音だが、テレビの音が聞き取りにくくなるほどでもない。この機種のふとん乾燥時間は55分だそうなので、1時間くらいやったところ、ふかふかになった。なかなかよい。ふとん乾燥機は、乾燥させる用途以外に、ふとんが温まるというメリットもある。

手持ちの丸型や角型のハンガーにカバーをかけて、衣類の乾燥もできる(まるごと衣類乾燥)。今まで使っていたハンガーをそのまま利用できるのが便利だ。この方式を採用しているのは、三菱電機だけなんだとか。特許を取得しているのだろうかと思って調べたら、たしかにあった。特許出願2001-112199、特許公開2002-306899の、「衣類乾燥ケースおよびふとん乾燥機」というのがそれ。特許電子図書館のサイトで簡単に調べられるので、興味があったら検索してみては。

で、1時間ほど衣類の乾燥をやってみたが、期待したほど乾かなかった。2時間やらないとダメか。しかし、そこまで時間をかけるなら、エアコンでいいじゃないかという気もする。自然乾燥よりは早いという程度に考えておくべきか。

U-siteという、ユーザビリティやインターフェイスデザインについての情報サイトがある。そこに、「Jakob Nielsen博士のAlertbox」を和訳した連載コラムがあるのだが、それについて気になったことがある。

スクロールとスクロールバーの記事で、横スクロールバーがユーザビリティを低下させているといった内容が書かれている。それはよくわかるけれど、少なくとも私の環境では、そのページ自体に横スクロールバーが出ている。おそらく、横が750ピクセルもある画像を表示させているからだろう。なお、該当する本家のページの、Scrolling and Scrollbarsでも、同じ画像が使われているが、左にメニューがないため、日本のサイトに比べて横スクロールバーは出にくい。

最初、これはジョークなのかと思ったけれど、どうやら画像の大きさの問題なので、みっともない記事になってしまっている。

インターネットの掲示板やブログでは、何件もの記事がサーバに保存されていて、通常は何ページかに分けて表示するようになっている。それらのページにジャンプする際に、たまにとまどうことがある。

記事を下まで読んで、その続きのページがある場合は、たいてい「次のページ」というリンク名で表現される。次のページへ行っても、まだ続きがあるときは、「次のページ」のリンクがまたある。そして、さっき読んだページは、「前のページ」と表現されることが多い。この「次のページ」「前のページ」が両方現れたときに混乱が生じる。

これは、掲示板やブログの大半が、新しい記事から順番に並べられていることに起因する。次のページに行くと、それはさっき読んだ記事よりも日付が前の記事ということになる。「日付が前のページ」が「次のページ」であり、「日付があとのページ」が「前のページ」なのだ。つまり、「前」という表現がどちらにも当てはまることが、混乱する原因だと考えられる。

以前、同じような内容の記事をどこかで読んだと思ったら、「こんど」と「つぎ」(3)がそれだった。Amebaブログを例にされているが、どうやら今は改善されて、別の表現になっているようだ。

「古い記事」「新しい記事」というのは非常にわかりやすいと思う。「古い」「新しい」という表現は、自分が次に読みたい記事がどちらなのかという意思と一致するので、間違うことがないからだ。しかし、フィンローダさんは、どうもしっくりこないそうだ。むぅ。

「<< 1 > 2 > 3 > 4 >>」とか「[1][2][3][4]」のように、ページ数を表示するのも有効な手段だと思う。ただ、この数字はクリッカブルな範囲が狭くて、クリックするのが難しいことと、ページが変わるたびにマウスカーソルを少し右にずらしてクリックしていく必要があり、手間がかかるという短所がある。

そういえば、ブログによっては、続きのページがあるのにリンクがないこともある。その場合、月別のリストから読むはめになるのだが、今読んだばかりの記事がまた表示されるので、次にどこから読めばいいのかがわかりにくいのが困る。

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では動かない機能を使っているので、最初から対象外にした。

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