CompactFM に関して気になる記述

CompactFM は視聴者向けのツールではなく配信者向けツールという旨の記述を Vector の説明欄に書いているのだが、あの書き方だとわかりにくいのでしょうか。

時代の変化と自分の変化

Blog が普及してからというもの、だんだんと個人サイトの運営スタイルも変化してきたように思っていたのだが、よく考えてみると実際には変化したというよりも今までサイトを持っていなかった利用者層が Blog を書くようになっただけなのではないかと思い始めた。

何の話かというと。

今までは個人サイトというのは基本的に借りたりするなどして Web スペースを確保し、そこへ html ファイルをアップロードすることで運営するのが基本的スタイルだったと思うのだが、最近では極端な例では Blog に未来の日付や過去の日付のエントリを作りそこへサイトとしての体裁を保つために必要なページを作ることで、Blog 上で全てを済ませてしまう人が増えたような気がしていた。
しかしそこを掘り下げて考えてみると、Blog の登場によって与えた影響はインターネットベースでの個人の手による情報配信の敷居を下げたことではないかと思う。恐らくずっとそういうものが望まれていたんだろう。そういう視点で見ると、簡単に個を主張できる環境として mixi が流行った理由のひとつとも考えられなくもないように思える。

HTML を覚えなくてもそれなりに使えるし、ブラウザがあれば一通り何でも出来てしまうような感じなので非常に手軽で確かに流行る理由もわからなくはないし、（何のために存在しているのかはわからないが）Blog に関する本もたくさん出ているようで取っ付きやすさも増して、「自分でも何かコンテンツ展開してみたい」と思う人が気軽に始められるような環境は整ったのかも知れない。
そういったいわゆる職人気質的なクリエイターではなく何となくサイト運営を始めるような人に取ってはデジカメの画像が掲載できれば大抵困る事はないと思うので、まさに Blog や mixi の日記などはそういう用途に適していそうな気がする。

で、話を戻すが結局のところ HTML を自分で記述できる人は今でも普通に Web スペースを借りてコンテンツ展開している人は少なくなく、それとは別に新たに Blog だけでサイトを構築するタイプの人が増えただけじゃないか、という話。
もちろん中には Blog に全てのコンテンツを置くように変更した人もいるだろうが、大多数の人が鞍替えをしたというわけではなくてまだまだ従来のスタンスで展開している人は多いんじゃないかな、なーんて。

NIH シンドローム

私はどうも長らくNIHシンドローム気味なところがあった。

中学生ぐらいの頃までさかのぼってみても、自分のサイトで使う日記や掲示板を Perl で作っていたりしていた。
もちろん中学生が書いたようなスクリプトなので高度なことが出来るものではなかったが、それでも日記に関しては過去記事編集、自動リンク、引用文の着色など自分が欲しいと思っていた機能は全て実装していた。掲示板はあまりやる気がなかったので名前と本文が書けるだけでレス機能もないようなものだった（どうせ書き込みなんてほとんどないだろうからその程度のもので十分と考えていた）。

ちなみになぜそこまで自作に拘るのかというと、当時考えていたことはただ「ページ下部に開発元リンクを入れたくなかった」というだけである。色々なサイトを見て回っても当時は自作でやっている人は少なく、そこに小さな憧れがあったのだと思われる。

それからしばらくした頃に PHP に興味を持って、少し触ると最初から用意されている関数の豊富さに惚れ込んで使うようになった。スクリプトの見た目も Perl のように難解な書き方がなくシンプルで理解しやすかったと思う。それ以降 Perl は使う事がなくなってしまったので、今では構文がほとんど理解出来ないところまで舞い戻ってしまった。
また PHP からはデータベースとの通信も容易だったので、過去に作った Perl スクリプトを一通り PHP で再実装した後にデータベースを利用した Wiki のようなものを自作したりした。ローカルに HTML を一切置く必要がなく管理が楽になると思っていたのだが、textarea の中で本文を編集するのは想像していたよりも面倒臭く、また HTML でバックアップを取るのも機能をちゃんと作らなかったため面倒で、更に追い討ちをかけるようにソースが比較的スパゲティだったので使うのはすぐに止めてしまった。

そんな個人的な格闘を繰り広げているうちに、日本にも段々と Blog ブームがやってきた（といっても本格的に流行り出したのは去年、一昨年あたりだと思うので、それより３～４年前で実際にはまだまだ流行っておらず言葉が知られ始めていた時期だった）。
トラックバックシステムや RSS への対応などは構造がシンプルなので実装は簡単だったのだが、いわゆる「ブログパーツ」のような個人で使うために作るものとしてはちょっと荷が重い部分が増えてきていた。

