Funnel 010以降の方向性について

[Shigeru Kobayashi]

みなさま

小林です

先日加藤さんからRubyのGainer I/O Mode
7に関するコントリビュートがありましたが、AS3用にもI2Cのバリエーションでいくつか追加がありそうです。検証用に注文したデバイスがまだ届いていないために数日先になりそうですが、この辺りを追加したところで009としては完成ということになるかなと思っております。

・・・

その先の010からなのですが、ここしばらくある案件にかかり切りだったこともあってなかなか考えがまとまらなかったのですが、いや、今もまだまとまっていないのですが、とりあえず思ったことを書いてみようと思います。是非、みなさんからも率直なリプライをいただけたら嬉しいです_o_。

○今後の機能追加に関して

・実際にいくつかのプロトタイプを使ってみると、「入力が変化したらすぐにアクションを起こしたいが、その後しばらくの間の変動は無視する」「入力が変化したらある程度待ってからアクションを起こす」といった時間軸上の判断を伴う処理を扱いたい場合が結構多い。そうした処理は各言語側のタイマ機能と組み合わせることで記述可能だが、煩雑になりがちなので、SetPointなどの機能として取り込んでしまうことはできないか？

・加速度センサを使って何か特定のアクションがあったときに反応する、というようなものを作る場合、簡単なパターンマッチングがサポートされていると簡潔に記述できるのではないか。マウスジェスチャを前提とした簡易な実装は結構豊富にあるので、その辺りを参考にしつつフィルタの1つとして実装するというのはどうだろう？

○新しいプラットフォームへの対応に関して

・現在サポートしている言語はProcessing、AS3、Rubyであるが、これ以外に組込み系のOSでの利用を前提とした言語を追加できないだろうか。具体的には、BeagleBoardのようなそれなりに高速に動作するハードウェア上でLinuxを動かして何かを作る際、ビデオやオーディオの処理自体はネイティブ言語（C/C++）で書かれたアプリで扱うとして、ロジック部分を軽量なスクリプト言語で記述できるようにすることで、実世界で動作させながらチューニングを行う、本当の意味でのライブコーディングができないだろうか。現時点で候補となる言語はPythonかあるいはLuaあたりではないかと考えているが、他に候補はないか？

○プロトタイプのレベルまでカバーするためのチューニングに関して

・Funnelでは、信号処理的な処理も全てクライアント側で行っている。これは透明性やユーザ側での拡張ということを考えると有利だが、多チャンネルのアナログデータをAS3やRubyといったスクリプト言語で処理するのは結構負荷が高い。とりあえずスケッチ的に作ってみる場合であればこれでも問題ないが、クオリティを求めたいプロトタイプのレベルでは、こうした処理のために数fpsでも負荷が変わるのであれば結構問題かもしれない。アナログ入力に対するノイズカットのような処理は、マイコン側、あるいはサーバ内で行うべきなのでは？

・組込み系の場合により重要になるが、Javaで書かれているFunnel
Serverはそれなりに処理が重い。openFrameworksの成果などをうまく利用してC++で高速かつ軽量に動作するものはできないか？それができれば、Beagle
Boardなどでの利用も現実的になるはず。

○その他

・当初のFunnelはソフトウェアライブラリと位置づけていたが、フレームワークと呼ぶべき段階にきているのかもしれない。ブラックボックス化させることなく、よく使う処理を簡潔に書けるように、というバランス感覚を忘れないようにしなくては。

…と、書き出すと長くなってかなりまとまりがないのですが、何か気になるところなどあればお気軽に突っ込んでいただけたらと思います。よろしくお願いします。

[takanori endo]

遠藤です。
ずいぶん遅い反応ですが、

よりアプリケーションの層に近い部分での、サポートという感じで、
いろいろなタイマー処理などの機能をついかという部分での、
機能拡張は、基本的には必要なことなので賛成なのですが、

最近ワークショップなどをやらせてもらっていて感じることが、
Funnelが、I/Oモジュールとの通信のドライバてきなイメージで
捕らえている人が非常に多いということで、
たしかにワークショップで扱える部分は、初心者対象とすると
入出力とわずかな＋αとしてやらざるを得ないところがあります。
ので、そう捕らえる人が多いともいえます。

