「あの楽器」プロジェクト†
「あの楽器」製作に関する情報を集約するページです。
関連リンク†
もくじ†
形状・大きさ†
相談事など†
- ページ作成、ありがとうございました。 -- 髭伯爵
- 不在通知Pの発表 http://handsout.jp/slide/1109 によればマルチタッチは必ずしも必要でないとのこと。ありあわせのハードでどんどん練り込んでいけばいいかな。あとモジュール間のプロトコルは試案を出すべきか。 -- 尻P
- 「描画モード」は内容に即してないので「コンストラクション・モード」としてはどうでしょうか。 -- 尻P
- ハード仕様などがある程度固まると、ソフト側を進めやすいかも(ソフト仕様も混ざっていますが↓) -- っ
- 使用可能な技術について
- OS選定(Windows、MacOS、Linux、その他)
- OS(その他)→楽器には(Windows等の)OSの機能のほとんどは不要なので、専用OS込みで製作する場合
- .Netの使用可否(Windows以外もMonoを積めば使えますが・・)
- DirectXの使用可否(描画、音周り)
- COM(Component Object Model)の使用可否→GDI+もCOM→透過処理などに影響
- Javaの使用可否
- Windowメッセージの使用可否(OS選定、内部通信周りの仕様の考察とかぶりますが)
- 図形描画機能の有無→無い場合はドットマトリクス(ビットマップ含む)として処理→プロセッサ負荷、メモリ使用量、通信帯域幅等も考慮する必要があります
- 負荷について
- ハード側で処理する範囲(特に描画、音周り)
- 最適化の扱い(特定ハード向けに組む？)
- マルチタッチについて
- ハードの有り・無し、感圧機能の有り・無し、入力画面の形式(ピアノ鍵盤、ギター、テルミン式など)で仕様が変わると思います
- 奏法(+演奏の難易度)にも影響するので慎重に
- 特に音の高さ、大きさをどこに割り振るかが、気になるところ
- その他
- バス幅(メモリ、I/O)
- メモリ容量
- 通信周り(速度)→内部で賄えない処理を外部からどの程度取り込めるかが気になります
- 通信周り(プロトコル)→(オーバーヘッドが発生しますが)ラップも可能と思います。ただ、メッセージのフォーマットだけは先に欲しいかも。
- ソフト側の開発環境(テスト機、コンパイラ(アセンブラ)等)を確保する方法を考える必要があるかも
- construction：建造、建築の他に｢作図｣って意味もあったんですね。候補となる名称も色々と挙がってきそうですが…確かに、製品版のための正式名称必要でしたね。 -- ネギスー
- 相談事と言いますか、素朴な疑問なんですけど、バイオリンや二胡など、弓で弦を弾く楽器って、あの楽器ではどうやって演奏するんでしょう？皆さんはどんなイメージを持っていらっしゃいますか？ -- ネギスー
有用情報へのリンク†
ミーティング†
ハードウエア†
プログラム関連†
演奏用データ、その他(未分類含む)†
モジュール分割†
- 不在通知Pによる、モジュール分割とバス必要部分の図
- 演奏制御→表示制御もあるかも。(描画図形、位置など)翻訳結果を使いたい場合もあると思うので。 -- っ
- ソフト版の場合は、表示制御→入力操作(又は演奏制御)のラインも追加が必要かと思います。(表示座標系→入力座標系の翻訳が必要になるので)
- (外部)通信ユニットも必要になりそうです
- 外部通信ユニット(インターネットとの接続)←→内部通信の翻訳機能を入れておくと、開発が楽(+トラフィック、CPU負荷の低減につながります)
- 内部通信(ローカル接続)について
- 同期(1:1コントロールなど)、非同期(ブロードキャストなど)の選択も必要になりそうです
- (モジュール間を有線接続する場合)トポロジはスター型(又はバス型)が良いかも。ループ型(絶滅危惧種)だとステージ上の配線が煩雑になりそう
- 特に同期の場合、クロックモジュール(+クロック分配)が必要かも
- 演奏スタイル(記録されたMIDIを再生、リアルタイム演奏)についても考察が必要かも
- 時間回りの扱いが変わります→(MIDIの場合)記録された再生する場合:ゲートタイムで制御、リアルタイム演奏:ON/OFFで制御なので
![[PukiWiki]](image/logos/nialogo.png "[PukiWiki]")
innokb.mid
