なぜ作ったか（思想・背景）

今後書く予定

思想・背景

• 鳴る
  • 世の中、鳴らないアプリが多い
    • 鳴ればhappy
  • なのでpostmate-midiは「鳴る」ことを優先する、別項も参照のこと
• ブラウザ
  • ブラウザなら環境を選ばない、比較的選ばないので、このprojectはブラウザをターゲットに絞る。ブラウザ以外は別projectに切り分ける
• 無料
  • 高価なDAWを買うお金がなくてもOK
  • webpageにアクセスするだけで使える
  • 煩雑な会員登録手続きは不要
  • 教育用は想定したりしなかったり。もし教育用の高品質を得たいなら、別組織がcloneして組織でちゃんとメンテすることを推奨する
• OSS
  • プロプライエタリなので環境変化時にメンテされず鳴らなくなっていく、という問題の対策用
  • ほかプロプライエタリの抱える問題の対策用
  • 自分が動けなくなってもcloneすれば他の人が鳴らすことができる
• 環境
  • FLASHが使えなくなって鳴らなくなった自作アプリの悲劇を対策する
    • 疎結合をゆるく連携させることで、今後の環境の変化にもできるだけ対応しやすくする
• 楽器
  • リアル打楽器は、叩けば1秒以内に鳴るものが大部分
    • webpageを開いて、操作して、1秒以内に音が鳴ればhappy
• 連携
  • 複数webpageで、MIDIメッセージ送受信したい
    • 用途は別項を参照
  • Web MIDI APIではそれは実現できない。機能がない。用途が違う
    • Web MIDI APIは、「ブラウザ = 1つのMIDIデバイス」と「ブラウザの外にあるMIDIデバイス」とを接続し、MIDIメッセージ送受信するものである
  • 新たな仕組みがあるとよい、それがpostmate-midi
• 即時性
  • ブラウザでdemopageを開けば、そのまま音が鳴る、を実現する
    • ローカルPCに専用アプリをinstall等は不要
• 鳴らせる
  • postmate（postmessageライブラリ）とブラウザとWeb Audioがあれば、
  • 今まで制約があって「鳴るわけがない」とされていたハードウェアやブラウザやwebpage間連携においても、
  • 常に安定して
  • 鳴らせる
  • これがpostmate-midiの意義の柱の一つのつもり

音楽アプリの、これまでの課題

• ※アプリに問題はない。アプリをとりまく環境に問題がある
• 鳴らない
  • ※以下のように、音アプリは、web検索で見つけても、いろいろな理由により、音が鳴らないものが多い
    • それへの対策として、postmate-midiを提案する
    • ※この欄は「一見、鳴りそうなwebpageが見つかったが、鳴らない」というものに絞っている
  • ハードウェア
    • MIDIハードウェアを持っていないと鳴らない
  • OS
    • iPadだと鳴らない
    • Androidだと鳴らない
    • Linuxだと鳴らない
    • Windowsだと鳴らない
    • 上記どれかでは鳴るが、鳴らないハードウェアがあり、どれか用にアプリを作ったとき、ほかのどれかでは鳴らない
  • お金
    • 高価なDAWを購入しないと鳴らない
  • 環境変化
    • FLASHが使えなくなったので鳴らない
    • WebAudio？の仕様？が変わったので鳴らない
    • ブラウザ？の仕様？が変わったので鳴らない
    • 環境変化に対してメンテされなくなっているので鳴らない
  • 404
    • 404になっていて鳴らない
    • 環境変化に対してメンテされなくなっているので鳴らない
  • 運営
    • サーバ運営系、運営コストが支払えなくなり運営をやめ、鳴らない
  • 会員登録
    • 複雑な会員登録手続きをしないと鳴らない
  • インストール
    • 複雑なインストール作業をしないと鳴らない
  • 操作
    • 複雑なDAWの操作の作法を理解しないと鳴らない

開発者の責務を分割し最小化する

• 鳴らない原因を分析していくと、
  • 開発者の責務が広範かつ、分割困難である
  • 点も見えてくる
• 例えば、
  • Tone.jsを使うとき、低レイヤー処理まで実装しメンテし続ける
    • → ミドルウェアで楽はできないか？
  • GUIを実現するとき、フロントエンドのフレームワーク選定から細部まで実装しメンテし続け、ときにはフレームワークを乗り換える
  • コアなロジックを実現するとき、すべてを一人で実装しメンテし続ける
    • → 機能を分解し、複数の作業者で分担できないか？
  • 上記や、その他もろもろを、一人ですべて実装しメンテし続ける
    • → 作業を分担できないか？