Funnelの柱の一つとして、SetPointやScalarをもちいて、入出力の
扱いまで言及できるのは、何度か製作でつまったことのある中級者
の人たちしかいない思いますが、今のところその人たちにうまく
伝えられていない状態です。
新しい、機能拡張を追加してもこの状態はつづくと思えます。

小林さんがおっしゃっている、よく使う処理を簡潔に書ける
ということができるように、何がよく使う処理なのかという部分を
うまく紹介できる機会がつくれないかなと考えています。
さらに擬似コード的プログラミングは、基本的にはプログラムが
わかる人にしかつたわらない要素なので難しいところではありますが。

Processingのように、ひつような知識を部分的に紹介できるように
まとめられればちょっとわかりやすくなるかもですね。

以前ゲーム系の組み込みスクリプトを探していてLnaのほかに
http://squirrel-lang.org/default.aspx
Squirrelというのを見つけました。ほとんど見てないので差はわかりませんが、
一応メモっときます。

とりとめもなくてスイマセン
遠藤孝則

2009/02/14 23:09 Shigeru Kobayashi <koto...@gmail.com>:

--
endo takanori

[Shigeru Kobayashi]

遠藤さん、みなさん

小林です

すっかり間が空いてしまってすみません。

機能追加に関しては、APIの案を明日くらいにwikiに追加して、コメントなどをつけてもらえるようにしようと思います。

> Funnelの柱の一つとして、SetPointやScalarをもちいて、入出力の
> 扱いまで言及できるのは、何度か製作でつまったことのある中級者
> の人たちしかいない思いますが、今のところその人たちにうまく
> 伝えられていない状態です。
> 新しい、機能拡張を追加してもこの状態はつづくと思えます。

確かにそうですね…。現時点でなかなかFunnelが普及しない原因だと思います。この点に関しては、今後山辺さんが担当されるFunnelベースのワークショップが開催されたり、書籍が出てくれば少しずつ解消していくのかなとは思っております。

> さらに擬似コード的プログラミングは、基本的にはプログラムが
> わかる人にしかつたわらない要素なので難しいところではありますが。

この部分は、コードベースで組んでいく以上、どうしてもついて回る問題になりますね…。

直接の解決策になるのかどうかわかりませんが、使用頻度の高いロジックを簡潔に書けるような仕組みを用意して、ユーザ側は目的にあったロジックを選択した上で、パラメータをチューニングして使う、という方式だとハードルが低くなるかなと思っています。

> Processingのように、ひつような知識を部分的に紹介できるように
> まとめられればちょっとわかりやすくなるかもですね。

この部分に関して、現時点でまとまったドキュメントがないというのが一番のネックですよね。「フィジカルコンピューティングにおけるデザインパターン」のようなものがそろそろ必要なのだと感じています。

> 以前ゲーム系の組み込みスクリプトを探していてLnaのほかに
> http://squirrel-lang.org/default.aspx
> Squirrelというのを見つけました。ほとんど見てないので差はわかりませんが、
> 一応メモっときます。

Luaを参考にしつつ、実用的にチューニングした言語ですよね。ドキュメントを読んだり、簡単なスクリプトを動かしたりしてみましたが、結構良さそうな気がしています。

しかしながら、そこそこ余裕のある環境で動かすのであればむしろPythonの方がいろいろなアドバンテージがあるかもしれない（例；組込み用を含む大抵のLinuxディストリビューションで用意されている）ということもあり、なかなかこれだというところに至りません。

新しい言語のサポートは結構コストがかかりますので、まずは現行でサポートしている言語を拡張しつつ、平行して実験を進めて…というのが現実的かなとは思っております。もしまた何か良さそうなものがあればぜひ情報をください。

他のみなさんも、何か思いついたことなどありましたらぜひリプライをお願いします。:)

2009/2/23 takanori endo <sweeta...@gmail.com>:

[takanori endo]

遠藤です。

>「フィジカルコンピューティングにおけるデザインパターン」のようなものがそろそろ必要なのだと感じています。

