投稿者: nishimotz

  • NVDA + GalateaTalk

    昨日の日記の続きです。gtalk.pyは今日はこんな感じになってます。

    class SynthDriver(silence.SynthDriver):
    name = "gtalk"
    description = "galatea talk (experimental)"
    def initialize(self):
    os.chdir("c:\\work\\istc\\SSM\\gtalk")
    cmd = "gtalk -C ssm-win.conf"
    (self.cout, self.cin) = popen2.popen4( cmd )
    self.cin = codecs.getwriter('shift_jis')(self.cin)
    self.cin.write("prop Speak.text = NoAutoOutput\n")
    self.cin.write("prop Speak.pho = NoAutoOutput\n")
    self.cin.write("prop Speak.dur = NoAutoOutput\n")
    self.cin.write("prop Speak.stat = NoAutoOutput\n")
    self.cin.write("prop Speak.len = NoAutoOutput\n")
    self.cin.write("prop Speak.utt = NoAutoOutput\n")
    self.cin.write("set AutoPlay = YES\n")
    self.cin.flush()
    self.frame = SynthFrame()
    return True
    def speakText(self,text,wait=False,index=None):
    self.cin.write("set Text = " + text + "\n")
    self.cin.flush()
    if wait:
    s = "[speak wait]"
    else:
    s = "[speak]"
    self.frame.textCtrl.AppendText(s + text + "\n")
    def cancel(self):
    self.cin.write("set Speak = STOP\n")
    self.cin.flush()
    self.frame.textCtrl.AppendText("[cancel]\n")
    def terminate(self):
    self.cin.write("set Run = EXIT\n")
    self.cin.flush()
    if not self.frame:
    return
    self.frame.Close()
    self.frame.Destroy()
    self.frame = None
    def getVoiceName(self,num):
    return "gtalk voice"
    

    で、今度は5~6行くらいは読み上げるようになりました。カーソルで行を移動すると「音切れ」もちゃんと実現されています。ちょっと反応が遅く感じるのは GalateaTalk の処理時間の問題でしょう。

    数行読み上げるとやがて止まってしまうのは GalateaTalk のコンソール出力をちゃんと読み出ししていないから不安定なのかも知れません。

    そもそも cout の読み出しをどうやればいいのでしょう。別スレッドを回して non-blocking I/O でcoutを読み出して捨てる必要があるのですが、まだ Python に慣れていない私はそこでつまづいています。

    ところで GalateaTalk の README には

    各スロットは、プロパティとして AutoOutput か NoAutoOutput のどちらかの
    値をとり、それぞれ自動出力する、自動出力しないを表す。
    プロパティの値を変更するには、
    prop Text.text = NoAutoOutput
    prop Text.text = AutoOutput
    のように prop コマンドによって行なう。
    初期値としては、全て AutoOutput が設定されている。
    

    と書かれているのですが、サンプルのPerlスクリプト(RUN)は

    print OUT "prop Text.text = NoAutoOutput\n";
    print OUT "prop Text.pho = NoAutoOutput\n";
    print OUT "prop Text.dur = NoAutoOutput\n";
    

    になっています。これ Text.text ではなくて Speak.text じゃないでしょうか?

    今日はここまで。

  • Python + GalateaTalk

    NVDA というオープンソースのWindows用スクリーンリーダーで GalateaTalk が使えないか、という話があったので、調べてみました。

    最新の NVDA snapshots には NVDAJp の活動の成果が取り込まれています。

    まず、python で gtalk を実行してみます。下記を UTF-8 で保存して実行。

    # -*- coding: utf-8 -*-
    import popen2
    import os
    import codecs
    os.chdir("c:\\work\\istc\\SSM\\gtalk\\")
    cmd = "gtalk -C ssm-win.conf"
    (cout, cin) = popen2.popen4( cmd )
    cin = codecs.getwriter('shift_jis')(cin)
    text = u'こんにちは'
    cin.write("set Text = " + text + "\n")
    cin.write("set Speak = NOW\n")
    for line in cout.readlines():
    print line
    

    あちこちからパクったソースです。「こんにちは」と喋ってくれました。

    次は NVDA のドライバー実装です。

    NVDA/synthDrivers/display.py をコピーして gtalk.py を作り、

    class SynthDriver(silence.SynthDriver):
    name = "gtalk"
    description = "galatea talk (experimental)"
    

    にしてみたら、とりあえず NVDA 起動→ Ctrl-Shift-S で gtalk が選択可能に。

    def initialize(self):
    os.chdir("c:\\work\\istc\\SSM\\gtalk")
    cmd = "gtalk -C ssm-win.conf"
    (self.cout, self.cin) = popen2.popen4( cmd )
    self.cin = codecs.getwriter('shift_jis')(self.cin)
    text = u'子猫が隠れんぼをしています'
    self.cin.write("set Text = " + text + "\n")
    self.cin.write("set Speak = NOW\n")
    self.frame = SynthFrame()
    

    gtalk ドライバー選択時に「子猫が・・」と喋ってくれました。

    def speakText(self,text,wait=False,index=None):
    self.cin.write("set Text = " + text + "\n")
    self.cin.write("set Speak = NOW\n")
    self.frame.textCtrl.AppendText(text + "\n")
    

    お、最初の2行くらい喋った!!

    でも、すぐに音声合成がハングアップ。やっぱり「音切れ」の処理を実装しないとダメですね。

    続きは明日!!

  • Ruby on Rails ふたたび

    ひさしぶりに CodeGear 3rdRail を触っています。

    きっかけはインプレスジャパンのこの本です。

    基礎Ruby on Rails (IMPRESS KISO SERIES)

    基礎Ruby on Rails (IMPRESS KISO SERIES)

    Ruby on Rails の環境、ライブラリ群、そして Ruby 言語の、すべてにおいて初心者の人を対象にした本であり、とても読みやすいと思います。

    この本を片手に 3rdRail で遊ぶのも、なかなか良さそうです。

    この本の第1章だけを試してみて、こんなことを思いました。

    • RoR を単なるテンプレートエンジンとして使うところから出発して、だんだんまともなアプリケーションに向かってリファクタリングしていく、というのもアリじゃないか?

    そこで来月のWIT研究会のページを作成する作業をやってみました。

    いままで ActivePerl と Template-Toolkit を使ってやってきた作業を、index.rhtml と main_controller.rb の index メソッドだけで実装し直してみました。rhtml の中で ruby が直接使えるのが嬉しいです。そして index の中にはひたすらハッシュ配列の代入文が並んでいます。そんだけかい。。

    階層化アーキテクチャによるアプリケーションにおいては、けっきょく、各レイヤの要になるのはテンプレートエンジンではないか、と思います。マルチモーダル対話アーキテクチャの標準化委員会にこの数年関わっていますが、そこで議論していても常々思います。

    3rdRail では rb ファイルでしかメソッドの入力補完は効かないようですが。。あと、実行時エラーのときにやたら重くなるのはなぜだろう。。

    RoR はあっちこっちのレイヤで縦横無尽にテンプレートエンジンが使えるのが魅力です。yml の中で eRuby を使う例を最初に見たときは目から鱗が落ちました。

    そんなわけで、ちゃんとデータモデルを使えるように勉強を続けたいと思います。

  • 携帯電話とPCのシェア競争

    数年前から思い続けてきたことが、だんだん現実になってきました。

    それは、1995年ごろのPCのシェアと、ここ数年の携帯電話のシェアの競争の構図が似ている、ということです。すごく乱暴にいうと、

    • NEC PC-98 = NTT Docomo
    • Apple Mac = au
    • DOS/V = Softbank (Vodafone)

    という対応関係です。

    PC-98 はかつての「国民機」で独占的なシェアがありました。一太郎やLotus 1-2-3などのキラーアプリもありました。それは、PDC 800MHz 帯でエリアが広く、iモードというキラーアプリを産んだかつての NTT Docomo にどこか似ています。

    Apple は当時から、デザイナーやコンテンツクリエーター御用達でした。筐体のデザインも広告も洗練されたイメージがありました。出版や音楽製作など、特殊用途の専用アプリケーションがたくさんあり、また Excel などヒューマンインタフェースに優れたビジネスツールが生まれました。それはどこか、音楽やナビなど新しいアプリケーションを切り開きつつ女性受けするイメージを保ってきた au に似ています。

    DOS/V は PC-98 の進化に停滞が感じられたころ、ハイスペック、世界共通仕様、というふれこみで黒船のように日本にやってきて、コンパックショックなどの価格破壊を起こしました。そして Windows 95 というプラットフォームの世代交代の波に乗って、一気にメインストリームに躍り出ました。それはどこか、Vodafone のグローバルスタンダード 3G という遺伝子を継承しつつ、価格破壊を引き起こしたこの1年の Softbank の快進撃を彷彿とさせます。

    そして、久しぶりに量販店の売り場を見ると、ひところは特等席にあった au がお店の奥に引っ込んでしまいました。Jobs が戻ってくる直前の停滞期の Apple がこれから au にも訪れるのでしょうか。そして大々的に宣伝されている Docomo 905i は NEC の 98MATE から Lavie などのラインに続く、反撃の狼煙のように見えます。7ヶ月純増ナンバーワンで迎え撃つ Softbank も、まだまだ油断ならないところです。

    そんな中 NTT Docomo の PHS の停波が迫ってきました。私はかつて(Windows CEになる前の)NEC MobileGear でISDN公衆電話からモバイルしていて、PHS に乗り換えました。データカードに乗り換えてからもずっと使い続けて、最後は腕時計型PHS Wristomo も所持していました。感慨深いものがあります。

  • WIT研究会のあり方を模索

    もう一つ、WIT研究会の専門委員会において、

    私は「もっと研究会を活性化したい」という問題提起をしたのですが、

    幸い皆様に好意的に受け止めていただき、

    建設的な議論をしていただくことができました。

    来年はどんどん新しいことに取り組んでいきたいと思っています。

  • 情報と理解

    研究会では私が共著の発表も1件ありましたが、

    学生さんは元気に立派に発表してくれました。

    質疑応答も堂々とこなしてくれました。

    実は前々日、前日と準備をして、

    何度発表練習をしてもよくならなかったのです。

    ちゃんと原稿を書いて読んでいるのですが、

    全然内容が伝わってこない。無駄が多い。

    じゃあ、ダメモトで、原稿を読まないでスライドだけ見て喋ってください、

    とお願いをしたら、たどたどしくはなったものの、

    格段にわかりやすくなったので、私が驚きました。

    あまりに変わったので、なぜだろう、と考え込んだほどです。

    仮説1)

    原稿を読まずに喋ることで、聞き手の考えるスピードと、

    読み手の喋るスピードが一致して、理解しやすくなる。

    仮説2)

    原稿を読まずに喋ることで、

    スライドに書かれた情報量と喋ることができる情報量が一致して、

    情報量が適切になる。

    ということをいろんな人に話したら、

    「じゃあアナウンサーの原稿読み上げはなぜわかりやすいのか」

    と反論されましたが、きっとニュース原稿が特殊なのだと思います(汗)

  • 善意と配慮

    12月5日と6日の2日間、

    HI学会と福祉情報工学(WIT)研究会の共催研究会に出席しました。

    http://www.ieice.org/~wit/program/2007_12-no39.html

    特に2日目の畠山卓朗先生の講演、大変なショックを受けました。

    「スイッチの神様」という紹介を受けて登壇された畠山先生。

    http://homepage2.nifty.com/htakuro/index.html

    リハビリテーションの現場の御苦労が生々しく伝わってきました。

    善意の押しつけや配慮に欠ける技術は受け入れてもらえない。

    見かけのニーズではなく、真のニーズを発見すること。

    「観察者」「対話者」に加えて「共感者」の視点を持つこと。

    福祉技術に限定せずヒューマンインタフェース技術の研究一般に当てはめても

    思い当たることがたくさんあったと思います。

    「とにかく現場をよく見てください。場と時間を共有してください」

    という畠山先生のメッセージに対して、質疑応答では

    「研究者とリハ技術者の役割分担の可能性はありますか」

    という質問が出たのですが

    (私も、そうかな、と思ったのですが)

    畠山先生は否定的でした。

    そのこともあって、

    現場に出ることができない研究者はどうしたらいいのか、

    学会が研究者に対してできることは何だろうか、

    と考えさせられました。

  • 展示と点字

    2007 国際ロボット展

    東京ビッグサイトで今日から12月1日まで開催。

    昨日、会場の設営現場に行ってきました。工業用ロボットの並ぶ大きなブース群ではなく、サービスロボットという分野の小さなブースに、音声認識を使った簡単なデモを搬入してきました。最近ずっとこれをやっていたので、とにかく形になってホッとしました。

    東3ホールのSR-14というブースで、ユニバーサルロボットさんという会社の展示です。

    最近 CodeGear C++Builder のことを何度か書きましたが、この仕事を通じて C++Builder の経験を積むことができました。まだまだですが。。

    UDソリューションセミナー

    夕方、毎日新聞の「ユニバーサロン」が企画するセミナーに参加。視覚障害者の支援技術をいろいろ見せていただきました。

    今回はグラフィックスや地図や触覚がテーマでしたが、自分が3年前にやった「谷中標本」とかなり近いコンセプトでICタグを使う提案もあり、音声と組み合わせる提案もいろいろで、新鮮でした。

    懇親会に参加したら、いろいろな方に声をかけていただいて、すっかり料理を食べそびれました。

    2次会に参加したら、10人のうち晴眼者は2人だけ、という状態。いろいろ本音を伺うことができました。

    「視覚障害者がどのくらい触覚から情報を得ることができるか」

    これは、本人がどれくらい前向きな気持ちになるかどうか、という要素が大きい。

    点字が使える視覚障害者は10%程度と言われています。訓練を受けないまま中途失明した方は、いまさら点字なんか覚えたくない、という方が多いようです。しかし立体コピーなどの機器が普及して、

    「こんな情報なら頑張って読んでみたい」

    と思うようなことがたくさん出てくれば、状況は変わるだろう、とのことです。

  • 電話音声認識の記録

    宅配便の不在連絡票には「音声またはプッシュボタンで自動受付」というものがありますが、プッシュボタンでしか操作したことがありませんでした。

    先日、固定電話から音声入力を試してみたら、こんな感じになりました。

    • お客様のお電話番号:ボタンで入力。
    • 送り状番号:3桁、2桁、3桁、4桁の合計13桁。音声で読み上げていたら、最後まで読み終わる前にタイムアウトしたので、ボタンで最初から入力し直す。
    • 営業所番号:6桁。音声で「XXXのXXX」と発話して入力に成功。
    • 配達ご希望日:1桁。音声で「2番」と発話して入力に成功。
    • ご希望時間帯:1桁。音声で「1番」と発話して入力に成功。

    振り返ると、桁数の少ない部分は音声でもうまく入力できる、という結果です。

    本当は「数字をボタンで入力するのが苦痛な項目」を音声で入力できて、全体として効率的になればいいのですが、現実はそうでもないようです。

  • Interface as Mimesis

    Brenda K. Laurel: “Interface as Mimesis”, User Centered System Design, pp.67-85, Lowrence Erlbaum Aassociates, Inc., 1986.

    を読んだら面白かったので簡単に内容をまとめます。

    • インタフェースは本質的にミメシスである
    • インタフェースの科学は成立していない?演劇や詩など「ミメシスの芸術」における理論はインタフェースにも有用なはず
    • 対話的ソフトウェアの目的=人間にいろんなことをさせること
      • インタフェースは、演劇と同じく、理解されうる世界を、わかりやすく表現すべき
    • ミメティックとは
      • 偶然や気まぐれではない。写実よりデフォルメがよい場合もある
      • 対象はリアルな事物でも仮想現実でもよい
      • システムは閉じていること。世界観が一貫していること
      • 閉じた世界だからこそ拡張できる:スタートレックのエピソード
      • 理論的に知ることができる世界を構築せよ
        • 原則論と確率論から演繹できるべき
    • アリストテレスの「詩学」はミメシスの形式を論じている
      • 「心地よい約束」
    • 1:手段
      • 調和がとれて心地よい手段=マルチモーダルが必要
    • 2:様式
      • ユーザに嘆願と説明をするUIは望ましくない
      • 物語形式:小説やテキストデータベース
      • 戯曲形式:演劇、アクションによるUI(望ましいインタフェース)
    • 3:目的・対象
      • オブジェクト表現がインタラクションをもたらす
      • ユーザは表出されたコンテクストの中で役割を演じる
      • インタフェースの役割=表現の提示
      • 操作の対象はミメティックコンテクストである
        • 道具としてのコンピュータ:偶然の産物。必然ではない
      • 媒介物=約束によってギャップを埋めるのは得策ではない
        • 道具メタファはユーザから直接行為の経験を奪う
        • ユーザがミメティックコンテクストに完全に参加するべき
    • 一人称メタファはインタラクティブなミメシスに最適
      • 二人称:説明書
      • 三人称:映画や小説
    • 設計原則1:表現の側面
      • レーシングゲーム=一人称
        • スピードを数字でキー入力させてはダメ
        • ペダルを踏む強さを数字で提示してはダメ
      • ファイル操作
        • 消去したいものを線で囲む:一人称
        • 「私は***を消したい」と音声入力:一人称
      • シミュレータやゲームは一人称ミメシスの正しい方向
      • 自然言語インタフェースも正しい方向
    • 設計原則2:インタラクションの側面
      • frequency : どのくらいの頻度で入力を受理(あるいは受理できるという表示)
      • range : 二値?連続値?語彙サイズ?(選択肢数を自覚させることも)
      • significance : 入力や選択に対するインパクト
    • 設計原則3:ユーザ制約の設計
      • よい制約=創造性、ユーザをミメティックワールドにとどめる役目
      • 可視的制約:コマンドメニュー アクションの前に提示すれば有効
      • 暗黙的制約:システムの振る舞いからユーザが察する
      • 外的制約:コンテクストの外、リセットボタン、電源スイッチ
      • 内的制約:コンテクストに合わせてESCキーを意味づける
      • Phone Slave (Schmandt 1984) ユーザ発話を効果的に制約する例
    • Selection Criteria
      • 「詩学」より:あってもなくても気づかないものは無効
      • 役立たない Help、意味のないインシデント、CAIにおける無意味な「動機付け」
    • Traits
      • アーティスティックな表現の中でインタフェースエージェントは直接的に実現できる
      • エージェントが参加するアクションの特性を定義すること
      • そのアクションをミメティックに表現するための特性を定めること

    直接操作インタフェースの根拠をアートに求めていて、著者自身の演劇体験なども書かれており、なかなか興味深い文章です。

    自然言語インタフェースや音声認識の有用性にも言及されていましたが、その部分に素直に賛成できない気がするのはなぜでしょう。

    もっと根っこの部分から考え直すと、音声認識や自然言語技術をどうやったらうまく使えるか、ヒントが見えてくるのではないか、と感じました。