2005/06/14
短篇映画の撮影で、丸2日Kaneohe近辺でロケしてきた。 今回はprincipal roleで、長ぜりもある。
カメラと舞台での演技のつくりかたの違い、そしてカメラでの仕事で 目指すべきことがなんとなくわかってきた気がする。
映画では、監督は役者の演技以外にも気にすることが山ほどある。 音、光、フレーミング、タイミング、背景に映るもろもろ。 全てがベストに揃えばラッキーだがそういうことは滅多に無いので、 基本的には監督の望んだレベルの画が撮れた時点で次のショットに 移ることになる。また、リハーサルの時間もあまり取れないから、 役者が持ってきたものを見せて、監督が若干adjustして、それでgoとなる。 つまり、こういうことが言える。
- 演技が "good enough" であればそこで終わり
- 演技しながら色々なオプションを発見している暇はない
舞台のようにリハーサルにたっぷり時間が取れる場合、最初に役者が 演出に見せるのは叩き台で、そこから演出や他の役者との共同作業で 場を作って行く作業が始まる。演出が当初期待していた通りの 演技をするのは役者の負けというか、そこがスタートラインであって、 そこからどれだけ上を目指せるかというのが勝負どころになる。 当初誰も予想できなかったくらい良いシーンをつくることがゴール なんで、"good enough" な演技だけじゃだめだし、演技しながら いかに発見してゆくかが重要だ。
Acting Classの先生の一人は、"If you can act on stage, you can act on anything" と言っていたけれど、"good enough" な演技をdeliverする、という意味では確かにそう言えるかもしれない。
でもなあ、やっぱり演技として観たい/観せたいのは、人の頭で あらかじめ予想がつく程度のものじゃないはずだ。 カメラの現場でそれをやるには、最初に監督に持ってく時点で "beyond `good enough'" でなければならない。
オーバー気味で持ってけばadjustmentで抑えるのはできるが、 アンダー気味で持ってくと予想を越えられない可能性が高いだろう。 また、監督の予想する演技というのは、その役者が過去にやった 仕事とかオーディションでの演技を元にしたものであることが多いだろうから、 まだ誰も発見していない側面を出したいと思うなら、やっぱり リハーサルの最初の一発でそれを見せられるように準備しておかねば ならないだろう。そこらへんで舞台と違うアプローチが必要なようだ。
(もしこの知見が正しいとしたら、カメラの演技しか経験しないことは 役者の成長にとって不利だといえる。その役者が天性の勘で上を目指さない限り、 "good enough" 以上のものを求められないからだ。)
Tag: 芝居
2005/06/06
真偽の程は定かではないが、かつて忍びの者は人並み外れた跳躍力を得るために、 成長の速い木の苗を植えその上を毎日跳び越えたという。木は一日一日、目に 見えぬほど少しづつ成長し、それに伴って訓練者は知らぬうちに少しづつ 高く跳躍することを強いられる。ふと気づけば見上げるほどに成長した木さえも 跳び越せるようになっている、という。
かねてより私は子を育てる親にも同様の原理が働いてしかるべきではないかと 考えていた。すなわち、産まれたばかりの、3kg少々の赤子を「ひょい」と 抱きあげるのは造作もないことである。親ともなれば毎日いちいち数えていられない くらい赤子を抱きあげる。そして赤子は一日一日、着実に成長してゆく。さすれば 1年2年と経つうちに、親は知らぬうちに20kgの荷物を「ひょい」と 持ち上げられるようになっていて然るべきではなかろうか。
この疑問は実地検証によっていともたやすく覆された。子供の成長速度は、 親の筋力の増強速度を確実に上回っているのであった。
Tag: 生活
2005/05/15
あちこちで話題の「コード読みのコード知らず」。自分の感覚で言えば、 OSSのコード書きは芝居の役者だな。自分でやってるプロジェクトの場合は 作・演出を兼ねてる。
役者が居ないと芝居は始まらないが、もひとつ芝居に不可欠なのは観客だ。 (あと、街頭パフォーマンスのようなものを除くなら、スタッフも)。 役者の役割は全体の何割、スタッフは何割、 観客は何割、なんていう分析はできない。
役者が観客の批評に対して「演技もできない人に口を出されたくない」 というのはおかしいわな。なんのために客に見せてるんだってことになる。 一方観客の方も、口を出すのは自由だけど、それが舞台に反映されなかったからって 文句を言うのは筋違いだわな。 双方のより良いものを(創りたい|観たい)との思いが噛み合った時にのみ、 みんなが得をする。そうでなければ誰も得をしない。
OSSでは観客=ユーザ。自分流の「プログラマの定義」を 「人に使ってもらえるプログラムを書く人」としているのはそういうわけ。
Tags: OpenSource, 芝居
2005/05/14
へぇ。米国での経験では、宣伝媒体に出演する場合、たとえエキストラであっても 「宣伝期間が終了するか、クライアントから了承を受けない限り、 直接競合する他者の宣伝媒体には出演しない」という書類にサインさせられる。
もっとも契約はケースバイケースなので、実際の契約を知らない外野が 個々の事例についてとやかくは言えない。
Tag: 芝居
2005/05/11
64bit なシステムで、64bit 浮動小数点数を即値で扱うとしたら、 どういうふうにして浮動小数点数を区別するのが適切か?
おそらく、(Fixnum が 63bit 整数であるのと同様に) 64bit よりもちょっと小さい浮動小数点を定義することになる。 たぶん指数を削るのが適切だと思うが、他の選択肢はあるか?
「浮動小数点数でNaNになるビットパターンに他の型のオブジェクトを詰め込む」 というLisp処理系があったはず。実装したのはFritz Kunze (Franz Inc.の社長)。 Fritzから聞いたところによれば、浮動小数点数の性能は格段に向上したが、 非常に稀な確率で演算結果が別の型のビットパターンになってしまう可能性が あって使えなかったそうだ (ここんとこ、具体的な話は聞かなかったんだけど)。
ネイティブコンパイラを持つ現在のCL処理系では、型をちゃんとdeclareしとけば コンパイラがboxing/unboxingを避けるコードを出してくれる。 でもインタプリタでうまくやる方法は知らない。 VM上に浮動小数点数レジスタを持っておくなんてことをちらりと考えたんだけど、 継続やクロージャ作成に伴うコンテキストの保存がとても面倒になりそうなんで 試してない。
Tags: Programming, Lisp
Comments (4)