来年度、コンセントにつないだものを操作するには、人がいるか、いないかを知るには、
といった分類で、プログラムとツールキットの勉強会みたいなものができないかなと
思っています。（今の赤松さんのiPhoneのような感じで）その成果をうまくまとめられれば
よいのですが。Physical Computing's Greatest Hits (and misses)もうまく、参考にしたいです。

> 確かにそうですね...。現時点でなかなかFunnelが普及しない原因だと思います。この点に関しては、今後山辺さんが担当されるFunnelベースのワークショップが開催されたり、書籍が出てくれば少しずつ解消していくのかなとは思っております。

ロクナナさんとの雑談のなかで、Gainer入門もFunnelベースにするべきではという話をしていました。
最初の敷居は高くなるのですが、その後の展開をも考えるとFunnelベースにするメリットは大きい
のではないかと考えます。Funnelのほうが説明しやすいところもありますし。

遠藤孝則

2009/03/03 17:35 Shigeru Kobayashi <koto...@gmail.com>:

> 遠藤さん、みなさん
>
> 小林です
>
> すっかり間が空いてしまってすみません。
>
> 機能追加に関しては、APIの案を明日くらいにwikiに追加して、コメントなどをつけてもらえるようにしようと思います。
>
>
>> Funnelの柱の一つとして、SetPointやScalarをもちいて、入出力の
>> 扱いまで言及できるのは、何度か製作でつまったことのある中級者
>> の人たちしかいない思いますが、今のところその人たちにうまく
>> 伝えられていない状態です。
>> 新しい、機能拡張を追加してもこの状態はつづくと思えます。
>

>
>
>> さらに擬似コード的プログラミングは、基本的にはプログラムが
>> わかる人にしかつたわらない要素なので難しいところではありますが。
>
> この部分は、コードベースで組んでいく以上、どうしてもついて回る問題になりますね...。

>
> 直接の解決策になるのかどうかわかりませんが、使用頻度の高いロジックを簡潔に書けるような仕組みを用意して、ユーザ側は目的にあったロジックを選択した上で、パラメータをチューニングして使う、という方式だとハードルが低くなるかなと思っています。
>
>
>> Processingのように、ひつような知識を部分的に紹介できるように
>> まとめられればちょっとわかりやすくなるかもですね。
>
> この部分に関して、現時点でまとまったドキュメントがないというのが一番のネックですよね。「フィジカルコンピューティングにおけるデザインパターン」のようなものがそろそろ必要なのだと感じています。
>
>
>> 以前ゲーム系の組み込みスクリプトを探していてLnaのほかに
>> http://squirrel-lang.org/default.aspx
>> Squirrelというのを見つけました。ほとんど見てないので差はわかりませんが、
>> 一応メモっときます。
>
> Luaを参考にしつつ、実用的にチューニングした言語ですよね。ドキュメントを読んだり、簡単なスクリプトを動かしたりしてみましたが、結構良さそうな気がしています。
>
> しかしながら、そこそこ余裕のある環境で動かすのであればむしろPythonの方がいろいろなアドバンテージがあるかもしれない（例；組込み用を含む大抵のLinuxディストリビューションで用意されている）ということもあり、なかなかこれだというところに至りません。
>

> 新しい言語のサポートは結構コストがかかりますので、まずは現行でサポートしている言語を拡張しつつ、平行して実験を進めて...というのが現実的かなとは思っております。もしまた何か良さそうなものがあればぜひ情報をください。

>>> ...と、書き出すと長くなってかなりまとまりがないのですが、何か気になるところなどあればお気軽に突っ込んでいただけたらと思います。よろしくお願いします。
>>>
>>> >
>>>
>>
>>
>>
>> --
>> endo takanori
>
> >
>

--
endo takanori

[Yoshitaka Kuwata]

小林さん
皆様

桑田です。これまでgainerがメインだったのですが、ようやく昨日本格的にFunnelを試しました。
フレームワークを正しく理解しているかどうか自信が無いのですが、第一印象です。

１．様々なデバイスを統合して使えるようにするというアイデアは、非常に有益だと思いました。

