テキスケ

ｷﾀｺﾚ（毎度のごとく…

問題おきないといいんですが・・・（ドキドキ）
順調なら次はファミコン音源ですね。

ActionScriptがすごいことがわかったので、いろいろ環境整えて、結局自分でJSMMLをマージしちゃいました。
http://logue.be/Web%E7%B4%A0%E6%9D%90/JSMML.html

だいぶ、前のバージョンと音がかわってますね。

ブラウザが固まる環境があるようです。その環境でデバッグしてみましたが、よくわかりませんでした
revision 24583的なコードが入るといいのかな？

あとは、冒頭の１秒で再生が終了してしまう場合もあるようです。これは手元で再現できていません。

＞Logueさん
　どうもです！
　JSMMLはずっと古いままだったんですかね、きっと。はてなのMML記法もアップデートされてませんしね。ありがとうございました。
　前のバージョンと音が変わったっていうのは、同じMMLでも音が変わっちゃってますか？
　互換性は残してるつもりなんですが・・・。

＞グニャラくん
　固まっちゃいますか…。
　24583のバージョンでは何だかよくフリーズしてたのでその処理を止めて、安定したかと思ってたんですが・・・もうちょっと調べてみますね。
　１秒で再生終了っていうのはちょっとよく分からないです。どうやったら再現するんだろう。。

本当に微妙な違いなんですけど、若干低音域の音が違って聞こえます。フィルタのかかり方がちがく聞こえるというか。

それでも、確実に音切れが少なくなりました。

＞あとは、冒頭の１秒で再生が終了してしまう場合もあるようです。
マージしたJSMMLの場合、２回目を再生すると同じような現象が起きたり、一部の楽器が鳴らない事がありました。
もしかすると、一度最後までならした後、Playボタンを押すと止まるって事なのではないでしょうか？また、ブラウザの挙動が不安定になるのも２回目の再生以降です。

うーん。フィルタが入った頃からはあまりコード変えてないつもりなんですが、何かやっちゃったのかなぁ。

なるほど。二回目以降の再生ですね。
確かに終了処理などはいい加減なところがあるので、もしかしたら JavaScriptから起動する JSMMLやニコニコ大百科では問題が発生しやすいのかもしれませんね。
情報ありがとうございます！

僕の手元で固まるときには、LFOを使っているときのようです。１回目の再生から問題が発生します。
たとえばこんなMMLです。
http://dic.nicovideo.jp/b/a/%E3%82%B0%E3%83%8B%E3%83%A3%E3%83%A9%E3%81%8F%E3%82%93%20%E2%98%85/91-#96
http://dic.nicovideo.jp/b/a/%E3%82%B2%E3%83%83%E3%83%80%E3%83%B3/61-#71
@lの部分を全て抜くと固まらなくなりました。

LFO自体が問題なのではなく、LFOによって処理に時間がかかった時に何か起こっているものと推測します。
テストコードの実行や各種変数値など報告できますのでお気軽に！

お初です。mmlで書かれたちょっとしたピコピコサウンドを再生させたいと思っていたらこんなのがあるとは・・・渡りに舟という奴でしょうか・・・早速利用させてもらいます・・・
さて、ためしに自分のアプリに組み込んでみたところ、AIRで再生させると、再生終了後にフリーズしてしまいます・・・なぜ、、という訳で調べてみたところ、onSampleData内からstop()を呼ぶとフリーズしてしまうように見えます・・・そこで、直接stop()を呼ばずに、Timer(0,1)をかまして、タイマーイベントからstop()を呼ぶようにしてみたところ、フリーズを回避できるようになりました。
上のフリーズとは関係ないかもしれませんが・・・

はじめまして＞monさん
おお～なるほど！
onSampleData()からstop()を呼ぶとマズイっていうのはいかにもありそうですね。
２回目の再生で問題が起きてるのはこれかもしれないですね。
とりいそぎコミットしてみました。
他の変更もいれちゃったのでエンバグしてないといいんですが・・・。
ご報告＆ご指摘ありがとうございました！

