こんばんは、ぺろりです。
このブログ、最初っからテクニカルな話題ばかりで普通のREAPERユーザーを完全に置いてきぼりにしてる感が半端ないですが、もう少しだけ続きます。
今回はポーリング処理についてですが、その前にhookcommand2コールバックに来るActionIDの話を少し。
REAPERはActionを実行する際、Extensionに対してどのActionがリクエストされてますよ、ということをhookcommand2コールバックで通知してきます。
これによって何かActionが実行されるタイミングだということが「ある程度」検知できます。
何故、「ある程度」なのかというと、実際にActionを実行するExtensionが「実行しましたよ」ということをhookcommand2コールバックで返す（戻り値をtrueで返す）と、そのActionIDの通知はそれ以上他のExtensionへ通知されることはないからです。
恐らくExtensionのDLL登録の順番に依存しているのかもしれません（未検証）が、そういった環境依存で自分のExtensionに通知が来たり来なかったりと動作が変わってしまうのも困ります。
REAPERの組み込みアクションであれば、最後にREAPER本体が処理しそうですが、これにも問題があるようです。
Action実行リクエストの通知はREAPER上のすべての挙動を検知できる訳ではないようで、例えば、Markerは作成(Mキー押下)時にはActionが通知されてきましたが、MarkerをAlt+クリックで削除する際にはAction通知は来ないようでした。
Markerが作成されるタイミングは分かっても、削除されたタイミングが分からないので、自分でMarker情報をもとに何か処理を書く時にだいぶ扱いづらそうなのが予想出来るかと思います。
例えばMarkerの情報をキャッシュしておいて自分のウィンドウに表示等したいが、削除されたタイミングが検知できないとそのキャッシュを更新するタイミングがない、とかでしょうか。
せめてポーリングできるような仕組みがあればなあ・・・
ということで前置きが長くなりましたが、ポーリングで処理を書く方法があるのでそれを紹介します。
■ポーリング処理の実装方法
SWSの実装を参考にすると、IReaperControlSurface::Run() というコールバックメソッドを利用した方法が使えそうです。
ダミーのControlSurfaceクラスを作って利用する感じです。
このクラスのインスタンスを生成し、"csurf_inst"で登録（plugin_register）してやります。
（不要になったらこれまでのコールバック等と同様に "-csurf_inst" で登録解除してあげましょう）
今回はポーリング処理の書き方について説明しましたがいかがでしたでしょうか。
おそらくこれまでの5回分の記事の解説で、REAPERのExtensionを実装する最低限の準備が揃ったというか、これで大抵のことは無理矢理なんとか実装＆問題回避等出来るかもしれません（ホントか？）。
ではまた次の記事でお会いしましょう。
このブログ、最初っからテクニカルな話題ばかりで普通のREAPERユーザーを完全に置いてきぼりにしてる感が半端ないですが、もう少しだけ続きます。
今回はポーリング処理についてですが、その前にhookcommand2コールバックに来るActionIDの話を少し。
REAPERはActionを実行する際、Extensionに対してどのActionがリクエストされてますよ、ということをhookcommand2コールバックで通知してきます。
これによって何かActionが実行されるタイミングだということが「ある程度」検知できます。
何故、「ある程度」なのかというと、実際にActionを実行するExtensionが「実行しましたよ」ということをhookcommand2コールバックで返す（戻り値をtrueで返す）と、そのActionIDの通知はそれ以上他のExtensionへ通知されることはないからです。
恐らくExtensionのDLL登録の順番に依存しているのかもしれません（未検証）が、そういった環境依存で自分のExtensionに通知が来たり来なかったりと動作が変わってしまうのも困ります。
REAPERの組み込みアクションであれば、最後にREAPER本体が処理しそうですが、これにも問題があるようです。
Action実行リクエストの通知はREAPER上のすべての挙動を検知できる訳ではないようで、例えば、Markerは作成(Mキー押下)時にはActionが通知されてきましたが、MarkerをAlt+クリックで削除する際にはAction通知は来ないようでした。
Markerが作成されるタイミングは分かっても、削除されたタイミングが分からないので、自分でMarker情報をもとに何か処理を書く時にだいぶ扱いづらそうなのが予想出来るかと思います。
例えばMarkerの情報をキャッシュしておいて自分のウィンドウに表示等したいが、削除されたタイミングが検知できないとそのキャッシュを更新するタイミングがない、とかでしょうか。
せめてポーリングできるような仕組みがあればなあ・・・
ということで前置きが長くなりましたが、ポーリングで処理を書く方法があるのでそれを紹介します。
■ポーリング処理の実装方法
SWSの実装を参考にすると、IReaperControlSurface::Run() というコールバックメソッドを利用した方法が使えそうです。
ダミーのControlSurfaceクラスを作って利用する感じです。
// DummyのControlSurface
class DummyControlSurface : public IReaperControlSurface
{
public:
DummyControlSurface() { }
virtual ~DummyControlSurface() { }
virtual const char *GetTypeString() { return ""; } // SWSを参考に
virtual const char *GetDescString() { return ""; } // SWSを参考に
virtual const char *GetConfigString() { return ""; } // SWSを参考に
// 30FPSかそれくらいで呼ばれるらしい（頻度は未検証）
virtual void Run()
{
// ここでの処理は出来るだけ軽くしておいた方がいいかも。
// IReaperControlSurfaceには他にも特定のタイミングで
// 呼ばれるメソッドがあるので、出来るだけそちらで処理して
// どうしてもダメならここで適当な間隔でポーリングする
}
};
このクラスのインスタンスを生成し、"csurf_inst"で登録（plugin_register）してやります。
（不要になったらこれまでのコールバック等と同様に "-csurf_inst" で登録解除してあげましょう）
// Run()タイミング検知用ControlSurfaceを生成・登録 DummyControlSurface* csurfInst = new DummyControlSurface(); plugin_register( "csurf_inst", csurfInst );これで DummyControlSurface::Run() が定期的に呼ばれるようになります。
今回はポーリング処理の書き方について説明しましたがいかがでしたでしょうか。
おそらくこれまでの5回分の記事の解説で、REAPERのExtensionを実装する最低限の準備が揃ったというか、これで大抵のことは無理矢理なんとか実装＆問題回避等出来るかもしれません（ホントか？）。
ではまた次の記事でお会いしましょう。
