＃４GENＦＭ音源日記さらに遅くなる
■さらに遅くなる。（２００６－０１／２０） 昨日はＤＧＥＮの「ＦＭ．Ｃ」だけ弄ってた。 （注：このＤＧＥＮは１．００です。最新のＤＧＥＮはもっとずっと進んでいます。 スキルがあり、開発をしたい方は開発者に直接コンタクトをとって下さい。 私は開発者とは全く関係のない第三者です。 あくまでこのページの話は実験用途（教育用）です。）
昨日とまったく同じテスト。 昨日
| ＯＦＦ | ７９ｆｐｓ |
| １１０２５ｋＨｚ | ６９ｆｐｓ |
| ２２０５０ｋＨｚ | ６５～６６ｆｐｓ |
| ４４１００ｋＨｚ | ５６～５８ｆｐｓ |
| ＯＦＦ | ７７ｆｐｓ |
| １１０２５ｋＨｚ | ６７～６８ｆｐｓ |
| ２２０５０ｋＨｚ | ６３ｆｐｓ |
| ４４１００ｋＨｚ | ５５～５６ｆｐｓ |
「ＦＭ．Ｃ」はＤＧＥＮのというよりも「さとうたつゆき様のをみんながあれこれ弄った奴」と 言った方が正解。 アルゴリズムは変えないで、（管理人如きが変えられる訳がない）コーディングだけ変えた。 いつもと同じである。 ＰＣ（ＤＯＳ／Ｖ）のＰｅｎ２、Ｐｅｎ３マシンでは、（Ｐｅｎ４では実験してない。速過ぎてさ） それなりに実績のある最適化手法を取り入れた。 （ＤＯＳ／Ｖは、８６ＣＩＳＣしか解釈できないＲＩＳＣマシン。技術的には特殊な位置付け だと思うが、現実の世の中のマシンは殆どＤＯＳ／Ｖ） つまり、ずーーーーーーーと前に、管理人が趣味で（３つ程）ＤＯＳ／Ｖ用にメガドラエミュ （ソース公開されてる奴）を、カスタマイズしたり、高速化したりして、遊んでいた奴のうち、１つを。 っていうか３つとも音源部分はほぼ同じソース。参考にして、見ながらカスタマイズした訳。
話は変わるが、エミュを高速化させたい場合、管理人の経験から、一般的には 「メモリアクセス＞ＣＰＵ＞レンダーやレンダリング＞音源＞その他」 である。 だから、音源なんて少しぐらい変えたって、「ｆｐｓレベルで効く」とは思わなかった。 ＦＭ音源は、「浮動小数点演算のペナルティー」が大きいマシンでは、その辺を改善すれば効くが、 一般的には、劇的に速くなるものでもない。 （場合による。たとえばＦ３辺りは劇的に改善したＰＣＭ／ＡＤＰＣＭだからだ。）
コーディング手法とまったく関係ない話なんだが、ＹＭ２６１２のＤＡＣ、最近のソースでは チャンネル５のＯＰ４にわざわざ接続されているけど、これって意味あるの？ 昔みたいに、ミキサーに直接出力じゃあ駄目なのかな？ （チャンネル５とＤＡＣを同時に出力じゃあ駄目なのかな？） それとも、まさかとは思うけど、ＰＣＭにＦＭ変調かけられるの？それじゃあまるでＯＰＺだよ。 この辺どおなってるのかな？もう少しソースを精査する必要があるな。
この「ＯＰＺ機能」実機にあるとして、エミュでは外しちゃえば、構造的に少し整理ができるよなあ。 っていうか昔のソースに戻るだけなんだけど。
結果をみると、ＯＦＦで重くなってるし、単純に 「単にモジュールサイズがでかくなったから、配置が遠くなって重くなった」 のかもしれない。 まさか、ループ展開等という過去の手法を施した訳ではないよ。 そんなことしたら、現在のマシンでは、ずーーーーーと遅くなる。 管理人その程度の常識はあります。（いつもキャッシュを考えている） モジュールサイズがでかくなったのは別の理由です。（テーブル化でもないよ）
いづれにしても、Ｒ４０００のデーターシート取り寄せて少しお勉強した方がいいかも知れない。 キャッシュのサイズとか、キャッシュフローする条件だとか。
もし、パフォーマンスが上がるのならば、クラス化も検討事項かもしれない。 殆どの変数がprivateでいいし、publicにする変数は、ＳＡＶＥＳＴＡＴＥで使うデーター部分だけ。 ＳＡＶＥ／ＬＯＡＤするたびに、内部形式からデーター変換させる。 （現状内部形式が変わってるので、この話と関係なく、この部分を作る必要があるが、まだ作ってない）。 publicにする関数は、基本的にread,writeだけでしょ（もうちっとあるかも知れないが）。 Ｃのままならstaticだね。