Release #146
Muse V5.90
ステータス: | 終了 | 開始日: | 2011/04/25 |
---|---|---|---|
優先度: | 通常 | 作業時間の記録: | - |
担当者: | - | ||
カテゴリ: | - | ||
対象バージョン: | - |
説明
新コマンド、移調楽器y登場。その他、X7の遅延やアクセントwの効果スコープを改善。
関連するチケット
履歴
#1 Redmine Admin がほぼ11年前に更新
;《Ver5.9 開発後記》2011.04.23
;
; ◆一年ぶりのバージョンアップとなりました。今回は6つの開発テーマをピックア
; ップしてみました。何年も頭の中で煮詰めていたものから、開発直前に思い付い
; たもの、ミューザーの皆さんから頂いた要望への対応など、取り上げたテーマは
; 様々です。久々の開発でしたが、着手してみると次々と当初想定していなかった
; 部分にも手を付けたくなり、ボリュームとしても結構盛りだくさんとなりました。
; ◆1つ目は、新たなフィンガー属性コマンドの追加です。その名も“移調楽器 y”。
; 大編成のオーケストラやブラスバンドの音楽をMusingする際、異なる移調楽器を
; 1メンバー内の各フィンガーに割り付ける記述法に、従来からもどかしさを感じ
; ていました。調性(\)と移調(T)がフィンガー属性でないため、次のフィンガーに
; 移る度に指定し直さなければならないからです。そこでこれらのフィンガー属性
; を新設する検討を以前から行っていました。しかし単に夫々のフィンガー属性を
; 立ち上げる対応は、対処療法的で気が乗りません。納得感が得られないと実装に
; 踏み切れないのが私の性向なのです(苦笑)。そしてやっと先日、お風呂の中で閃
; きました。課題は移調楽器の指定なのであるから、調性と移調を一括してセット
; できる機能こそ、目的にストレートに向かって美しいと。こうして完成したのが
; “移調楽器 y”です。もっと早く欲しかったです。自分自身が(笑)。
; ◆2つ目は、小西さんからご要望を頂いた件です。V5.6の改版でフィンガー拍数の
; カウント表示を撤廃したのですが、微分音長を活用したデータの場合は譜面モニ
; タでもタイミングのずれを確認できないため、せめて微分音長だけでも定量的な
; 表示を復活させてくれないか、というリクエストでした。小西さんはどの局面で
; この様な事態に陥るかを具体的な例で示し、しかも極めて謙虚な態度でご依頼し
; てくれました。利用局面の明快なイメージが沸いたため採用させて頂きました。
; 有意義なご提案、ありがとうございました。この要請の真意を汲み取ると、その
; 表示は一覧形式が相応しいと考え、音名指定xをフッターの方に移して対応しま
; した。ついでにフッターの行数を増やし、今回新開発した“移調楽器 y”の状態
; も表示させました。フッターの下膨れ感が否めませんが(笑)、このエリアの右ク
; リックによるリロードがしやすくなったことでもあるし、まあ許容範囲でしょう。
; ◆3つ目は、多くの方から要望を頂いていたテーマです。ボリューム(X7)の遅延指
; 定。Xコマンドは実に8年前に実装したのですが、当時から断続的に遅延対応の
; ご要望を頂いており、積年の課題となっておりました。本当は、この機会にX7に
; 限らず全てのXコマンドの遅延に対応しようと思ったのですが、いくつか複合的
; な課題があったのです。ご存知のように、Museの遅延指定は到達値だけを指定す
; るポリシーなため、データの冒頭でいきなり遅延を記述した場合、開始値として
; 音源の初期値を採用する必要があります。ところがいくらサイト等で調べても、
; 代表的なコントロールの初期値しか判らないのです(苦笑)。また仮に判ったとし
; ても、128個のXタイプのすべての値を記憶するのみならず、キープレシャーに於
; いては128メンバー×128音程の計16384個の値を管理しなければならい。更には
; そもそも遅延という機構には相応しくないスイッチ系のコントロール制御も多く、
; またVやRなどMuseが独自に予約語化したメンバー属性と併用されてしまった場合
; の開始値の扱いをどうすべきか等々、課題山積でなかなか美しい指針を得られま
; せんでした。結局、実質的に最も使用頻度が高く、実効力のあるコントロールの
; みをサポートしようと考えました。そして、上記の課題を全てクリアするコント
; ロールは、X7を置いて他に無いと判断した訳です。この実装は思いの外プログラ
; ミング量が多く、muse.exeの容量が一気に増えてしまいました。と言っても、ま
; だこのReadme.txtより小さいのですが(笑)。何はともあれ、これでVで抑揚を付
; けながらX7で全体をクレッシェンドするといった演奏表現が可能となりました。
; ◆4つ目は、Ayakongさんの掲示板の書き込みに端を発した改善です。V5.8でのマ
; イナーバージョンアップにて、メンバー情報でキーボード操作をした際、フォー
; カスをメインウィンドウに強制移動させる処理を施しました。メインウィンドウ
; はすべてのメニュー操作ができるハブ的なウィンドウなので、基本的にフォーカ
; スはそこにある方が視覚にハンディを持たれた方のMusingが楽になるだろうと考
; えたからです。しかしこれは実に浅はかな憶測でした。読み上げソフトはアプリ
; ケーションによるフォーカス移動を知らせてくれないため、利用者が迷子になる
; という事実を諸熊さんから教えてもらいました。「小さな親切大きなお世話」の
; 典型ですね(苦笑)。私はちょっと独善的な面があるので、気を付けなければいけ
; ません。今回、強制的にフォーカスを移動する処理を全廃することにしました。
; Ayakongさん、諸熊さん、ありがとうございました。
; ◆5つ目は、アクセントwの文法解釈の微調整です。和音のカッコの直前にwを添え
; ると和音内のすべての音がアクセント対象となるのですが、連符はカッコ直前に
; wを添えてもアクセントが効くのは次に出現する一音だけ、というのが今までの
; 仕様でした。連符は和音と異なり一音づつ奏でられていくので、この仕様の方が
; 自然だと当初は考えていたのです。しかし先日、修飾音を連符で記述しその修飾
; 音全体を一時的に強くしたいという局面に出くわしました。考えてみると、カッ
; コの外側から指定するか、内側の音符に添えるかで効果スコープを制御できる方
; が明らかに優れた文法です。という訳で連符も、和音と同じ仕様にしました。和
; 音内連符とか連符内和音、連符内コードなどがあるため、プログラム制御が結構
; 複雑で苦労しましたが、綺麗に仕上がったと思います。少々データの互換性が崩
; れますが、Museの美しい進化のためにどうかご容赦下さい。
; ◆6つ目は、何年も前から多くの方からご依頼を受けていたテーマです。Museは、
; 文法エラーを検出すると、各種ウィンドウ状態を初期化します。そして、その文
; 法エラーを直した後リロードしても、直前状態には復帰しません。演奏位置は曲
; 頭に巻き戻されたままですし、演奏をオフにしていたメンバーもオンになったま
; まです。ですから、Musing中に文法エラーが出ると、エラーを直すよりも直前状
; 態に指定し直す事の方が面倒で、私自身もエラーが出る度に舌打ちしていました
; (苦笑)。実はMuseは、従来からリロード時に直前状態を極力維持するようにして
; ありました。無論の事、リロード後のデータが直前状態を維持できない内容に変
; 更されていても、破綻が起きない様にリカバリする処理も組み込んでいます。例
; えば先程までいたメンバーがいなくなったり、直前状態の演奏位置よりも演奏時
; 間が短くなったりした場合です。これらの対応を万全にしていたので、論理的に
; エラー時からの復帰もその派生にすぎず、結構簡単に対応できるはずだと頭では
; 考えていました。しかし何と申しましょうか、何やら嫌な予感がして手を付けら
; れずにいたのです。そして、今回改良に着手しその予感が当たっていることに気
; づきました。結局今回の6つの開発テーマの内、このテーマが一番苦労しました。
; 厄介だったのは、エラーが起きてからリロードをするまでの間はデータが何も読
; み込まれていない状態にしなればならないということです。この状態にしておか
; ないと内部状態と外部状況に乖離が起こり、論理的に収拾が付かなくなります。
; にもかかわらず、リロードでまた直前状態に復帰させなければなりません。この
; 様に、状態クリアと状況維持という背反律を満たさなければなりませんでした。
; とても神経を使う改良でしたし、動作テストもバリエーションが多くて大変でし
; た。何か気になる挙動があったら、どうぞお知らせ下さい。
; ◆他にもいくつかの改善を試みました。初期起動時の音源応答遅延により鍵盤表示
; と発音がズレる傾向を抑止するために起動直後にMIDI音源をダミーでOpen/Close
; させたり、フォントのロードによる文字列描画のモタレを軽減するために同時刻
; イベントでの文字列描画タイミングを後方に移動させたり、バッチ処理モードで
; は必要ないウィンドウ制御などを排除して高速化を図ったり、譜面モニタがアク
; ティブになっていなくてもSHIFTキー押下で虫眼鏡カーソルに変化させる、とい
; った諸々の改善を施しました。(非アクティブウィンドウのキー押下イベントは
; 検知できないため、マウスを少し動かさないと虫眼鏡になってくれないのですが)
; という訳で、久々の本格的な開発であったにもかかわらず、どうやらプログラミ
; ングの勘は鈍っていない模様で、以上の改修すべてを2週間程で終えることがで
; きました。でも、現段階で偉そうな事を言ってはいけませんね。皆さんからバグ
; 報告がビシバシ飛んで来る様でしたら、やっぱり勘は鈍ってます。ていうか、そ
; れは今に始まったことではありませんね(苦笑)。