おっと・・・Timerを使わずに、MSequencerの外側からstop()するような形に変更してみたんですが、これでも大丈夫かどうかは未確認です。すみません。
というかDebug用のFlashPlayerだと元々問題おきないんですよね、これ・・・。

えっと、結論から言うとダメでした・・・
dispatchEventは呼ばれた時点でハンドラの処理を実行してしまうので、結局中から呼ぶのと同じだからだと思います。
私はコンストラクタで、
m_stopTimer = new Timer(0, 1);
m_stopTimer.addEventListener(TimerEvent.TIMER, onSoundStopReq);
を作って
m_stopTimer.start();
を呼び、
onSoundStopReqで
stop();
dispatchEvent(new MMLEvent(MMLEvent.COMPLETE));
を呼ぶようにしました。
これでとりあえず、動いています。

なんと！
呼ばれた時点で実行しちゃうんですね…。
勉強になりました。

setTimeoutでも一緒なら簡単にかけるこっちを使おうかなぁと思ってとりあえずやってみたけどちょっと体調不良なのでもう寝ます。すみません！m(_ _)m

過去のバージョンと比較してみたところ、どうも
@3の音が大きくかわっちゃってるみたいでした。昔と比べて低音域がでないというか、軽い音になったというか。@1と同じように聞こえちゃってます。ほかの音はあまり変化はないようですが。

自分の環境だと試せないので、とりあえずmonさんが教えてくれたやりかたでstopするように変更しました。
ついでに、同じやりかたを使って、処理が重すぎたときにsleepのようなことをする処理を入れました。

どうでしょうか・・・＞monさん、グニャラくん

そしてLogueさんご指摘の件。
@3 @w50 o3c の音について、昨年末のバージョンと現在のもので波形を出力して見比べてみたのですが、特に差が分かりませんでした。
もっと低くしたときに問題があらわれるのか、デューティ比を変えたときにマズイのか・・・引き続き調査してみます。

修正ありがとうございます。
問題の環境で再現を試みてみます！
わくわく。

お。書き込みにいこうかと思ってたんですが見つけてもらいました。
よろしくおねがいしますm(_ _)m

試してみましたー！
結果としては固まっちゃっています…(flmml.swf/Flash Player 10.0.12 debug windows)

各種traceなどを仕掛けて僕も追ってみますー。再現できる環境でないと、追うのキツそうなので…

おつかれさまですー。
そうですか（；；）
Active X用のDebug Playerですかね？　こちらもインストールして試して見ますー。

やってみました。
うちの環境でも再生が重い間はブラウザが応答しなくなっちゃいますが、再生終わったあとで復帰します。
これじゃなくて、ブラウザごと落ちるか、復帰できない状況になっちゃうんですよね？

僕の環境で起こっているのは、その問題です（再生が重い間にブラウザ/FlexのUIが応答しなくなる）。ちなみに、rev.25882のflmml.swfをデバッグプレーヤーのexeファイルで実行して試しました。
popforge版では、処理落ちが発生している場合にもFlexのUIやブラウザにイベントが渡りやすかったのですが、Dynamic sound generation版だとイベントが渡りにくくなっているようです。

ピコカキコに組み込んだ場合も試してみました。イベント遅れでpauseされる機構はうまく働いているようです。

Internet Explorer 7でブラウザごと落ちるという問題も報告されていますが、これが上記問題と関係しているのかどうかはよくわかっていません。Flash playerのバグかもなーとは思っています。
https://bugs.adobe.com/jira/browse/FP-985

とりあえず、普通にLFOを高速化してみよっかなー…全体の構造はあんまり把握できてないですが、細かい高速化なら協力できそうです。

おお。了解です。その現象ならウチでも確認していますので、なんとか考えてみます。ありがとうございます！

いまぼんやり考えているのは、バッファサイズを増やすやり方です。
重いデータのときは大き目のバッファに予め計算結果を書き込んでおいて、onSampleDataではコピーする作業しか行なわないようにしてしまいます。
10秒間のデータで４byte×44100×10秒≒1.7MBくらいのメモリを食いますが、割と現実的な線かなと・・・。
まだまだ高速化も必要ですね。LFOはバカ正直に１サンプルごとに周波数をいじってるのですが、ここの精度を荒くしてやるだけでも効果でるんじゃないかと思ってます。

