おしらせ
| Studio ftn は、2007/11/5 より、ＵＲＬが変更になりました。 従来のＵＲＬでもアクセスできますが、６．０リリース後には完全に新しいＵＲＬに移行します。 あわせて問い合わせ先のメールアドレスも変更となりました。 |
新しいURL
http://studio-arts.bglb.jp/studio-ftn/
あらすじ
|
ファイルプリセットと内部的なプリセットの最終調整を行った。
しかし、デフォルトプリセット読み込みの際に、
ドラムマップに関しての設計ミスが発覚。
以前、ＭＩＤＩとＡＵＤＩＯで共通するパラメータを追加し対応したが、 この対応はもともと、ドラムマップのためのものでもある。 しかし、めぐりめぐって、最後の最後に設計ミスとして発覚。 検討の結果共通パラメータと称するものはパートパラメータである事が判明。 ６．０にして始めてパートパラメータの概念を入れる事になった。 ドラムマップの仕様も再検討し、パート側とＣＨ側に情報を持つようにした。 移調楽器をパートに持つように変更した。あわせてパート名を対応。 従来のＣＨ名はそのまま使用できるようにした。 こうして、ドラムマップの新仕様が完成。 実際に何度か試作し動作させてみて、操作感もそこそこ良い仕様にまとまった。 ６．０からは、ドラムマップをパートごとに持てるような仕様になった。 ドラムＣＨも複数使用できる。 ドラムマップが複数持てるようになったので、パーカッション譜が必要となる事は明確。 そこで、パーカッション用の音部記号を追加した。また、一線譜を追加した。 開発以外に Studio ftn のＵＲＬ変更作業を行った。 ＦＡＱの整備やＵＲＬ表記の変更作業を行った。 ＵＲＬは、将来の事も考え、フリーのＤＮＳ(国外)でなく、有料のＤＮＳ(国内)に変更した。 フリーのＤＮＳの手続きが面倒になった事と、将来、突然に有料化した場合に打撃を受けるため、 今のうちに対策を行った。のが今回のＵＲＬ変更の経緯。 |
2007-11-29 追加報告
-
ついに、ドラム機能に関しての作りこみが完了した。
実に嬉しい。
試作に対してドラム譜マップを楽譜でなくパートごとに持つようにし、 操作感を確かめた所、違和感無く操作できた。 仮に設定ミスがあった場合、すぐにどこがおかしいのか直感的に分かる。 どこがどうなって・・・と、訳が分からなくなる事もない。 安心して普通に操作できる感じである。
また、パーカッション譜を対応した事で、休符の扱いの仕様を変更した。 中段、上段、下段に休符を置く事ができるようにした。 これで、パーカッションの場合、中段に休符が置けるので自然である。 また、５．４と同じように、上段下段が必要な場合も対応できる。 ６．０１にて、ドラム譜による中段の休符が追加された。 補足であるが、中段に置いた休符は、内部的に上段下段に休符が入る。
パーカッション譜の追加に伴い、演奏処理や印刷機能に影響が出たため、 これから、それについての副作用対応を行いたい。
ようやく先に進めそうである。しかし、万が一の仕様不具合があるかもしれないので気が抜けない。
-
ドラムマップの試作が完成した。
問題点を全て改善した仕様が無事動作した事に関しては、
前進である。
１つのドラムＣＨ資源にて複数の違ったドラムパート譜を持てるようになったので、 当然、ある機能が欲しくなる。
パーカッション譜である。７．０１の開発に入ると、長期間手が入れられなくなる事を考え、 ６．０１にて対応する事とした。エディタ関連は７．０１で対応予定であったが、 ドラム譜の機能アップを活かすには、６．０１の段階である程度の対応が必要になる。
という事で、６．０１にて、新たに、パーカッション用の音部記号と、 １線譜を追加した。プログラミングも大枠完了している。 １線譜に関しては仮の仕様とした。小節線の上下のラインが５線譜の幅のままでの１線譜である。 譜表の括弧等の改善は７．０１で行うので、それまではこの仕様で十分である。
これで、ドラム機能に関しては、かなり充実した事になる。 しかし、操作性に関して言えば、何かしっくりしない点が２つある。
まず、１つ目であるが、 ドラム楽器を選択する時に、ＣＨ側での設定と、マップ側の設定とで２回行わなければならない。 これについて、５．４のように直接指定できないかと考えたが、 不思議な事にプログラミングが極端に難しくなる。他の理由としては、 ドラムＣＨ側の楽器リストが１２８個にも及ぶ画面となり、 その楽曲で使用するドラム楽器の視聴が困難になる。 また、ドラム楽器ごとにパラメータを持つとすれば、１２８個のＣＨは膨大すぎる。 やはり、少々不便ながらも、２段階の設定を行う仕様にしたほうが良さそうである。 手順としては、最初に、その楽曲で使用するドラム楽器を選び出し、楽器マップを用意する。 ドラム譜の画面から、使用したいドラムを楽器マップから選択する。 この２段階の操作が必要である。なぜこうしなければならないかの決定的な理由が分からないのであるが、 このほうが、自然なのである。あらかじめドラムＣＨ側に初期設定がされていれば、 １段階の選択操作も可能である。６．０１はこのような仕様で固めたいと思う。
もう一点のしっくりしない点は、 ドラム譜のマップを楽譜側に持つという仕様である。 複数のパートが１つのマップを参照すると、片方のパートのドラムを変更したとき、 勝手に、もう一方の設定まで変わってしまう。そのうち、どれがどうなっているのか、 訳分からなくなる。そもそも、マップを楽譜に持つようにしたのは、 パートを削除した場合に設定が残るようにするためであるが、 果たして、苦労して入力したパートを簡単に削除するのであろうか？ という現実である。そのパートのために設定したドラム譜の設定なのだから、 パートを削除するなら、ドラム譜マップの設定も不要である。 更に、１つのマップを複数のパートで参照する必要があるのか？ 必要はないだろう。 ドラムパートが複数になるのだから、個々のマップの設定も大した事はない。 パートごとに作り直せばよい。そのほうが安全であるし、 安心して、パートごとに設定作業に取り組める。 そもそも、ドラム楽器自体の設定は、ＣＨ側に分離したので、 パートを削除しても、その設定は残る。マップの情報などたかがしれているかもしれない。 良く使うマップがあるならば、プリセット機能で読み込めばよいのである。
このような理由から、マップを持つ場所を、楽譜ではなく再びパート側に持つようにしたほうが良さそう。 との結論に至った。これから、この点に関して修正する作業を行いたい。 ドラム楽器選択の２段階操作に関しては、仕方が無いがこのままの仕様としてみたい。
-
ドラムマップに関して仕様がまとまった。
現在、試作を作成中。
11/22 の段階では、あまりにもプログラミングが難しい仕様であった。 ドラムマップと実際のドラムＣＨの情報を融合させる必要があるからである。 出力先等の設定を変更した場合、どこがどうなるのか訳が分からなくなる。
今までの経験からすると、プログラミングできないほど訳分からない仕様は、 設計ミスを含んでいる可能性が高い。 そこで、更なる仕様の追求を行った。
結果的に、ドラム譜部分とドラムＣＨ部分の情報を完全に分け、 画面も完全に分離させる仕様に到達した。 ５．４の仕様では、直接ドラムＫＥＹを指定するが、 これを、ドラム楽器番号というパラメータに置き換える。 楽器番号を経由して２つのデータを結合する仕様が出来上がった。
ユーザにとっては、画面が２つになるので、今までのように、 ドラムの設定画面１つで操作ができなくなるので、不満を抱くかもしれない。 しかし、ＭＩＤＩとＡＵＤＩＯを完全に分離するには、この方法しか思い浮かばない。 この部分に関しては、操作性に関して妥協した。 それよりも、出来ることが増える事。のほうが重要とした。 ドラムの設定など、その楽曲で１回しかしないので、 出来ることが出来ないよりは、絶対に良いはずである。
こうして決まった仕様であるが、 もしかすると、５．４よりも分かりやすくなるかもしれない。
ドラム楽器リスト画面で、使用するドラムをまずユーザがピックアップする。 パン等のドラムのパラメータもこの画面で設定する。 この画面はその曲で使用するドラムセットの編集画面という事になる。 つまり、ＭＩＤＩとＡＵＤＩＯで完全に独自のドラムセットをそれぞれ作成可能になる。
一方、ドラムマップの画面では譜面の書き方を設定する。 ここから、ドラム楽器リスト画面のドラム楽器番号を指定する事になる。 このマップ設定はパート毎に独立するため、 １つのドラムＣＨ中の、ドラム楽器を自由に選べるようになる。
５．４では出来なかった、複数ドラム譜が実現する。 ＣＨ１０をフルに活用できる訳である。 もちろん、ＸＧ音源であれば、更に独立したドラムＣＨを使用できる。 ＡＵＤＩＯモードに関しても独立したドラムＣＨを使用できる。 ドラムＣＨ１０という縛りは一切なくなる。 ＭＩＤＩとＡＵＤＩＯでドラムＣＨが別々でも良い訳である。
出来ることが格段に増える。 そして、プログラミングが出来ないくらい訳分からなくなる事もない。 至ってシンプルである。こうして新たな仕様が決まった。
現在、試作を作成中。うまく行くことを祈る。 これで、うまく行くはずなのであるが・・・。油断はできない。
-
現在最終的な設計を見直している。残念ながら１７日の試作も失敗した。
それについて、深く考えてみた。
問題の原因は根深い所にあった。これにはショックを隠しきれない。
以前、ＡＵＤＩＯとＭＩＤＩの切り替えにて、 ドラム譜が変化してしまうと、楽譜の描画が変化してしまうという問題が見つかり、 部分的にＭＩＤＩとＡＵＤＩＯを共有するパラメータを導入した。
この作業の副作用は大きく開発が長引いた。 そして、収束したかと思われた最後の最後で、 最初の問題にめぐりめぐってたどり着いたのである。
そもそもの原因はドラムマップであった事が今判明した。 ドラムマップはどこに持つべきか、検討の結果、 パートに持つべきである事が分かった。
すると、ＭＩＤＩとＡＵＤＩＯとは切り離されるため、 部分的に共有するパラメータなど、必要なくなったのである。 なんとも心苦しい。必要のない機能の開発に今まで３ヶ月くらい苦戦していたという訳である。 ただ、苦戦しながらも、仕様が洗練されてきたので、全く無駄という訳ではなさそうだ。 実質、サンプルレートの追加やＶＳＴの強化や新機能が追加され、 納得のいく仕様になるまで不足が無いようにしたいという思いが強まった。 これらは、６．０には含める予定のなかった機能でもあったが、対応してしまった。
ドラムマップ以外にもＭＩＤＩとＡＵＤＩＯで共有するパラメータがある。 ＣＨ名と移調である。共有パラメータを無くすとすれば、 これらはどこに持つべきか。答えはパートである。 共有パラメータと称するものは、実はパートのパラメータである事が判明した。
移調に関しては、パートに持つようになることで、更に自然な考え方になると思う。 同一ＣＨを複数パートで参照し、それぞれ移調を変える事が可能になる。 ５．４ではそれができない。同様にＣＨ名に関しても同じである。 しかし、ＣＨ名は、分かりやすさのためのパラメータでもあるので、 そのまま残す事にし、新たにパート名のパラメータを増やそうと思う。 これによって、同一ＣＨを参照する複数のパートの名前を個別に設定できるようになる。
最後に、ドラムマップである。 そのままパートに持つと、うっかりドラムマップを削除してしまう恐れがある。 ドラムマップの存在をユーザが意識できるようにするには、 パートから切り離し、楽譜全体に持つようにしたほうが良い。 パートからは、どのマップを参照するかという指定の情報を持つようにする。 こうする事で、安心してパートを増やしたり削除したりできる。
今回の事を考慮し、再び試作を開発したい。 これでうまくいってほしいと願うばかりである。
余談であるが、共通パラメータが無くなることで、 ＭＩＤＩとＡＵＤＩＯのＣＨとポートは、必ずしも一致させる必要がなくなった。 今回の発見により、自由度が上がったという事になる。 完全にＡＵＤＩＯの世界にて、音源を縛り無く使用できるはずである。
-
残件を１件対応。残り７件。
このままラストスパートに入ろうと思ったものの、
最後の最後で仕様ミスが発覚した。残念である。もう１パターン試作を作る必要がある。
デフォルトプリセットの読み込みを対応していた時、それに気がついた。
問題はドラムマップである。Score Editor 特有の仕様により、 ＭＩＤＩとＡＵＤＩＯモードは共存関係にある。 この時、ＭＩＤＩとＡＵＤＩＯで、起動時のプリセットを読むと、 ドラムマップの整合が取れなくなる。 ＭＩＤＩを初期化時、ＣＨ１０をドラムマップに設定したとすると、 その後、ＡＵＤＩＯを初期化する際、勝手にＣＨ１０がドラムになりマップがかき消される。 これは、Score Editor がＣＨ１０はドラムという仕様によるもので、 ６．０１から、ＸＧを考慮し、この部分の仕様が見直されている。 必ずしもＣＨ１０はドラムでない。というルールが加わった。
ここで、ドラムマップは誰の所有物かという事を見直す必要がある。 音源の所有物として開発を進めてきたが、どうやら違うようである。 まず、ドラムマップは楽譜の表示に関係してくる。 ドラム譜の記述はドラムマップを参照しているからである。 なんとか、うまい具合に、仕様を固めたのであるが、 まさか、起動時プリセットで問題が確定するとは思わなかった。
素直に考えて、ドラムマップは、楽譜の所有物である。 それでいて、鳴らす楽器の設定は音源側の所有物なのである。 ＧＳ音源の場合、ドラム楽器の位置やエフェクトなどの設定が可能であり、 これは音源固有である。しかし、詳細には、楽譜に関連するパラメータは、 楽譜側、音源に関連するパラメータは、音源側。 という風に、分離させなければならない。分離しなかった事が今回の仕様ミスである。
これから、分離させる場合としての試作品を１つ作成してみる事にする。 現在のままリリースしてしまっても、使えない事はないが、 将来、問題になってくると思う。せっかくユーザが作成したプリセットが無駄になる。 といった事を避けるには、リリースする前に、この問題を解決しておいたほうが良い。
楽譜に関連するという事はエディター部分に関しても若干手を入れなければならない。 これは７．０１で対応しようと思っていたのであるが、 どうやら、今やらなければならなくなりそうである。
恐らく、ユーザはドラム譜にするにはどうすのか？ と、疑問を感じていたと思う。その改善を６．０１で行わなければならないかもしれない。 ただ、可能な限り、エディタの修正は７．０１に送る方向で考えたい。
-
残件を４件対応。プリセット関連の残件はあと２件。
全体の残件は８件。再び１桁台に。
ドラムマップに関してがまず完成。 プリセット関連の連動処理が完成。 パラメータ毎のプリセット保存可否属性の対応が完成。 等々。
残件が片付く方向に収束しつつある。 プリセット残件は、起動時のデフォルト値対応。 ＶＳＴパラメータの保存に、プログラム番号を含める対応を忘れていたので、 それの対応。
後は、楽譜読み書きの最終調整。楽譜雛形機能の改善。 これが完成すれば、大枠ソフトが使用できるレベルに到達する。 いよいよα版が近くなってきた。 もちろん、本格的にテストで使い始めれば問題は出てくるだろう。 ６．０１環境と、Studio ftn のＵＲＬ変更に伴う、インストーラの対応も行わなければならない。
α版が出来れば、作者の Score Editor も、５．４から６．０１をインストールができ、 日々の作曲で６．０１が使用できるようになる。楽しみだ。 １年前に購入し眠っていたＶＳＴ音源がいよいよ満足に活用可能になるはずである。
そして、β調整の後、フリー版に含める機能の選定後、リリースである。 やるべき事はさっさとやってしまいたいので、 ベクター等での価格変更も行う予定。数週間はベクターからシェア版の姿を消すと思う。
まだ残件は残っているので油断はできないが、作業予定を書いてみた。
-
残件を２件対応したが、プリセット関連の調整残件が５件くらい増えた。
残件が増える事はショックであるが、
何をすべきか良く分からない状態にしておくと、思い出すのに時間を取られる。
残件を書き出す事は、やるべきことが明確になるため、開発効率は良くなる。
どちらにしても、潜在的な残件は含んでいるはずなので、
それが明確になるということは、うれしい事なのである。
どんどん見つけた件数を上げていこうと思う。やがて収束する事は確かなのである。
プリセット関連のメニューの仕様も最終調整が終わり、 違和感の無い、安心できる仕様になった。これなら問題が発生しないであろう。 その分、プリセットタイプごとに、丁寧に作りこむ作業が増えてしまったのである。
例えば、プリセットとして保存しなくても良いようなパラメータは保存しないようにしたい。 保存すべきかどうかの設定も新たに増えてしまった。これについても対応を行う予定。
-
なんとか、複合プリセットが可能な仕組みに改良する事ができた。
ＡＵＤＩＯモードの黒画面に相当するプリセットも無事に完成した。
ただ、副作用や修正したい点がいくつか出てしまったので、 その対応を行いたい。これが終われば、プリセット関連の最終調整はほぼ完了する。
ところで、とうとう、開発期間が１年を経過してしまった。 こんなに時間がかかるとは思ってもいなかった。 どのような仕様にするべきか、試行錯誤をしつつ試作品を作っては、 操作性を試す。といった繰り返しを続けた事もあるが、 かなりの時間を要した。アイディアというものは、来るべき日にしか浮かばない事が、 開発の難しさだろう。
それにしても、アイディアが浮かばず壁にぶつかり悩みながらも、 開発を続け１年も継続している忍耐力もかなりのものかもしれない。 引き続き開発の続きを進めたい。
-
残件を１件対応。残り８件。
どうもプリセット関連の開発がしにくかったので、先にドラムマップ関連の連動処理を片付けた。
続いて、５．４でのＡＵＤＩＯモードの黒画面に相当する部分のプリセット連動の開発を行おうとしたが、 黒画面上の情報と各ＶＳＴのパラメータ情報が複合するプリセットである事に気がついた。 更に、ドラムマップの状態も記憶しなければならない。
良く考えればこれは、楽譜ファイル書き出しでも対応しなければならない問題である。 そこで、プリセット関連のファイル書き出しの仕様をもう一度見直したい。 とは言っても、大改造になる事はない。組み合わせ処理の問題である。
いろいろなプリセットを複合させてそれを１つのプリセットにできるように改良するという訳である。 ただ、連動処理も関係するので、開発には苦戦しそうである。 この連動処理は、楽譜読み込みの時も利用できるはずなので、そのあたりも考えたい。
-
残件を１件対応。残り９件。再び１桁台に入った。
ＵＲＬ変更に伴って、ＦＡＱページの分類分けを行った。この作業に多くの時間を取られてしまった。
-
開発の報告ではないが、予定していたＵＲＬの変更が完了した。
できる事をさっさとやってしまおうという事でＵＲＬの変更へ踏み切った。
現在は古いＵＲＬからでも参照できるが６．０１公開後に古いＵＲＬは解除する予定。 Classic 版の認証については問題ない。
URL 変更に伴って、各ページのＵＲＬ表記を修正しているが、 まだ修正漏れがあるかもしれないが、見つけ次第修正したい。
URL が変更になった事により、Studio ftn の知名度もゼロからやり直しとなるであろう。
今まで使用していた dyndns はフリーの dns であるが、国外にあるため、 運用サービスが変更になるたびに英語を読まなければならないし、 (作者はあまり英語は得意でない)また、将来有料化した場合、支払い方法等、面倒で困ることになる。 そういった事もあり、ＵＲＬ変更へ踏み切った訳である。将来的にも安心できると思う。
-
残件を１件対応。残り１０件。
プリセットの残件がようやく１件対応できた。 今までは、ファイル読み書きに関してのプリセット対応であったが、 今回は、内部的な処理でのプリセット対応である。 いわゆる、連動関連の処理である。
なんとも厄介だったのが、インサーションエフェクトのプリセットである。 ＬＳＢ，ＭＳＢが決まった時に、データ枠や値の範囲が決まるため、 毎回このあたりの処理は苦労する。 プリセット復元の途中で、処理が入るのである。
今回は、値の範囲を無視して無理やり値を書き込む処理を追加して対応した。 データ枠や範囲の処理は後回しにする事で、うまくいく。 もっとシンプルな処理にならないか、６．０１以降の課題である。
引き続き、残りのプリセット関連の対応を行う。