ADR：WAVLPF：曳光弾でなくプロトタイピングを採用する

• 経緯
  • たぶん今プロトタイピングとして決めておいたほうがずっといい
• 背景
  • postmate-midi
    • 過去にpostmate-midiで停滞があった
  • WAVLPF
    • 直近でWAVLPFとオシロについて振り返ったとき、
      • WAVLPFとオシロのUXが非常によかったのに対して、
      • postmate-midiの現在のUXは、非常に限定的な機能で、UXとしてはいまいち
      • userとして、WAVLPFやオシロのようなUXがほしい
        • 開発者として、そのような成果物を作るほうが見通しがよいのではと感じた
          • 要はプロトタイピングが必要と感じた
  • 探索が必要だから、プロトタイピングがいい
    • 以下、見えていないものがある。探索すればそこが見える
      • 探索して結果をADRに残していく
    • プロトタイピングで探索する
      • WAVLPF原作どおりのUXで問題ないか？どこをアレンジするか？
      • WAVLPF原作だと今のモダン環境とUXが違うが、どうしても仕方ないか？
      • どんな技術的課題が発生するか？
      • UXの実現のために必要なものはなにか？
• 決定
  • WAVLPF project の実装方針として、
  • UX実現を優先とした探索のため、
  • プロトタイピングを採用する
• 却下した選択肢
  • 曳光弾
    • このケースで曳光弾だと、postmate-midiのような停滞になりがち
      • UXデータ不足で、卵と鶏問題になる
    • このケースは、曳光弾のつもりで骨組みをがっつり作ろうとすると失敗しそう
      • というよりWAVLPFを土台にした新規realtimeシステムを作ろうとして失敗しそう
        • 必要なのはそのシステム設計でなく、
          • プロトタイピングによるUXの探索
• 影響
  • メリット
    • すごいスピードで書ける
      • code捨てるので
      • と期待している
    • 結果、長期的にはトータルで大きな恩恵がある
      • UXの探索ができるので
      • うひょー楽しい音色づくり体験、ができるので
  • デメリット
    • code捨てるので短期的には損失

補足

• 参考資料
  • Blueskyで、この経緯、プロトタイピング、について、
    • がっつり書いたので、
    • 参照のこと
• 関連
  • ADRのお手本、テンプレ
    • ADR：WAVLPF：WAV生成において non-realtime render を採用する