好きになったクリエータは夭逝するという話

この世を去った、大好きなクリエーターたち

　いいなぁと思った作品の作者であるアーティスト、クリエータの訃報のニュースを聞く、という機会がよくある。

　パッと思いつくだけでも、

・梅本竜（コンポーザー）
・モンティ オウム（RWBYの生みの親）
・近藤喜文（耳をすませば 監督）
・G.Bruno / Aqualtra（アーティスト）
・Scatman John（アーティスト）
・Saki Kaskas（コンポーザー）

　などなど、挙げればいろいろ出てくる。

　根拠など無く「たまたま」なのは明白だが、僕が好きになったら死ぬのか！？とさえ感じてしまうほど、そのような結末に巡り逢ってきた。いいなぁ、今何やってるんだろう、からの検索結果は結構堪えるもので、彼らの新たな「作品」をもう観れない、聴けない、と思うと虚しさを感じてしまったりする。

DAWにおけるSMT（HTT）有効無効の話

オーディオを処理するとはどういうことか

　今回の話に「だからこうだ」というように結論づけるものはないのだけど、言及している記事が見つからなかったので書きなぐっておく。

　オーディオのリアルタイム処理というのは、いわゆるベンチマークソフトでスコアの大小を競う、というような時間制約のない処理とは事情が異なる。

　動画のエンコードや3Dレンダリングのような時間制約のない処理は、8スレッド16スレッド32スレッドと処理を並列化（複数人で分担作業する）することで、プロセッサ全体における時間単位のスループットが上がり、結果的に処理能力が向上するというのは直観的でわかりやすい話だ。

▲ AIDA64のCPUベンチマークの例。並列で処理するユニット数、スレッド数が多いほど（クロックも高いほど）スループットは上がりスコアが上昇する。

　対して、DAWやオーディオ機器のCPU、DSPといったデジタルオーディオのリアルタイム処理においては、入力されたデジタル信号を1sampleごとに加工して出力するという処理を連続的かつ、リアルタイムに行う都合上、いわば制限時間のようなものがある。

　どういうことかというと、サンプリング周波数（FS）が48kHzのばあいは単純に1sampleを1/48000秒以内に処理する。0.2msecの処理を1秒間に48000回繰り返してバッファに出力している。遅延しうる要因はいろいろあれど、これが遅延してしまうと0.2msという枠から溢れ、出す音声がなくなってしまって、「ブツッ」とディップが発生して音が切れることになる。フィルタ処理やらリバーブなどの畳み込みやら処理が増えるとさらに計算に要する時間が増え、この枠内での処理時間のマージンは減っていく。

▲ 音の時間波形をSampleレベルに拡大したもの

　CPUにはオーディオ処理以外にリソースを食う様々な割り込み処理（OSのカーネルだったり、Chromeでネットを見るだったり未知の割り込み）が発生するから、処理した音声をそのまま出力するようなことはせず、一旦サンプルバッファにためた音声をストリーミング出力するわけだけど、バッファサイズが大きければ当然レイテンシは増え、バッファサイズが小さければ空になるリスクが高くなる。入力に対する遅延を軽減したければバッファサンプル数を減らすことになるが、そうなれば音はブツブツと切れてしまうリスクが高まることになる。リアルタイムオーディオ処理は「いかに途切れさせないか」という細かい制限時間の連続と、バッファのバランスで動いている。

インパルスってなんだ？サウンドクリエータから見たインパルス応答（IR）

インパルス信号とは

　電磁気学や音響工学などの教科書によく書かれている「インパルス信号」。時間幅が0で高さ無限大のパルス信号のことを言う。

▲ 理想的なインパルス信号

　ただ、僕らが扱っているデジタルオーディオは必ず信号をサンプリング周波数に基づいて時間サンプリングしていて、信号の大小を記録しているので、「時間幅0で周波数的な情報を持つ」はありえない。レベルも16bit 24bitのように表現可能なレベル幅に上限がある。

　デジタルオーディオにおけるインパルス信号では、1サンプル目で最小→最大、2サンプル目で最大→最小に遷移する2sampleの信号のことを便宜的に言う。

