話が進んで参りました。
まず今年度から同じ研究室に入ってこられた方（社会人です）から誘われて W3C の WCAG (Web Content Accessibility Guideline) の公式文書を和訳する仕事（報償もある）を一緒にやらせていただく事になりそうです。 ビバ「コネ」（笑）。
また、本日 CD を数枚買いました。
やっぱり PLAID はすごくいい。 他はまだ聴いてないです（苦笑）。
さて、SOL2 プラグイン第二弾であるリストエディタの作成はちゃくちゃくと進んでいます。 見た目は普通のリストエディタですが、 各ブロックのイベントはもちろんトラックやブロックの位置や名前まで編集できるものにするつもりです。 これがグラフィカルなインターフェイスを前提にしている DAW ソフトにごくごく小さなパラダイムシフトを起こすものであればいいなー、などと思ったています（笑）。 現段階で思い描いている、エディタ内部で扱うデータモデルは 感覚的にはディレクトリシステムに近いものです。 具体的には「各ソングの中にトラックがたくさんあって、 各トラックの中にブロックがたくさんあって、 各ブロックの中にイベントがたくさんある」 というもので、VectorWorks の SDK の影響をとてもとても大きく受けています、というかそのまんまです（苦笑）。 本当にやりたいモデルは VectorWorks のように 「トラックも、ブロックも、ノートも、CC も、何もかもは "Sequence Object" である」と考え、総称します。 操作はすべて Sequence Object へのハンドルを使い、 例えばトラックなのかノートイベントなのかを意識しないような考え方で構築したいと思います。 まあ恐らくムリでしょうけれど。 ちなみに次のようなコードでプログラムできればなあと思っているわけです。
int rc; // returned code
Handle rootObj;
Handle song;
Handle track;
char trackName[256];
// オブジェクトツリーのルート（ソングの親）を取得
rootObj = MP_GetRootObject();
if( rootObj == NULL )
{
return false;
}
// 最初のソングを取得
song = MP_GetFirstMemberObject( rootObj );
if( song == NULL )
{
return false;
}
// このソングのトラック名を次々とメッセージボックスに表示する
track = MP_GetFirstMemberObject( song );
while( track != NULL )
{
// トラック名を取得
rc = MP_GetObjectName( track, 256, trackName );
if( rc == NULL )
{
break;
}
// トラック名を表示
MessageBox( this->m_hWnd, trackName, "トラック名", MB_OK );
// 次のトラックへ
track = MP_GetNextObject( track );
}
なお、これは MP を GS に変えるとほぼ VectorWorks SDK のコードです（苦笑）。
アクセシブルに作るのは大前提なので少しずつ Microsoft Active Accessibility (MSAA) の仕様を眺め始めています。しかし、前述の方から聞いた話では MSAA はじき無くなる・・・もとい新しい規格 User Interface Automation (UI Automation) に統合される、という話があるそうです。 従ってリストエディタに MSAA を適用するべきなのか、UI Automation の仕様が固まるのを待つべきなのか？などと考えていたりします。 ・・・が、よく考えるとたとえ MSAA が廃止されたとしても UI Automation でのアクセシビリティ機能が MSAA と同じ概念（各コントロールごとに名前、役割を記述する、など）を使う可能性は高いですね。 少なくとも基本的な部分の概念は同じになるでしょうから、MSAA で実装してしまいますか。
近況。
メインのテキストエディタを K2Editor からサクラエディタに代えました。 理由は、ThinkPad のスクロール機能と K2Editor の相性が悪いため（妙に動作が重い）。 また、サクラエディタは C/C++ の構文を解析して関数を一覧表示、ジャンプできたりする。 カスケードした名前空間でもちゃんと解析してくれる。 これは結構嬉しいですね。 さらにオープンソースの C++ プログラムなので何か自分にとって欲しい機能ができた場合、 自分でその機能を作って追加できます。まあ実際やるかどうかという話は別ですが、 Delphi で作られたエディタだったらオープンソースだろうと手が出ないですからね（笑）。
Diamondback というゲーマー向けマウスを買いました。 一般のマウスでは解像度が 400dpi なのに対し、 この製品は 1600dpi というトンデモナイ解像度を持っています。 つまり普通のマウスと同じ設定で Diamondback を使った場合、 普通のマウスのつもりでカーソルを動かすとその 4 倍の距離だけカーソルが移動します。 ここでカーソルの移動速度を 4 分の 1 に落としますと、 普通のマウスの 4 倍の精度でカーソルを操作する事ができるわけです。 私の趣味である FPS というジャンルのゲームではこれの恩恵をかなり受ける事ができます。 ちなみに値段は 8 千円程度なので別段高いわけではありません （Microsoft の IntelliMouse Explorer 4.0 は 7 千円だったし）。
SOL2 用プラグイン第 2 弾、設計の大枠ができました。 結構前からちょっとした夢だった MIDI のリストエディタ（ステップエディタ、イベントリストなどとも言う？） を作ります。 COM はまだイマイチしっくりこないのですが、 前回の Randomizer のおかげで OPT で利用する分にはある程度の理解ができました。 従って、あと知っておく必要があるのは、いくつかの OPT 用 COM インターフェイスの使い方と、 「MSAA」です。 そうなのですが、OPT の SDK が 1.0 から 1.1 (StudioConnections に同梱される midiplugin.h のコメントの中に OPT SDK 1.1 という記述がある) になると対応プラットフォームに MacOS X が入るわけですね。 Randomizer は GUI を思いっきり MFC で作りましたが、 これは GUI が簡単だったからです。 MacOS X 版を作る時に GUI 部分を一から作り直したとしてもたいした手間になりませんが、 エディタとなるとそうはいきません。 そこで Win/Mac 両環境でソース互換のある GUI ライブラリで、 さらにアクセシビリティに気を遣っているもの・・・ という事で Qt/Windows に目をつけています。 ただ、まだフリー版が公開されていないので待つか、先に MFC で Windows 版を作ってしまうか考え中。 まあ、実際にはもう owner draw 部分を実装したリストコントロールができているので後者になりそうですが。
Randomizer をバージョンアップしました。 日本語版ダイアログの追加とヘルプの加筆、です。 これで英語環境では英語のダイアログが、日本語環境では日本語のダイアログが表示されるはずです。 よく考えると OPT プラグインの MIDI エフェクトはおそらく SOL 以外で使えるソフトが無いと分かっていながら SOL 用の具体的な説明が無かったんですね。 という事で、Randomizer のヘルプと Randomizer のダウンロードページに説明を追加しました。
CD を数枚購入。 Kyoto Jazz Massive の RE:KJM が欲しいのに CD 屋に行くといつも売ってない・・・。 早く eclipse の Sleep Walker リミックス？（まだ詳しく調べてない）を聴きたい（苦笑）。
自作 OPT プラグイン「Randomizer」公開。 ユーティリティのページからどうぞ。
あととてつもなく関係無い話ですが Shuriken Pro 4 買いました。
さてさて、作っていた OPT プラグインができあがったわけですが・・・ COM サーバーなのでレジストリをいじらないとインストールできません。 公開するにはインストーラが必要です。 しかし私はいわゆるインストーラを使った事がないのでどうしたものかと思案中。 まあ良い機会なので NSIS に手を出してみますか。 というわけで予定よりも少々公開が遅れます。
それと Studio Connections Total Recall の SDK を入手しました。 まだ中身はほとんど見ていないのですが、個人的にうれしいと思ったのは正式に MacOS X に対応している事ですね・・・というよりも Windows 以外のプラットフォームを考えて作られている事がうれしいんですね。 私は、GUI などプラットフォームに依存する部分以外でプラットフォーム依存の機能を使うのを嫌っています。 例えば MFC で作ったウィンドウのクラスのメソッドで CString を使うのは問題無いと思いますが、プラットフォームに依存しない処理の実装部などに 「使えるし便利だ」からといって CString を使うのは意識的に避けています。 その関数を MFC が無い環境にコピーできませんから （ソフトウェア工学でいう「凝集度」でしたっけ？（笑））。 あとは例えば単純に何かの数やサイズを返す関数で DWORD を使う、なども非常に嫌いです。 こうする人たちに聞いてみたいのですが、何故 unsigned long にしないのでしょうね？ unsigned long で実装しておけば何の手間も無くプラットフォーム非依存で使える関数になるというのに。 ・・・と、愚痴はさておき・・・もう夜遅いので寝ます（苦笑）。
現在制作中の OPT プラグインがほぼ完成しました。 いつだったかどこだったかに書いたと思いますが、ベロシティ、ノートの長さ、 発音タイミングをある割合以内に収まる範囲でランダムに変化させる MIDI エフェクトです。 「べたうち」したパートのベロシティ設定が面倒な時に、 そのパートの各ノートのベロシティをグラフ表示してランダムツールでランダマイズしていた （私のような）方には「使える」エフェクトになると思います。 いつの間にか超えていた一万アクセスの祝いをかねて近々公開、といきたいところです。
やっと安定して動く OPT プラグイン（のひな形）ができました。 野望は・・・もうすぐそこに！（笑）
ところで私は LPMPEVENT とか REFMPEVENT とかそういうマクロは大嫌いなんですよ。 ポインタなんだから単純に MPEVENT *、MPEVENT & と書けばいいだろうと思います。 ポインタである事を隠す事で何かメリットがあるかといえば、 ローカル変数で LPMPEVENT 型の変数を定義して領域を与え忘れて参照して異常終了させたり、 引数が LPMPEVENT という型の値引数だと見た目（アスタリスクがないから）で勘違いして NULL チェックし忘れて「ぬるぽ」出したり、 個人的にはデメリットしかないと思いますね。 当然これらはあっという間に修正されるバグですので大きな問題にはなりませんが、 バグの元になりうる事をわざわざ手間をかけてする理由などないと思います。 そも LPxxx というのは xxx という型の変数への long ポインタ（コンピュータ的にはただの long でアドレス値を格納）を表すものであって、ハンガリアン記法と同じ思想から生まれたものだと思います。 ハンガリアン記法は型情報を変数名に含ませる事で変数の型を毎回調べる負担を軽減するという思想ですが、 これは型情報を正しく含ませる事を前提にしています。 例えば short 型の変数を、整数だからといって iXXXSize と命名した場合、 他の人が int 型だと勘違い（普通はする）して、GetXXXSize( &iXXXSize ); といった使い方をしたらどうでしょう？オーバーフローしますよね（int が 4byte で short が 2byte の一般的な環境の話）。 このようにハンガリアン記法で命名された変数を命名者でない人が使う場合、 基本的にその命名者を信用するよう心理的に強制される事になります。 たとえ接頭辞が間違っている事に気づいていたとしても、 無意識レベルで働くその強制力は絶対に思考の妨げになりますし、 矛盾している名前を使い続ける苦痛を味わう事にもなります。
なお、ハンガリアン記法そのものが嫌いというわけではありませんのであしからず （LPxxx というのは型の命名であって変数の命名ではない）。 型が重要、という場面で使えば非常に有効な記法ですしね。 ただ、何が何でもハンガリアン記法を使おう、というのはどうかなーと思いますけれど。
Windows の関連づけ設定の仕組み という記事を追加しました。
Windows XP になったとたんに関連づけがうまく働かなくなった という話がいろいろな日記や掲示板などでよく見かけます。 具体的には「関連づけ設定を変更しても『Windows 画像とFAXビューア』が起動 してしまって困っている」というものですね。 どうやら PerceivedType という仕組み（？）が関連しているという事で、 実際私も叔父の PC を設定する時に困った覚えがあります。
そういう現象が起こる原理も分かりましたので、 レジストリをいじりまくっても分からなかったという経験を持つ方はぜひ （レジストリをいじった経験がない方は読んでも何がなんだか分からないかも）。
今頃ですが、トップページのフッターにある著作権表示を2005年に対応させました（笑）
ひょんな事から Ruby をちょこっと（ほんとうにちょこっとです）いじる機会を得ました。 Ruby くらいに高級な言語なら foreach みたいなものがあるかな、 と思って調べてみると、なんとも面白い構文を使うんですね。 例えば要素が"a"、"b"、"c"である配列がある時、 次のコードを実行したとします。
# Ruby のソース
itemCount = 0
// 配列に格納された文字列を一つ一つ表示していく
someArray.each{ |item|
print 'someArray['
print itemCount
print "] == " + item + "\n"
itemCount = itemCount + 1
}
ちなみに C# だとこうなるでしょうか。
// C# のソース
int itemCount = 0;
// 配列に格納された文字列を一つ一つ表示していく
foreach( string item in someArray )
{
Console.Write( "someArray[" );
Console.Write( itemCount.ToString() );
Console.Write( "] == {0}\n", item );
itemCount = itemCount + 1;
}
出力結果は、次のようになります。
someArray[0] == a
someArray[1] == b
someArray[2] == c
C# の構文は私にとって非常にわかりやすい構文ですが、 Ruby の構文はかなり理解しにくかったです。 結局リファレンスで調べるまで分かりませんでした。 まあこういうものは文化なので「だから何だ」というわけではないですが、 言語ごとの違いも面白いですね。
キーボード配列の好みはその人が慣れ親しんだ環境によって違い、 例えば CapsLock の位置に Ctrl があって欲しいという話はよく聞きます。 ともかく Microsoft がそれを知って知らずか用意した機能について少々説明を書いてみました。
プログラミングの世界における、「ハンドル」の概念について。 ずーっと曖昧な理解をしたまま今日まで来ていたのですが、 今日一つ進歩しました。 まあ完璧な理解をしているのか、と言われるとまだ曖昧な部分もありますが、 概念の大筋は理解できていると思います。
まず、ハンドルについて解説しているウェブサイトは極めて少ないです。 また見つかった（日本語の）解説の多くは アスキー用語辞典の解説 と同じ内容です。 この辞典によると「このハンドル値はオブジェクトごとにシステム内でユニークな数値」となっています。 しかしハンドルがウィンドウを識別する数値であるならば、 ハンドルが void 型のポインタで typedef されているはずがありません。 もし ID だというのなら普通に long などで typedef するでしょう。 これは Visual C++ 6.0 に付属する winnt.h の207行目を見ると次のように なっているのが確認できます（なおVS.NET 2003でもBCC5.5でも同じ定義）。
typedef void *HANDLE;
これはGDIオブジェクトへのハンドルも同じ定義になっています （NEARはWindows3.1との互換性のためにあり、 プリプロセッサによって空白文字に置き換えられる）。
typedef void NEAR* HGDIOBJ;
一方、HWNDやHFONTなどは次のように違う定義になっています （実際はDECLARE_HANDLE(HWND);となっていますが、マクロの実行結果はこのような定義文になります）。
struct HWND__{
int unused;
};
typedef struct HWND__ *HWND;
これについてはちょっと自信が無いのですが、 int 一つ分の大きさを持つ構造体へのポインタと定義しているのだと思います。 構造体にしてある理由は、void * で typedef した場合と違って次のように型チェックが行われる為でしょう。
void NonsenseFunction( void )
{
int anInteger = 1234;
HANDLE fooHdl;
HGDIOBJ gdiHdl;
HWND wndHdl;
HFONT fontHdl;
fooHdl = &anInteger; // エラーが出ない！
gdiHdl = &anInteger; // エラーが出ない！
wndHdl = &anInteger; // エラー
fontHdl = &anInteger; // エラー
}
さて、話をハンドルそのものに戻しましょう。 ほとんどのプログラムは自分が使用するメモリ領域を確保します。 しかし古い時代のコンピュータはすべてのプログラムが同一のメモリ空間を使用していました。 この状態ですと、システム全体の安全性に問題があるのは良いとして（全然良くないが（苦笑））、 いろいろなプログラムが確保と解放を繰り返すうちにメモリ領域が分断されていきます。 ハードディスクの断片化と同じ原理です。 しかしハードディスクと違い、 メモリ領域における断片と断片の間にある未使用領域はなかなか再利用されません。 というのもメモリ領域は連続的な領域を確保するため、 広い領域から優先的に確保されていくからです。 これは C 言語の配列とポインタの関係を考えるとわかりやすいでしょう。 このような断片化は、メモリ容量が小さい頃には深刻な問題になりました。
ここで、プログラムによって確保された領域を「動かす」 事ができれば隙間を無くする事ができますね。 しかしプログラムはメモリ領域を確保するとその領域のメモリアドレスをポインタとして取得します。 もし確保された領域を OS が勝手に違う領域へと動かせば、 その領域を参照していたポインタはその領域とは違う場所を指す事になります。 つまりプログラムに断わらずに領域を動かすわけにはいかないのです。
では、領域を「動かす」にはどうすればいいのでしょうか？ 答えは「ポインタのポインタを使用する」です。 まず、プログラムには特別な関数を使って領域を確保させます。 その関数は呼ばれるとまずメモリ領域を確保し、 そのアドレスを指すポインタをどこかに格納します。 ここで、そのポインタを OS(?) に登録します。 そしてそのポインタを格納した場所のアドレスを、プログラムに返します。 つまりポインタのポインタを返すのです。 これをハンドルと呼びます。 ハンドルを取得したプログラムはハンドルのみを用いて処理を行い、 ハンドルが指す先のポインタは直接参照したりしないようにします。 こうすると、例えばハンドルを複製してもその先にあるポインタは不変なので、 OS が領域を移動してそのポインタの値が変化させられても元のハンドルと複製されたハンドルは影響を受けず、 有効なままです。 これだけで領域を OS が動かせるようになるのです。 なお、「特別な関数」とは Win32 API でいうと GlobalAlloc() などです。
以上、現在理解しているところのハンドルの簡単な説明でした・・・って、また結構すごい文量になってますね（苦笑）。 今は Java に C# にと C に比べて超高級（笑）なプログラミング言語がどんどん現れているわけですが、 「ポインタは要らない」とか言っても何だかんだ言って結局ローレベルな知識もある程度必要なんじゃないかなと思いますね。 今挙げた両言語にも「参照」という形でポインタ的な考え方が残っていますしね。 まあ、ともあれハンドルは一般的なプログラミングで使う技術ではないと思われます。 昔と違ってメモリもふんだんにある時代ですので、そもそもこういった技術はあまり必要とされませんしね。 ですが、考え方は非常に面白いと思います。 まあ何にせよハンドルという言葉は MSDN を見ていてもそこら中で出てくるので意味を知れたのは良い事だと思います。
あ、最初の話ですが、 HWND などはおそらく関連づけられたウィンドウの情報を格納した構造体へのハンドルなどではないでしょうか。 予想するに、ヘッダファイルにはその構造体へのハンドルのみを定義し、 その構造体の定義はソースファイルに書いてあるのだと思います。 こうすると C 言語の場合ヘッダをインクルードすると HWND を使用する関数群を使う事はできても HWND が指す構造体（ここではHIDDEN_HWND_STRUCTとします）の定義がヘッダに無いので
( (HIDDEN_HWND_STRUCT*)*hFooWindow )->m_Member1 = foobar;
などと直接構造体を変更したり、
HIDDEN_HWND_STRUCT * hFooWindow = new HIDDEN_HWND_STRUCT;
などと直接生成したりできないようになります(HIDDEN_HWND_STRUCTは隠されている本当の構造体の名前の代わりです)。 Adobe の Illustrator Plugin SDK や Apple の Carbon API もこうしていますよね。
最後に、MSDN の 16bit Windows から 32bit Windows への移植に関する文書をリンクしておきます。 訂正情報を求めつつ（笑）、今日はこれにて。
本日購入したCD群。
もじぴったん関係です（笑）。
新年明けましておめでとうございます。 というわけで、去った年2004年を購入したCDを通して見る。
数えてみると合計23枚ですか・・・思ったより少ないですね。 っていうか、12月の頭に行われたWarp Recordsのクリスマスパーティー。 このフライヤーって・・・（苦笑）。
一覧の中のリンクは基本的に試聴できるページへのリンクですが、 中でもリンク先を訪れる価値があるという意味でオススメなのはOE、Mellow、Plastikman、The Get Up Kidsです。 特にThe Get Up Kidsはアルバム全体をストリーミングで試聴（音質的にもかなり良い）できるあたり、 音楽著作権業界への反発などを感じるような感じないような。 その点、Sigur Rosも同じようなスタンスですよね。 あとMillencolinなんですが、Home From Home収録のHappiness For Dogsという曲がUnreal Tournament 2003というゲームのムービー（ゲームプレイムービーでオフィシャルではない） のBGMとして使用されていて、それを聴いて買おうと思いました。
このムービー、著作権的にはかなり黒に近いグレー・・・というか黒ですが（笑）、 調べてみるとあのムービーを見てMillencolinを買った人は私以外にも結構います。 少なくとも、 私を含むこの人達は音楽の著作権をギチギチに堅く考えたくはないでしょう。 音楽はたばこのような他人に迷惑がかかるものでもないですし、 もっと気楽に楽しめるものであって欲しいと思います。 どこかの名前がJで始まる 「ファイル共有ソフトでMP3ファイルが違法に大量にあからさまに悪意を持って流されているのに、 そのほとんどがかなりの品質低下を伴うアナログコピーである耳コピMIDIのコミュニティサイトなどに課金して、 さも自分たちは著作権保護活動をしているのだと世間、業界にアピールして取り繕った極めて矮小な営利団体」 は、私は嫌いです。 くるりの岸田さんじゃないですが、 「違法コピーがどうのこうのと騒ぐ前に良い曲を書け」ば良い。 アイデアをパクっただけの二番煎じのダメ曲のせいで色あせてしまう程度の音楽しか作れないのなら、 才能が無いのだからプロとして音楽を作るのをやめて違う職につけばいい。 CDが売れなくなった理由を違法コピーのせいだとしてコピープロテクト技術を導入した各レーベルの行動を否定はしません（CCCDはどうかと思いますが）。 しかし耳コピMIDIを駆逐しようという動きには賛同できませんね。 耳コピMIDIは数万円する対応音源を買わなければまともに聴けないので決して安いわけではありません。 つまりそのコミュニティにいた人達は明らかに音楽に興味を持っているのです。 それならば気に入った曲のCDくらい買います。 あの団体がCDの売り上げ低下を受けてMIDI課金に動いたのかどうかは知りませんが、 そうだとすれば明らかに八つ当たりです。 まあ実際には楽譜の売り上げ低下の影響でしょうけど。
もっとも、 彼らの主張と私の主張には音楽を「曲」として見るか「音」として見るかの違いがあります。 つまり曲として見る場合、メロディやコード進行のような音符の並びに著作権が発生するのでしょう。 従って完璧に耳コピされたMIDIファイルは曲としてオリジナルと全く同等になるといえます。 一方、音として見る場合、その波形を再生して「同じ音源だ」と分かるかどうかでオリジナルと同じかどうかを判断する事になると思います。 すると歌モノの耳コピMIDIなどは全く別物であり、MP3ファイルは同一であるといえます。 正直に言うと、私にとってこのあたりはどうでもいいのですが（苦笑）、 今の時代、音楽を曲として見るのはもう古いのではないかと思います。 現代音楽はすでに音の創作になっていますし、 そもそも音にこだわらない音楽は昔から存在しないでしょう。 大抵のメロディはよく言われるように出尽くしたパターンの切り貼りで構成できると考えられますので、 完全に新しいメロディというのは既に創作不可能。 「音を楽しむ」と書いて音楽。 音楽の本質は音にそもそもあるのです。・・・たぶん。
えー、新年早々問題発言っぽいです（苦笑）。 書いてる時間が長すぎて途中で思考が暴走しました。 ちょっとツッコミを入れると、個人的に歌は詩を音楽に乗せたもので、 相乗的な効果や価値があるとは思いますが著作物としては別個に切り分けて考える方が良いと思います。 つまり歌詞と音楽の組で一つの著作物ととらえるのではなく、 歌詞と音楽を別々の著作物としてとらえ、楽曲はあくまで組み合わせただけのものと考えます。 そうしないと同じ歌詞で違うメロディの曲や、 同じメロディで違う歌詞の曲が「違う曲」になってしまいますから。
だからこの日記長いって・・・（苦笑）。 切り上げるために書き始めた前段落はまた話が広がりそうだったので打ち切りまして、 ここらで本当に終わらせたいと思います。 まあ何はともあれ今年も平和な年でありますように。