２．サーバを動かす分、処理が複雑になり初心者向けには敷居が高くなっていると感じました。
　　例えば、セキュリティソフトでポートを開く等は難しいかも。

３．（すみません、この部分はジャストアイデアです。ソフト屋の発想かも）
　■デバイスの仮想化（論理デバイス化）
　　せっかく統合するのであれば、デバイスを仮想化して統合的に扱えるようにすると面白いのではないかと思いました。
　・今の実装だと、例えばArduino向けに書いたアプリケーションをGainerに移植するのは一仕事になります。
　・プログラマレベルでは、論理デバイスを対象として作成し、実行時に物理デバイスにマッピングする
　・でも設定が面倒にならない工夫も必要ですね。
　　物理デバイスでも論理デバイスでも書けるようになっていると互換性も維持できます。

　■デバイスの名前解決の仕組み
　・いまの実装では、アドレス、ポート、デバイスを意識してプログラムを組む必要が有ります。
　　できれば、「デバイスの論理名」と「機能名」でプログラムしたいです。
　　上記の論理デバイスを導入した場合、物理アドレスのマッピング時にどこかで名前解決ができると良いと思いました。
　　インターネット上でユニークにデバイスの名前が解決出来れば、（セキュリティの問題はあるにせよ）リモートでインターネット越しにデバイスを制御す
るのも楽になると思います。

　実装しなければ絵に描いた餅ですが、まずはアイデアのみで失礼します。

[Shigeru Kobayashi]

桑田さん

小林です

ご意見ありがとうございます。:)

> ２．サーバを動かす分、処理が複雑になり初心者向けには敷居が高くなっていると感じました。
> 例えば、セキュリティソフトでポートを開く等は難しいかも。

もともとダイレクトにデバイスを開いていたProcessingに関しては確かに敷居が高くなっているかもしれません。特に、途中からProcessingは複数のスケッチを同時に開けるようになったため、それと相まって混乱する原因になっているようです。

この対策として、現在は単体で起動しているfunnel_server.jarを、Processingから直接開いてしまう、という案があります。Funnel
Server内部の変更はいくらか必要になりますが、同じJava同士ですので、比較的簡単に実現するのではないかと思います。同様に、Rubyに関してもJRubyの利用を前提とするのであれば同じ方法がとれるかと思います。

Flashの場合には、Gainerでも同様でしたので、今のところ現状の方式しかないかなぁと思っております。もし何か良い方法をご存知でしたらぜひ教えてください。

> ３．（すみません、この部分はジャストアイデアです。ソフト屋の発想かも）
> ■デバイスの仮想化（論理デバイス化）

この部分に関しては、開発当初にいろいろディスカッションして、結局今の形に落ち着きました。主な理由は以下のようなものだったと記憶しています。

・GainerとArduinoではconfigの考え方が異なる
・GainerとArduinoではアナログ入出力／デジタル入出力の考え方が異なる

しかし、これはI/Oモジュールを中心としたものの見方で、実際には早めの段階で物理的な接続状態を論理的な接続状態に変更してしまうのがよいと私も思っています。あまり効果的な解決策ではないのですが、サンプルコードの一部では

var gio:Gainer = new Gainer();
var led:Pin = gio.analogOutput(0);
var sw:Pin = gio.digitalInput(0);

if (sw.value == 1) {
led.value = 1;
} else {
led.value = 0;
}

のような書き方をしてはいます。ledとかswとかに読み替える部分を自然に最初の方でやってしまえるような仕組みが用意されているとずいぶん違うでしょうか。

あと、009でI2Cデバイスのサポートを追加したのですが、

aio = new Arduino(Arduino.FIRMATA);
compass = new HMC6352(aio);

function loop(event:Event):void {
clockHand.rotation = compass.heading;
}

のようにかけるようになっています。I2Cデバイスを表すインスタンスのコンストラクタにI/Oモジュールのインスタンスを渡す、という形式なのですが、電圧で入力するタイプのセンサとI2Cで入力するタイプで、うまく同じルールにできないかな、とは思っています。

このあたり、何か良いアイデアがあれば是非お知らせください。