いろいろ調べてもらっちゃってすみません。土曜も日曜もお疲れ様です・・・。

いえいえー。こちらこそ、趣味のソフトウェアを仕事に巻き込んでしまって申し訳ないです…
何も考えず、バッファサイズを8192から適当に増やしたら、Flashに怒られてしまいました。ダブルバッファでバッファ間転送はすごく現実的だと思います。

あ、１点不具合報告を。
rev.25651にて、ファミコン音源の準備のため、m_frequencyとm_noiseFreqの共通化を行ったと思います。その際に、@nの設定が効かなくなったようです。

LFOは確かに重そうですよねー…ループの回数を減らして、さらにgetNextSampleの呼び出し回数を減らす(getNextSampleVector的なもの)、といった感じでしょか、と釈迦に説法サーセン…

取り急ぎノイズの件なおしました・・。すみません。m(_ _)m

最新のRev. 26079でお願いします。

うひょ！
深夜にスンマセン…
（といいつつも、僕も本番反映の準備をする

Logueさんのblogを見に行ったけどどこにコメントすればいいか分からない・・・。
フィルタに渡すパラメータを間違えていたので、Logueさんご指摘の件はもしかするとそれが原因かもしれません。
現在のバージョンではいかがでしょうか？

ダブルバッファから転送する方式のものをコミットしてみました。
応答なしになる確率は減ったようですが、まだ重いですねぇ。
とりあえず次はLFOにテコ入れかな・・・。

ちなみに…
バッファのサイズ（MSequencerの引数）を増やせば、時間はかかっても途切れずに再生されそうなもんなんですが、今は上手くいきません。
Track単位で処理を分割してるんですが、１Trackにかかる時間が 8192/44100秒を超えたときに結局途切れちゃうんですよね。
まあ一曲まるまる入るほどサイズを大きくすれば問題ないんですが、それもねぇ…。

わーい！！早速取り入れます！

あんまり色んなMMLでは試してないんですが大丈夫でしょうか・・・。
そしてLFOをいじってみたんですが、思ったほど効果出てない感じですねぇ。
あとはPixelBenderくらいしか思いつかないんですが、Flash 10ではGPU使わないからあまり速くならないって話もあるしなぁ。どうなんでしょ。

とりあえず、リビジョン26937でマージしてみましたけど、ほかの設定の楽器が入っただけで、音がぼろぼろに・・・。

再生も途中で中断してしまいますね；；

別々のモジュレーション設定があるトラックが複数あるとおかしくなるような？不思議なことに、モジュレーションを使わない楽器までその影響が波及します。（mml.inc.phpのページのサンプルのルパン三世のMML参照）

すみません、うちのPCだとフィルタを使った場合３パートほどで限界に達してしまうのでとてもとても検証できませんでした（；；）
ぼろぼろというのは具体的にはどういう感じでしょうか？

うーん、検証してみた結果、@L命令を使うトラックが複数あると、そのゆらぎに引きずられてほかのトラックの演奏まで演奏がぶつ切れ状態になるって感じです。

現象から想像するに、たぶん、単純に重くなっているのではないかと想像します。
高負荷のときでもUIに処理を戻してやるようにしたので、当然全力で計算できないので重くなってます。
いろいろ試しているんですが、すみません・・・。

時間経ってしまいましたが、ダブルバッファ＆LFO軽量化版をリリースしてみました。問題があるMMLがあったら報告させていただきまーす。
GPU使ってくれないとPixelBenderで激高速化！とはならない気もするんですが、実際試してみないと分からないですよね…単純にループをまわすこと自体が重いのかもしれないですし。求む！ActionScriptの高速化ノウハウ！

時間が経ってしまいましたが、たぶん、つい先ほどコミットしたもののほうが安定していると思います。
バッファリングの進行具合も表示するようにしたので、ストレスも軽減されました。
って、ピコカキコのほう対応させるのも大変ですよね・・・この忙しい年末時に。m(_ _)m

そろそろファミコン音源にとりかかりたいです。OffGaoさん、お待たせしてごめんなさい。