※メジャー番号の付与を導入し、開発中 5.5 は 6.01 として新たに命名されました。
あらすじ
|
ドラムマップのデータ構造を修正しＭＩＤＩとＡＵＤＩＯで独立した設定をもてるようになる。 画面下に出てくる赤いバーの画面。これをモニターという。の画面を開発。 演奏時間が出るようにし、液晶っぽいデザインとなった。 続いて、ＳＭＦの設定画面を開発。ＳＭＦの書き出し処理の開発を行う。 複数音源対応のＳＭＦはこれはこれで奥が深かった。format 1 にも２種類の流派がありそれに対応。 さらに、楽譜ファイルの読み書きを開発する。従来の楽譜は全て読めるように、 いくつものローダを開発しなければならない。その対応が終わった。 そして、プロパティ関連の作りこみを行う。 主に環境設定に関しての画面の最終調整を行った。
完成が近づくにつれ、作者の意識が高まりすぎ、睡眠バランスを崩し体調を崩す。 プログラマはいかなるときも冷静でいなければならない。まだまだ修行が足りない。 そして、深刻な問題を対処した際、これが設計ミスであった事が発覚。 複数音源の設計ミス。同一音源にＡ，Ｂ、とポートが入っていてエフェクトが１つあるという構成。 この時、エフェクトやリセットが２回発動してしまうという設計ミスである。 更に、謎の不可思議現象に見舞われ、追い討ちをかける。なんとかこれに打ち勝ち、 深刻な問題の対処も最小限でおさまる方法が思いつく。 設計ミスのショックは大きく、次のバージョンで対応しようと思っていた機能が、 チラチラと頭で思い浮かび落ち着かない。 結局、完成が近かったのに新機能をいくつか増やす事を決意する事になる。 |
2007-07-31 状況
-
なんとか現在の仕様を保ったまま、深刻な問題の対処ができる方法が思いついた。
パラメータの分類を１つ増やし、構成情報を自動生成する事で解決できるが、 この修正に伴い副作用が生じ、その対処で多くの時間を取られそうである。 想定よりは、小さな機能追加で解決できるが、機能を追加しなければならない事には変わりない。
また、もう一度、ＸＧ音源、ＧＳ音源を使って調査を行った。 その際、説明書をもう一度読み直し、深刻な問題を対処するための準備が整った。 これから深刻な問題の対処を行いたい。
ここに来て設計ミスが見つかった訳であるが、 原因は、音源がたぶんこういう仕様になっているだろう。 という推測しかしていなかった点である。 実際にに音源に命令を送ってきちんと調査をしておくべきであった。 コンピュータにおいて推測は通用しない。その事を忘れていた。
という事は、知らない音源については、調査できないので、 いずれにしても、将来仕様を修正しなければならない時が来ると思う。 ある程度の割り切りは必要である。 将来仕様を変更しない。と決め付けるといつまでもリリースできない。 逆に、将来仕様を変更する事を許してしまったほうが良いのかもしれない。
-
パラメータがめちゃめちゃになる問題は解決した。
プロパティＯＫ時のデータ書き込みの不具合であった。
続いて、深刻な問題について検討している。 検討の結果、更に機能を１つ追加しなければならなくなりそうである。 ５．５のリリースまでには更に時間がかかりそうである。
深刻な問題とは同一音源内に１６ＣＨのパートが２つ以上あり、 エフェクタを含むミキサーが１つ。という構成の場合で、 例えばＤ７０という音源の場合、 ＯＳからはＡ，Ｂ，というポートしか見えない事による問題である。 つまり、エフェクタの操作をするポートがＯＳ上に存在しない。 どうやって操作するかというと、ＡかＢのどちらかを通してエフェクタを操作する。 どっちなのか？これを定義できなければならない。通常はＡであろう。
そもそも、この問題は根が深い。つまりＯＳが音源本体を認識する事ができない。 音源の内部的な機能が中途半端にばらばらになってＯＳ上で見える。 そして、昔ながらのＭＩＤＩファイルの伝統的な考え方も取り入れるため問題は深刻なのである。
なんとかしてこれを統合しないと、音源の初期化順序が正しく記述できなくなる。
通常のシーケンスソフトの場合だと、自分でＳＹＳ・ＥＸを書き込むので 何ら問題が生じないが、Score Editor の場合は、その手順を自動化しなければならない。 ユーザからはＳＹＳ・ＥＸ等の命令は意識しないのが Score Editor の設計思想だからである。
それゆえ、今まで行ってきた５．５の対応は途方も無く難しいのである。 さらに音源それぞれ仕様や規格、機器の構造がばらばらなので、 それらもふえまた構造にするには、様々な難しい問題が出てくる。 さらに、ＶＳＴとくれば、これもますます仕様が決まっておらず、 どうやって Score Editor から、音源を制御するかといった問題は以前から頭を悩ます。
Score Editor は、できるだけ自然に音源を操作できるように設計しなければならない。 ＯＳの制限上、どうしても面倒な設定作業が必要になる。 いかにしてその設定作業を少なくしてユーザの負担を減らすかが課題である。
音源関連にあたっては、ＯＳ上の段階で、 昔のままで進化していないというのが現状なのである。 Vista によって更にこの部分が放棄された。Vista によって、 音楽ソフトを開発するベンダーに、 音源関連機能を全て託した。といった現状である。 ５．５を開発してて思うのは、作り損ねたＯＳの一部を開発しているよう。
こういった背景には音楽のＡＵＤＩＯ化が進んでいる事が考えられる。 全てソフトウエア音源になる時代が来るだろうと。
ユーザが快適に音源を使用できるソフトになるまで５．５の開発は続くのである。
-
ようやく体調のリズムが整ってきた。
残件を４つ対応したのであるが、 いくつか問題点を見つけた。
今回は謎の不可思議現象に悩まされる事となった。 何もしてないのに突然発生するバグの一種である。 １つは、画面上に謎の四角形が起動時に描画される問題で、 なんとか根気良く追求したら修正できた。
もう一つはパラメータがめちゃめちゃになるという現象。 何もしてないのにこうなった。 現在追求中であるが、プロパティをＯＫして音源設定を保存した際に、 何かが生じたと思われる。今まで見つからなかった何かが起こった。 早めに見つかったのは、運が良かったかもしれない。
原因はおそらく深刻な問題の部類と思われ、 ショックを隠しきれない。
深刻な問題が１件残されているのでそれとともに対処してしまうべきかもしれない。 またしても、データ構造を若干修正しなければならない。
今回の５．５はとても重要なバージョンアップとなる。 できるかぎり良い仕様にしておく必要がある。 なぜなら音源定義をユーザが作成できるからである。 後からバグが見つかってデータフォーマットの仕様が後から変更になると、かなり苦しいのである。
それで５．５の開発はとても時間がかかっている。 音源処理がプログラムの外に出るので、定義次第で動作に影響してしまう。 テストパターンは無限の可能性があり、なかなか開発が難しい。
-
寝不足の影響が引きずってどうも調子が良くない。
８項目の残件を対応した。プロパティ反映処理はまだ完成しない。 残り残件は１３項目。なかなか減らない。 そして、最後のプロパティ反映残件処理がとても難しい。
気持としては開発を進めたいのであるが、 精神力と集中力が低下しているため、体調を整える事を優先したい。
気持ちが高まりすぎて、必要以上に気合が入りすぎ、 かえって力んでしまい無駄な体力消耗が生じてしまった。 サクサク進むはずだったのに残念である。
体調としての症状は目が痛くしかも痙攣する。これのせいで集中ができない。 どんなにワクワクしても落ち着いた冷静な態度で開発しなければならない事が、 今回分かった。
目の症状であるが左目が痛いのであるがこれは過去にも同じ事を体験している。 痙攣はブルーベリーを食べれば改善され、 目の痛みはトマトジュースを飲めば改善される事が過去の経験で分かっている。 そしてコンピュータから離れての気分転換が必要となる。
-
プロパティの反映処理の開発を行っている。
反映処理自体はすでに前からできているが、
反映した後の起動しなおしなどの整合合わせの処理が必要なので、
その開発を行っている。
従来の Score Editor は設定を変更後ソフトを起動しなおさなければならないが、 ５．５ではその必要もなくなる。そのための処理を開発している。
じっくりと考えた結果とても良い動きをしてくれた。 これでポロポロと落ちなくなる。開発中はソフトがポロポロと落ちるので、 しょんぼりしたり５．５は大丈夫だろうか？と心配になるが、 さすがに完成が近づいてくるとしっかりと動作するようになってくる。
完成の近さを実感すると、止まらぬワクワク感がこみ上げ、 気持ちが高まりすぎて昨日は寝不足である。
とはいえ、まだまだやることが沢山残されている。 そして、深刻な問題が１件残されている。 しかし、ちゃくちゃくと完成に近づいているのを実感する。
-
残件を１３項目終わらせた。主にプロパティ関連の対応を行なった。
画面数は膨大であるが、使用する項目を分類して見直し、
動的にプログラムで画面を作成する事でわりと楽に対応することができた。
楽になった分こだわって開発することができた。
当初プロパティ関連の画面は上級者用だったので、 おおざっぱな仕様でリリースする予定であったが、 何か納得いかなくそのため完成が遠ざかっているように感じていた。 しかし、全ての画面にこだわったため内容が分かりやすくなり、 完成した感じがする。これにて抱えていた厄介な画面から開放された。
残り残件は１７項目。更に細かい粗が沢山出てきたが、 次々に対処した。だんだんと完成品に近づいてくる。
これから残り残件を分類して対策を検討してから、 対応に入りたい。大枠６分類となる。
１．主要な残件、２．深刻な問題、３．最終調整項目、４．開発中に発生したバグ対応、 ５．設定反映に伴う再起動処理、６．プロパティの反映処理。である。
５、６、はプロパティ関連である。まずこれを片付けたい。 その後、３、４、を対応する予定。
-
フリー互換フォーマット３．０を完成させた。
これで楽譜ファイルの読み書きは全て５．５対応された。
さらに５．５開発にて生じた不具合など４項目の残件を対処した。
残り残件は２１項目。なぜか開発を進めると残件が増えていく。 完成度が上がるにつれて細かい粗が目に付くからである。 これを繰り返す事でソフトウエアは完成するものである。
引き続き残件対応を行う事にする。 残り残件は主に環境設定に関連する項目となってきた。
-
考えても始まらない事が分かった。
とにかく残件を片付けていくしかない。
まず５．５フォーマットにてＡＵＤＩＯ音源の読み書きを完成させた。 続いて、フリー版互換フォーマットへの書き込みを開発する。 楽譜形式は２．０、２．５、３．０の３種類である。
２．０はドラムなし。２．５はドラム譜あり。３．０は主に拍子対応である。 これらは、旧バージョンのフリー版でも読める形式となっている。 つまり、下位互換フォーマットとなる。 データやファイル形式がほとんど違うので苦労する。 しかし、旧バージョンは記号や機能が少ないのでそれほど難しくない。
ひとまず、２．０、２．５形式を完成させた。続いて３．０形式を開発する。 これが終わったら、５．５開発にて生じたバグ対応を行い、 とにかく残件を減らしたい。そして先送りしていたプロパティ画面関連を進めたい。
-
できることから片付けたいと思い、ミキサー情報の楽譜保存と読み込みを作成した。
その後、５．５フォーマット読み込みでＡＵＤＩＯ音源のアサイン処理は４．３の処理を使えない事に気がつき、
５．５楽譜ファイルフォーマット用のＡＵＤＩＯ音源読み込み処理を作成している。
初期化手順の関係なのかどうもうまく音源が読み込めない。 苦戦している。開発のノリがどうも良くない。不調期である。
何をすべきか順序が良く分からなくなっている。 おそらく開発の疲れがまた出てきたのであろう。 調子が出るまでは、超スローペースで開発を進めることにしたい。 コンピュータから離れて紙の上でいろいろと考えてみたい。
-
いつの間にか時間が過ぎていた。
ひとまず４．９フォーマットの読み込みが完成。 続いて新フォーマット５．５の読み書きを開発した。 今回オクターブ記号が増えたので５．５フォーマットに含めた。
５．５にて、演奏がしょんぼりした音になる事があったので、 原因を調べたら音律関連のパラメータがうまく反映できていなかった。 Ｄ７０音源の場合は、工夫が必要な事を思い出し、 その対応を行った。しゃっきりした演奏になった。 また、システムリセットが作動していなかったので、 その修正も行った。
さらに、５．５のエフェクトがかからなかったりする状況に遭遇し、 調べたところ、複数音源で動作させると発生する事が分かった。 そして、ショッキングな出来事に遭遇した。
同一音源内においてエフェクトは１つしか設定できないようである。 Ｄ７０音源の場合、１６ＣＨのポートが２つあるが、 エフェクトは音源で１つという訳である。センドエフェクトなので複数あっても音楽として無意味である。 センドエフェクト、つまりミキサーは１つであるというのが当たり前である。 Ｄ７０はその当たり前の考え方で設計されていた。これは当然だろう。
勘違いしていた作者が愚かであった。 単に１６ＣＨの音源が丸ごと２つ入っていると思い込んでいたが、 エフェクタだけは別枠となっていたようだ。 この想定違いにより５．５の仕様の設計ミスが発覚してしまった。
ＵＳＢ接続の場合音源には複数のポートとして見える。 しかし、エフェクト用の音源全体のポートは見えないのである。 仮にポートＡ，Ｂがあったとすると、エフェクトの設定は、ＡかＢに１回だけ行えば良い。 このＡかＢといった考え方がコンピュータは苦手なのである。 結局ユーザが選択してやらなければならない。選択は操作性を低下させる要素となる。
ただ、もしかしたら、音源によっては、Ａ，Ｂ，で別々にエフェクトの世界を構築できるものもあるかもしれない。 何も、エフェクトだけに限らないからである。これによって選択肢がまた増えてしまう。 選択肢が２つならば、全ての選択肢は４通りあるという事になる。 エフェクトを使うにあたってユーザは４通りの操作性を考えなければならない。
どうすれば分かりやすい仕様になるか？また頭を抱えなければならなくなった。 メイン画面においても１４回目の検討を始めなければならないだろう。 データ形式においても、また修正を入れなければならない。 そして、パラメータ共有のほかにポート共有パラメータの概念が必要になるかもしれない。
現在の残件は１７項目。完成しそうで完成しない５．５である。 そしてまた１つ、ソフトを複雑化する要素が増えてしまう。 機能が増えるのはうれしいが、それをわかりやすく操作できなければ、 Score Editor の価値が半減する。
ユーザが５．５の機能についてこれるかという点が作者の不安要素として付きまとう。 このままでは市販ソフトのような、機能に押されるソフトになってしまうのである。 ユーザは何をすべきか分からなくなってしまう。 Score Editor は、ユーザが中心になり、音楽を統括する気分を体験できなければならない。 これが従来からの方針である。ソフトが中心になってはならない。
開発に時間がかかって申し訳ないが、作者のこだわりの関係上、 今回の問題は時間がかかっても解決したい。
-
楽譜ファイル４．３の読み込みがようやく完成した。
続いて４．９フォーマットの読み込みの開発を行う。
４．３の対応はＡＵＤＩＯ機能が関連するためとても苦労した。 どうしても、とあるデータ構造にアクセスできないのである。 以前から違和感があったのであるが、デバイス関連のデータ階層が深いので、 どうも開発がしにくい。階層的なデータ構造にするとプログラムの処理も階層的にしなければアクセスできなくなる。 基本的に平坦なデータ構造にしたほうが良い。そうすることでプログラムのループが減り楽にアクセスできる。
そこで、思い切ってデバイス関連のデータ構造の大改造を行った。 またしても、副作用が出る覚悟であったが、ＭＩＤＩモードは不思議な事に副作用は出なかった。 問題はＡＵＤＩＯである。多数の副作用が出たが何とか片付けた。 これにて、デバイス関連のデータ階層が１つ減った。 これで楽にデータ構造にアクセスできる。結果的に分かりやすい構造になった。
そしてＡＵＤＩＯ対応の４．３フォーマットを読んで演奏してみたところ 無事に演奏ができた。５．５の新しいＡＵＤＩＯ機能を楽しんだ。
現状リリースしているフォーマットは４．９までである。 これから最後のローダを開発する。 ４．９は移調楽器パラメータと、 エフェクトの音源定義が今回の対象となる。
-
楽譜ファイル２．０、２．５、３．０、の読み込みが完成した。
現在、４．３形式の読み込み処理を開発している。
４．３といえば、ＡＵＤＩＯ機能が追加されたバージョンである。 従来のバージョンのＶＳＴ関連の読み込みを、 新しい５．５上で再現しなければならないが、 読み込み手順が従来と大幅に変更されたため苦戦している。 この部分の作りは大切なので納得いく構造になるよう改良を始めている。
一方、２．５形式の読み込みは完成したが、 この形式はドラムマップが使用できる。 ドラムマップの５．５上での復元は苦労した。 ドラムは２．０でも演奏できたが、ドラムのキーを直接楽譜に書き込む方式であった。 この方式も複数音源対応をする必要があり、急遽対応を行った。
当たり前の事であるが、過去の楽譜を５．５で読んで 演奏をしてみた所、昔と全く同じで再生がされた。 内部構造の仕組みが大幅に変更されたが、ちゃんと同じように再生されて、 喜ばしい気分である。
-
副作用関連の残件を８項目対応した。
ほとんどの副作用は改善された。全ての残件はあと１６項目。
これから楽譜ファイルの読み書きの開発に入る。 ひとまず、古い処理を全て取り除く作業を行った。 まずは、楽譜ファイルの読み込み処理を開発する。
けっこう根気がいる。Score Editor は、過去の全ての楽譜形式を読み込めるようになっている。 ２．０、２．５、３．０、４．３、４．９、の５つのローダを開発する必要がある。 新しいバージョン５．５の内部データ構造が変化したため、 各ファイル形式から新しい形式に変換する処理をそれぞれ開発しなければならない。
楽譜の読み込みができれば、過去のファイルを読み込みながらの動作確認ができる。
-
ＳＭＦの書き出しが完成した。純正な format 1 と format 0 の書き出しが完成。
これから、AUDIO ファイルの保存を開発しようとおもったが、 きれいな順番で開発が進まないのが実質である。 以前行ったデータ構造変更の修正で副作用が出ており、 先にこちらの残件を終わらせてからのほうが開発がスムーズになると思われるので、 副作用対応を先に行う事にした。
副作用関連の残件対応を進め、６項目が完了した。 これらはあと２０項目も残されている。一方、主要な残件は４項目である。 ７月中の５．５リリースは難しそうである。
複数音源対応、それは、Score Editor Classic が持っている、 ほとんど全ての機能に対してソフトの改良を行うといった大掛かりな対応である事を今更ながら実感した。 これに手を付けてしまったからにはもう戻れない。
しかし、この対応を行う勇気を与えてくれたユーザには感謝である。 思えば、SD-20 ユーザからの問い合わせが、その始まりである。 続いて、ＣＨ数増量要望、ＶＳＴマルティティンバーの要望、ＸＧユーザからの要望、 音源定義の問い合わせ、これらユーザの思いが込められた５．５となっている。 さらに作者が前から思っていた納得行かない点が改善される。
コツコツと進めるしか方法がない。
-
久しぶりに休憩を取った。
そしてＳＭＦフォーマットのファイル書き出し部分を作成し動作した。 いろいろなシーケンサで読み込ませてふさわしいトラック構成になるよう調整し、 無事完成した。複数音源のポート認識も正常である。
シーケンサ受け渡しに適した format 1 の書き出しができたので、 今度は、現在ではあまり使われていないと思われるが、 純正な format 1 の開発に入る。それが終わったら format 0 の書き出しを開発する。
処理の流れやデータ構造はシンプルな構造が思いつき、 開発がしやすくなった。メモリ効率や処理速度も普通レベルだと思う。
２日に及ぶ完全な休憩を取ったという事もあるが、 単なるファイル変換で時間をかけてしまった事で焦りが生じてしまいそう。 しかし、ＭＩＤＩファイルの書き出しは大切な機能なので、 開発に時間がかかっても落ち着いて開発をしたい。
-
本日は０７０７０７の日。無事５．５が完成するよう願い事をしたいと思う。
手始めに他のシーケンサへの受け渡し向けの SMF format 1 の書き出しを開発している。 だいたい基本的な部分は出来上がった。
あとは、ファイル形式に変換する部分を開発すればよいのであるが、 この部分で小さな悩みが生じている。どのようにトラックを作り出すか。 という点である。楽譜ソフトならではの悩みである。
本当に処理速度とメモリを気にしなければ簡単なのであるが、 それではプログラマとして失格である。 メモリを多く使えば処理は早くなり、メモリを使わなければ処理が遅くなる。 普通はこのどちらかであろう。 少ないメモリで早い処理が作れれば上級である。 メモリを使って処理が遅くては、よろしくない。こうしてプログラマはいつも悩むのである。
特に処理速度を求めなくて良い場合は、できるだけ自然な流れで処理できるデータ構造を考えるようにしている。 データ構造の決め方次第でソフトの品質は大きく左右する。
それで作者はデータ構造がとか、パラメータの持ち方がとか、よくつぶやくのである。
-
ひとまず残件をいくつか対処した。
演奏終了時の処理、音源リセット処理、等々５項目を対応。
大きな残件は残り６項目。そのうちの１つ、ＳＭＦファイルの書き出し。 を現在開発中。
複数音源ならではの問題がけっこう出てくる。 イベントの順番についてである。ＧＳ音源用と決まっていれば、 それにしたがって順番を決めれば良いが、どんな音源を使うか分からないとなれば、 それなりに工夫が必要である。
特に楽譜系ソフトの場合、イベント順番をユーザが指定しないので、 自動的に判断してやらないといけない訳である。これについて現在考えている。
-
ＳＭＦの設定画面が完成し、いよいよＳＭＦデータ作成の処理を開発するのであるが、
複数音源対応の問題が発生。
つまり、ポート指定をＳＭＦ上でどう指定するかという問題である。
というのも、このあたりの仕様は現在においても規格化されていないようである。 どうしたものか？
実は最初のＳＭＦの規格の中で複数音源の対応が可能な仕様となっている。 しかし、誰もそれを使っていない。というのが問題である。 format 1 の規格ではない format 1 の使い方が主流となっているようである。 その理由は作者も良く分かるので、本当にそんなＳＭＦが存在するのか調べてみたら、 最近はほとんど見ない。昔は真の format 1 を見たことがあったが・・・。
また、複数音源の正式な追加仕様がそれとは別に決まったようなのであるが、 不思議とこれも誰も使っていないようなのである。
そして、多くのシーケンサはＳＭＦ規格に準じない仕様を使って複数音源を対応しているようで、 それが標準となってしまっているようだ。とはいえ、シーケンサ側のソフトもトラックの概念が多様なため、 なかなか規格とソフトが一致しない。というのが現状かもしれない。 従来の Score Editor の format 1 も同様である。
Score Editor の仕様としても、みんなに合わせるという意味で、 暗黙の標準仕様を使ったほうが、何かと便利である。という事でそれに対応する。 もしかしたら、いつの間にか正式に規格化されていた。という事も考えられる。
また、真の format 1 も作成可能にしたい。 format 1 だけでも３種類も存在する。早いところ規格化してしまえば、 こんな事にはならなかったと思うが、ハードウエアやソフトウエアの進化のほうが早かったという事かもしれない。
そういうわけでＳＭＦの保存処理を書くために従来のＧＳ用のコードをざくざくと削除している。 そして、複数音源対応用のＳＭＦのコードを新たに書くことにする。
-
ＳＭＦの設定画面を開発している。
従来のバージョンでは、定義ファイルで画面を作成していたが、
手抜きがちになるので、今回、直接作りこみを行っている。
ＳＭＦの設定に関してのパラメータも見直した。
今になって気がついたのであるが、 従来のバージョンで作成する SMF format 1 は、少々特殊用途かもしれない。 考えてみれば音源が１つなので、SMF format 0 で十分だったのである。 今回、複数音源対応となるので、真の意味での SMF format 1 をサポートする事となる。 従来の Score Editor 用の format 1 も継続して使用できるようにする。
また、細かいＳＭＦの設定パラメータがいくつか増えることになり、 ＳＭＦ作成処理についても、やはり複数音源対応が必要である事が分かった。 この部分を修正するのはうんざりするが、 ５．５からは変換速度は気にする必要はないので気が楽である。 ＳＭＦを書き出す時はメニューからなので、それほど高速化する必要もない。
５．５からは、Score Editor 上での演奏はＳＭＦ形式でなくても可能になった。 実質、内部的にＳＭＦデータを作成しないで演奏をする事ができる。
従来の仕様で一旦内部的にＳＭＦにしていたのは、ＭＩＤファイルにした時の演奏の再現性を一致させるためであったが、 ５．５では音源が常にセットアップされた状態であるため、セットアップ小節は不要である。 そういう意味でも、別にＳＭＦにしてから再生する必要もなくなった。
ＳＭＦ関連では、書き出しメニューを名前を付けて保存ではなく、 ファイルメニューに項目を表示する事にした。 どうやってＭＩＤを作成するか分からないといった問い合わせが多かったため、 分かりやすくした。
あと、ＳＭＦ設定パラメータは、４．９あたりから音源ごとに保持していたが、 そもそもこの考え方は複数音源では通用しない。 音源ごとにＳＭＦの設定をするのは、めんどうだし無意味である。 それで５．５からは、１箇所で設定を行うようにした。
また、ＳＭＦファイルを作成するときに、画面をだしてその場でパラメータを調節する。 といった事ができるので、操作性が向上したと思う。画面を挟むので操作が１つ増えるが、 どのような設定でファイルが作成されるのか良く分からないよりは安心できるしリターンキーを押すだけなので、 慣れればそれほど問題にはならないと思う。
-
画面下に出る赤いバーの複数音源対応を行った。
画面幅の問題もあるため、結局従来の仕様を重視すべく１６ＣＨ表示とし、
音源を選びながら全てのバーが見れるようにした。
これを簡易モニタ画面と呼ぶことにします。 今回の改良で、この部分が液晶っぽい見た目になった。 なので赤いバーではなく黒いバーとなる。 そして、以前から付けようと思っていた演奏時刻表示を、 ここに表示する事にした。
これで大枠５．５の機能は一通り作り終わった。 しかし、悲しい事にデータ構造を改良した副作用とも言える残件が出てきてしまった。 現在見つかっているだけで１８項目に及ぶ。 これには、作者、気が遠くなる。
これ以外に主要な残件を対処しなければならない。 音源のプロパティ関連、音源リセット処理の完全化、 ＳＭＦのパラメータ、ＷＡＶＥ作成、ＭＩＤＩ作成、 ユーザ環境関連。である。６項目である。
さらに、演奏停止処理、楽譜の読み書き。で２項目。 優先度の高いユーザ報告、印刷の改善(高速化)で１項目。
これで５．５の残件全てである。 副作用関連は、どちらにしてもα版からβ版そしてリリース版の作業で、 沢山出てくるので、これはひとまず無視する。
やるべき残件は９項目という事になる。 これが終わればα版の完成である。 現在の残件のほとんどが演奏関連であり、ＳＭＦに関する残件である事が分かる。 ＳＭＦのパラメータとセットアップ小節作成の部分が複数音源対応できれば、 一気に進むと思われる。
ゴールは近いが焦らずにゆっくりと考えながら開発を進めたい。
-
高速用のドラムデータ生成の作りこみが完成したので、
共通パラメータ関連の副作用を修正し、ドラムの演奏処理の開発を行った。
そして、ついに、ドラムの演奏が出来るようになった。
今回の残件は荷が重かったが何とか片付いた。 しかし、共通パラメータ処理のデータ構造修正に伴う、 副作用がいくつか生じているので、その修正も行う必要があり、 共通パラメータ関連の残件が増えてしまった。 しかし、目標としていたドラムの演奏が出来たので、 先に進むとする。
次は、演奏時に出てくる画面したの赤いバーの複数音源対応を行う。 ５．５で音源が増えるので従来のようには画面には入りきらない可能性がある。 それにどれだけのバーの数になるか予想できない。 この点について考えなければならない。
-
ドラムマップのデータ構造改良に伴う、ドラム設定画面の修正が終わった。
また、プリセット関連の作りがごちゃごちゃしてきたので、共通処理化を行った。
そして、５．５から追加になるドラムプリセット機能の保存と読み込みが完成して動作した。
ようやく中断していた開発が再開できる。 これで、部分的な共通パラメータがドラムマップに持てるようになったはずなので、 検証を行いつつ、ドラムの演奏ができるよう開発を進める。
ドラムマップに関しては、譜面や演奏において高速な処理が要求されるので、 高速用のドラムデータ構造を新たに作成し、内部的に変換処理が必要になる。 この部分を新たに開発しなければならない。