つーさのくーかん

ソフトを作った。
リモートにあるMIDI音源を鳴らして、WAVEで拾って遠方で聞くソフト。

UIが味気ないのはまぁボク用ツールってことで気にしないω

続きを読む

Mimuraの独り言 ≫ Blog Archive ≫ やっぱり問題だよ。
http://mimura.dyndns.tv/blog/2007/09/17/%e3%82%84%e3%81%a3%e3%81%b1%e3%82%8a%e5%95%8f%e9%a1%8c%e3%81%a0%e3%82%88%e3%80%82/

昨晩、上記ブログ記事のコメントに適当なことを書きましたが、
今後もたぶんC#は流行らないと思っています。
.NET Framework が標準でOSに入っていないからだと思います。
ランタイムの再頒布パッケージが22MBもあります。
.NETを使う利点は「開発における生産性の高さ」ぐらいで、エンドユーザには
「ランタイムをインストールしなくちゃいけない」めんどくささを強要するばかり。
開発者のエゴでクライアントに迷惑をかけるだけですよ、こんなもの。
…… .NET 3.0 な Vista からは状況が変わってくるのかも知れませんが、
Microsoftの.NET戦略には正直あまり期待できません！
ちなみに、.NET、GDI+描画周りの動作がかなりトロトロですが、
単純な計算やメモリアクセスに関しちゃHSPより速いと思いますよ、試してませんがが！
いえ、C言語には敵いませんけど。
……今後はunsafeコードももう少し積極的に書いていこうかしら。

インフルエンザ？

Over39 とかどんだけ
自分の好きなことだけをやっていられるうちに、たくさん好きなことをやっておけ！
カレーパーティ参加したかったなぁ。
突然ですが、秋のFE受けますので同志の人はよろしく＞＜ｂ

C# で midiIn と midiOut を扱うクラスはできたけど、なんかめんどくさくなってきたので終了。
理由。

続きを読む

夜中に鼻血を出したので例の音いじり用プログラムをぼちぼち。
C++で書き始めたんだけど、VS2005のC++のいんてりせんすがあまりいんてりではなくて、MSDN読みながらじゃないとウィンドウさえ作れなくなってしまっていたので、やめました。
当時は、あのくらいの定数群全然気にならずに使えたのに、いんてりせんす慣れとは恐ろしいもので。
もうC++でGUIプログラム書けないかも。

まぁ、C#でMidiOutを扱うクラスは書けたんですが、midiInはどうしようかな。
データが入力されるたびに発生するコールバックに何を使うか。
Win32のWindowMessageかThreadかEventかFunctionか。
Functionにしてdelegate渡すのが一番良いんだけど、呼ばれたコールバック関数の中でバッファを再投入してはいけないことになっているのが問題。
再利用するなら他の方法を使えってこと？　っていうか、どうなのこの泥仕様^^;
あまりにもスマートではない気がする。
ところで、この場合の用法における「スマート」の反対語って何だろう。

むーω　なんでいつも同じことするかなぁω
そりゃ、LRでOgg読めるんだから、全部OggとPngにしてディスクスペース稼ぎたいよねぇ。

自分も書いてたり、それ＜この間の「こいつわどうすれば」
バックアップとるのを楽にするために。
ついでに、好きな楽曲を抜き出したり、曲再生＋削除ができる総合BMS管理ツールを目指してたり。
自前でBMSおすすめパック作り安いよーに。

続きを読む

またC++でWin32アプリなんか書いてる。
しかもコンソールなのは、Win32用のリソースエディタがついてないから。

インターネット経由でmidiデータをやりとりして、圧縮波形を返します。
サーバに繋がっているMIDI音源を鳴らして、その波形を得ます。
自宅にMU2000を起動状態にすれば、ネット上のどこからでもMUの音が、みたいな。

VSTiの時代に箱音源を鳴らしたいとか、.NETの時代にWin32だとか、いろいろ間違ってる気もする。
言語をC#にするかCにするか迷ったんだけど、C#だと、使うAPIを全部自分で宣言しなきゃいかんのでめんどくさいなぁ、と。
あぁ、C++/CLIにすれば、Frameworkも使えてAPIも使えるのかな。
なんか過去資産の悪いところだけ引きずってる気がするω

私はどうすべき？ω
　　→ なんかめんどくさくなってきたので中止