> ■デバイスの名前解決の仕組み

DNSのような仕組みがあると解決できますよね。いくつかヒントになりそうなものがある気がしますので、ちょっと調べてみます。

2009/3/10 Yoshitaka Kuwata <kuw...@nifty.com>:

[Yoshitaka Kuwata]

小林さん
皆様

冷静になって見てみると、ワークショップで数個のデバイスを制御 する範囲であれば、明らかにオーバースペックな気がします。
フレームワークに求められている要求条件を明確にする必要があると感じました。このためには、「だれが」「どのような場面で」「どの様に使うか」（また
は範囲をどこまで考えるか？）などをイ メージしておく必要があります。これは一つでなくても良いし、ス テップ論でも良いと思います。
「ユースケース」を明確にするということです。

少し考えてみます。

> > ■デバイスの名前解決の仕組み
>
> DNSのような仕組みがあると解決できますよね。いくつかヒントになりそうなものがある気がしますので、ちょっと調べてみます。

RFIDの世界では、EPC Globalという組織の定義した名前解決の標準があります。Object Naming Service (ONS)と
いう規格が有り、世界中のRFIDタグ（の先にあるもの）の情報を一意に特定することが可能です。

http://www.epcglobalinc.org/standards/ons

実装はDNSを使っています。仕組みも基本的にはDNSです。

でも、Funnelはここまでは要らないですよね。

桑田

[Shigeru Kobayashi]

桑田さん、みなさん

小林です

コメントありがとうございます。

> 冷静になって見てみると、ワークショップで数個のデバイスを制御する範囲であれば、明らかにオーバースペックな気がします。

> フレームワークに求められている要求条件を明確にする必要があると感じました。このためには、「だれが」「どのような場面で」「どの様に使うか」（また
> は範囲をどこまで考えるか？）などをイメージしておく必要があります。これは一つでなくても良いし、ステップ論でも良いと思います。
> 「ユースケース」を明確にするということです。

ここは重要なところですね。Funnelのターゲットとしては、フィジカルなインタラクション（UIなどが多いと思いますが電子玩具なども含みます）のスケッチからプロトタイプまでを想定しています。

Gainer I/Oとライブラリの組合せは、いわばドライバレベルのもので、入門編的なワークショップでは十分に機能します。しかし、GUIと同様の気軽さでスケッチ~プロトタイピングを行っていくにはいろいろな落とし穴があり、それほど簡単ではないというのが実情です。

※例えば、マウスやキーボードは、デバイス内部のマイコンやドライバがさまざまなノイズ対策などを行っているおかげで簡単に扱うことができますが、生のセンサ情報を扱い始めるととたんにさまざまなローレベルの処理が必要になります。

どのレベルで盛り込むかが難しいところなのですが、例えば次のバージョンでは以下のようなAPIを追加するのはどうかなと考えておりました。

＜時間軸上の変化を伴う入力を扱うためのAPIの実装案＞

// パラメータ：閾値、ヒステリシス、動作開始までの時間、反応後の不応期間
// 例：最初の変化には瞬時に反応したいが、その後の変化は一定期間無視したい
var detector:SetPoint = new SetPoint(0.5, 0.1, 0, 1000);

gio.analogInput(0).filters = [detector];
gio.analogInput(0).addEventListener(CHANGE, onChange);

function onChnage(e:Event):void {
// 変化が起きたら以下を実行
...
}

＜ジェスチャを扱うAPIの実装案＞
// 正規表現などを用いてパターンを記述
// 例：加速度センサを上下左右に振る
var shake:String = "-1, 1, -1, 1, ...";

// インタプリタに対象となる入力とパターンをセット
var interpreter:Gesture = new Gesture(gio.analogInput(0..2), pattern);

// イベントリスナをセット
interpreter.addEventListener(MATCH, onShake);

function onShake(e:Event):void {
// ジェスチャを検出したら以下を実行
...
}

こうしたAPIを追加すればするほど、フレームワークとしてファットになってしまうのですが、black
box（中が見えない箱）ではなくglass box（ガラス箱のように中を見ることのできる箱）であればいいのかなと最近では思いつつあります。

