Sr山本の曲の楽譜が手に入った。
主旋律と、コード進行だけ。
これだと、相当に手を入れないとだめかも...
まあ、アルペジオで伴奏を入れる程度で、とりあえずアップかな。
2006年12月24日日曜日
2006年12月20日水曜日
VoIP (続き)
つながらない。とりあえず SIP での通信そのものはできているようだが、認証で失敗する。Access Forbidden になる。
( まあ、何も反応がないわけではなく、返事が返ってくるだけ、まだ救いがあるのだが... )
一番、シンプルな構成の Rt-200KI -- X-lite2.0 の直結の構成でもダメ。こちらは、Missing Caller ID と言ってくる。
解説サイトを見ると、特に何の苦労もなくつながるように書いてあるのだけれどなぁ...
RT-200KI相手に話すのでなく、asterisk 相手に話してみた方が良いのかもしれない。
( まあ、何も反応がないわけではなく、返事が返ってくるだけ、まだ救いがあるのだが... )
一番、シンプルな構成の Rt-200KI -- X-lite2.0 の直結の構成でもダメ。こちらは、Missing Caller ID と言ってくる。
解説サイトを見ると、特に何の苦労もなくつながるように書いてあるのだけれどなぁ...
RT-200KI相手に話すのでなく、asterisk 相手に話してみた方が良いのかもしれない。
2006年12月14日木曜日
VoIP
いま、VoIP というか、ソフトウェアオンリーの SIP電話 を調査中。きっかけは、NTTの光電話アダプタの RT200KI というルータが、非公式ながら SIP の機能がある という記事。
X-lite という Windows用のクライアントソフトを使うと、IP電話として使えるらしい。
単に電話機能が使えるというだけなら、すでに、無料のSkypeがあるし興味をそそられることもないのだが、(Skypeのような独自プロトコルでなく)SIPやH323といった公開された規格の上で動作しているということだと話は変ってくる。
で、まあ、上記ソフトを入手してテストしてみたのだけれども... 一筋縄では動かない。理由のいくつかはすぐに見当がついて、一つにはソフトをインストールしたPCが ファイヤウォールの内側にあること。なのでファイヤウォールを通り抜ける工夫をしなくてはいけない。
まず最初にIP端末をレジストする部分で失敗する。まあ、レジストできなくても着信できなくなるだけらしいので、とりあえず無視して内線で発呼。ルータの発着信ログには残るくせに、相手の電話器が被呼されず。ムムム。
てなわけで、しばらく規格書なりVoIPの入門書なりを読んでみようかな...っと。
X-lite という Windows用のクライアントソフトを使うと、IP電話として使えるらしい。
単に電話機能が使えるというだけなら、すでに、無料のSkypeがあるし興味をそそられることもないのだが、(Skypeのような独自プロトコルでなく)SIPやH323といった公開された規格の上で動作しているということだと話は変ってくる。
で、まあ、上記ソフトを入手してテストしてみたのだけれども... 一筋縄では動かない。理由のいくつかはすぐに見当がついて、一つにはソフトをインストールしたPCが ファイヤウォールの内側にあること。なのでファイヤウォールを通り抜ける工夫をしなくてはいけない。
まず最初にIP端末をレジストする部分で失敗する。まあ、レジストできなくても着信できなくなるだけらしいので、とりあえず無視して内線で発呼。ルータの発着信ログには残るくせに、相手の電話器が被呼されず。ムムム。
てなわけで、しばらく規格書なりVoIPの入門書なりを読んでみようかな...っと。
2006年12月13日水曜日
JIS0213
文語訳(大正改訳)のPDF化が、予想以上にすんなりとことが運んで、さて次はどうしようということに。
問題点がないわけでもない。今は PDFJというPDF化ツールを使っているのだが、これの縦書き処理部分は未完成のように見える。とりあえず関係部分に手を加えて(quick and dirty hack というやつ)必要な処理だけは行なえる状態にしているのだが、あまり綺麗な状態とはいえない。一旦、XML風の中間形式に落とすという手法は正統的な方法だと思うが、その次のステップはむしろ、TeXのソースに落とすべきなのだと思う。
で、日本語 p(La)TeXの状況を調べてみると、どうも、JIS-X-0213対応はまだまだ開発途上というのが現実らしい。いくつかのパッチはあるようだけれども、これが決定版というものはないようだ。第三水準漢字はサポートしていても、第四水準漢字までは手が回っていないようにも見える。
もともと8bit文字用の処理系のTeXを EUCなりSJISに対応させることにすらいろいろ混乱があったので、すんなりコード拡張できない理由も理解しているのだが、もう TeX全体を 16bit化するべき時期なのだと思う。関連するツールをすべてアップデートしなければいけないというデメリットは
あるが、いつまでも8bitコードでもあるまい。
問題点がないわけでもない。今は PDFJというPDF化ツールを使っているのだが、これの縦書き処理部分は未完成のように見える。とりあえず関係部分に手を加えて(quick and dirty hack というやつ)必要な処理だけは行なえる状態にしているのだが、あまり綺麗な状態とはいえない。一旦、XML風の中間形式に落とすという手法は正統的な方法だと思うが、その次のステップはむしろ、TeXのソースに落とすべきなのだと思う。
で、日本語 p(La)TeXの状況を調べてみると、どうも、JIS-X-0213対応はまだまだ開発途上というのが現実らしい。いくつかのパッチはあるようだけれども、これが決定版というものはないようだ。第三水準漢字はサポートしていても、第四水準漢字までは手が回っていないようにも見える。
もともと8bit文字用の処理系のTeXを EUCなりSJISに対応させることにすらいろいろ混乱があったので、すんなりコード拡張できない理由も理解しているのだが、もう TeX全体を 16bit化するべき時期なのだと思う。関連するツールをすべてアップデートしなければいけないというデメリットは
あるが、いつまでも8bitコードでもあるまい。
登録:
投稿 (Atom)