Ｍｕｓｅ掲示板

> 花燃ゆを見てて思ったですが、文字が真ん中から出るとかどうでしょう。
このご提案は以前より何度か頂いており、検討リストに入れてあります。
ただ、文字描画の部分で演奏のモタレを生じることが多かったので、
できるだけ処理を軽くするため、今まで実装を躊躇していました。
今般、抜本的なモタレ対策を施したので、そろそろ実験してみても良いかもしれませんね。
しかし、WindowsのセンタリングAPIを利用すると、やはり演奏時にそれなりの負荷は生じると思われます。
それでも、やるかどうかですね。

> ・LEFT,CENTER,RIGHT""（TEXTの代わり案）
> ・LCR（TEXTR"",RTEXT""案）
> ・lcr（TEXT""c,TEXT""r案）
> ３番は無理ありそうですが
やるとすると、MARKやSTOPもサポートしたいので、
１番や２番の案ですとコマンドを量産してしまいます。

現在の文法と矛盾しないデリミッタを使って、３番になると思います。
*MARK"ほげほげ"-C とか。

あるいは、FONTにおける太字や斜体のような属性の拡張と考えて、
*FONT"ほげフォント,1,C" とか。
こっちの方がエレガントかな。

・・・花燃ゆを受け取ったということは、
過去、私にMuseデータをご送付されたミューザーの方ですね？

> あれ……もしかしてMuse、演奏と描画が同じスレッドだったりします？
はい。同じスレッドです。
演奏と文字表示は、常に同期を取る必要があるのですが、
それでもなお、マルチスレッドのメリットを生かしながら、
タイマーコールバックでそれを利用する方法を思いつきませんでした。
何かうまい方法があれば、ご指導頂けると幸いです。

現在のタイマーコールバック内のシーケンスは、
かなり大まかに書くと、以下の様になっています。

タイマーコールバック{

        while( 対象データが該当時刻である ) {

                if ( 音データ ) その音を出す

                if ( 文字データ ) その文字を表示する

                次のデータに位置更新
        }
}

マルチスレッドにする場合、
音出し用と、文字表示用にタイマー自体を２つ生成するのでしょうか？
もしそうだとすると、同期を取るのが難しそうだし、同期を取る時点でモタレる気がする・・・。

あるいは、あくまでもタイマーは１つで、
コールバック内の音出しと文字表示で、都度スレッドの生成と消滅を行うのでしょうか？
コールバックは4msecで発生しているので、スレッド制御自体がかなり高負荷になる気がします・・・。

私は、基本的なところがわかっていないのかもしれない・・・。
ご指導のほど、よろしくお願いします。

私なら、メインスレッド(＝UIスレッド)とは別にMIDI演奏スレッドを作って、
こんな感じにするでしょうか……？

void MIDI演奏スレッドFunc( 演奏開始データ位置 ) {
　演奏中フラグ = true;
　演奏開始時の処理();
　while( !演奏中止フラグ ) {
　　while( 対象データが該当時刻である ) {
　　　if ( 音データ ) その音を出す();
　　　if ( 文字データ ) UIスレッドに対して表示更新メッセージをPostMessage();
　　　次のデータに位置更新;
　　}
　　whileループに使用した時間も考慮しつつウェイト();
　}
　演奏停止処理();
　演奏中フラグ = false;
}

midiOut系メッセージに非UIスレッドでは使用できない制約がなければ、概ねこんな感じにいけると思います。
別スレッドなら何も考えずにSleep()できますので、
本質的にタイミングが不安定なWM_TIMERに時刻制御を任せる必要もなくなるというメリットも。

なお、注意点としては2点でしょうか？

・演奏中フラグや演奏中止フラグを設定する際、確実なスレッド間同期が必要
（InterlockedExchange() ならスピンロックなのでコンテキスト切り替え不要で同期可能？）
・演奏中止フラグの設定後、実際の演奏中止が非同期で行なわれる
（その間のラグを適切に処置してやる必要アリ）

主に開始／停止周りがややこしくなりますね……。

> 　　whileループに使用した時間も考慮しつつウェイト();
う〜ん。
これでは、音楽演奏ソフトとしてまったく精度が出ません。
それに、ポーリングタイプのウェイトを入れると、
その間はUI操作が効かず、操作感度が劣化します。
そこでMuseでは、マルチメディアタイマーを使っています。

ですから、
> 本質的にタイミングが不安定なWM_TIMERに時刻制御を任せる必要もなくなるというメリットも。
現在でもWM_TIMERの類は使用していません。
マルチメディアタイマーのタイマーコールバックのみを利用しています。
よって、演奏と独立したUI操作は、おのずと分離されています。