> RFIDの世界では、EPC Globalという組織の定義した名前解決の標準があります。Object Naming Service (ONS)と
> いう規格が有り、世界中のRFIDタグ（の先にあるもの）の情報を一意に特定することが可能です。
>
> http://www.epcglobalinc.org/standards/ons

寡聞にしてこれは初めて知りました。とても参考になりそうですのでじっくり読んでみようと思います。ありがとうございました。

2009/3/12 Yoshitaka Kuwata <kuw...@nifty.com>:

[Yoshitaka Kuwata]

皆様

勝手にユースケースを考えてみました。
(A) ,(B), (C)はあるかなと思っていますが、(D)は無理やり作った感じで、あるかどうか良く分かりません。
また、実際の要求条件は想像で入れてみました。ワークショップ等を経験されている皆様の方が詳しいと思いますので、ご意見を頂ければと思います。

桑田

＊＊＊Funnelの想定するユースケース＊＊＊

(A) ワークショップ
　対象ユーザ：初心者
　形態：個人ないし数名のグループでの作業
　規模：１デバイス
　期間：数時間から数日
　要求条件：
　（１）フィジカルコンピューティングの基礎を習いたい。（体験したい）
　　　ラピッド・プロトタイピング
　（２）簡単であることを教えたい。
　　　設計のシンプルさ

(B) メディアアートの制作
　対象ユーザ：美術の学生、先生
　形態：個人ないし数名のグループでの作業
　規模：～数個のデバイス
　期間：１ヶ月から数ヶ月程度
　要求条件：
　（１）ユニークな作品を素早く作成したい
　　　ライブラリの充実
　　　センサ詳細情報の隠蔽
　（２）実装レベルでは他人の作品を参考にしたい
　　　再利用性／流通性など
　（３）自分の知っているプログラミング言語で作成したい
　　　様々な言語のサポート

(C) 実験室／電子工作
　対象ユーザ：工学系（学生、社会人）
　形態：研究の一環または個人プロジェクト
　規模：～数個のデバイス
　期間：１日から１年程度（？）
　要求条件：
　（１）様々な物理デバイスとつなぎたい
　　　フレームワークの拡張性
　　　スタンドアロン動作
　（２）既存プログラムや測定器を利用したい
　　　処理速度／レイテンシ
　（３）過去に作成したものや他人の作成した物を利用して手早く作成したい
　　　再利用性

(D) インターネットワイドのメディアートの制作
　対象ユーザ：美術の学生、先生
　形態：組織の異なる複数グループでの共同作業
　規模：～数個のデバイス　×　数グループ
　期間：１ヶ月から数ヶ月程度
　要求条件：
　（１）遠隔地と共同の作品を作りたい
　　　分散実行環境
　　　名前解決
　（２）他人に邪魔されると困る
　　　セキュリティ

[Shigeru Kobayashi]

桑田さん、みなさん

小林です

タイミングの良いリプライができていないくてすみません。ここしばらく花粉症でさっぱり集中力がなかったのですが、ようやく復活してきました_o_。

> 勝手にユースケースを考えてみました。
> (A) ,(B), (C)はあるかなと思っていますが、(D)は無理やり作った感じで、あるかどうか良く分かりません。
> また、実際の要求条件は想像で入れてみました。ワークショップ等を経験されている皆様の方が詳しいと思いますので、ご意見を頂ければと思います。

ありがとうございます。:)

最後の(D)に関してですが、増井俊之さんの提唱されている「全世界プログラミング」と共通するところがかなり多いかもしれませんね。

http://www.pitecan.com/papers/ProSymSummer2006/ProSymSummer2006.pdf

ちょっと方向性は異なりますが、pachubeなども展開次第ではこうしたものにつながる面白い試みだと思います。

http://www.pachube.com/

以下、気がついた点に関してリプライします。

> (A) ワークショップ

このシナリオに関しても、次の(B)であげていただいた

> （３）自分の知っているプログラミング言語で作成したい
> 様々な言語のサポート

が必要になるかなと思っています。個々のワークショップは単一の言語で行いますが、どれにするのかを決定する過程では、想定される参加者層に合わせて決定しています。