▲ 行って帰ってくるまでがインパルス

　つまり、Fs=48kHzのインパルスと、Fs=96kHzのインパルスでは、後者の方が秒間2倍サンプリングされているので幅が1/2になる。アナログの場合このサンプリングという考えがない（常に連続）ので幅が0に近似する。インパルス信号はサンプリング周波数（fs）に依存する。

2代目「干瓢うぉっち」

ごあいさつ

　新ブログの記念すべき第一回目。

　今回は特に話題は用意しておらず、簡単な挨拶と言うことで。

　どうぞよろしくお願いします。

前身の「初代 干瓢ニッキ」

kanpyo.hatenadiary.org

　前身である「干瓢ニッキ」にて最後にブログ記事を書いたのが3Dアニメーションの「RWBY」に感銘を受けた時の話で、もう4年も前の話になる。随分と間が開いてしまった。

　「干瓢ニッキ」自体は大学生のころ、それまでWebサイトのトップページにHTML直で書いていた日記の管理がめんどくさくなったのがきっかけで、ブログに移行したのが始まり。14年前だ。名前も当時てきとうに決めたものだ。

▲ 前ブログの初稿。やる気ないけど文豪だなんだぜ・・・みたいな斜に構え感はやっちゃう

　特に何か目的を持って書き綴っていたわけではなく、１週間に１回程度の頻度で思うことを主観多めでダラダラ書く、まさに日記的立ち位置から始まった。14年以上経った今、改めて見ると奇声を発したくなるような痛い記事も多めである。やんちゃって怖い。

　記事投稿が激減したのは2010年ごろにTwitterを始めたタイミングだろうか。手軽さゆえ、即時的な雑談話はTwitterが肩代わりし、そのような記事は殆どなくなった。ニコニコ動画に楽曲をアップした時や、イベントに参加した際の告知など、何かイベントごとがあった時の告知のついで、というような記事が半数を占めていたわけだが、その機会も次第に減って、いつしか「干瓢ニッキを維持する」という半義務的なノルマ感のみが残った。

　そしてモチベーションも自然消滅し、結局書かなくなって今に至る。

本ブログ 立ち上げの目的

　仕事の報告書や説明資料などで長文を書くことはあっても、自分の思うがままに長文を書く機会というのは殆ど無くなってしまった。長文を書けない状況に「まぁしゃーねぇか」と思いつつもどこか燻るようなもやもやした気持ちがずっと続いており、目的を持ったログとして長文を書くという行為をまたやりたいと思ったのが切っ掛けである。

　他の発信の場としてはTwitterがあるが、Twitterでは140字という文字数制限がある。僕の場合下書きの段階で140字を超えることが多く、その都度添削して文字数を減らしてからツイートをするわけだけど、結局長文を書きたいのだなと思う。しかし僕には長文を書く場というのは「干瓢ニッキ」しかない。

　とはいえ、荒廃してよくわかんなくなってしまった「干瓢ニッキ」の延長として仕切りなおしで書くのもなんだかぶれていて書きづらいし、かといって数百日というエントリーを整理するのも気が遠くなる。

　ということもあって、今度は自分なりの「目的」をもって新しく始めようと思い立ち、この有様だ。

　社会人になって、10数年余。ハードウェアエンジニア、サウンドエンジニア、サウンドクリエータ（現職）と様々な経験をして、今でも元気に音屋をやってる。と、学生時代に夢想していた自分に報告しておく。

今後について

　今後は特にノルマを設けることはせず、自分の音楽の話、レビュー、エンジニア/クリエータ観点での技術的な話を中心にログを残していくつもりだ。身の内にまつわる甘口話から、ググってもあまり出てこないような音響技術や信号処理など突っ込んだ話まで、浅い話を深く掘り下げたいと思っている。

　仕事や趣味で都度思うことも沸いては（Twitterで話すことじゃないななどと思いながら）発散することなく霧散する、を繰り返してきたわけだけど、それら情報資産が誰かの役に立てばいいなと思いつつ。