問題は、演奏中にリアルタイムに表示が変化する、
鍵盤表示やテキストエリア、指揮棒カーソル、メンバー情報楽器名などですね。
これらの表示更新と、演奏とを、タイマーコールバックを前提として、
どのようにマルチスレッド化するのか、が課題です。

ひとつ教えてもらいたいのですが、
以下の２つを比べて、マルチスレッドにする意味があるのでしょうか？
（複数のCPUを搭載したPCで、CPUパワーを活用できるのはわかりますが、
　後述するように、結局待ち合わせなければならないので・・・）

●マルチスレッド
> 　　while( 対象データが該当時刻である ) {
> 　　　if ( 音データ ) その音を出す();
> 　　　if ( 文字データ ) UIスレッドに対して表示更新メッセージをPostMessage();
> 　　　次のデータに位置更新;
> 　　}

●シングルスレッド
> 　　while( 対象データが該当時刻である ) {
> 　　　if ( 音データ ) その音を出す();
> 　　　if ( 文字データ ) 表示更新メッセージをPostMessage();
> 　　　次のデータに位置更新;
> 　　}

それと、
以前に、文字表示のモタレと格闘した際の実験結果なのですが、
文字表示にポストメッセージを使うと、演奏との同期がまったく取れませんでした。

> 主に開始／停止周りがややこしくなりますね……。
そうですね。
加えて、WAVE再生もありますし、繰り返し演奏の制御もあります。
音源切り替えによる停止とMIDIクローズ、マウス右ボタンのリロード再演奏、
演奏中シークによる演奏再開の制御などなど・・・。
鍵盤表示や譜面モニタの指揮棒カーソル、自動譜めくり、メンバー情報の楽器名などは、
上記の「UIスレッド」にポストするのでしょうが、
これらすべての処理に対して終了を監視し、同期をとらなければならないでしょうね。

ここまで考えると、
マルチスレッドは、処理が長く続くような、非同期であっても問題のない数値演算などでは効果的ですが、
音楽演奏ソフトの場合は、表示と演奏で逐次同期をとらなくてはならず、
結局、一番遅い処理に律則されてマルチスレッドの効果がほとんど出ない。
いや、むしろスレッド制御自体がその効果以上に負荷を与え、
全体としては性能を劣化させる恐れがあると思えてきますが、
それは私の前時代的なイメージに過ぎず、実際はマルチスレッドの効果は絶大なのかな？
巷の多機能なプレーヤーは、やはり効果的なマルチスレッドのプログラミングを実現している気もするし。

himajin925さん、コメントありがとうございます。

マルチスレッドのプログラムは、面白いですね。

> （片方の処理が重くないのであれば、メインループでやっていいんですが＝スレッドが2つ。これは、PostMessage を 同期オブジェクト(Event)に置き換えただけ、ともちょっと違いますね）

実は、これをちょっと試しに作ってみたところです。
今回のきっかけは、「文字表示更新でモタレる、更には将来のセンタリング表示などに備える。」
であるし、「音を出す」処理の方は音源にメッセージを送信するだけなので、
スレッド化する意味はないと判断し、以下の様な感じにしてみました。

     スレッド  サブ
     while(終了しない間) {
       ・文字の表示の Event 待ち  ←�A
       ・表示の更新処理
     }

 ・メインループからは更新のタイミングを通知する
     while( 対象データが該当時刻である ) {
         if ( 音データ ) その音を出す
         if ( 文字データ ) その文字を表示する Event  →�A
          次のデータに位置更新
     }

一応、まともに動いていますが、�Aで通知する時、３つの情報を与えなければなりませんでした。
　・表示する文字列
　・フォント
　・文字色
これをスタティックの構造体に格納して、その構造体のアドレスを渡してみました。
しかし、スレッドサブが表示中にメインがスタティックの値を書き換えるとまずいことになります。
そこで、スレッドにEventを発行する部分を、クリティカルセクションで待機させたのですが、
でも、考えてみると待機させてしまっては、結局シングルスレッドと同じレベルの性能に
なってしまうのでは、と思っています。

> プログラムの構造は簡単になる（単機能のループだけになる）ような気もしますが、メリットは？です。
実行体感としては、今の所マルチスレッド化した効果は得られていません。
タスクマネージャーでＣＰＵ占有率や、スレッド数などを観察したのですが、
それらの数値も変化していないようでした。
もう少し、いろいろ実験してみたいと思います。

> 発音と表示の同期がとれるかどうか分かりません。
上記の方法だと、ちゃんと同期は取れているみたいです。