「サクラ」交流掲示板

ご無沙汰しております。以前ポストTWとしての新音源開発について書かせて頂きました。
前回は連絡先をお教え頂きありがとうございました。

実はあの後少し方針を転換しまして、DirectMusicを使わずに作ることに決めました。
そのためTakesoftさんにはまだ連絡を取ってません。
理由はDirectMusicは後継互換APIも含めていずれサポートが終わると考えられること、Linux環境でも動くようにコア部分を揃えたいからです。（WineもDirectMusicをサポートできてない）

開発の進み具合に関しては、まだコードは一行も書けてません。
現在は専門書を買って本業の研究の合間にMIDIの仕様、フーリエ変換やラプラス変換について勉強しているところです。
フーリエ変換やラプラス変換は分野柄方法論としてよく使うのですが、専門的な部分に触れるのは初めてです。

非常に長い道のりであるが故、完成までかなり時間がかかりそうです。
特に私は何事にも完璧を求める性格のためコーディングの遅さには定評ありです（苦笑）
しかしインラインアセンブラを使いこなしてクロック効率の高いプログラムになります。

実装予定の機能を草案として以下に列挙します。

・名前はExtMIDI
・2002年製のノーパソでもフリーズせず動作
・CPUの種類やコア数を自動認識して最適化
・WAVE、MP3、M4Aへの直接変換（256kbps対応）
・サウンドフォントやDLS差し替えによるカスタマイズ
・デフォルトのDLSはTWのものを使用
・MIDI音源として当たり前のリバーブ、コーラス、ピッチベンド
・VSTi対応（優先順位低め）


結論としてはTWと全く異なる音源になるので、ExtMIDIが完成してもTWはTWで愛用され続けるでしょう。
そもそもTWは完成度の高い優秀なAPIであるDirectMusicを使っているので、車輪の再発明したところで果たしてそれに張り合えるものができるかどうかやってみないとわかりません。
大元のPCMは同じでもスピーカーから出る音は処理によってかなり違ってくるそうです。

何か意見や要望等あればこの掲示板でもTwitterにでも書いて頂けると嬉しいです。
TwitterのアカウントはExtMIDIです。
https://twitter.com/ExtMIDI

では、今後ともよろしくお願いします。

なるほど。TWとは別の内容のものになるんですね

個人的にはTW-Music2に装備されていた曲掲示板再生機能をつけてもらえると非常にうれしいです。
曲掲示板に投稿されている曲を聞くことが出来るという機能です。
曲掲示板がPart.5のころは使えていたのですが、今ではエラーがでます。
投稿順や作者別などで聞くことができ、非常に便利でした。
ただ、これは相当難しいことのようなのでなくても構いません。
でもあったほうが掲示板自体が活性化します

さくら→TiMidiTy++に流し込んで、事実上 DAWにしています。

・サウンドフォントやDLS差し替えによるカスタマイズ

このような機能を搭載されるとのことですが、せっかくなら
timidity.cfg を読み込めたり、GUSPAT（こっちは音源）が
読み込めると、助かるのかもしれないです。

以下は、プラグインとかで対応できるといいのかも。。。

DLSやSF2は、そのまま使うだけではなく
EGやLFO、できれば、FilterEG (VCFのような感じ）が付けられるようにできる。基本はパラメータなしで再生するが、
ユーザー任意で使える。。。

FM音源シミュレータ

ご無沙汰しております。柚媛梁です。

曲板プレーヤは音源本体と比較してきわめて簡単に（あくまで本体と比較してですが）できそうなので実装します。
FM音源のほうはオープンソースのFM音源をどこかで見かけたのでそれを参考にやってみます。
その他の技術は勉強不足でわからないことが多いですが、順次チャレンジしていこうかと思います。

当面はGUIをなでしこで実装してコアの部分だけCで作る方針です。
曲板ブラウザはなでしこのHTTP関数群で簡単にできそうな気がします。
現在は絶賛修論なうですが、それと瑞にゃんの卒論が終わったら本格的に開発していく予定です。

お久しぶりです。
私事が忙しくて顔出せませんでした

FM音源はオープンソースですね。これは楽しみです
お手伝い出来ることがあるかもしれないので
また何かあれば掲示板に書き込んでください

音源の一つとして、ソースに、TiMidiTy++のConfigをつけておくと
自動認識でTiMidiTy++のWrapperになるようにするのはどうだろうか・・

と思うのだが、問題はそのguspatとサウンドフォント

確かに無料でDLできるものの、容易にかつ高速でダウンロードできるサイトなんて、まずあまりない。
それに、SoundFont関係のアップローダーは、死亡が多い・・・

SoundFontを自動HTTPダウンロードしたとしても、かなり激遅であることも考えられる
（手持ちで、１ファイル1.6Gのsf2が存在する）

今日時点での、うちの手持ちのsf2は、26.7Gbytes

確かに、無料でホスティング出来るところはあるにはあるが
運用も非常に面倒になってしまうだろう。。。

実は、今回、「AMD64」というもの、「超最適化コンパイラ」の存在があるんですよね。
＞しかしインラインアセンブラを使いこなしてクロック効率の高いプログラムになります。

うちも昔はその類のプログラマーでした。perlになってもある意味そうでしたが・・
しかし、今では、gccですらかなりやばい最適化をしてくれるようで。。。

とりあえず、高速化をあげるとしたら、このような感じで考えると良いのかもしれません。

１．むやみなステップ数の増加防止より、モジュールのサイズ低減を優先する
　→ループを上手に使ってL2キャッシュにヒットしやすくする
２．コアモジュールは、CPU相応にして1本とする
　→例）
　　x86 SSE1 DLL
　　x86 SSE1 SSE2 DLL
　　x86 SSE1 SSE2 CHORUS REVERB DLL
　　x86 SSE1 SSE2 SSE3 CHORUS REVERB DLL
　　x64 SSE2 SSE2 SSE3 CHORUS REVERB DLL
　　x64 SSE2 SSE2 SSE3 SSE4.1 CHORUS REVERB DLL (INTEL)
　　x64 SSE2 SSE2 SSE3 SSE4.1 SSE4.2 AVX CHORUS REVERB DLL (INTEL)
　　x64 SSE2 SSE2 SSE3 SSE4a CHORUS REVERB DLL (AMD)
　　x64 SSE2 SSE2 SSE3 SSE4.1 SSE4.2 AVX FMA3 CHORUS REVERB DLL (INTEL)
　　x64 SSE2 SSE2 SSE3 SSE4a FMA4 CHORUS REVERB DLL (AMD)

　　※x64からx86のDLLが呼び出せないとかいうオチはなしね
　　普通に、起動専用のexeからexeを起動すれば、x86からx64でもなんでも起動するし

このあたりのCPU判別と、詳細の計算ライブラリ（厳密にはマクロ）だけが
アセンブラになればいいのかな・・とも感じられる

　→言い換えれば、DLL間の呼び出しも、オーバーヘッド

３．無論、AMD64はコアなレジスタ数が倍になっている。（幅も倍だが）
　それだから直接速度が倍になるわけではないが、有効活用する。

４．外部計算モジュールが実装できる余地を残しておく？
　おかしいな、音を鳴らすために「GPUの力」を借りるなんて・・・