あらすじ
|
どうやら、プログラミングよりも設計に時間がかかている事に気がつく。
確かに、UIの設計は苦手で、その克服もかねて Score Editor の開発を始めた訳で、
苦手な事をしているゆえ、なかなか完成せず、長いこと、このソフトの開発から逃れられなくなってしまった。
バージョン６はビスに影響された事も多く、反省点も多い。
それらを改善をすべく６．ｘの開発を行っている。
繰り返し記号 toCoda が動作しない不具合の修正版をリリースした。 基本的なパターンが動作していなかったというショッキングな出来事。 アーティキュレーションの開発を再開する。 テキストをユーザが自由に作成できる事になるため、 フォントの作成を行った。 ASIOドライバが複数入っている環境でそのうちの１つしか使用できないといった、 バグを見つけてしまい、修正版をリリースした。 ダブルショック。 ffff をユーザが追加した場合のパラメータ。 アーティキュレーションサウンドの画面の開発。 いろいろ設計しなければならないが、先に、右メニューの開発を行う。 ユーザが記号を追加するという事はメニューも動的にしなければならない。 また、8va の ... をユーザが指定できるように改善を検討。 ユーザが追加した記号に範囲があるかもしれないからだ。 その仕組み、またがり記号。の検討も並行して行う。 動的右メニューの実現であるが、大枠完成した。 しかし、メニューの表示がきれいにならない。 記号属性を持たせる必要が出て、全ての記号の概念を作り変える。 ふと、テンポなどの記号はユーザが追加可能なのか考えた。 一方、記号の描画情報を自由に取れるようになった。 全ての記号の概念を作り変えた。８０％が完了。 小節またがり記号の概念を６．１３に組み込み始めた。 現在、範囲を示すマーカを、触ってつかんで移動する所まで完成した。 あとは、またがり記号の描画である。 |
2008-12-28
-
8va の範囲指定機能を６．１３に搭載させる予定であるが、
その開発を行っている。小節またがり記号機能である。
アーティキュレーション機能で活用できるようにするため、バージョン７で予定の機能を、
６．１３に入れる事にしたのである。
現在、範囲を示すマーカを、触ってつかんで移動する所まで完成した。 あとは、ページをまたがって描画する部分を開発すれば、見た目に関しては実現完了。 またがり記号は、簡単そうで奥が深く、慎重に開発を進めている。
-
新しい概念で記号の処理を書き直した。
記号の数が多いが８０％の記号は完了した。メニューのほうも同様に対応した。
残りの記号はいろいろ特殊な処理が必要である。 その１つに、範囲指定ができる記号がある。たとえばオクターブ記号である。
バージョン７の開発でも試作していた、 小節またがり記号の概念を６．１３に組み込み始めた。
-
ついに記号の描画情報を自由に取れるようになった。
内部的な大きな進化である。メニューの表示もきれいになった。
やっと次に進める。
アーティキュレーション記号とそうでない記号の統合も行った。 なので、テンポもユーザがメニューに登録できるようになりそう。
-
記号をメニュー上にきれいに並べるのは、なかなか大変である。
記号にレイアウト関連の情報が必要になるからである。徐々に出来つつある。
更には、メニューの場合だけフォントのサイズを小さくする必要も出てきていろいろ厄介だ。
しかし、メニューに限った話でもない。印刷関連で、レイアウト情報は有効活用できる。
今までは、記号を追加すると印刷の改造が必要だった。レイアウト情報があれば、
印刷処理はそのままで良い。なので、メニューといいつつ、印刷の事も考慮している。
なので、重要な開発である。
しかし、また、心に引っかかる事が見つかった。 アーティキュレーション記号以外の記号もユーザが登録出来うるのではないか？ という事である。
たとえば、テンポ。である。好きな速度のテンポをユーザが登録し、 メニューにもそれが反映できれば、良い感じである。 しかし、テンポはアーティキュレーションの仕組みとは別である。
その他には、１１連符等である。繰り返し記号の番号も、４までメニューにあるが、 ５を登録しても良いはずである。拍子記号も同様。
これらの考えを再び、よく考えたほうが良さそうである。 アーティキュレーションに限らず、自由にメニューを構成できても良いはずである。 立ち止まって考えてみたい。
-
動的右メニューの実現であるが、大枠完成した。
しかし、やっかいな事が生じた。
メニューが動的になるという事は、音楽記号を動的にメニューに描画しなければならない。 今までは、メニュー全体の画像を用意していたので問題はなかった。
記号を描画する際の問題点は、きれいに並べて描画する方法に関して考慮しなければならない。 従来の場合、記号の中央のみしかデータを持たない。 これでは、きれいに並べられない。いろいろな情報が必要。
話は若干それるが、 今までは、音楽記号＝ビットマップ画像。である。 つまり、画像の種類で、音楽を処理していた。 これは Score Editor 開発当初、記号を貼り付けるだけという、 単純なソフトだったからである。
しかし、この考えも、そろそろ限界である。 １つの記号にしても、表示方法がいろいろある。 ユーザがテキストを指定するならば、なおさら。 つまり、記号のデータ構造を全て作り直す必要が生じてしまったのである。 というより、記号の分類法が若干変化する。そうなると、バグが生じかねない。 それを回避するには、記号のデータ構造を直してしまったほうがよいのである。 これも、最終形態思考に従う。もう、小手先修正はしない。 以前からそうしたいとずっと思っていた。この際、一気に、最終形態に作り変えるべきである。
という訳で、プログラムを書き直す作業を永遠にやっている。 これからは、音楽記号として管理できるようになる。普通は最初からそうするものなのであるが、 Score Editor 1.0 を開発した時は、ここまで本格的なソフトにする予定がなかった。 しかし、現在は違うと思う。ともあれ、 この修正によって、将来プログラムが分かりやすくなるし、 作りやすくなるのは言うまでもない。 今までは従来のバージョンをずっと引きずっていたが、 そのせいで、プログラムが大変だった。
なぜ、音楽記号が最近増えないのか？その疑問が今回の問題で、 これも、バージョン７でやる予定だった。 ６．１３でやらなければならなくなった。
ただ、音符の描画処理の改良だけは、６．１４以降にしたい。 この部分に手を入れると大変な事になる。
たかが、メニューとはいえ、この修正を行えば、 いろいろな事ができるようになる。いつかはやらないとならないと思っていた。 もうやってしまおうと思った。
-
６．ｘの開発状況を報告したい。
ユーザがアーティキュレーションのテキストを自由に作成できるようになるため、 アルファベットのフォントが必要で作成した。 その際、ppp や fff の形状も変更したのであるが、 後に、あまりにも無機質すぎるデザインと感じ、 従来の Score Editor の ppp / fff のフォント形状はそのままで、 それに合うような他のアルファベットのフォントを再作成した。 文字を表示する部分を開発し、良い感じになった。
フォントであるが、ppp スタイルのものと、legato で使用している Window フォントなど、 ユーザが選ぶ事ができ、いくつかのフォントを組み合わせる事もできる。 rin fz などが組み合わせの１例である。
次に、音楽記号のパラメータに関してである。 たとえば、ppp や fff などのベロシティ値を指定できるようになる。 これは、pppp をユーザが追加した場合、などに対応するためである。
また、スタッカートの長さ、アクセントの音量など、 これらもユーザが指定できる。現在の仕様でも「記号の編集」にて、 パラメータを調整できるが、その初期値を一括して管理できるようになる。
さらに、これらの初期値は、全体設定を１つ。 パートを作成する際に、そこからコピーされパート独立の初期値となる。 つまり、パートごとに、ppp のベロシティやスタッカートのニュアンスを変える事もできるようになる。
これらのアーティキュレーションは、一括して画面で調整したり、 新たな記号を追加できるようになる。で、この画面の開発を大枠終えた。
次に、アーティキュレーションサウンドの画面。 これは、記号によって、音質が変化する場合に対応するための設定である。 Windows には存在しない、特殊なＧＵＩ部品がないと実現できず、 先に、ＧＵＩ部品を開発しなければならない。 ただ、先にやることがあるため、そちらを優先する。
それが、Score Editor の右メニューである。 多くのアーティキュレーションをユーザが定義したとしても、 メニューに入りきらない。そのため、パート単位に、 メニューに表示する記号を設定しなければならない。 これは、たとえば、強弱記号族をＯＮにすれば、簡単にそれらが、 メニューで表示される。用意するのは、 強弱１、２、アーティキュレーション１、２、３、テキスト１、２、 のメニューグループである。これらの枠が用意されており、 強弱関連は、強弱１、に割り当て。 など、ユーザがどこのメニューブロックに表示するかを、指定できるようになる。 何もしなければ、従来の Score Editor のメニュー表示が標準となる。
このメニュー処理であるが、従来までは、テキストファイルに定義しており、 固定であった。なので、動的に変化する仕組みにしなければならず、 メニュー処理は１からの開発しなおしとなる。 設計を終えたので、これからメニュー処理の開発となる。
最後に、8va ... などの ... が問題となる。 アーティキュレーションを定義できるということは、 これらの ... をどうするかも考えなければならない。 結果的に、ほとんどの記号に、... を自由に付けられる仕様にする事とした。 8va などは、メニューに最初から入れる。 ６．ｘは、... の形状等を後から変更できるようになる。 これによって、音符だけに有効な 8va や、ちょっとだけの範囲の 8va なども、 書く事ができるようになる。 たとえば、ドラムの o -> も、同様な概念なのである。 つまり、あらゆる記号に、やりたければ、有効範囲指定ができるようになる。 という事である。
と、言う事は、小節またがり記号を対応しなくてはならなくなる。 バージョン７の開発の際、クレッシェンドのまたがりの開発をしていた。 その概念が、６．ｘで必要になってしまったのである。
単なるドラム操作改善が、これほどの修正規模になってしまった。 多くは７でやろうと思っていた事。それが６．ｘで徐々に組み入れられる。
結果的には良かったと思う。たまたまいろいろな案が浮かびやすかった時期に、 仕様を考える事ができたからである。
最終形態思考と直接思考の発見が大きかった。 そして、設計が苦手である事が明確に認識できた事。 それによって、設計手法の研究が進みつつある。 結局のところ、考え付く案を全部紙に書いて、どれが良いか選ぶ事である。 ９０％良い案で１０％問題があったとした場合、１０％の問題があっただけで、 その案を捨てる必要はない。１０％部分の改善案を更に出せば良い。
-
toCoda リリース後に、別のバグを見つけてしまった。
ＯＳに１つ以上ＡＳＩＯドライバが入っている場合、
最初のＡＳＩＯしか使用できないというバグである。
何気なく、いつもとは他のハードウエアを使ってＡＵＤＩＯを鳴らしてみようと思ったものの、 ＡＳＩＯがうまく起動できない。
昔、開発環境を Vista から XP に戻した際、XP のドライバがどれだか忘れていて、 適当に入れた。なので、それが原因と思い込んでいた。
しかし、どうしても、２つめのほうのＡＳＩＯを鳴らしたくなり、 原因を調べてみる事にしたのである。
まず、MIROSLAV をスタンドアロンで起動し２つめのＡＳＩＯが動作するか確認した。 うまく動作した。すなわち、ドライバでなく、Score Editor が問題である事が証明された。 かなり、ショッキングである。
すぐさま、Score Editor 側の原因を調べた所、 いくつＡＳＩＯが入っていても、必ず最初のＡＳＩＯを動作させようとしている。 一番最初のデバッグ時のコードのまま、忘れ去られていた。 極めてショッキングである。ＡＳＩＯが動作しなくて泣いたユーザが沢山いたかもしれないのである。
重大なバグなので、修正版を緊急リリースする事とした。 これから、リリース作業に入る。
一方、６．ｘの開発のほうであるが、いろいろ進んでいる。 くわしい開発状況はまた後日報告したい。リリース作業が先だ。
-
繰り返し記号 toCoda が動作しない不具合の修正版をリリースした。
特殊なパターンは動作していたが、基本的なパターンが動作していなかった。
まさに、ショッキングである。ずっと以前にも他の方から報告をいただいており、
気にはなっていたが、今回修正できたので、心配事が１つ消えた。
引き続き６．ｘの開発に戻る。 以前は、データ構造に関しての設計を終えていたが、 ようやく、アーティキュレーション関連の画面設計も完了した。 早速プログラミングに入りたい。
この部分が完成すればドラム譜関連も同時に操作性が改善される。 その後、ＭＩＤＩ関連の演奏処理を開発し、ＡＵＤＩＯ関連に入る。 最後にプリセット関連と楽譜読み書き、音源定義の作成画面を開発し、 ようやくリリースできる予定であるが、やることが多く、 この事を考えると気が遠くなる。特に、演奏処理は、 今回の概念＋音源エンジン改善の関係で、半分は作り直すし、 苦手な設計も待っている。山はまだ沢山ある。
それと、テキストをユーザが自由に作成できる事になり、 ppp や fff のフォントを作成する必要がある。 音楽で使用されているこのフォントは何なのか？不明である。 結局、p や f 、m 、s 、z 、v 、a の形状を元に全てのアルファベットの形状を推測。 なんとか、フォントの作成が完了した。 rin fz などの rin は、小さい文字なので、これも同様に形状を推測して作成した。 同様に数字に関しても推測できるが、今回は力尽きた。
-
思うに。作者の場合、プログラミングよりも設計に時間がかかっているように思える。
プログラミングはあっという間に終わるが、
すぐに壁にぶつかる。壁とは不明確な要素と考えられる。
この壁であるが、とにかく悩ましい。迷いの生じるやっかいなものである。 機能を優先すべきか操作性を優先すべきかがその多くの悩み。
Score Editor の場合、操作性を優先しているが、 操作性を優先するという事は、機能を単純化するという事でもある。
機能を単純にすると、機能が増えないので、 ソフトを使いこなしているユーザは不満となる。 操作性を無視して機能を優先したのがバージョン６でもあるが、 結局、ドラムと音源設定で不便になり、機能を使えるどころか、 基本的な操作すらできにくくなる。
結果的に操作性を改善すべく６．１３を現在開発している。 最終的には操作性が重要になるという事である。
それには、最終形態と直接思考を重視することで、 シンプルな操作で細かい機能が使えるようになる。
しかし、簡単に思い浮かぶものでもない。 やっぱり設計には時間がかかるのだろうか。
音楽記号にはパラメータがあるが、 初期設定とパートごとの設定の２とおりが存在する。 下手すると、ユーザはどっちの設定を操作しているのか分からなくなる。 このあたりの部分で現在悩んでいる。
これに関しては音源設定でも同じ状況であった。 共通設定にしたバージョン６の操作性に疑問を感じ、 ６．１３では、共通設定という概念を極力避けるような方針としている。
同じ状況にならないためにも、よく考える必要がある。