だらけた気分に喝を入れて、サクッと仕事に取りかかれる“引き締め系”ソフト

Vectorのソフトウェアスポットライトという特集でSmartAudioPlayerが紹介されていました。
最終更新から5年も経過しているので個人的には今更感があるのですが、
特定用途向けのシンプルさがいいのか、需要はあるみたい。
ありがたいことです。

CPUのクロックがギガ越えするかどうかという時期に、動作速度にはこだわって作ったソフトだけあって、
今動かすと軽すぎて笑えるんですが、それもまた一興。

逆に、初代SAPやSAP1xからSAPFxを見ると動作速度の面では全然で泣けてくる。
機能や曲の見やすさはいいとは思うんですが、無駄にリソースを喰う点で嫌われるのかも。
ホント、この辺は悩みどころですよね…。

.NETとWPFがこのぐらい軽くなってくれればいいのにｗ
それは無理な相談だろうけど。

またひとつ、SmartAudioPlayerに不都合が生じたようで、ちょっとため息な愁です。
今回見つかったバグは、書き逃げ板に書いてあるとおり、プレイリストファイルに関係するものなのですが、
プレイリストファイルによる再生は普段使っていないので気づきませんでした。(汗)

バグの１つは、プレイリスト内のファイルをすべて再生完了したときに、
『すべてのファイルが再生不可能だった』というチェックをしていないこと。

すべてのファイルを再生し終えると『再生済み』のフラグを外してまた選曲し直すんですが、
その際に、再生可能な曲が見つかるまで無限にループしちゃうのでフリーズしてしまいます。

もう１つのバグが、プレイリストファイル内のファイルパスに対する問題。
SAPがファイルパスを『絶対パス』として仮定しちゃっているので、『相対パス』だとファイルパスを間違えてしまいます。

フォルダをスキャンしてSAPにプレイリストを作らせると大丈夫なのですが、
ほかのアプリなどで、相対パスのプレイリストを吐き出したものを読ませるとアウトです。

相対パスに関しては、アプリケーションによって基準となるパスが違うので、何を基準にすればいいかわからないんですよね。
プレイリストファイルの位置を基準にするのが一番な気がするんですが、作成したときはそこまで気が回らなかったんでしょうね。

しかし、SAPが最後にリリースされて約2年半ですか…。

個人的には、今のSAPに満足しているところもあり、
開発環境の変化でコンパイルが通らず、作り直しが面倒というところもありで、
バージョンアップ等が全然出来ない状態になっているんですが、そろそろどうにかしないと不味いかもしれませんね。

どうせならC#で組みたいとか、そういう企みも邪魔して開発が進まないというのもあるんですが、課題も山積みです…。

コーディックのライセンス、音声のマルチチャンネル対応、キーフックでは取れないキーの対応、停止状態サポート、
ランダム再生の単調性の改善、DnDとか操作性の向上、そしてメタデータ(タグ)の対応…。
いっそのこと、DirectShow専用でというのも手とか思ってみたりしちゃう…。(汗)

４月１日といえば、エイプリルフールですね。
イントレ的にも、何かネタをやった方が良いのかも…と思っていたんですが、
今年も何もせずに終了したみたいです。

ＳＡＰも出来ることなら今日に間に合わせて公開したかったりもしたんですが、
さすがに２週間じゃどうにもならなかったみたいで。
一からの開発ですからね…。 しゃーないです。

新しいＳＡＰの試みとして、シークバーを導入実験しています。
再生位置を変えたり出来るアレですね。
また、それにあわせるカンジでボリュームコントロールの方のシークバーもテスト中。
ボリュームコントロールは、従来のＳＡＰやＳＡＰ１ｘは別ウィンドウに表示させていましたが、
今回はどうにかメインウィンドウ内に納められないか検討を重ねてるカンジ。

メインウィンドウの高さはタイトルバーorステータスバーの高さである、
18～24ピクセル以内で作成したいのでやっぱり配置に困ります。
削るとしたら、再生中の曲名を表示している部分と、上下の余白ぐらいか…。

