comments.質問などは、以下のコメント欄へお願いします。動作報告もお待ちしております。PMこのコメントはテスト用です。Rev.2は認識はするもののペアリングできない。OUTの当方環境では極度のレイテンシーで実用にはならない。iOSのようにサクサクとは行かないようだ。PM動作状況を教えていただき、ありがとうございます。MONITORのOFF時に、通常は自動で行われるガベージコレクションを強制的に行います)。それ以外の状況には今のところ対応できないでいます。Updateという環境でさほどレイテンシが気にならない状態なのですが......。Synthでも同じ状態でしょうか?個人で制作しており、テストできる環境が少ないので、こうした報告はありがたいです。現状で改善策を出せないのは申し訳ないですが、いただいた情報は今後に生かしていきたいと思います。今後もよろしくお願いします。PM早速の返答ありがとうございます。Synthでも同じでした。EWI4000Sの設定は工場出荷時の設定にエクスプレッションをonにした程度ですが、結構大量のMIDIデータが出力されていて、それを処理しきれていないような感じです。Out(ASIO)->モニタースピーカーとなっています。WX5は使用したことがあるのですが、EWIについては知らなかったので、EWI4000Sが送信するデータを確認してみました。http://ewi.akai-pro.jp/ewi4000s/data/EWI4Ks_v24menu_fngr.pdfブレス・センサーは、初期状態でアフタータッチ、ブレスを送信するとのこと。>EWI4000Sの設定は工場出荷時の設定にエクスプレッションをonにしたさらにエクスプレッションがONとなると、同時に3つのデータがPCに送信されることになるのですね。ブレス(CC#2)のみを送信するWX5とは段違いのデータ量になることを初めて知りました。APIは昨年登場したばかりということもあってか、パフォーマンス面で従来のものより劣るようです(これはマイクロソフトにがんばってもらうしかありません)。プログラム使用している言語のC#も、C++よりも劣るようです(半分は当方のプログラミングスキルの問題)。した現状から、私が提案できるのは、EWI4000Sから送信するデータをなるべく減らすことくらいです。しぼることはできませんか?当プロジェクトでは、MIDIberryのほかにウィンドコントローラ向けにWindSYNTHberryというアプリケーションも製作・配布しております。このアプリは、ブレスコントローラのデータを、ボリューム/エクスプレッション/アフタータッチ(チャンネルプレッシャー)のいずれかに変換してMIDIポートに出力可能です。こちらもお試しいただければと思います。WindSYNTHberryは、海外のWX5ユーザーにご利用いただいてまして、概ね好評を得ております(その方によれば、ブレスコントローラーをアフタータッチに変換するだけで、十分とのこと)。使用するソフトウェア音源が対応するコントローラーの種類にもよるので、お役に立てるかどうかわかりませんが、もしお時間があればどうぞ。今後もよろしくお願いします。CCを11(Expression)だけにすると、かなりレイテンシーは改善しますが実用レベルではありません。Verocityが固定される為に、音の立ち上がりが単調になり吹奏楽器の特徴が失われます。VolumeまたはExpressionを駆使して音源に表情を付ける楽器のようです。WindowsでBLE-MIDIがなんとか出来るようになった事に、敬意を表します。APIの早期改善を切望します。MIDIを実装したDJ用のポータブル・ミキサー「SigmaMIX」というものを開発している者です。Max7で受信出来ることを確認しました。自前で開発しようかと思っていたところ、MIDIBerryをたまたま見つけ、とても感謝しています。MIDI経由でハード・シンセなどを制御したいと思っている人は一定数います(特にMax7ユーザー)。MIDIの通信ができると、ものすごくありがたいです。開発が大変なようでしたら、githubでソースコードを公開していただければ、開発に協力させていただきます。あるのですが、まずは手短に。MIDIberryでもPC→デバイスへの送信は可能です(要loopMIDI)。同時に双方向通信をしたいが、それができないということですよね。いうこともあるかと思い、MIDIberryとほぼ同様の機能を持ったアプリとして、WindSYNTHberryというのを作ってこのサイトで公開しています。使い方はほぼMIDIberryと同じです(リアルタイムでのデータ変換がありますが、使わなければ同じ)。loopMIDIのポートは別にもう1つ作って使用してください。これで、双方向通信が同時にできるはずです。現状、PC→デバイスへの送信では問題が出ます。同時に複数のデータを送信すると、一部のデータが欠落するのです。4和音を送ると1音が抜けます。離鍵時のノートオフもどれかが欠落するので、音が鳴りっぱなしになったりします。10のBLE-MIDIサポートがまだ完全ではないから発生する問題です。当方ではいまのところどうしようもないです。SONARでも同様の状態で、PC→デバイスの送信側で不具合が出ています(SONARのフォーラムでもいくつか例があがっています)。ここで、ユーザーができるのは、マイクロソフトに現状を伝え、早期のバグフィックスをしてもらうことだと思っています。10のフィードバックハブへの報告をお願いします。とりとめのない話になってしまいした。説明が不十分なところもあるとは思いますが、ひとまず、こんな感じで。今後もよろしくお願いいたします。AM早速のお返事ありがとうございます。MIDIBerryでも、PC→デバイス方向の通信はすでに実装されていたんですね。こちらではその通信が出来ておらず、まだこの方向の通信の実装はしていないものと思っておりました。MIDIberryもしくはWindSYNTHberryで入力ポートにLoopMIDIで作成したポートを、出力にデバイスのポートを選択し、Max7からCCを送っているのですが、モニターの部分にはControlChangeのチャンネル、番号、値が表示されますがデバイス側には届いておりません。PM当方が用意しているアプリケーションのドキュメントに不足があるので、まずはいくつか補足説明をしておきます。MIDIberry、WindSYNTHberryともに、正常に認識されている場合、入力側では「入力デバイスの選択に成功しました。メッセージを待っています......。認識されていない場合は「デバイスの選択に成功しました。」とだけ表示されます。出力側ではこうした処理ができておらず、判別がつきにくいですよね。APIを使用しています。同APIでのプログラミング時は、従来からある有線デバイス、新たにサポートされたBLE-MIDIデバイスを気にする必要はありません(判別方法はMIDIデバイス名を見るくらいしかないようです)。当方、Windowsプログラムはこれが初めてで、UWPのドキュメントに従い、APIが提供するインターフェイスに丸投げする形でアプリを製作しました。そんなわけで、出せる情報がないのが現状です(ポート選択時に出てくるメッセージも、取得できる情報をすべて出力しているだけです)。テストの際、MIDIデバイスが入力・出力ともに列挙されるものの、データの送受信がうまくできない場合、以下の手順でうまくいく場合がありました。Port(1)」というように正常に名前が出ますが、出力側はすべて「MIDI」という名前になってしまいます(これはUWPの仕様。マイクロソフトはloopMIDIの実装に問題があると主張しているようです)。末尾の[xxxxx])。これで判断してください。nanoKontrolなど)を選択、出力側にBLE-MIDIデバイスを選択した場合など。WindowsのBLE-MIDIドライバあるいはAPIの実装にも問題がありそうなので、デバイスによっては結局うまくいかないという可能性はおおいにあります。Rev.3の1つしかないので動作検証がままならない部分もあります。それでもなんとか問題解決のお役に立てればと思っております。何かわかりましたらこちらに書きたいと思います。ツイッターもやっております(@linclip)ので、そちらでも対応できるかと思います。長くなってしまいましたが、今後もよろしくお願いいたします。PM丁寧なお返事ありがとうございます。ご提案いただいた方法を試してみましたが、状況変わらずでした。こちらも手元にBLE_MIDIの入力を受けるデバイスが他にないため、何か入手して比較検証を進めてみようと思います。こちらで何か分かりましたら報告させていただきます。PMこちらこそありがとうございました。今回はお役に立てずに残念でしたが、今後も検証や調査、開発を続けていきます。