●萩谷PM
5つ。
→新井、音楽から楽譜抽出、鼻歌くんとの比較が必要
→分子計算
→慶應の岩井さん
→小松、入力
→浅野、RelaxerStudio
●新井さん
→Sing-a-Tune project
→MIDIの自動分析。
→受賞経験のあるソフトウェアデザイナ
→教師の歌、生徒の歌の比較
→ヴィブラート、音の強弱。半音以下のゆらぎも表示できる。
→音楽教育、音痴の治療
→音を出すと敵がたおれるというゲーム。
●競合
→ソング頼太、採譜ソフトは作曲を目的。
歌の練習を目的としていない。
→歌唱練習はあるが、完成度が高くない。
→ピアノ練習のソフトはある。
●競合
→一オクターブでしか認識できない。
(こちらは三オクターブできる。)
→半音単位の識別ができない。
対して、10cent(半音の1/10)の認識が可能
→誤認識がおおい。
2000円程度のボーカルマイクでも認識可能
●当初
→歌の練習ソフト
→認識精度の向上
→ウィザード機能
●派生
→語学練習、中国語ではアクセントが重要
→楽器練習
→自動伴奏機能
●目標
→日本から音痴をなくす
→PCをつかって音楽を楽しむ
→消費者ソフトウェア不毛の時代に終止符を
売れない、もうからない時代である。
ソフトというと、給料計算などばっかり作っている。
●新井俊一
→プロジェクトリーダー
●小畑幹 (有限会社アンブレラ所属)
→企画、インターフェイスデザイン、音楽
→世界初の音声認識ゲームの開発で、日本ゲーム大賞 優秀賞を受賞。
●音痴には、聞くほう、出すほうの両方ありうる。
教師の音をだして、聞く練習とか。
●質疑応答
→音程がある音。
→視覚化することによって目でフィードバックする。
→カラオケのエコーは音で
→モー娘。とか、高低よりリズムをつかむのが難しい
リアルタイムで女の声にするとか。
音感より、拍子の研究はまだ。宿題。
→音痴な音をリアルタイムでプロの声に変換する。
正しい音程に直せるんか。
歌手で、外れた音程を直すツールがある。
→MIDIギターで採譜をこころみたことがある。
少し早めにしたり遅めにしたりする。
リズムがちゃんととれない。
→hidden マルコフとか、少しのびたり縮んだりをどうするか。
DPマッチングをつかって対応。
歌の練習の手助け。
Quantizeをどのくらいにするか。
識別率をあげるというのとのトレードオフは?
50msで、音が10centという単位。
→ゲーム、アンブレラはゲーム会社である。
小畑さんはゲーム畑の開発者。まだ先の話。
●デモ
→産総研の後藤さん、
適応フィルター
それぞれの楽器を採譜している。
ボイストレーナー的な機能をつよくするのがいいのでは。
→NHKの番組で、本質的な音痴をなおせるか。
出すとこがだめなのか、聞くのがだめなのか。
耳鼻咽喉科がきて検査、声帯を見て検査。
生理学的な分析も必要なのだろう。
→後藤さんの論文をよんで始めた。
→CDから音程をとって、教師データにするのがいい。
●近山PM、東大新領域創成科学研究科
→エンターテインメントでやってきた。
→ジャズピアノをひく。
●岡田
→自動音楽生成。
→リアルタイム自動作曲システムGershwinの開発
岡田、菅沼、辻の三人。
→既存技術: DirectMusic
→ビデオゲームにおいて、流れに応じて変化していく。
→ネットワークゲーム、
→新コンセプトのゲーム。
→ネットワークゲームのドラマティックな演出。
「Rez」というゲーム。
音楽そのものをインタラクティブなゲーム。
「パラッパラッパー」。
→ジャンルは?
●スタジオ・ミュージシャン・モデル
→リード譜を用意する。
→Performerは自分なりの演奏を勝手にやる。
→ブレイクする。みんないっせいに演奏をやめる。
→ここからここにかけて、もりあげていって、とか。
→リードシートの自動生成
→パート毎の演奏内容決定
●リード系 →メロディライン、ソロ楽器、ベースライン
●伴奏系 →ピアノ伴奏、ギター伴奏、ドラム・打楽器
→ベースはモノフォニックのラインが展開していく。
→ギター、ドラムなどの伴奏しているもの。
●自動作曲のプロセス
1. 学習
2. オーサリング
3. 楽曲生成
ゲームで使うことを想定。作曲家がいることが前提。
→平静時と戦闘時とか。
●1. 学習プロセス
→学習元曲データ (★これはどっからもってくるの?)
一般的演奏スタイル、リード系 (サックスソロ、ギターソロ、)
一般的演奏スタイル、伴奏系 (バッキング、オールデイズなど)
メロディーラインがあってコード進行があれば、それで曲。ジャズ的な発想。
●2. オーサリング
→Sound Creatorがいる。
→特定的作曲スタイル定義ファイル
→特定的演奏スタイル定義ファイル(リード系)
→特定的演奏スタイル定義ファイル(伴奏系)
●3. 楽曲生成
→一般スタイルの知識と、特定スタイルの知識
→作曲モジュール、イベントトリガ
→それからリード譜が生成される。
→そこから演奏モジュールが、
一般スタイル、特定スタイルを元に、生成する。
●DirectMusicの問題点
→条件に応じた曲の変化を全てオーサリングしないといけない。
→音楽理論をとりいれてない。
Cm7, F7とかコードを入力することができるのだが、
そのコードを全部自分でいれないといけない。
●岡田
携帯電話向けに、remix4U
●菅沼
修士論文で自動作曲技術。
remix4Uコアエンジンの設計と実装。
●質疑
→インタラクティブにかわるとは?
四小節、八小節単位?
→Gershwin。
ハッコク、エバンス。とか。
マイルス。死刑台のエレベーター。
→自動作曲をいくつか聞いたことがあるが、いいものはなかった。
コードの変遷を、演繹的にみちびきだしているようなものがおおかった。
音楽的にないだろ、という展開がでてきたりした。
演繹的な手法に問題があった。
音楽理論はガイドである。
そのため、学習でカバーする。
→近山さん、
このプロジェクトは壮大である。
学習のところが危険かも。
なにに注目して学習するのか?
演奏データからアブストラクトな演奏データを導きだすのは?
→MIDIをベースに学習する。
この曲から
300
50曲くらい用意する。
各パートとの相関関係を人手でつける。
→学習するとき何を学習するのか?
こういうまとめ方でやったらうまくいったというのをやってほしい。
→ジャズ以外に摘要できるのだろうか?
スタイルをどうあらわすのか。
→伴奏のスタイル、
Cm7というコードにたいして、こういうバッキングすると。
リズムに対応するのをかいていく。
コード進行にあわせて高さをかえていく。
こういうときにこういうバックという学習をする。
メロディーライン、ベースラインをどう学習するか。
4beatの学習。
→コスト関数をきめて、こういう音のときはコストいくつというのを、手であたえていっている。
それを学習させたいのだが…。
→ゲームの場面にあわせて。
どの場面にどういう曲という、それも学習するのか?
→この一撃でこれがしぬのか?
やばい状況の音をつくる。
★学習元曲データはどこからもってくるのか?
★歌詞があるような、歌は対象としていないのか?
歌詞とのマッチングは?
★トリガイベントの種類としてはどのようなものを考えているのか?
→通常と戦闘くらいの違いしかないような?
→音楽の骸骨の話、
→演歌
●岩井 @慶應SFC
→視覚的な分散アプリケーション構築ツールuBlockの開発
→uBlock toolsの紹介
→徳田研究室のこころみ
→ホームネットワーク普及
・視覚的な分散アプリケーション構築用ブラウザ uBlock Browser
・分散イベント配送ミドルウェア Dragon
・TranService
→Jini技術を一部使っている。
●uBlock Browser
アイコンによる操作でアプリケーション構築。
分散型JavaBeans
→マルチモーダル化
Java/Swing, 携帯、 Webブラウザ
→一貫性のあるシステム
→サーバサイド技術
●Dragon
→Jiniを実装
push(A, B, evt)
pushR(A, B, evt) 信頼性をもって非同期で通知
pull(A, B) BからAにたいしてイベントを同期的に要求
callBack(A, B)
callBackPull(A, B)
push(A, *, evt) Aが規定のマルチキャストにイベントを送付
●TranServeice-uBlock
→QOS、XMLで各サービスが記述される。
●アプリケーション1: どこでもインターフォン
●アプリケーション2: プレゼンテーション
●Smart Entrance
●徳田研の紹介。
●萩谷。
→採択のときになやんだ。
→研究とソフトウェア開発の関係は?
→ユビキタスコンピューティングは重要なのは確か。
→ただ、その中で、デバイスからアプリケーションまであって、
その中で、ミドルウェアを開発するというプロジェクト。
→未踏の目的はなにか?
→基本的な考え方は、
ソフトウェアを作る。ソフトウェアの作者として社会的に認知されるのが重要。
ミドルウェアを作るのが、ソフトウェアのcreatorとして世の中に見えるのが重要。
大きなプロジェクトの中で、ミドルウェアを作るのは重要なのというのもいいのだが、
uBlockの開発者として岩井さんが有名になってほしい。
→研究的な側面が強いのだが、ソフトウェアを世の中にだしたい。
●尾下、実時間衣服シミュレーションライブラリの開発、近山PM
→昨年、モーション制御だった。金出PMだった。
九大、システム情報科学府、博士3年
発表手順
→開発予定のソフトウェア
→技術的背景と問題点
→これまでの開発手法と改良案
→開発計画
→Shreak, 2001 Dreamworkds
→幾何学的手法をくみあわせる。
完全な力学ではなく、近似的に。
力をくわえるのではなく、変形をくわえるとか。
高速かつ自然に。
●開発ソフトウェア
→ライブラリ
ゲーム、仮想スタジオ、仮想現実環境
→仮想試着システム
●ライブラリ
→シーン情報
→衣服モデル
→シミュレーションモジュール
→レンダリングモジュール
●仮想試着
→モーションキャプチャとの組み合わせ。
●粒子モデルによる計算
→煙、炎のシミュレーション
→微少粒子によるメッシュ構造
→弾性力、屈折力などの衣服内部の力
まがっていたらまっすぐにもどるとか。
→重力、接触による反力などの外力
一つの衣服で、数千から数千万の点が必要
数百から数十万。
→Dear or Alive 3、Tecmo、Xboxのゲーム。
→衣服のしわなどは表現できない。
→それらしい、手法
Oshita, Makinouchi,
Real-time Cloth Simulation with Sparse Particles and Curved Faces.
Proc. of Computer Animation 2001, Nov. 2001.
●提案手法
1. 洗いメッシュ。少数の粒子によるシミュレーション
→全体的なはらめき、屈折
2. 幾何的手法により、衣服の表面計上を生成
衣服の細かい振舞いを実現
→細部のねじれ、ふくらみ、しわ
●スカートのアニメーション
→66粒子
→1000頂点
●
1. 洗いメッシュからbezier曲面をつくる。
2. 粒子にはたらく力におうじて曲面計上を制御
3. 辺の長さを制御。
辺の長さを保つようにする →しわができる。
●問題点。
→広範囲に接触するときはうまくできない。
→十分に自然ではない。格子がみえる。
●解決案1
→接触部分だけadaptiveに粒子数をかえる。
シミューレションが不連続にならないように。。。
●解決案2
→細かいメッシュの頂点が、荒いメッシュから離れることをゆるす。
規則的なしわができてしまう。
●関連研究
→Implicit積分手法。[Braff]
→ブレイクスルー。
→比較的高速なシミュレーションを実現
→テクスチャによるしわの生成。 [Volno]
しわのパターンをアーティストがかいておく。
しわのパターンは決まっている。
→2層モデルによるシミュレーション [Kang 02]
→同じく2解消のメッシュ。
→細かいメッシュにもシミュレーションを摘要。
●開発計画
→8〜9
環境整備
仮想試着システムフレームワーク
→9〜11
→12〜2
●環境整備
テスト用の衣服モデル。
人体モデルの準備。
→LookStailor (とうようぼう)というソフトがある。
アパレル用の衣服の型紙データからつくる。
●モーションキャプチャの導入
spice inc.
→スーツ式。安い
Ascension Tech. Co.
→光学式。高い
PhoneiX Tech. Co.
●ライブラリ本体
1. より安定な積分計算・めり込み回避手法を。
2. 接触処理のために適応構造を追加
9〜11に完成をめざす
●目標
→Pen4 2.0Gで、
キャラクタ一体分
衣服1セット、ズボンorスカート、シャツ、上着
→秒間30フレーム
→最低限、発散、めり込み、不連続などはないように
→自然なしわの実現
→衣服をつまむ、脱ぎ着するのが理想
●ライブラリの商用化
●質疑
→ローポリは?
→Digital Fashionの坂口さんがいる。
Cloth simulation
Xbox, プレステのRealTime Cloth simulation。
「はおれば」というのが数億円規模で動いている。
Dressing Simが進化したバージョンがはんぱじゃない。
50人規模のハッカーがいる。年間数億規模で動いている。
Cloth Simulationだけをやっている会社。
★服のデザイナーが使えると面白いのでは?
■寿福、紀PM、Webアプリケーション・ジェネレータ B2J
→IDEやコンパイラの開発経験。
→CP/M BIOS開発 1980-1985、FM8
6809。Z80カード。
→マイクロソフトウェア・アソシエイツ、コーディング
→Unix用表計算ソフト Noel、 1986
http://noel.msa.co.jp/
プロジェクト・マネジメント、コーディング
→ボーランド日本法人 1985-1994
40名あまりの開発者
→米Borlan社 1993-1994
8年いて、昨年の12月にもどってきた。
コンパイラの偉い人
アンダーソン・ヘイゼルバーグ、16才でTurbo Pascalを作った。
そのとき19才。非常によいアセンブラをかいていた。
→Visual .NETの開発責任者になった。
Turbo C、ピータークックウェル →J++を作った。
→米Symantec 1995-1999
開発ツール チーフアーキテクト
→VisualCafe 1996-1999
設計、コーディング
WebGainにうつった開発と販売
●B2Jの実現
言語処理系の変換。Visual BasicからJavaへ。
プログラム・パラダイムの変換。
スタンドアロンAPからWeb APへ。
●デモ
→Tomcatを動かす
●変換
→パーサ
VBを解析、フォーム定義ファイル
→トランスレータ
制御構造
→データタイプ・ラッパ
データタイプ12個
→オブジェクト・ラッパ
ファンクション(150個)
→コンポーネント
VBの標準コンポーネント
サーバサイドではこれ、クライアントサイドではこれ、とわけていく。
GOTO文がやっかい。サポートできない。
●Web AP
WebブラウザをGUiのコンテナとみなす。
UIオブジェクトとビジネス・ロジック・オブジェクトが、
HTTPプロトコルにより互いに情報を交換しつつインターネット上で動作する。
→HTTPリモートプロシージャ呼出し機能
→サーバ・オブジェクトのデプロイ管理機構
●実装
→独自のIDEはもたない。
VBのアドインとして実装
→力技と労力のみの標準コンポーネント作成は後回し
■アントラッド中口、XML通信を基盤としたオブジェクト共有・オーナー管理システム
●3D-NWS、H12,H13の未踏ソフトウェア創造事業
→これまでは、プロジェクトリーダーの和田さんがやっていた。
→位置情報、加速度などが共有されている。
→波の位置が共有されている。
●合意形成支援システム、(株)大広
client: flash
server: JSP, Java, JSTL(tag library)
●フレームワーク、ライブラリ
→クライアントサーバ
CGI
Servlet/JSP
SOAP
→P2P
Jxta
→マルチユーザ
DirectPlay
その他ネットゲームライブラリ
→GSS、オブジェクト共有・オーナー管理システム →これが今回の提案
●問題点
→ネットワークプログラミングの複雑さ
セッションの維持
メッセージ配信
メッセージ管理
メッセージエンコーディング、デコーディング
オーナー(所有権)管理
→汎用セッションサーバ (General Session Server - GSS)
→オブジェクト共有システム
→オーナー管理システム
→アスペクト指向によるネットワークロジック導入
まず最初はAspectJを使う。
●GSS
セッション特有のサーバサイド機能を実装できるフレームワーク
●技術要素
→Java
→TCP/IP (java.net.*)
→XML
→ダイナミックプロキシ (java.lang.reflect.Proxy)
→AspectJ (http://www.aspectj.org/)
→C++, Python, Action Script
●課題
→セキュリティ、暗号化、認証、アクセス制御
J2ME対応
軽量XMLパーザ
データ量削減(XMLのバイナリエンコード)
●担当
→中口、コアシステム
→和田、クライアントAPI、Javaによる応用アプリケーション
→熊坂、Flash MXによる応用アプリケーション
●質疑応答
→合意形成システムをなんに使うのか?
■松井、Cプリプロセッサ
→10年前からこつこつとやっていた。
→世界一優れたCプリプロセッサ
→9月のLinuxカンファレンスで発表
■川合、3DのWIKI、CVSとか。
13:00 ●漢字プロジェクト
g新部、先週の金曜日午後に不採択が決まった。
■苫米地、文字データベースに基づく文章処理環境の開発
→8人
CCSのコードポイントなども、属性として扱う。
→漢字、、、、OpenType
●visualization
→近い漢字を学習することができる。
→近い字の範囲を決めることができる。包摂基準の設定。
■CodeRidge: 協調可能なソフトウェアマップの開発
FSFとかFreshMeatのソフトウェアマップのようなもの。
→いろいろある。
SourceForge, GNU Savannah, Tigris, GJT, etc.
動的なしぼりこみ検索
■大場幹浩 http://www.ne.jp/asahi/o/o/ougishi/index.html
http://www.forest.impress.co.jp/article/1998/12/07/nengajo.html
http://www.forest.impress.co.jp/article/1998/10/20/oh.html
1.0(98/09/30)
http://www.vector.co.jp/soft/win95/art/se083595.html
http://my.vector.co.jp/servlet/System.FileDownload/download/http/0/83595/pack/win95/art/graphics/edit/ougis310.exe
Ougishi 3.10
ougis310.exe / 1,800,874 Bytes / 2002.1.15
■FontWizard http://www.techno-advance.co.jp/fw/FW.htm