しかし、どう考えてもシークバーに使えるスペースは4～6ピクセル程度。
スライダーコントロールはそんな幅では使えないので…自作するしかありませんね。(汗)

それから、プレイリスト部分もまだデザインが決まってません。
昔、ＳＡＰ２ｘ用としてバルーンデザインのリストをやったことがあるんですが、
あれはUpdateLayeredWindow APIを使っていたので、画面が32bit以外の環境ではまとも非表示も出来なくなります。
そうなると、それ以外の方法も検討しないと行けないですし…

悩めど悩めど、良いアイディアは見つかりません。
スキン切り替えの方も問題が微妙に発生してきたし…。

というコトで、今日は失礼します。

ウィルス『netsky.D』が鬼のように届いている愁です。
ＰＣに届いたメールはすべてケータイにも転送されるんですが、ケータイのメールボックスが埋まってしまいました。(汗)
困ったモンですな…。

さて、例によってＳＡＰですが、基本機能は実装し終わりました。
あとは、ウィンドウの位置を保存するとか、再描画のちらつき押さえるとか、
細かいところをやれば一段落です。

今はＳＡＰも見た目をそのまま持ってきてるんですが、ＳＡＰ１ｘモードとか、
新しい見た目のヤツも作らないとイケませんが…

あ。 キーフック忘れてた。(爆)

…ま、そんなカンジで微妙に順調に見える(？)今日この頃でした。

最近、夕方になると眠くなる愁です。
今日も午後５時頃にパタッと２時間ほど寝落ちしてしまいました…。(汗)

最近、日中の日差しが強くなってきたおかげで、
部屋の中が暗い状況が続いていますからね…。
一応、昼間でも電気を付けたりして明るさを保ってはいるんですが、
目の疲れが『明るさが足りない』と言っているようですね…。
夜の方が、目も疲れずコーディングしやすいです。(ぉ)

さて、ＳＡＰの方ですが、
各種ＤＬＬのラッパも作り終わって音楽の再生が出来ました。
OggVorbisの方は、SDKのバージョン上げたらコンパイルできなかったので、
とりあえず野村XXさんのVox.dllを使ってみました。
それから、DirectShow関係はManaged DirectXのAudioVideoPlaybackにバトンタッチ。

今回のＳＡＰから正式にはＷｉｎ９ｘをサポートしないつもりなので、
ＭＰ３再生にDirectShow使っても大丈夫だろうという判断から、
DirectShowの再生優先度を上げてみました。

将来的に、Longhornになったら真っ先にAvalonを使うと思いますが、
それまでは各自ＤＬＬに任せるしかないですね。

また、今回からＳＭＦナイフは切り捨て。
以前も実装したりしなかったりとあったんですが、
MIDIの配布も少なくなってきたと感じる今日この頃ですからね…。
再生はDirectShowがやってくれるでしょう。 うん。

しかし、.NETの仕様には良い意味で驚かされます。
アンマネージコードがよっぽど酷いモノでなければ、
殆ど.NET側で利用することが可能です。

アンマネージＤＬＬなどから関数を利用する手段として、
P/Invokeというのが用意されているんですが、
マネージメソッドとアンマネージ関数の間でマーシャリング(データの変換)が行われるんです。

文字列なんかは、Cだとchar *とかw_char *で表現されるんですが、
system.Stringで認識できるようになりますし、
配列もちゃんと変換されて、利用できます。

DirectShowとかが、Unicodeしかサポートしないっていってたときは、
わざわざＡＰＩ(しかもWin95じゃ使えなかった)で変換していたんですが、
マーシャリングによって、その辺も自動化されるってのはスバらしいことだと思います。

あと、もうちょっと速度が速かったら文句ないんだけどな…(笑)

そういえば、．ＮＥＴのコードって実際はどのぐらい重いんでしょ？
mp3とかOggVorbisのデコーダー自体を.NETで書いても使い物なるんだろうか？
一応、SharpZipLibという.NETオンリーのZIPライブラリがあるけど、
そんなに重く感じなかったから、もしかしたらイケるかもしれない…

では今日はこの辺で。