ADR：WAVLPF：高機能化・高性能化 を捨てて、Smile BASIC3版の仕様そのまま移植を目指す

• 経緯
  • たぶん今方針を決めたほうがずっといい
• 背景
  • 重要なのは、限られた時間で、「うひょー音色づくり楽しい」という体験を実現すること
    • それを優先すること
      • 追加機能や、性能改善は、捨てること
        • 後回しですらなく、はっきり割り切って、捨てること
          • でないと、完成が遅れる、迷走する
  • WAVLPF
    • 直近でWAVLPFとオシロについて振り返ったとき、
      • WAVLPFとオシロのUXが非常によかったのに対して、
      • postmate-midiの現在のUXは、非常に限定的な機能で、UXとしてはいまいち
      • userとして、WAVLPFやオシロのようなUXがほしい
        • 開発者として、そのような成果物を作るほうが見通しがよいのではと感じた
  • このケースだと、
    • 開発してるとつい、以下の失敗をしそう
      • 「ここはモダンじゃないから仕様変更しよう」
      • 「ここは機能追加して、もっと楽しくしよう」
      • 「ここは性能改善して、もっと高速に動作させよう、新たなUXが可能になりそう」
    • 高機能化・高性能化をしていると、
      • 時間がどんどん取られて、
      • 目標の「うひょー音色づくり楽しい」という体験を実現すること
        • からどんどん遠ざかるリスクが高い
          • 迷走のリスクが高い
• 決定
  • WAVLPF project の実装方針として、
    • 「うひょー音色づくり楽しい」、というUX提供を
      • 早期に実現、を優先するため、
    • 高機能化・高性能化 を捨てて、
      • Smile BASIC3版の仕様そのまま移植を目指す
  • 具体的には、
    • ADR：WAVLPF：WAV生成において non-realtime render を採用する
    • ほか、モダンではないが、割り切って高速に実装できる原作仕様、
      • をそのまま、踏襲する
    • もし「機能を追加しようか」と感じたら、即座に、バッサリ機能追加をNGとし、
      • ADRを書いて、追跡可能にすること
• 却下した選択肢
  • 機能追加
    • realtime render機能
    • ほかのアプリとのpostmate-midi連携
      • ※切り分けて別のprojectとして、
        • このプロトタイピングを完了してcodeを捨てたあと、やるべし
          • そうすればデータが取れるから連携の設計ができる
  • 性能改善
    • Rustの採用による高速化
      • 却下理由
        • YAGNI
        • 複雑になるぶん、UXの提供が遅れる
• 影響
  • メリット
    • 最速でUXを提供できる
      • 「うひょー音色づくり楽しい」という体験ができるし、userに提供できる
  • デメリット
    • モダン
      • いろいろな「今なら当然のモダンなUX」ができない
        • ※すべて原作WAVLPFと同じ体験となる
    • 高機能
      • realtime renderによるDAWのような高度なシンセ音色作成体験はできない
    • 高性能
      • Rustで爆速で多段チェーンのような高度なシンセ音色作成体験はできない

具体例

• ※個別ADRにするのは、ひとまず省略
  • ほぼ同じ内容になりそうなので
• phase modulation
  • あくまでwavlpfの移植に留めること
    • 少し仕様を増やすだけで、
    • その瞬間に開発規模が爆発的に増大するので
• Nuked-OPM
  • 組み込まない
    • あくまでwavlpfの移植に留めること
      • なぜなら、仮に「oscとして」組み込むことができても、
        • 「内部を分解して任意PCM chどうしのFM」ができない
        • その瞬間に開発規模が爆発的に増大するので
      • そしてoscとして組み込むだけでもパラメタ量が爆発的に増え、
        • その瞬間に開発規模が爆発的に増大するので