そんなこともあり、NIH シンドロームから少しずつ開放され始めている。
この通り今では Blog も Blogger で書くようになった。

QuadrupleD の DirectSound

QuadrupleD の DirectSound 周りの実装は色々と危ない香りがする。

まず最初に TDDSDCapture の問題。このクラスは一般的にはあまり使われるものではないと思うのでバグを持っているのは仕方がない部分ではあるのだが、相当前にQD3 の正誤表に書いた通りこのクラスにはリソースリークがある。
しかし実はその他に私は原因を発見出来なかった問題があって、このクラスを使うと不定期のタイミングでプログラムが例外を起こして止まる事があるように思える。これは原因がどこにあるのかハッキリと確証が持てなかったので Wiki では言及しなかったのだが、このコンポーネントを使用していると思われるねとらじステーションでは配信中にエラーを起こす問題があるという掲示板の書き込みを見た記憶があるので、恐らく何か抱えているだろうと思う。
実際自分で TDDSDCapture を用いて OggVorbis をリアルタイムレコーディング＋エンコーディングするツールを作った時にも不定期のタイミングで落ちる問題が起きていて、その時に自分で似たようなクラスを作り直した（ちなみに予想はつくと思うのだが、このツールでの経験をもとに CompactFM を作っている）。
それ以来同じトラブルにはまだ遭遇していない。

もうひとつ、さり気ないながら致命的な問題がある。
検索してみると過去に同じ事例があったようなのだが、QuadrupleD の DirectSound ヘッダを組み込むと ShellExecute の呼び出しが失敗するようになるらしい。
QuadrupleD に付属している DirectX のヘッダファイルは参照カウンタの扱いが特殊になっていて、自分で Release などを呼ぶ事でインスタンスの管理をしなければならないようになっている。それに関連しているのか、いくつかの場所で厄介な構造になっている事に起因しているのかも知れない。
この問題は Clootie graphics pages にて配布されているヘッダファイルを利用する事で解決できた。このヘッダファイルでは特に特殊なことはせずに素直に関数と構造体と定数を宣言しているようで、一部引数が var とポインタで違いがある部分や、参照カウンタを自前で扱う必要がなくなったので Release の呼び出しを削除するなど一部コードの修正が必要になったが問題自体は解消できた。
DDPD でもこのヘッダを使うと問題が解決することがあるらしい（未確認）ので、悩むことがあったらヘッダファイルの差し替えを検討してみるといいかも知れない。

TDDSD など頻繁に使われるコンポーネントは問題が露呈しやすく見つかっても大体すぐ修正されると思うのだが、TDDSDCapture など特殊な用途でなければあまり使われないクラスの場合は問題が見つかりにくいのだろう。
また、ShellExecute の場合もゲームなどの場合あまり使うことがないので恐らくあまり気付かれないままずっと使われてきたのだと思う。

以前不定期のタイミングで落ちるトラブルに遭遇した時点で TDDSDCapture を使うのは止めたのでこれ以上の問題追求や修正などを行うつもりはないが、今後同じトラブルに遭遇する人が出た時のために、一応こういう形で明文化しておくことにした。
この記事が役に立つと嬉しい。

CompactFM にあるといいもの

相変わらず妄想段階から抜け出さないのだが、どんな機能があればいいのか考えたりしている。

思いつく中で一番実装して価値がある機能は、配信しているデータのローカル保存機能。
私の配信している内容の場合「あんまり溜め込んでもなあ…」などと思うところがあるのでそれほど実装する事に重要性を感じてはいなかったのだが、他人が使う上で自分の配信を残すことを考えるならこの機能は結構重要な気がする。
まあ RAZIE などを併用することで録音する事はもちろんできるが、頭から欠損のないデータをネットワーク上の負荷ゼロで保存できることは地味ながら結構重要だろう。この辺は実装する事を考えていこうと思う。
録音中に容量が足りなくなった場合などを考慮して、予めドライブの空き容量不足を警告したりする機能があるといいかも知れない。

あと、これは自分でも必要と思いつつもまだ実装できていない部分なのだが、CompactFM の配信音量変更機能は若干問題がある。
もちろん機能的には正常な動作をしているが、音量変更が反映される周期が実は非常に粗い。
つまみを弄りながら「音量このぐらーい？」とかやると上手く行かないし、ミュートする場合などに不親切な部分が間違いなくあるのでここは修正したい。
あと、音量の変更をできれば滑らかになるように自動的にフェード処理をするようにしたい。動作の理想としては音量操作を行うと一定時間で音量変化していく感じで、変化幅が大きい場合は変化速度も速くなる感じで行きたい。
音量変化の実装自体は難しくないのだが、変更させようとした地点の記録をどうすればいいか迷っているのでこの辺はちょっと考え中。

