編集時に再生速度をあげて時間短縮できる、という話を聴いたので Audacity でもできるか調べる。で、できる。"Play-At-Speed" という機能があるのでそれで再生速度を速くし、かつ "Play-At-Speed" に適当なキーボード・ショートカットを割り振れば良い。
視覚障害者です、という人から Podcast 良かったよと感想をもらった。図で説明されがちな話題を言葉で説明しているのがよい、という。
なるほどねえ。
自分は特にそうした配慮によって話題を選んでいるわけではないので、そういう役に立ち方をするのは意外で、ありがたいことだが若干申し訳なくもなった。つまり、特にそういう人々のことを気にしてなかったから。
言葉だけで、特に声だけで、伝えるためのテクニックというのはきっと存在して、ラジオの人とかはそういうのをどこかで学ぶのだろうなあ。自分はなにも気にしていない。それには気まずい面もあるが、一方で low hanging fruits がありそうな気もする。なんかちょっと調べてみようかなあ。
少し前から話の構成は準備するようにしたわけだが、音声メディア固有のテクニックというのはどういうのがあるんだろうね。ちょっとぐぐったくらいではわからない・・・。あと自分たちの Podcast は編集とかはそんなに頑張れないので、たとえば音声クリップを挟む、とかは厳しい。自分たちの話の仕方の範囲でできる工夫を探したい。
Link: retrage on Twitter: "#misreading KVM回聞いたんですがFreeBSDのbhyve、OpenBSDのvmm、NetBSDのNVMMあたりも触れて欲しかった"
がっくりするフィードバックの例。話の内容がわからなかったから詳しく話せというフィードバックは歓迎だが、これはもうね・・・自分の好きなものの話は自分でしろ！ FreeBSD にしろ OpenBSD にしろ心の底から興味ない。とかクソリプしかけたが聴いてくれている人に喧嘩売っても仕方ないのでそっとじ。
前も書いたけど自分の知っているものの話を聞きたいという人は割と多いっぽく、KVM の話とかはまさにそういうだった模様。Podcast の人気を高めたいのであれば聞き手が知っており、かつ他人はそれを知らないと思っている、という程度の疑似ニッチを紹介するのが良いのだろうが、そういう圧力とは戦っていきたい所存。他人の関心に引きずられるべからず。
今週は旅行のため Podcast を録音しておらずしたがって編集もないので、その暇にどうやったら購読者を増やせるかを考えてみる。増やす必要があるのかは今は脇においておく。
まず完全に自分の直感で頭に浮かぶアイデアを書き出してみる。
話題を buzz りやすいものにする路線がありえる。buzz りやすいすなわち social media でリンクされやすということね。これには２つの切り口があると思う。
一つ目は題材/headline に流行り物や人々の好きそうなものを選ぶ。流行り物はさておき、好きそうなものとは何か。聞き手がその話題について知っており（あるいは知っていると信じており）、どれどれこいつらどれだけわかってるか聴いてみっか、みたいな態度で聞ける話。たとえば bikeshed であったり古典であったり。自分の意見を (support であれ confrontation であれ) 表明しやすい話題と言えるかもしれない。昨今は意見を表明する = social media になんか書く、なので buzz に向いている。
流行り物は自分も知りたい時があるのでそういう時だけやればいいとして、「人々の好きなもの」はねえ・・・購読者を増やすことが他のなにより優先するひとだけがやることであって、自分はそれに該当しない。Empirical software engineering の話、読むと面白いけどあまりやりたくないのはこの「人々の好きなもの」成分が強すぎるから。
つぎ。話術を軽妙にする。なんつうかこれは「話を面白くする」みたいなトートロジーぽい主張に見えなくもないけれど、情報としての価値ではない filling の部分をよくする、ということで、ようするにテレビのトークショーとかのホストやレギュラーのようであれ、ということだよな。まったくできる気もやる気も沸かない話だが・・・。
ただ軽妙さはともかく滑舌はもうちょっとなんとかしたい気がしている。編集してて自分のいってることがしばしば聞き取れことがあり、聴いてる人に申し訳ない。
すこしデータをみてみる。上で buzz ればよいと書いたけれども、じっさい social media 上でのリンクの流通はどのくらい購読者増に寄与するものだろうか。Misreading Chat, stats を見ていると social media より検索エンジンからの流入の方がだいぶ多い。これは自分がむかし blog を書いて stats を眺めていた時には見られなかった現象な気がする。確認のため前に書いてた Medium の stats を見たら Twitter だのブックマークサイドだのばかり。検索エンジン全然 refer してくれてない。
検索でサイトにたどり着いてくれていることを考えると・・・。どうしたらよいのだろうね。たとえば show notes をもうちょっと親切にするとか? でも show notes で気が済んだら聴いてくれないからダメだな。Rebuild とか Turing Complete FM とかは chapter をつけていて、あれはエライし聴いてもらう敷居はさげていると思うが、面倒すぎるし Wordpress の hosting ではどのみちうまくリンクできないからダメ。
多くの podcast は番組内で iTunes に review を残してくれるよう頼んでいる。Review の流量が iTunes 内でのランキングに寄与するためらしいのだが・・・ Apple デバイスというか iTunes の動くデバイスを持ってない身としてはランキングってなに？ってかんじなのだよなー。てか Chrome OS 開発者と Android アプリ開発者がやってる podcast をみなさん iTunes で聴いているの? ほんとに?
iTunes の Podcast Analytics はいちおう見えるようにしてあり、それによると各エピソード最終的に 500 devices くらいでは聴かれているらしい。これは多いと思うけれども、一方で 7-8 割くらいといわれる iTunes の podcast market share を自分たちの購読者が反映しているというアイデアも直感的には信じがたい。まあ自分が Android にバイアスされすぎてるんだろうね。ただ自分で見えないランキングのために何かをお願いするのはアホらしいなあ。 自分がこのアホらしさを克服できたらお願いすることにしよう・・・。
とかぼんやり考えていたら職業 Youtuber の苦労について書かれた記事を見かけた。記事の中では彼らが購読者獲得のため何をがんばっているかについても触れられている。YouTube は podcast よりは Web 寄りだけれども、同じ非活字メディア同士参考になる部分はある気がする。
記事の中では social media やコメントでの engagement, 更新頻度, 他の Youtuber からの推薦(を得るための Youtuber 同士の社交) に苦労しているとある.
自分は social media があまり好きでないので Twitter で反応するとかはあまりやってない. 購読者を増やす意味ではやった方がいいんだろうけれども, Twitter にログインしたくないので. Social media の外に dedicated な forum をつくる、というのも理論上はできるけれども、なんとなく嫌な予感しかないので多分やらないでしょう。
更新頻度は, 結果的に週二回になっていてこれは良い方向に機能してるのだろうけれども, 個人的には編集とかが大変なので半分くらいでもいいかなと思っている. ただ論文を読む量も減ってしまうので, 今のところ週二回になっている.
他の Youtuber がどうこういう点だと、じっさい Misreading Chat の購読者は Rebuild や Turing Complete FM 経由でやってきた人が多いっぽいので、きっと効果はあるのだろうな。ただ、たとえば Rebuild に出してもらって自分の podcast の宣伝をするというのも図々しく感じてしまう。一回やらせてもらったからもう十分でしょう。自分が他の podcast を宣伝するのは別にいいのだが。
むしろこの記事を読んで思うに、自分は職業 podcaster ではないのだから生活がかかってる人々と同じ指標すなわち購読者数を気にするのは筋が悪いのではないか。そもそも日本語のプログラマ向け Podcast を職業でやってる人はいないと思うけれども・・・。
様々な時代の力によって本職ではない個人までもが stats と attention の虜になってしまった blog の不幸を繰り返さないためにも、購読者数のような他人の数字ではなく自分にとっての価値を重視する方がよい。とおもう。と、結局いつもの結論になってしまうのだった・・・。
ただ滑舌は、もうちょっとなんとかしたいです。はい。
Podcast, 自分のターンは基本的には論文の構成にしたがって話を進めているのだけれど、これはイマイチだな。概要をつたえるという趣旨に合わないし、門外漢相手に話をするメディアの性質にもあってない。そして書いて有ることを全部伝えようとする結果長くなりがち。もっとこう、内容を把握した上で話す順番とかとりあげる話題は自分で考え、細部はざっくざくと削ってしまう方が良さそう。
それはつまり Linear Digressions みたいにするということで、幾つかの理由からもともとはあまり乗り気でなかった。まず若干パクリっぽい気分になるので自分なりの方法を考えたかった、というエゴのようなもの。あと Linear Digressions はあっさりしすぎて食い足りないところが自分は不満なので、詳しい話をしたかった。あとは理解がいいかげんな状態で中身を再構成するとかできなそう、という気がしていた。
が、その結果として締りがなく時間ばかり長い現状になってしまっているので、何か違うことを試して良い頃合いでしょう。難しかったらまた考え直すということで。
たとえば向井さんとかは、割とあっさり済ませているよね。そしてそれは機能している気がする。自分はせっかく読んだので読んだよーと言いたい誘惑に負けてるのだろうな。
というわけで次回からは構成を無視してあっさり目に話してみたい。
あとで読むかもリンク from Technical Papers - SIGGRAPH 2018
SIGGRAPH のサイトに論文はないのでタイトルで適当に検索してさがす。
SIGGRAPH 2018 Papers が論文へのリンクをまとめている。
GANのep聞いたけど具体的にどのproposition, theoremがわからなかったか言ってくださるとよかったかな / 学部レベルの確率統計の知識でprop1とthm1はわかるはず. Thm2も用語調べつつ読めばわかるんじゃないかな
というフィードバック。聞いてる人が論文を手元にもってない前提で話しているし自分も向井さんの読んでる論文は手元においていないのでこのレベルの細かさで話すことはないけれども、一方で何がわかってないかちゃんと理解するのはいいことにも思える。
というわけで論文をちらっと眺めてみると・・・以前よんだとき、自分はそもそも式 (1) がよくわかってなかった気がする。今みるとわからなくもない。記憶をたどるに、まえは式中の P_{data} が何なのかわからなかったせいで行き詰まったのだと思う。文中にも出てこないし。これが要するに training data のことだよ、というのがわからなかった。今回は向井さんの話もあってそういうものだという前提で読めたのでわかった気になれたのだろう。
というところで満足して証明は読まず。ひどい。
なにを読むか。
Braindump:
説明するってのは難しいなあと Podcast をしていて思う。今回の Graal/Truffle は周辺論文も読んでほぼ理解したつもりだったが、話してみるとわけわからんかんじになってしまった。
なぜかと考える。ひとつは Truffle/Graal というものがどう振る舞うかはわかったが、それが他のものと比べてどう新しいのかについての理解が足りていなかったこと。たとえば普通の最適化コンパイラ/JIT にはなぜそれができなくて、なぜ Truffle ではできるのかという部分の説明ができなかった。それは
とかだよな。
でもこれは、実際に説明しようとして失敗しないと思い至れない。いちおうなにを話すかはノートに箇条書きしてあるのだけれど、それが不十分なのだろうなあ。結局、自分がアイデアのコアを理解できてないということのような気もする・・・が、こうして事後的にはわかるのだから、理解してないというのとも違う。説明できないだけで。
公開前に読みなおしてわからなさを判断できるブログだとこういう問題はおきない。でもブログを書くのがと大変だから Podcast をやってるわけで、たとえばブログを書いた上で Podcast に臨むとかは時間がかかりすぎて本末転倒。
もうひとつのオプションは、前の日のランチとかでリハーサル？をしておくことだろうか。ただそれだと聞き手がねたばれしてしまい、本編の会話がいまいちになってしまう気もする。向井さんじゃない誰かに説明してみるのがよいのだろうけど、日本語の通じる知り合いがまわりにあんましいないのだよなー Y 氏くらいで・・・もうちょっと日本人同僚たちと親しくしておくんだった・・・。英語でやれ？すみません・・・。
箇条書きのノートだけだとうまく話せないのは、スライドだけつくってもうまく講演ができないのと似ている。事前の練習が必須。一人で、あまり手間をかけずに、それができないもんかなー。まあ講演の練習なんかは一人でやることもあったから、やればいいだけかもしれないが・・・。夜中にやるの？ひとりで？まあ一回くらいは練習してみていいかもしれないな。あとはやはり Y 氏に犠牲になってもらうか・・・あのひと木曜の昼はあいてるのだろうか・・・。
あとはノートをもうちょっと会話に近づけていくというのはあるかもしれないね。しかしそれほぼ Blog なのでは、という気はする。時間と手間をかければよくなるのはわかるが、本業および家庭に差し支えると困るのでラクさは重要なのだった。持続可能性。
持続可能性という意味では週に一本、担当は隔週にするのはよい。自分への論文読み圧が減ってしまうのはやや残念でもあるけれど。
前回の RISC-V の話がなぜ比較的大丈夫だったかというと、立ち入った話が少なかったからだろうね。ああいう与太話寄りのはラクだけれど、やっぱり立ち入った話ができないと面白くないよなあ。自分が。世の中の説明がうまい人たちの頭の中ってどうなってるのだろうね。
追記
うー
こう説明すればだいぶ腑に落ちるはずだが、この理解には到達できていなかった。限られた時間でこういう理解に辿りつけなかったのは、自分が言語処理系に通じておらずメンタルモデルが弱かったせいだよなあ。
練習するとかもあるけど、ちゃんと腑に落ちるまで考えるのも大事。練習をすると自分の理解の不備に気付きやすくはなるが、けっきょく理解には時間をかけないといけない。
結構あるのでどれを読んだものか・・・。特徴的な最適化手法の話と、上のレイヤからのインターフェイスすなわち IR の話を読むのが良いかなあ。