httpsでChrome 43 BetaのSysEx問題回避、しかし、Web MIDI Browserが

 前回のエントリ、Chrome 43 BetaでhttpなサイトだとSysExが送れない問題の続き。
 結局解決策が見つからないので、httpsのサイトでやろうということに。しかし、まだまだ問題は続く。例によって、いろいろわからないまま試行錯誤。
 使用しているレンタルサーバー、CORESERVERでは
 https://ss1.coressl.jp/ドメイン名
 で、ファイルそのままでアクセスできるようになる。独自ドメインで提供できないのがアレだけど、とりあえず我慢。アップロードしたら、なんとか表示できる。
 しかし。これがどうも不安定。ファイルの一部がロードされない場合がある。jsファイルとかcssファイルがロードできない。リロードを繰り返すと大丈夫だったりするのだけど、だめなことが頻繁にある。こりゃだめだ。まあ、URLがかっこわるいからどうかとは思ってたのだ。すっぱり忘れて次を模索。
 金もないので、無料でなんとかできそうなところを探す。
 すると、Google App Engineで提供される「app名.appspot.com」ならそのままhttpsでアクセスできることが判明。PythonとかJavaを使わず、静的ファイルだけで構成されるサイトは、前にやったことがある。余裕! とか思ってたらいろいろはまったり。まあ、単なるチェックもれだったわけですが。なんだかんだあって、安定した動作に。
 よし、appspotでイケる!
 と思ってたら、今度はiOSのWeb MIDI API対応のブラウザ「Web MIDI Browser」でつまづく。
 Web MIDI Browserだと、httpsでのアクセスができない!
 Googleの検索ページに行ってしまう。

 https://app名.appspot.com/ に一致する情報は見つかりませんでした。

 というメッセージ。
 あらら。
 「//app名.appspot.com/ 」もだめ。まあ、そんなもんか。
 それでも、デプロイは一回で済むからいいですかね。デスクトップやAndroidはhttpsで、Web MIDI Browserはhttpで、とかいう感じでも。いや、逆ですかね。Chrome 43正式版はまだ来ないわけですし。


 あと、解決すべきは、Android版Chromeのタイムスタンプが無視される問題。Note On/Note Offなどのタイミングを指定できるはずなのだけど、できてない。
 デスクトップ版のChrome 43 Betaが16日にリリースされたのだけど、Android版はまだリリースされてない。このChrome 43 Betaで問題が解決されるというのだけども。
 しょうがないので、User Agentを判断して、Androidだったら自前のタイマー処理でなんとかすることに。負荷が高くなりそうだけど(あんまりわかってない)、プツプツいうよりはいいだろう、という判断。タイマー周りをいろいろ修正した時に、ロジックがだいぶわかってきたので、さほど手間なくできた。1ヶ月前はタイマー処理を書いたこともなかったのに。
 そんなこんなで、やりたいと思ってたことはほぼできたような気がする。デスクトップでもAndroidでもiOSでも動いてるし。あとはビデオ作ったりとかかなあ。
 という記録。忘れないうちに。

コメント

  1. Takashi Mizuhiki より:

    あぁ〜、しまった凡ミス、https。すみません。近いうちに修正版出しますm(_ _)m

  2. ここの人 より:

    httpsの件、わかりました。安心しました。:)

  3. ここの人 より:

    あっ、あと、x-webmidi使用時にノートオンを送る際に、ベロシティを誤って文字列で送ったらアプリが落ちました。間違って送った方が悪いわけですが、落ちない方がありがたいです(見逃しが多かったりするので)。対応、よろしくお願いします。

  4. ここの人 より:

    すみません。さらにもうひとつ。ネットワーク経由での送信がうまくいきません(出力先にSession 1を選択)。ある程度送信すると、しばらく送信が止まってしまうという状態。再開しても数秒後にはまた送信が止まります。単一チャンネルでもマルチチャンネルでも同じ(とくにマルチチャンネルだと早くから送信が止まっているようです)。受信は問題ないようなのですが……。

    テスト環境は、Web MIDI Browserで送信先にSession 1を選択。受信側はWindowsマシンで、rtpMIDIを介して、Chromeにて「http://www.taktech.org/takm/WebMIDIBrowser/startpage.html」を開いて受信状況をモニターしています。

    ほかのネットワークMIDI対応アプリで試すと問題ないので、こちらのネットワークまわりの環境の問題ではないような気がしています。

    Web MIDI Browserが動くiOS端末がiPad 2しかないので、端末自体の問題という可能性もありえるのですが。

  5. Takashi Mizuhiki より:

    https の件、今日出した 1.0.5 で修正してあります。

    パラメータの文字列渡しでクラッシュの件、すみません…(今知りました)。こちらは、次のバージョンで修正します。

    rtpMIDI の件も調べてみます。ただ、MIDI のネットワーク送信処理は完全に OS (iOS) 任せで、Web MIDI Browser 本体は何もしていないので、もしかすると直せない(原因不明)かもしれません…

  6. ここの人 より:

    1.0.5試しました。https、バッチリです!
    ありがとうございます!

    あと、MIDIネットワークはOS任せなのですね。把握しました。今後もよろしくお願いします。