きっちん

　Final Cut Express 4 (FCE) を使っていてハマったのでメモ。

　クリップが 2 つあり、その間に 4 秒のディソルブトランジションを設けたいとする。このとき 2 つのクリップは 4 秒の間クロスして再生されるわけだから、それぞれのクリップは 2 秒以上ないといけないのは理解できる。
　が、それぞれのクリップが 1 分あるのに、間にトランジションを設置しようとすると「内容が不十分なため編集できません」と言われることがある。

　ググっても出てこなかったので、FCE の英語版のローカライズ文字列を調べて "Insufficient content for edit." でググってみたら理解することが出来た。

　クロス再生する映像は、クリップのイン点、またはアウト点の外側が使用されるため、4 秒のトランジションを設けたいとすればイン点とアウト点の外側に少なくとも 2 秒は余白が必要らしい。

　最初は

// a.cpp
#include <stdexcept>
char array[128 * 1024]; // 128 KB
main()
{
    std::runtime_error e("e");
}

$ spu-g++ -Os -D NDEBUG a.cpp
/usr/lib/gcc/spu/4.1.1/../../../../spu/bin/ld: .bss exceeds local store range

みたいな何の変哲もないコードで SPE のサイズをオーバーしちゃってハマってたのね。

　で、原因を調べてみたら、どうやら原因は std::runtime_error が依存している std::string にあるらしい事が判明。

// a2.cpp
main()
{
}

$ spu-g++ -Os -D NDEBUG a2.cpp
$ ll a.out
-rwxr-xr-x 1 yoffy yoffy 97K 2008-08-30 11:01 a.out

// a3.cpp
#include <string>
main()
{
    std::string s;
}

$ spu-g++ -Os -D NDEBUG a3.cpp
$ ll a.out
-rwxr-xr-x 1 yoffy yoffy 167K 2008-08-30 11:04 a.out

　std::allocator を少し疑ったんだけど、std::vector は問題ないので std::string 側に原因がありそうな気がする。面倒くさいので細かくは追ってない。
　別に stdexcept や string が無くても困らないけど、SPE 用にもう少し考えてくれてもいいんじゃないだろうか。

// a4.c
main()
{
}

$ spu-gcc -Os -D NDEBUG a4.c
$ ll a.out
-rwxr-xr-x 1 yoffy yoffy 4.9K 2008-08-30 11:34 a.out

　…。
　何もしてないのに 97 KB も使うっておかしいなあとは思ってたんだよ。これ、libstdc++ が怠慢じゃない？コンパイラオプションで例外とか止めたら小さくできるのかな。

　もうだいぶ放置してある現象で、Karaoke が Mac OS X 10.5 で動かない。

NSColor * c = [NSColor whiteColor];
float r = [c recComponent];

　こんな単純なコードが動かない。
　今日重い腰を上げてドキュメントを読んでみたら、「RGBカラーでなければ例外を投げる」と書いてあった。whiteColor は RGB カラーではなくグレースケールカラーとして定義されているらしい。
　過去のアプリケーションとの互換性低すぎないか？これ。

　ということで、理由は分かったけれどもシステム標準の色からいつでも安全に RGB を得たい場合はどうすればいいんだろう。
　わざわざ変換しなくてはならないとか？
　それともシステムカラーは使えないものとして [NSColor colorWithCalibratedRed:green:blue:] で自力で解決するとか？

　Windows XP SP3 + IE7 でインストールした場合に KB950759 (Internet Explorer 7 for Windows XP 用セキュリティ更新プログラム) のインストールに失敗するので、それを無視する方法。

　Windows Update でダウンロードされて自動的に展開された update.ver の中身を消してから update.exe を実行する。以上。

　強制的にインストールするわけだから、その後に修正されたものも巻き戻してしまう可能性に注意。

　libspes(※)にioctl()を追加。

　あと他に何がいるかなあ。
　思いつくのはselect()とネットワーク関連かなあ。

　ただ出来るだけ SPE 側でプログラムしたいんだけれど、ここら辺は PPE 側で持つべきだよねえ。

※現在リンク切れです。とりあえずはhttp://yoffy.dyndns.org/svn/libspes/trunk/からどうぞ。

　パソコンには現在のステータスを表示するソフトや、ちょっとしたツールを提供する常駐ソフトが沢山ある。

　でも普段主体にならないソフトが主張してしまうと邪魔になるため、居場所をどうするかで様々な方法が模索されている。例えばこんなの:

• 常に最前面に張り付くフローティングウィンドウ。Dock、タスクバー、ランチャーなんかが相当する。はっきり言って邪魔。
• マウスポインタを近づけると最前面に現れるタイプ。やはり Dock、タスクバーが身近な例。間違えてポインタを近づけてしまい、誤動作する事が多い。
• ショートカットで最前面に現れるタイプ。身近な例ではSpotlight、Dashboardあたり。これが一番邪魔にならない。不満な点はそれぞれショートカットを覚えないといけない点と、常に状態を把握出来ない点。特にDashboardの電卓やDictionaryは文章を書きながら参照出来ないのが不満。
• フローティングウィンドウの逆で、デスクトップに張り付くタイプ。カレンダーソフトのようなものが多い。これは全く邪魔にならないが、ウィンドウやデスクトップのアイコンが多いと延々と情報に辿り着かない。
• ウィンドウにくっついてくるタイプ。ドローワーや、フローティングウィンドウで、常駐ソフトというよりも使っているソフトの機能でしかない。よく出来たソフトだと、ウィンドウを動かした時に自動的に避けてくれるものがある。ただ、左端から右端に一気に移動したりするので動きが大きくて目障り。あとやはりメインウィンドウとの重なり具合があるので画面が狭くなる。

　ここで一つ提案してみたいのが、浮き方の弱いフローティングウィンドウ。デスクトップに張り付くのではなく、勝手に最前面に現れる事も無く、メインウィンドウを移動した時に勝手についてくる事も無い。常にZがメインウィンドウの1つ下に存在するだけというシンプルなもの。フローティングウィンドウと同じで、上下左右もZも完全に固定されているので動きが全くない。つまり目障りにならない。名付けてハンギング(Hanging)ウィンドウ。

　フローティングウィンドウがメインウィンドウに重なると、最悪メインウィンドウのタイトルバーがつまめなくなったり、サイズを変えられなくなったり、ボタンを押せなくなったりと障害が大きいが、これも解消される。

　情報が裏に隠れてしまうのは自己責任で、ウィンドウの配置を試行錯誤して欲しい。ただ少なくとも、触る事が少ないツールよりメインウィンドウの障害を取り除く方が優先事項だと思うし、Dashboardを出したりデスクトップまで潜ったりするような大きな動作も要らない。

　これで電卓の値や辞書、メッセンジャーの状態が常に見えるようになると非常に便利だと思うのだが…