Open Sound Controlを使用して、空気を介して自家製の鉄片を制御します

この記事では、iOSおよびAndroidの電話またはタブレットからネットワークに接続された自家製のデバイスをリモートで制御する方法を説明します。 少なくともある程度このトピックに精通している人は、この時までにあなたのArduinoとmbed'amへの次のWebインターフェースについてだと決定しました-私はあなたの考えを急ぎます-行きません。 私が話したい方法は、迅速で安価で、既成のフィードバック、便利なコントロールがあり、最もなめらかなWebインターフェイスがうらやましい可視性を備えています。



マテリアルが実際の生活から離婚していないように、4か月前にLightpackでこのトリックをどのように行ったかを示します。 この状況は、真空でOpen Sound Controlプロトコル（さらにOSC）を使用する球状のシナリオとは少し異なりますが、それでもラピッドプロトタイピングでの効果的な使用方法の良い例です。

挑戦する

在庫には、クロスプラットフォームソフトウェアによって制御され、外部プログラムまたはプラグインから管理するためのこのAPIを備えたオープンソースのUSBバックライトデバイスがありました。 タブレットとスマートフォンからネットワーク経由でこのデバイスを制御したかったのです。 オン/オフの切り替え、設定プロファイルの変更、明るさの制御、各チャンネルのバックライトの調整、他のプラグインの起動も可能です。

あなたの場合、状況は異なるかもしれませんが、本格的なPCと何らかのAPIの形の仲介者によって複雑になることはありません。 たとえば、ネットワークに定期的に接続されているARM / AVR上のデバイス、または少なくとも24時間年中無休で玄関のダッシュボードの後ろで消費電力を記録し、Googleドキュメントにデータを送信するイーサネットシールド付きのArduino。

このような問題を解決するために最初に思い浮かぶのは、Webインターフェースです。 それは普遍的であるように思われます：どのプラットフォームからでもアクセスできます。 しかし、どんなに微視的であっても、Webサーバーを強制的に回転させたくはありませんでした。 また、適切なコントロールを備えた優れたWebインターフェースデザイナーは見つかりませんでした。独自の描画を行いたくはありませんでした。結果はデスクトップでのみ真剣に機能し、将来スタンドアロンで管理する必要がある場合、通常のMKはマスターできないことを理解しました-デバイス。

ただし、ネットワークを介してデバイスに接続できる場合（この場合、Telnetを介してAPIにコマンドを直接送信できます）、メッセージパケットを送信するだけのモバイルプラットフォーム向けの本格的なアプリケーションを作成でき、サーバーはそれらを解析してデバイスを制御します。 この方法を活用したAndroid用の小さなプロトタイプを夕方にまとめたにもかかわらず、Webインターフェースと比較しても「高価」のままでした。

時間が経つと、タスクは皮質下のどこかに記録され、TouchOSCモバイルアプリケーションに偶然出会うまでそこから抜け出しませんでした。これは（ほぼ）iOSとAndroidで同じように機能します。



デモビデオとスクリーンショットを撮った後、試してみずに通り過ぎることは不可能でした。）

アイデア

要するに、 TouchOSCアプリケーション（ AppStore 、 Google Play ）は、モバイルデバイスにOSCおよびMIDIプロトコルインターフェイスを実装し、すべての専用シンセサイザー、サウンドエディター、DJ用プログラム、レコーディングスタジオなどを使用して作業します。ボタン-スライダー-ショートカットのコントロール（レイアウト）の定義済みレイアウトだけでなく、特別なエディターで非常にシンプルかつ迅速に独自のレイアウトを作成できます。 これらはすべてwi-fiを介して機能しますが、特別なアダプターを使用したワイヤでも機能します。

定義済みの一般的なレイアウトは次のようになります。 難易度：「コリアン」。ただし、レイアウトエディターでの繰り返しを止めることはできません。



表面的な分析により、このアプリケーションが唯一ではないことが示されました。必要に応じて、iOSではiOSC、OSCemote、Mrmr OSCコントローラー、Remokon for OSCを使用できます（Androidにはリストしません-さらに多くあります）。 同じ分析では、プロトコル自体が多数のプログラムとデバイスで使用されていることが示されました。私たちにとって最も重要なことは、ライブラリとその実装を備えたラッパーが多くのプログラミング言語とプラットフォームに存在することです（たとえば、 Arduinoとmbedのオプション）。 不完全なリストは公式ウェブサイトにあります。

私たちには、一見したところ興味深い新しいツールを適用するという、典型的ではない方法があります。 前は無料の休日でした。そのため、「コールを受け付けました」という言葉で、 timsatはGoogleをモニターの半分に、Notepad ++を2番目に導入しました。

プロトコル

Open Sound Controlは、マルチメディアデバイス（主に電子楽器/シンセサイザーおよびPC）間でデータを転送するためのパケットベースのプロトコルであり、最近ではMIDIの代替としてますます使用されています。 プロトコルの主な機能はネットワークを介して機能しますが、他の機能もあります 。 仕様の最新バージョンは、バークレー大学オーディオテクノロジーセンター（CNMAT）で入手できます 。

前述したように、今日のプロトコルの典型的な用途は、入力デバイス（シンセサイザー、タブレット、ゲームコントローラーなど）とスーパーコライダー、Traktor、REAPERなどの特殊なプログラムとの間のインターフェースを提供することです。 LemurやMonomeなどの素晴らしいデバイス。

