「あの楽器」プロジェクト†
「あの楽器」製作に関する情報を集約するページです。
* 臨時チャットのお知らせ *
本日 3/28(土) 22:00 よりIRC上で「あの楽器」浜松ミーティングに関する打ち合わせを行います。
詳細は下記の定例IRCと同じです。お気軽にご参加ください。
定例IRC(チャット)†
毎週木曜日23:00より、IRCにて定例会議をやります。チャンネルは#ano。第一回は3/19。途中参加・退出自由ですので気軽にご参加ください。
お知らせ†
過去記事→「あの楽器」プロジェクト／古い記事
関連リンク†
もくじ†
形状・大きさ†
思いつき・相談など†
- ページ作成、ありがとうございました。 -- 髭伯爵
- 不在通知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：建造、建築の他に｢作図｣って意味もあったんですね。候補となる名称も色々と挙がってきそうですが…確かに、製品版のための正式名称必要でしたね。 -- ネギスー
- 相談事と言いますか、素朴な疑問なんですけど、バイオリンや二胡など、弓で弦を弾く楽器って、あの楽器ではどうやって演奏するんでしょう？皆さんはどんなイメージを持っていらっしゃいますか？ -- ネギスー
- 弦楽器から「あの楽器」に入った奏者を対象として考えると、左手にあるリボンコントローラがギターのネックで、音階を決める感じでしょうか？...ピッチ、モジュレーションをオクターバー的に割り付け、画面部分へのタッチで弦をはじくイメージ。これで弦楽器風かなと。マイナー､7th系のコードは画面のタッチ位置で変えるしかないですが。 -- h@考察中
- なんとなく楽器＝メロディ・コード・リズムを奏でるもの、と思っていたんですが、テノリオンの機能をみて、「シーケンサ」としてのアプローチも重要かな、と思いました。あかやかPのこれを発展させたらどうかな、と＞http://akayaka.blog24.fc2.com/blog-entry-60.html -- 尻P
- あの楽器のOSは、出来るならLinux等を専用に開発して機能も必要最低限にまとめた方がいいですよね
起動時間が早くて、起動直後に楽器として使用可能とかが出来ればいいんですが
ネットワーク対応になるとセキュリティの信頼性も確保しないといけないんですよね・・・
軽くて、尚且つセキュリティレベルに問題がないものを作るのは大変か・・・ -- Aki
- AtomかIonかBeagleBoard上のLinuxベースにして物理インターフェイスはUSBとかだとラクそう...多言語共存できるし、入出力だけなら最低限catとechoでもできるし。 -- num0
- ふと思ったんですが、あらかじめ演奏を登録しておいて、タイミングよく画面を押していけば「演奏できてるように見える」という機能(音ゲーみたいな感じでしょうか）じゃだめなんですかね？ -- eliotropio
- 発音＋シーケンサでprogrammable music controller的なデバイス？。タッチセンサー部で丸を描くと聞き手側で音像が周辺をまわるとか、おもしろいですね。 -- h@考察中
- eliotropioさん、楽器ですし、何かをトリガーにして音が鳴る、もしくは音を変化させれば楽器かと。発音は単音、和音、小節、フレーズ、何でも良いかと。ミクがしゃべっても歌ってもいいと思います。 -- h@考察中
- コード楽器としてのインタフェースの提案。左ネックにメジャー、マイナー、7メジャー、7マイナーのボタンをつけて、右パネルで、キーとなる音の位置を叩くって感じで演奏できないかな？これだけで、大抵の曲は伴奏が出来る気がするよ。 -- 某
- 【ソフトUI希望】画面表示のエフェクトですが、☆、○、△、線とかに意味があれば面白いです。個人的にはビートマニアのような感じで、選曲した後、曲毎の音の鳴らすべきタイミングで Excellent なら☆、Good なら○、Normal なら△、Bad なら線とかができたら希望。（今は単にランダム表示なんですよね？） -- コンパイルエラーガトレナイ
- ↑それは楽器じゃないと思うけど、あてぶりの機能の一種としてならありかも。 -- Aki
- あてぶりのとき、ただタイミングを指示するだけじゃなく、ピッチベンド等のエフェクトも入力できるようにしたら、楽器ぽくなりませんかね？ -- 尻P
- エフェクトはコードの種類ごとに記号が決まってると良さそうかなー -- 通りすがり
- 使えそうなマルチタッチセンサについての情報を見つけました。 -- 工業系
- 間違えて書き込んでしまいました。 http://jp.makezine.com/blog/2009/01/intimate_control_for_physical_model.html これです。英語難しいです読めません。でも動画を見たら良さそうだったのでここに書き込みました。映像を表示できませんが、楽器としての性能が良くなりそうなのです。どうでしょうか？ -- 工業系
- これはひょっとして原始的な抵抗膜式タッチパネルでは… --
- XPの組み込み型（http://www.microsoft.com/windowsembedded/ja-jp/default.mspx）ならCFサイズまで落とし込み可能です。 -- Gin
- これをなんとか組み上げて原寸大・マルチタッチ対応の原寸大あの楽器をつくってみました(N:KM のプレゼン資料)。これは完全に俺様仕様ですが、このwikiの情報を使って第２弾を計画しています -- ミクミンP
有用情報へのリンク†
ミーティング†
ハードウエア†
プログラム関連†
参考になりそうな楽器†
演奏用データ、その他(未分類含む)†
モジュール分割†
- 不在通知Pによる、モジュール分割とバス必要部分の図
- 演奏制御→表示制御もあるかも。(描画図形、位置など)翻訳結果を使いたい場合もあると思うので。 -- っ
- ソフト版の場合は、表示制御→入力操作(又は演奏制御)のラインも追加が必要かと思います。(表示座標系→入力座標系の翻訳が必要になるので)
- (外部)通信ユニットも必要になりそうです
- 外部通信ユニット(インターネットとの接続)←→内部通信の翻訳機能を入れておくと、開発が楽(+トラフィック、CPU負荷の低減につながります)
- 内部通信(ローカル接続)について
- 同期(1:1コントロールなど)、非同期(ブロードキャストなど)の選択も必要になりそうです
- (モジュール間を有線接続する場合)トポロジはスター型(又はバス型)が良いかも。ループ型(絶滅危惧種)だとステージ上の配線が煩雑になりそう
- 特に同期の場合、クロックモジュール(+クロック分配)が必要かも
- 演奏スタイル(記録されたMIDIを再生、リアルタイム演奏)についても考察が必要かも
- 時間回りの扱いが変わります→(MIDIの場合)記録された再生する場合:ゲートタイムで制御、リアルタイム演奏:ON/OFFで制御なので
![[PukiWiki]](image/logos/kokiki_80.png "[PukiWiki]")
innokb.mid