入手性の面ではProcessingが優れているのですが、簡単な数式では記述しにくいアニメーションなどを作ろうとすると、敷居が高くなってしまうことがあります。このため、最近ではActionScript
2/3とProcessingの間での選択、というのが多いです。

> (B) メディアアートの制作
> (C) 実験室／電子工作

この2つに関しては、ユーザ層で分かれる意外にプロトタイピングの段階で分かれるのことがあるかもしれないという気がしています。

最初の方のスケッチの段階では、できるだけ早く試せることを優先する代わりに、インタラクションの全てが最終的なクオリティで実装されていなくてもOKです。しかし、製品開発でのプロトタイプ（＝一般的な作品展示は製品的にいえばこの段階に相当）では、スタンドアロン化、レイテンシ、長時間動作での安定性が重要になってきます。

なお、場合によっては、Funnelのようなアプローチではプロトタイプの後半の段階で既にカバーできない場合があるかもしれません。その場合には、いわゆる組込み的なアプローチになってくるのだと思いますが、その前段階でアイデアや個別のパートの検証で活用できれば十分かなと思っています。あるいは、スタンドアロン動作させる場合の動作モニタ的に使う方法もあるかなと思います。

以下は質問になるのですが…

> (C) 実験室／電子工作
：
> （２）既存プログラムや測定器を利用したい
> 処理速度／レイテンシ

ここでの「測定器」に関して具体例を挙げるとするとどのようなものになるでしょうか？例えば、MATLABのような実験系でよく使われるツールでしょうか。

2009/3/17 Yoshitaka Kuwata <kuw...@nifty.com>:

[Yoshitaka Kuwata]

小林さん

年度末／年度始めでばたばたしていていました。。
ユースケースに関するコメントありがとうございます。
なにか、表か図にするなりしてまとめてみると分かり易くなる気がしました。

頂いたコメントに部分的に返信します。

> 最後の(D)に関してですが、増井俊之さんの提唱されている「全世界プログラミング」と共通するところがかなり多いかもしれませんね。
>
> http://www.pitecan.com/papers/ProSymSummer2006/ProSymSummer2006.pdf
>
> ちょっと方向性は異なりますが、pachubeなども展開次第ではこうしたものにつながる面白い試みだと思います。
>
> http://www.pachube.com/
>
> 以下、気がついた点に関してリプライします。
>

これは不勉強で知りませんでした。想定外の利用イメージなのでしょうね。。。

> > (A) ワークショップ
>
> このシナリオに関しても、次の(B)であげていただいた
>
> > （３）自分の知っているプログラミング言語で作成したい
> > 様々な言語のサポート
>
> が必要になるかなと思っています。個々のワークショップは単一の言語で行いますが、どれにするのかを決定する過程では、想定される参加者層に合わせて決定しています。
>
> 入手性の面ではProcessingが優れているのですが、簡単な数式では記述しにくいアニメーションなどを作ろうとすると、敷居が高くなってしまうことがあります。このため、最近ではActionScript
> 2/3とProcessingの間での選択、というのが多いです。

なるほど。ワークショップの参加者もいろいろなレイヤ／ニーズがあるということですね。当たり前といえばあたりまえですよね。

> > (B) メディアアートの制作
> > (C) 実験室／電子工作
>
> この2つに関しては、ユーザ層で分かれる意外にプロトタイピングの段階で分かれるのことがあるかもしれないという気がしています。
>

同じユースケースでも時間経過でニーズが変化する場合がある。ということはこのコメントまで気づきませんでした。

> > (C) 実験室／電子工作

>
> ここでの「測定器」に関して具体例を挙げるとするとどのようなものになるでしょうか？例えば、MATLABのような実験系でよく使われるツールでしょうか。

ラボで何か実験の測定をする場合、簡単なジグをでっち上げてLABVIEWでモニタリングするというようなイメージをしていました。EJ-Blog記事
でもpepperで部屋の温度や明るさの測定を数日行うような例を書きました。
この手のジグの製作には持ってこいだと思いませんか？

桑田