それに関連して外部から音量変更出来るようにするインターフェイスを装備したいと思っている（プラグイン用の機能としてだけではなく CompactFM API としても）。
というのも、BGM を鳴らすためのツールなどをもし外部から準備する場合、PTT（Push to Talk 機能、ボタンひとつで配信中に発言用設定と音楽のみでの配信を切り替えるためのもの）を実装する場合に比較的重要になってくるのではないかと思うからだ。

現時点で BGM 配信のためのツールを外部の人が作ってくれる見込みはないのだが、API でのコントロールはできるようにしておいて損はないのでやろうと思う。
なお DirectSoundDUAL のように複数の音量調節項目を有している場合のために何番目の音量を調節するのか指定できるようにしようと思うので、音量調節に関して外部から変更する場合における制限などは特にない予定。

相変わらずやりたい事は減らない。

カレールーが入っている容器の名前

グレイビーボート、ソースポット、レトルトパウチ、どんぶり、などなど。

カレーうどんは、店によってスープを専用に作っている場合と、ただカレールーを上からかけるだけの場合と２パターンある。
後者の場合その工程の時点であまり期待は出来ないので、あまり胸は膨らませない方がいいと思う。

時間というものは

いくらあっても足りないけれど、無限に欲しいかと言われると決して欲しくない。

不思議。

USB ヘッドセットとサウンドカードでねとらじを放送する

拙作のインターネットラジオ配信ツール CompactFM は、元々は間違って Oddcast を終了してしまう私が自分のために作ったツールだった。

しかし作っている最中に「複数のデバイスから入力できるようにすれば、自分以外にも需要が出るのではないか？」と思い立ち、いつからか入力機能にプラグインシステムを搭載し、複数のデバイスから入力するための DirectSoundDUAL プラグインを作った。

このプラグインを使えば、例えば記事のタイトルにあるように USB ヘッドセット ＋ サウンドカードの音 という二つのデバイスの音をミックスさせて配信する事が出来るようになる。
だから「ただマイクが使いたくてヘッドセットを買ったのに、ラジオから声しか出せない」というしばしば起こりうる状況に対して対処できるようになっている（もちろん設定を変えてUSBヘッドセットからシステムの音声を出力するようにすれば回避できないわけではないが、なにより面倒臭いだろう）。

その他にも、例えば USB ヘッドセットを２つ繋いで放送したりする事も出来る（その場合は BGM などを流すのが手間になるが…）。
２つまでじゃなくて３つでも４つでもミックスできるようにすれば便利だと考える人も恐らく居るとは思うのだが、正直なところ個人的な用途で利用する場合は２つ以上使うケースというのは非常に稀だと思う。
そういう場合は複数のデバイスのバランスを適切に取らないと配信データが酷いことになるだろうし、使い勝手を考えるとミキサーを買ってきてツマミを手で弄ってバランス調節などした方がいいように思える（ついでにコンプとか通せばもっと良さそう）。

構想としては、もっと上を見ている部分はある。
例えば複数のデバイスからの音を入力して、リアルタイムにオーディオにエフェクトを施して声の音量を大体一定にして配信するだとか、そういう。
でも結局その辺は詳しい知識がある人じゃなければ滅多に使わないと思うし、少なくとも自分は使わないので実装にはあまり気が向かない。
（CompactFM のコアは自分で使っている限りでは今現在とても安定しているので、下手に弄らずにそのままで行きたいという考えもあったりする。）

一方で、宣伝や導入の際に敷居が高いように見えてしまっている部分もあるかも知れない。

個人的には CompactFM の初心者に対する手取り足取りのサポートをするつもりはまったくないので、導入方法に関するチュートリアルなどは同梱のヘルプ以外に用意する気はない。
サポートは非常に時間を要することで、自分のために作ったツールでそんなにサポートのために時間を割きたくない、というのが本心。
ただ、自分が使うためのツールなので機能に関しては自分が困らない程度に作りこんでいるし、自分のためにメンテナンスもそれなりにしている。
サードパーティ製ツールや、解説サイトなんかが今後充実してくれればいいのになあ、と思うところだ。

WINAMP を利用したツギハギな配信システムを脱ぎ捨てて、CompactFM を使うようになる時代がきたら、それはとても嬉しいことだ。
そのためには WINAMP で再生中の楽曲タイトルをリアルタイムに CompactFM に送りつけたりするような構造はきっと必要になるだろうし、作らないといけないのかなあ、などと思う。