2020年01月28日

フィルター選択機構の条件分岐をifからswitchに変更する

ifを使って複数の条件に分岐を掛ける場合、参照先のソースを全てチェックする分だけ不要な時間が消費される。 例えるなら、1番最初に設けた条件に合致した後も、2番目以降に設定した条件のチェックを行うことになり、その分だけ計算機のリソースが空費されてしまう。

switchは、入力された整数を参照してcase毎に分岐させて処理を行う機能で、breakを行うことでプログラムの下流に配置された無駄な参照と評価をスキップすることができる。

ただし、これを使う場合には事前に対象となるソースを加工してパラメーターをハンドリングが可能な規模の整数に刻んでおく必要がある。 

改修を行う前に、まずはcase判定用のレジスタをリザーブする。

Screen Shot 2020-01-26 at 19.24.32.png

入力するソースを除算してその結果からレベルを判定し、分岐先でディテクターアウトの変化に掛けるウエイトを選択する。

Screen Shot 2020-01-26 at 20.53.34.png

ifに比べてプログラムがより判り易い構造になった。

Screen Shot 2020-01-26 at 20.52.44.png

何れの場合もデータを16段階に分類している。

Screen Shot 2020-01-26 at 20.53.10.png

レベルの判定を等間隔で行う場合は以上の手法で問題はないのだが、不等間隔でポイントを設定したい場合は、ifによる条件分岐が必須となる。 今回は多項式の表現を用いて視認性をより向上させている。

Screen Shot 2020-01-27 at 10.26.43.png

最近のコンパイラは賢いのでifからswitchに記述を変えても余り差はないという話があって、場合によっては速度が低下することもあるらしい。 

体感上は若干の向上が見られているのだが、これも気分の問題である可能性は否定出来ない。 判り易い判定法としては、廃止したディテクターのstepを比較してアウトプットの同期を切替える機構を復活させ、それにswitchを組み込めばハッキリするので、後ほどこれを試してみる予定。

追記1:

switch投入後のベンチマークとして、一部のモードで動作不良が発覚して廃止に至った「参照step切り替え機構」を復活させてみたが、以前に見られた5和音以上の発音で一部のEnvelopeに遅延が出る不具合が完全に解消されていた。 今回の改訂版では条件分岐を行うルーティンを2箇所追加した分だけタスクが増大している筈だったので、これは予想外の健闘と言えるだろう。

Screen Shot 2020-01-28 at 8.03.00.png

RAMの消費が以前より抑えられているようだが、これは合理的なリソース配分が行われたことを意味している。

よって、改変の御利益はアリと判定する。

追記2:

試験運用の結果、ピッチの中間域という微妙なエリアでバウンシングが発生しだしたため、プログラムのヴァージョンを元に戻すことになった。 出来ればLEDマーカーを仕込んで境界域の挙動を徹底的に調査すべきなのだろうが、とりあえずは現状で不満の少ないヴァージョンを選択することにした。
posted by Yasuski at 02:08| LaVoixski