VSQX 読み書き対応の実現可能性と設計方針整理
背景
mikuscore は「多機能化」ではなく、既存 MusicXML を極力壊さずに編集する信頼性を主眼とした、ブラウザ完結型の MusicXML 4.0 譜面エディタである。
基本思想は以下：
- 読み込んだ XML DOM をそのまま保持（DOM 完全保持型）
- unknown / unsupported 要素を保持
<backup> / <forward> / 既存 <beam> を保持- dirty === false の場合は original_noop
- pretty-print なしシリアライズ
- 原子的ロールバック
- 最小パッチ編集
この思想を崩さずに VSQX（VOCALOID プロジェクト形式）読み書き対応が可能かどうかを整理する。
結論
VSQX 対応は 可能。
ただし「VSQX 編集機能の追加」ではなく、
VSQX を壊さず通す可逆ブリッジ
として設計すべき。
VSQX の位置づけ
VSQX は
🎼 楽譜 + 歌詞 + 発音 + ピッチカーブ + 各種歌唱パラメータ
を含む XML 形式（VOCALOID 用プロジェクトデータ）。
一方で mikuscore は：
🎼 楽譜編集特化
（歌唱エンジンパラメータは対象外）
この役割差を前提に設計する必要がある。
設計原則（mikuscore哲学との整合）
mikuscore の哲学を守るため、VSQX 対応は次の方針とする：
1. VSQX を「編集対象」にしない
歌唱パラメータ（PIT, PBS, ダイナミクス等）は編集しない。
凍結データとして保持する。
2. MusicXML を中間表現として利用する
のみを MusicXML に変換。
それ以外の VSQX 情報は、既存の ABC 実装と同様に
<miscellaneous>
<miscellaneous-field name="mks:vsqx-*">...</miscellaneous-field>
</miscellaneous>
へ保持する。
3. original_noop を維持する
- VSQX → MusicXML 変換
- 編集なし
- VSQX 出力
この場合、バイト単位で元ファイル一致を目指す。
既存 ABC 実装との整合
ABC ではすでに：
として外部フォーマット情報を保持している。
VSQX も同様に：
あるいは
として保持可能。
設計思想は既存実装と完全に整合する。
実装戦略
Phase 1（現実的かつ安全）
- VSQX → MusicXML（ノート中心）
- 元 VSQX XML をそのまま保持（Base64 等）
- 未編集時は完全復元
これは mikuscore の思想と完全一致。
Phase 2（差分適用）
- pitch / duration 変更のみ VSQX に反映
- それ以外は凍結保持
この段階でも歌唱パラメータ再計算は行わない。
やらないこと
- ピッチカーブ編集
- ビブラート再計算
- エンジンパラメータ編集
これは「多機能化」にあたり、プロダクト思想と衝突する。
技術的難所
最大の注意点は 時間軸整合性：
- VSQX は tick 基準
- MusicXML は divisions 基準
- テンポイベント位置の扱い
ノート再配置時に歌唱パラメータが時間的にずれない設計が必要。
難易度評価
前提：
- DOM 完全保持型
- unknown 保持
- ABC メタ保持実績あり
この条件下では、
難易度：中（★★★☆☆）
無謀ではない。
プロダクト思想としての意義
「MusicXML を壊さないエディタ」が
を 壊さず通す という設計は、
非常に一貫性があり、思想的にも美しい。
VSQX を編集するのではなく、
「通す」「橋渡しする」
という位置づけなら、mikuscore の理念を損なわない。
まとめ
VSQX 対応は：
- 技術的に可能
- 設計的にも整合可能
- ただし目的は「編集」ではなく「可逆ブリッジ」
この方針であれば、mikuscore の哲学を守ったまま拡張できる。
（今後の検討項目）
- 差分適用アルゴリズム設計
- dirty フラグとの整合
- property test 戦略
- VSQX バージョン対象範囲（VSQX3/4）
VSQX 読み書き対応の実現可能性と設計方針整理
背景
mikuscore は「多機能化」ではなく、既存 MusicXML を極力壊さずに編集する信頼性を主眼とした、ブラウザ完結型の MusicXML 4.0 譜面エディタである。
基本思想は以下：
<backup>/<forward>/ 既存<beam>を保持この思想を崩さずに VSQX（VOCALOID プロジェクト形式）読み書き対応が可能かどうかを整理する。
結論
VSQX 対応は 可能。
ただし「VSQX 編集機能の追加」ではなく、
として設計すべき。
VSQX の位置づけ
VSQX は
🎼 楽譜 + 歌詞 + 発音 + ピッチカーブ + 各種歌唱パラメータ
を含む XML 形式（VOCALOID 用プロジェクトデータ）。
一方で mikuscore は：
🎼 楽譜編集特化
（歌唱エンジンパラメータは対象外）
この役割差を前提に設計する必要がある。
設計原則（mikuscore哲学との整合）
mikuscore の哲学を守るため、VSQX 対応は次の方針とする：
1. VSQX を「編集対象」にしない
歌唱パラメータ（PIT, PBS, ダイナミクス等）は編集しない。
凍結データとして保持する。
2. MusicXML を中間表現として利用する
のみを MusicXML に変換。
それ以外の VSQX 情報は、既存の ABC 実装と同様に
へ保持する。
3. original_noop を維持する
この場合、バイト単位で元ファイル一致を目指す。
既存 ABC 実装との整合
ABC ではすでに：
として外部フォーマット情報を保持している。
VSQX も同様に：
あるいは
として保持可能。
設計思想は既存実装と完全に整合する。
実装戦略
Phase 1（現実的かつ安全）
これは mikuscore の思想と完全一致。
Phase 2（差分適用）
この段階でも歌唱パラメータ再計算は行わない。
やらないこと
これは「多機能化」にあたり、プロダクト思想と衝突する。
技術的難所
最大の注意点は 時間軸整合性：
ノート再配置時に歌唱パラメータが時間的にずれない設計が必要。
難易度評価
前提：
この条件下では、
難易度：中（★★★☆☆）
無謀ではない。
プロダクト思想としての意義
「MusicXML を壊さないエディタ」が
を 壊さず通す という設計は、
非常に一貫性があり、思想的にも美しい。
VSQX を編集するのではなく、
という位置づけなら、mikuscore の理念を損なわない。
まとめ
VSQX 対応は：
この方針であれば、mikuscore の哲学を守ったまま拡張できる。
（今後の検討項目）