• もちろん開発者がそれ（低レイヤーからGUIまでの実現責務をすべて背負って、実装とメンテを続けていく）を選ぶのは自由
• postmate-midiは何を解決するか
  • postmate-midiを使って、
    • アプリ全体を、
    • 小さなmodule、個別のwebpageに分解できる
  • 例えば、以下は個別のwebpageに分解できる
    • 楽器
      • バーチャルアナログシンセ
      • FMシンセ
      • サンプラー
      • 音色エディタ
    • 演奏
      • MIDIキーボード
      • Cutoff Knob （Cutoffフィルターのツマミ）
      • MIDIシーケンサー
      • MIDIフィルター
    • 作曲
      • コード進行エディタ
      • MMLエディタ
      • リズムエディタ
      • snippetエディタ
      • ピアノロールエディタ
    • ミックスダウン
      • ミキサー、EQ、リミッター
      • 波形エディタ
    • ※それぞれ個別のMIDIデバイスとして扱える
  • 例えば、
    • 複数のMIDIキーボードを、用途に応じて切り替えて使い分けできる
    • 複数のシンセを、組み合わせて鳴らせる
    • userの作曲スタイルにマッチした作曲アプリを、自由に選べる（ピアノロール、MML、etc…）
  • 制約
    • 例えば、リアルタイムにシンセを鳴らしながら、その音を別のwebpageでリアルタイム加工、それをAndroidスマートフォンでやりたい場合
      • 処理速度の制約がある
      • 現段階ではこれの実現は想定していない
        • 今後、実現メリットが大きく、実線可能性が高いものが見えたとき、試す可能性はある
      • 現段階では、シンセをサンプラーにつないでサンプリングして、そのサンプリングデータを加工はできる（experimental21）
    • 使い分ければOK。ネイティブDAWを使えばOK
    • 要は、処理負荷の大きすぎるもの、ハードウェアとOSごとに高度な最適化まで必要になってくるものは、postmate-midiのスコープ外

Web MIDI APIとの連携

• postmate-midiは、ブラウザ内の複数webpage間の疑似MIDI送受信システムである
• Web MIDI APIは、ブラウザと外部MIDIデバイスとを接続できる
• 今後、postmate-midiとWeb MIDI APIをつなぐmodule（webpage）を用意することで、
  • ブラウザ内の複数webpageと、ブラウザの外にあるMIDIデバイスとを接続する考え

Web MIDI APIが動かないOSがある問題

• 各ハードウェアやOSで、Web MIDI APIがブラウザで使えず、Web MIDI APIを使ったwebpageが鳴らないことがある
  • Appleの都合とかGoogleの都合とかいろいろあるのかもしれない
  • どの環境でもwebpageで音が鳴るようにしたい
    • それならpostmate-midiで、どの環境でも鳴るようにしよう
      • それから、どの環境でもWeb MIDI APIを使ったpageが鳴るようになっていくのを待とう

軽量で低機能なpostmate-midi

• ※制約やターゲットの話、思想に関連するのでひとまずここに書く
• DAWのような実際なんでもできる高機能・高性能アプリとは、
  • ターゲットが違う
  • 用途が違う
  • 実現したいことが違う
  • 棲み分ける
• 制約
  • レイテンシ
    • 50ms以上ある（50ms未満におさえてある、ではなく）
    • かわりにリズムのモタりはない
      • WebAudioの機能を利用して実現している
  • 同時発音数
    • Androidスマホ等ではおそらくかなり制約を受ける
    • ChromeブラウザでJavascriptで動いているので
    • Tone.jsなので
    • 高性能AndroidネイティブDAWとは、用途が違うので棲み分け、使い分け
  • サンプリングレート
    • ブラウザのデフォルトの48KHzや32KHz等に縛られている想定
    • ここを無理に凝るのはメンテコスト高そうなので、そのままやるつもり

Tone.js

• ※whyではないが取り急ぎ書いておく
• Tone.jsを主な音源として利用している
  • メリット
    • 簡易的に、FM音源、バーチャルアナログ、サンプラーを使える
    • プリレンダリングができる
      • なのでセルフサンプリングができる
• 他の音源の候補
  • ※現実的かが見えてないので注意、まず検証や調査が先
  • YM2151エミュレーション
    • メリット
      • コンパクトなデータで、豊かな表現力
      • 参考、Tone.jsのFM音源は2OPで、波形選択可能、フィルタ利用可能
        • Tone.js単体で4つのオシレータをFM接続できるらしいし、
          • そもそもTone.jsの2OP FMは2つのオシレータを周波数変調で接続しているだけらしい
          • ※裏は取ってないので注意
    • 採用基準
      • Tone.jsのように、「指定時刻（時間単位はWebAudio）に」「note onなど低レイヤーの操作」が可能であること
      • play/stop しかできないものはスコープ外
  • Tone.jsとは違うYAMAHA系2OP FM音源エミュレーション
    • メリット
      • 軽量ながら、Tone.jsの2OPよりも豊かな表現力
    • Tone.jsの2OP FMは、位相変調ではなく、周波数変調なので、
      • YAMAHA 2OP FMのようなサウンドはできないらしい
      • ※裏は取ってないので注意
    • → まずTone.jsの2OP FMでどれくらいのサウンドまで出せるかを検証するほうが先

破壊的変更を恐れない

• 長い目で見たとき、破壊的変更が頻繁に発生しても、そのぶん開発が進むならOK
• あるいは、例えば、コンセプトに従わず、あとからコンセプトを修正するのも、長い目でみて開発が進むならOK、かもしれない
• 雑に言えば、俺の好きなことを好きなようにやる、縛られない、そうすることで長い目でみて開発が進むならOK
  • 重要

スコープ外

• ※whyではないが取り急ぎ書いておく
• サービス運営
  • 運営コストを支払えないのでスコープ外
• 大規模なシステム
  • メンテコストを支払えないのでスコープ外
• ラズパイ等
  • 手持ちのハードウェアで手一杯なのでスコープ外