このプロトコルはネットワーク上で機能し、双方向でのデータ交換を可能にし、デバイスとのフィードバックを可能にします。 スクリーンショットをよく見ると、一部のコントロールボタンには、以前に送信されたコマンドが実際にサーバーによって実行された後に点灯できる追加のインジケーターがあります。 つまり タブレットは、制御しているデバイス（ターゲット）の実際の状態を反映している場合があります。 あなたがそれのコツをつかめば、グラフを描くことさえできますが、これは倒錯について多くを知っているムッシューのためのものです。

OSCサーバーとクライアント間で交換されるメッセージの例を次に示します。

/1/fader2 0.497120916843 /1/fader2 /z /1/rotary1 0.579584240913 /1/rotary1 0.605171322823 /1/rotary1 /z 

この場合、正確なコントロール識別子があり、 / 1 / fader2 0.497120916843は、最初のタブの2番目のスライダーから（はい、同じレイアウト内で複数のタブを使用できます）、値0.49がサーバーに到達したことを意味します。 この例のZメッセージは、必要に応じて含めることができます。これについては後で説明します。

Lightpackの例では、プロファイルの名前をタブレットに転送し、それらを切り替えるのが便利でした。 さらに、セッションの開始時に、タブレット上のすべてのコントロールの位置が、ターゲットデバイスの実際の設定に従って自動的に調整されます。

実装

Lightpack APIを使用するには、Pythonで記述された独自のラッパーを使用します 。 そのため、PythonにもOSCライブラリが用意されていたため、APIとOSCメッセージを送信するネットワークデバイスとの間の致命的なコネクタである小さなスクリプトを作成することにしました。 このような実装の主な要件：

• クライアント/サーバーポートの可用性（TouchOSCで独自に構成できます）
• クライアントとサーバーは同じネットワーク上になければなりません。

ただし、ルーターのトンネルを深く掘り下げると、2番目の制限を回避して、街の反対側のオフィスからハムスターの飲酒者を管理できます。

私のように写真を好む人のために、彼らは相互作用スキームを開発しました：



この場合、コネクタとAPI間の交換はソケットを介して実装されます（これはAPI自体の機能です）が、デモでわかるように、すべてが非常に迅速に機能します。 もちろん、Arduinoハムスターとの関係では、ルーターのすぐ後ろに、ネットワークとOSCを操作するためのライブラリが既に含まれているファームウェアを備えたマイクロコントローラーの形でロジックの中心を持つデバイス自体があります。

実際、実装のために、交換の初期化、フィードバック、および受信/送信値の変換のプロセスを処理するだけで済みました。 コードの大部分は単純なマッピングです。 つまり レイアウトを描いた後、コントロールアドレス（ボタン、スライダー、ショートカットなど）のリストを手に持つことになり、それぞれをAPI関数にマッピングする必要があります。 それだけです


正直なところ、ここでこれ以上何が書けるかわかりません。 プログラミングの観点から見ると、タスクはプリミティブです。 この「コネクタ」のソースコードは、通常どおり、 リポジトリにあり、誰でもアクセスできます。

ちなみに、TouchOSCはいくつかのかなり便利な追加機能を実装しています。まず、データ自体が実行されていない場合でも、クライアントとサーバー間で交換される/ pingメッセージを使用して接続を維持できます。 次に、いわゆるzメッセージがサポートされます。これは、クライアント上のユーザーが指で画面をタップし終えたことをサーバーに伝える特別なメッセージです（入力が完了した瞬間）。 この機能は使用しませんでしたが、非常に役立つ状況があることを除外しません。 第三に、ほとんどの同様のアプリケーションと同様に、TouchOSCはモバイルデバイスに組み込まれた加速度計からサーバーにデータを送信できます。 つまり スマートフォンやタブレットを、ネットワークの自家製製品のトリッキーな入力デバイスとして使用できます（カメラをサーボでねじるなど）。

落とし穴

TouchOSCアプリとの対話に関するすべてがスムーズに実行されます。 独自のレイアウトをロードすることも、ボタンをクリックするだけで「無線で」行われます。 今日の唯一の顕著な欠点は、Androidバージョン用の独自のレイアウトをダウンロードできないことです。 著者とのやりとりで、彼はなんとか「今、私はリリースの準備をしている」と私に納得させた。

Pythonのライブラリはあまり文書化されていないことが判明したため、レイアウト動作を実際にプログラムするよりもデータ交換プロセスの初期化に時間がかかりました。

一般に、このようなマッシュアップを作成するプロセスは非常に直感的であり、それほど時間はかかりません。 そのため、Webインターフェイスを備えた本格的なクライアントサーバースタックではなく、OSCを使用してラピッドプロトタイピングを行うことをお勧めします。 さらに、イベントで、または顧客にこのプロトタイプを提示しようとする場合、付随するすごいを実装するためのより視覚的なオプションです！-私は単にわからない質問でこのeppstorを欠場します。

繰り返しになりますが、フィードバックを使用して自家製のネットワークデバイスを視覚的に制御する簡単な方法を迅速かつ安価に実装する必要がある場合、OSCプロトコルは興味深い選択肢です。