Opened 10 years ago

Closed 7 years ago

#5 closed task (fixed)

コアデータの外部仕様を設計する

Reported by: murachi Owned by: murachi
Priority: major Milestone: SMFコンパイラ開発
Component: Core Data Version: beta
Severity: MUST Keywords: spec
Cc:

Description

コアデータ外部仕様の設計を行う。設計内容は コアデータ仕様の Wiki ページ内に記述する。

Change History (14)

comment:1 by murachi, 10 years ago

Status: newaccepted

とりあえず大枠を作成する。データとして何が必要かの詳細は追って詰めていくことにする。

comment:2 by murachi, 7 years ago

楽譜情報は一旦抜きにして、先ずは演奏情報だけを作ってしまおうかな…。

comment:3 by murachi, 7 years ago

先ず一番の大枠。

  • 共通情報 (タイトル・作者、テンポ、拍子など)
  • 楽譜情報 (楽譜、歌詞)
  • 演奏情報 (分解能、ノート、コントロールなど)
  • リソース (音色、同期映像など)

楽譜は当面後回しかな…。

リソースについては埋め込みと外部リンクの両方を許容… でも最初は埋め込みからかな…。

comment:4 by murachi, 7 years ago

共通情報は後回しにして、演奏情報…

  • 演奏情報
    • ヘッダー情報 (分解能、出力チャンネル設定、音色リソースリンクなど)
    • 時系列情報
      • トラック (対応チャンネル)...
        • コントロール (ピッチ、パン、ボリューム等)
        • メタ情報 (音色選択、連携リソースリンク等)
        • パート...
          • ノート (音名 (ノートオン・オフ)、ヴェロシティ、アフタータッチ)

comment:5 by murachi, 7 years ago

[40][41] ... クラス図を作成中。

in reply to:  3 comment:6 by murachi, 7 years ago

コアデータ一式ごとに、データ内で保持する要素の ID を管理する必要がある。 ID 管理オブジェクト自体は XML 出力する必要はない (ロード時に再生成すればいい) ので、要素型ではないデータとしてコアデータの直下か、もしくは共通情報の一部としてぶら下げておけばいいかな。

in reply to:  4 comment:7 by murachi, 7 years ago

Replying to murachi:

  • トラック (対応チャンネル)...
    • コントロール (ピッチ、パン、ボリューム等)
    • メタ情報 (音色選択、連携リソースリンク等)
    • パート...
      • ノート (音名 (ノートオン・オフ)、ヴェロシティ、アフタータッチ)

演奏情報の場合、トラックの中でパートを分ける必要って特にない気がする…。

comment:8 by murachi, 7 years ago

名前空間はどうしようかなぁ… otoco だけで括るんであればコアデータが持つ演奏情報のトラックとミキサーが持つオーディオトラックとで区別することを意識しないといけないし、かといってモジュールごとに名前空間を分けるのはあんまり C++ 的ではないし…。

in reply to:  3 comment:9 by murachi, 7 years ago

Replying to murachi:

  • 共通情報 (タイトル・作者、テンポ、拍子など)

拍子は小節の頭にしか入らないはずなのでこれで良いとして… テンポは譜面と演奏情報とで表記が異なる (moderato とか rit... とか) 場合があるので普通に楽譜情報と演奏情報にそれぞれ持たせる形になるかな。

comment:10 by murachi, 7 years ago

[43] ... クラス図作成中…。

comment:11 by murachi, 7 years ago

…あんまり上手くないなぁ。

演奏情報をタイムベースで呼ばれる物と拍子で呼ばれる物に分けようとしてたけど、後者は演奏の流れ制御と拍子の変更以外では使わなさそう。

演奏の流れ (繰り返しと分岐) については演奏要素として実行するより、別個に参照するようにした方が素直な設計になりそう。楽譜からも参照されるし。

拍子の変更は拍子で呼ぶというよりは小節の切れ目で切り替わる物だから、小節の情報として持たせた方が自然かも。

演奏の流れも拍子の変更も、楽曲のシナリオとして管理すると良いのかも。

comment:12 by murachi, 7 years ago

コアデータ生成の手順としては、まず楽曲のシナリオ情報 (拍子の変更、演奏の流れ等) を構築し、そのシナリオに則って楽譜と演奏を構築していくものとする。但し、あとからシナリオ情報を修正しても、それに応じて楽譜や演奏を修正することはしない。それによって小節からあぶれる位置に楽譜や演奏が存在する状態になった場合、それらのデータは (楽譜描画時および演奏時には) 無視される。

…といった条件で、楽譜パート、および演奏トラックにカーソル情報を持たせて、その位置に情報を追加 (もしくは挿入 or 上書き) していくという形を取ることにしましょう…。

comment:13 by murachi, 7 years ago

[44] ... クラス図作成中。コンポジションの矢印入れたらかなりサマになってきた。

comment:14 by murachi, 7 years ago

Resolution: fixed
Status: acceptedclosed

[45] ... 関連の矢印を追加するなど。これで概要は概ね完成。

そろそろ実装に入りましょう。

Note: See TracTickets for help on using tickets.