あらすじ
|
パートのエクスポートが完成し、パートの追加が完成した。
しかし、ドラムを追加する部分を開発しようとしたら、 データ構造に関してどうにも不快感を感じる。 そこで、データ構造を少し改良する事にした。 理論的に考えるとプログラムが煩雑になるデータ構造修正だったのでためらっていたが、 適当思考を思い出した。理論がどうの言っている時間があれば、 さっさとやってみるべしと思った。気になったのなら、 気になる要素をまず解決しないと、いつまでも悩む。 データ構造を改良し、ドラムの追加と削除機能が完成した。 理論とは正反対に、ものすごくすっきりしたプログラムとなった。 新しいプログラミング手法を得た。 考えてもしょうがないといったことが実証された。 記号の追加等の編集機能とメニュー作成機能の細かい部分を完成させた。 続いて、記号ごとに編集画面を作成する必要がある。 今までのバージョンで存在した構造を思い出すのが面倒だしわかりにくいプログラムだったので、 今回、この部分を１から適当に作り直した。あっさりと完成する。 余力で速度標語＋テンポ表記も新たに可能となる。 記号編集画面に演奏に関しての部分も加えた。 記号演奏パラメータの設定画面が大枠完成。 適当思考により、あまりに効果的な開発ができるので、 適当思考に関して感動に浸る。 演奏処理の開発に取り掛かる。 演奏処理であるが、内部的な作りになると適当思考ではうまくいかないようである。 という訳で、演奏処理は真剣思考で開発を進めている。 開発が遅れている事の言い訳をする。 6.13 から新たに追加されるまたがり記号。 8va などのまたがり記号演奏や、演奏データ作成をダイナミックにする取り組みを行っている。 |
2009-04-30
-
実を言うと、先に、演奏処理の開発を行っている。
アーティキュレーション画面の最終部分の開発は演奏が出来てから行うとした。
画面に関しての残りは操作性に関しての部分だけで、 それよりも、演奏のほうが重みがある。 演奏がうまくできなければ画面も変わる可能性がある。 理論上はうまくいくはずだが、演奏ができる。といった実証を先にしておきたい。
演奏ができれば今回のバージョンに関しての大きな部分が全てできた事になる。 後は細かい部分の作りこみだけになる。といっても、印刷処理は今回作り直すし、 AUDIOモードの作り直し等いろいろやる事は残っている。
演奏処理であるが、内部的な作りになると、 適当思考は通用しないようだ。適当でうまくいかない場合は、 真剣思考？で対応する必要がある。これは脳が消耗するし、忍耐も必要となる。 適当が通用するのはどうやら画面などの基本的な設計に関してかもしれない。 内部的な作りに関しては、真剣に取り組まないとぜんぜん進まないし、 適当では本当に動くのか不安になってしまう。
というわけで、演奏処理は真剣思考で開発を進めている。 この部分はなかなか難しいので、開発にはかなり時間がかかると思う。
ところで６．１３のリリース時期であるが早ければ５月ごろを目指していたが、 現在の状況では無理である。当初の想定どおり秋ごろになるかもしれない。 だが、できるかぎり、早くリリースできるようがんばっている。 長期開発は精神的につらいのである。なので早くリリースしてしまいたいと常に思っている。 ただ、６．１３は Score Editor の最終形態を意識して開発している。 だから、いろいろな仕組みや機能が今回追加される事になり、けっこう大きなバージョンアップとなる。 それなりに開発時間がかかるものとなった。
６．１３ではまたがり記号が対応される。8va の範囲も指定できる。 現在、演奏処理でのまたがり対応を行っているが、この部分はとても重要になってくるため、 慎重に開発を進めている。これができないと、8va が動作しないので音階すら決定できない。 しかし、できてしまえば、下手したらクレッシェンドも実現できる。 理論上はできるものと考えている。
それと、音符の視聴機能も可能なよう考慮している。 当然、8va などのまたがり記号が影響する。瞬時に視聴可能にするには、 演奏データ作成をダイナミックにする必要があり、現在それに着手している。 というわけで、開発に時間がかかっている。
-
記号演奏パラメータの設定画面を作成していたが、
大枠完成した。演奏方法の数だけ画面が必要で時間がかかっていた。
これで、記号の編集画面が完全なものとなった。 今までは、記号の表示に関してのパラメータ画面の開発を行っていたが、 今回、演奏に関しての部分も加わった訳である。
これらに関しての開発はまだ続く。 ６．１３では、ユーザが記号をある程度作れるようになるからである。 演奏方法などもユーザが決める機能が必要なのである。
しかし、もう少しで、この部分の開発が完了しそうである。 これが出来たらアーティキュレーションの最終部分の開発をし、 アーティキュレーション機能に関しての画面がようやく完成する予定。
拍子のデータ構造が以前のバージョンではわかりにくく、 今回拍子データの構造も変更したので、拍子作成に関しての画面も開発しなおす。 そのほか、ジャンプ記号関連の設定画面も作成する必要がある。 これら全てが終われば、演奏処理の開発に取りかかれる。
とにかく画面の数が多いので工夫をしているが、 開発にはそれなりに時間がかかる。 適当思考の副作用と言える。機能ごとに適した画面を用意するのが適当思考。 変に統合しようと考えてはいけない。統合すればプログラムは少なくなるが、 不必要な項目が画面に出る傾向になりソフトが使いにくくなるし、 後の修正が利かなくなるばかりか矛盾が多くなってしまう。 変に統合しようとせず、逆に画面を多くしたほうがユーザも理解しやすく、 ソフトがかなり柔軟になる。意外とプログラムも簡単にできるし頭も使わない。
これらの画面は、仕様決定が難しかったが、適当思考のおかげで、 見事にうまくいっている。昔、悩んでいた問題もいつのまにか改善されている事に驚く。 つまり、仕様面ではもう見えているので、作りこんでいくだけである。
これが適当思考のすばらしさである。適当というと、良くないイメージがするが、 ようは、無駄な力を抜いて開発するという意味である。自然体で。
以前、１００％以上の力を出して開発しようとしていた時期があったが、 そうするには栄養の高い食べ物もそれなりに必要になる。結果的に脳消耗と肝臓へのダメージへとつながる。 肝臓にダメージがくると全体にダメージが来て、スタミナがなくすぐに疲れる体質になる。 不思議と開発は失敗ばかりであった。無駄なことを考え作ってしまい、後で不要なので削除する事になる。 １００％の力を出すと、無駄な部分を詰め込んでしまうのである。
本来、ユーザは１００％以上の力を出して Score Editor を操作するのかと考えれば、 そんなはずはない。ラクに操作できないソフトは使いにくくなる。
開発者が適当に操作できるソフトを開発する事で、ユーザがラクに操作できるソフトになるのである。
適当思考になると、脳への栄養も必要としなくなる。 あっさりした食べ物で十分開発できる。結果的に肝臓へのダメージも減り、 疲れにくくなる。脳も疲れないので、以前に比べるとずいぶんラクである。 常に余力があるので、突然開発で問題がおきても、あっさりと解決できるのである。
１００％思考は、いわば、メモリをいっぱいまで使っているメモリ不足のコンピュータのようなものかもしれない。 その状態でもうひとつソフトを起動するとメモリ不足で速度が低下し時には異常終了する。 適当思考にすれば、余力があるので、全体としてスムーズとなる。
今の世の中は１００％以上思考の傾向のように思う。だから何も出来なくなる。 しかも苦労して１００％で作ったものは崩れやすい。損ばかりだ。 適当思考になれば、本当にラクになるのでお勧めしたい所である。 ちなみに、適当思考の場合、少しでも疲れを感じたら速やかに休み眠ってしまう。１時間で完全に回復するはずである。 やる気が出るまで寝ると良い（中途半端に何か別のことをしては駄目である。それはサボりか現実逃避である。徹底して寝る。これが適切な方法だと思う）。やりたくないならやらなくて良い。 やりたくなったらやれば良いのである。
この理論からすればビスはがんばって作った物に違いないという事が推測できる。 苦労しただけに捨てられず引きずる。悪循環である。良い部分を残し失敗した部分は素直に捨てるべきである。
-
記号の追加等の編集機能とメニュー作成機能の細かい部分を完成させた。
これに関しての画面関連の作成はこれで終わり。続いて、
作成したメニューを保存する部分を作成しようと思ったが、
記号１つ１つの保存機能が出来ないと出来ない。
記号の保存はめんどうなので、とりあえず忘れて、 アーティキュレーション画面の細かい部分を作成してしまおうと思う。
記号ごとに編集画面を作成する必要がある。 記号の編集画面であるが、以前の作りだとごちゃごちゃしているので、 適当思考で作り直すほうが早かった。
これらの画面作り直しは既に終えた。テンポの作成に関して、 今までの設定項目だと使いにくいと以前から思っていたので、 今回見直した。納得の形となった。しかも速度標語＋テンポ表記も新たに可能となった。
文章のながれがなんだか変だが、さっさと開発を進めたいので、 気にしないことにする。たぶん、理解できるだろう。開発日記に時間がかけられない。
-
データ構造を改良し、ドラムの追加と削除機能が完成した。
今度こそ、ドラムから離脱できる。
続いてアーティキュレーション作成関連の開発に入りたい。
いいかげん＆適当思考はかなり良い感じである。 ドラム画面の操作性もものすごく使いやすくなったと思う。 それに、今回のデータ構造変更であるが、 プログラムが複雑になるように思える変更で、着手をためらったが、 適当思考を思い出し、着手する事にした。 結果的には、プログラムが単純になって、ものすごく扱いやすくなった。 なぜ単純になるのか修正を終えた後に考えてもよくわからない。 結果的に新しいプログラミング手法を得たことになる。 世の中には頭で考えても理解できない事が沢山あるものだと思った。
-
パートのエクスポートが完成し、
パートの追加が完成した。エクスポートした設定から追加する事も可能。
これで、パート追加時のわずらわしさがかなり解消される。
アーティキュレーション画面の細かい部分の開発に取り組んでいたのであるが、 この画面はパートの設定画面の一種と考えられる。 ドラムを追加する部分を開発しようとしたら、 データ構造に関してどうにも不快感を感じる。 そこで、データ構造を少し改良する事にした。
本当にしつこいドラムである。なかなか抜け出せない。 とはいえ、抜け出せる時期は近い。
パートの追加。これはバージョン１からの悩みで、 どういう仕様にすべきか、かなり長い間考えては実現できず、 現在に至っていた。しかし、 ようやく今回、目的が達成できた事を伝えておきたい。