最近のベースの練習で向き合っているリズムのオカルトを解き明かしたい

最近、ベースの練習はフィジカル(指が正確に動く)の練習もだけど、それ以上にリズムに向き合う練習をしている。

リズムに関しては、「XXなイメージでリズムを感じるとノリが変わる」みたいな禅問答めいたことを言うひとが非常に多く、そこに対してエンジニアである自分はかねてより不満があった。というのも、音楽を受け取る受け手にとってリズムを成立させるのは奏者のメンタルではなく、発声のタイミングと音高、音量の変化であるはずだからだ。

当然、奏者のメンタルやイメージは奏者の体の動きに影響を与える。なので、「XXなイメージでリズムを感じるとノリが変わる」は一定の正しさがあるだろう。しかし、そこには「イメージが変わる => 発生タイミングや音高、音量が変わる => ノリが変わる」という機序があるはずで、「発声タイミングや音高、音量」をブラックボックスのままにしておくのはとても気持ち悪い。語られるべきは「どのような発声タイミング、音高、音量になるとどのようにノリが変わるか」「そのような発声タイミングや音高、音量を出すためにはどのようなイメージを持つと演奏しやすいか」であるはずで、極端にいえば「そのノリの変化を打ち込みで再現できないのであればそれはオカルトである」と言ってしまってもいいと私は思っている。

で、だ。

よく言われる都市伝説に、「日本人のノリは1,3拍に重心があり、黒人音楽のノリには2,4拍に重心がある」という都市伝説がある。しかし、これについて私の問題意識で読み解いてみると、「重心」ってなんだ? 音高、音量、発声タイミングの言葉で「重心」を説明できなかったらそれはオカルトでは? という話になるわけだ。ベースの練習をする際に、オカルトに飲み込まれてはいけない。そう思い、「重心とは単にアクセントのこと(つまり、2,4拍の音量がでかいということ)である」という仮説を立ててみた。

さらに、James Brownのファンクの秘密として「the ONE」という概念がよく挙げられる。これもよく「一拍目に重心(出た!重心!)を置く」というように言われている(要出典)が、これ、「バックビートに重心を置く」と矛盾してません? という話がある。ここについては、「日本人ノリが1,3拍にアクセントがあるのに対して、黒人音楽ノリは2,4拍にアクセントがある」というのを補助線にすると、「普通は2,4拍だけがアクセントなのだが、1拍目 にも アクセントを置く」ということなのでは? という仮説を立ててみた。

で、これらを検証してみるために、ベースとドラム、完全打ち込み、まったく同じタイミング、音量だけを変え、それぞれ「1,3拍にアクセントがある」「2,4拍にアクセントがある」「1,2,4にアクセントがある(2より4のほうが強い)」という三つのパターンを作ってみた。

soundcloud.com

どうだろうか。かなり「ノリ」が違うと感じられるのではないか。「重心」とか「イメージ」という言葉に包まれ、機序がブラックボックスとして語られがちな「ノリの違い」、実はたんに「どこの音量を上げるか」という話だったのでは? という仮説には一定の説得力があると私は感じた。

ので、「単に1,3にアクセント」「単に2,4にアクセント」「単に1,2,4にアクセント」で実際にベースを弾いてみたのがこちらだ。

soundcloud.com

なんだか打ち込みのときよりもノリ変化が大きい気がする……。おそらく音価や、ドラムに対して前にずれるのか後ろにズレるのかあたりが影響しているのではないかと思うのだけれど、これの機序を解き明かさないことには再現性が望めないので、この機序についてはもう少し研究を重ねてみようと思う。

まとめ

「1,3に重心があるイメージで」とか「2,4に重心があるイメージで」みたいな話は、midi打ち込みを使った実験の結果、単にアクセントをどこに置くのかというふうに読み替えたほうが良さそうだととりあえず結論付けた。the ONEとバックビートの関係についても、「1,2,4にアクセント」がthe ONEの正体だととりあえず結論付けた。音価や前ズレうしろズレがどのようなノリの変化をもたらすのかについてはさらなる探究をしてみようと思う。今後もリズムのオカルトを解き明かしていきたい。

シン・エヴァンゲリオン劇場版:|| 観た

ひとによってネタバレの範囲は異なるし、いつまでネタバレを回避すべきかもというのも明確なラインはないように思うし、情報は受け手がフィルターすべきだと思っているので、受け手がフィルターできるように最初に書いておくけど、直接的なネタバレらしいネタバレは書いてないつもりではあるけど人によってはネタバレだと感じる内容かもしれないので、ネタバレ嫌な人は読まない方がいい文章かもしれません。

それでも構わないひとだけこの先をどうぞ。

続きを読む

年末年始休みでメトロノーム作った

年末年始なので、ふだんなかなかまとまった時間が取れずできないことをやろうと思い、メトロノームアプリケーションを作った。

世の中にはメトロノームアプリは掃いて捨てるほどあるのだけれど、十六分音符や三連符、あるいは六連符でクリックをならせて、しかも任意の場所にアクセントをおける(ポポピポ ポポピポ、だとか、ポポピ ポポピだとか、ポッポピッポ ポッポピッポだとか)メトロノームアプリが見当たらなかった。

こういうことをやりたい場合はメトロノームではなくてリズムマシンアプリとかそういうやつを使わないといけなくて、で、リズムマシンだとこんどは無機質なクリックの音がなかったりする。

こういうメトロノームをバンドのリハでつかいたいんだけどな〜、というのが長年の課題で、なければ作ればいいというわけで作ってみた。

https://groove-partner.netlify.app/

Angular製。技術的に尖ったことはなにもしてないけど、自分にとって新しいことはいくつかあって

  • GithubActionsに触れた
    • 普通のCIという感じだった
    • GITHUB_TOKENがなにもしなくてもセットされててらくちん
    • stepの定義の際、runだけじゃなくてusesが使えるのがなかなか面白い
    • actionをコミュニティがどんどん公開できるあたりもGithubっぽいくておもしろい
  • こういう小さいアプリならば、ディレクトリ構成は凝らずにpresentationdomain(このdomainというのはDDDの文脈でいうドメインレイヤーではなくて、PDSの文脈で言うところのdomainである)で十分ではないかという仮説をたててそうしてみた
    • 結果として成功だったと思う、これくらいのサイズのアプリケーションに対して、無駄に複雑なレイヤーを作る必要はない。十分に見通しがいいし、開発もしやすかった。
  • 同様の理由で、ngrxも利用していない
    • ぶっちゃけ、状態に対するCommandとQueryを意識して、なおかつデータフローを単方向にできる人間だけで開発するぶんにはngrxは必要ないと思っている。が、人間はミスするものだし、そもそも人間が頑張って制約を守るよりも仕組みで制約をつけてしまったほうがいいので、問題のサイズが大きい場合や、チーム開発をする場合にはあったほうがいいという立場です。
  • WebAudioAPIを利用していて、なおかつ音声ファイルを読み込むのではなくて、自分で矩形波を書き込んでいる
    • 矩形波なんて誰にでも作れるんだけど、ファイル読み込みしないぶんシュッと立ち上がるのが気に入っている。スタジオって電波わるかったりするしね
  • 以前ドラムシーケンサーを作ったとき、その目的がDDD-like レイヤードアーキテクチャ(これは一般的な語彙ではない。詳しくは GitHub - Shinpeim/NekogataDrumSequencer を参照のこと)の解説がメインだったため、なるべく他の要素を減らそうとRxJSを利用せずに書いたのだけれど、今回はべつになんの解説のためでもなくて単に自分が欲しいものを作るだけなのでRxJSを普通に利用している(Angularだしね)。RxJSはぜったいあったほうが便利だよね。

妥協してしまった点として

  • UI
    • UIなんもわからん
  • スリープすると音が消える
    • これスマートフォンで再生するばあい致命的なんだけど、まあスタジオにいるときはスマートフォンを給電できるし、スタジオにいる間だけ自動スリープoffにすりゃええやろ、と思ってそのままにしてある。
  • マナーモードだと音が鳴らん
    • これどうすればいいんかな? WebAudioの限界?

以上です。労働ではあまり開発をしなくなってしまったので、久々に開発ができてよかった。

自分で使うために作ったのもなので、リハスタで実際に使ってみながら地味に改善を続けて行けたらいいなと思っている。

2020年音楽活動まとめ

年の瀬なので、毎年恒例の音楽活動まとめをしようと思う。

例年はその年に作ったり関わったりした音源をバーっと紹介していたんだけど、今年は数が多すぎるので印象に残っているものやことをまとめていきたいと思う。

ひとさまの楽曲の編曲、レコーディング、ミックスをやりはじめた

去年もちょいちょいやってたんだけど、今年は本格的にやりはじめた。きっかけは去年の夏にやったバンドのレコーディングで、そのときに

  • 自分のミックスのやり方は大きく間違えているというわけではない
  • 一方でプロの技術とは練度が違いすぎる

というふたつのことがわかった。これがきっかけで「もっと音源制作(楽曲制作ではなく、「音源」の制作)のレベルを上げたい」という気持ちに火がついた。

練度を上がるためにはとにかく試行回数を増やす必要があるが、自分の作った楽曲だけミックスしているだけでは、スループットが「自分で作れる楽曲の数」に律速されることになり、試行回数を稼げない。とくに自分は作詞が苦手なので、そこが一番のボトルネックになっていた。そのため、今年は以下のふたつを新しい活動として始めた。

  • 自分がいろんなひとに曲を書いて、詞はひとにまかせちゃう。それをレコーディング、編曲、ミックスする。
  • 弾き語りミュージシャンを主な対象に、編曲、レコーディング、ミックスを低価格で請ける
    • ありがたいことにリピーターも少しずつ増えている。価格に対して満足してもらえる程度の出来であるということだろう。嬉しい。なお購入した機材やプラギンなどのことを考えると、この活動は赤字です(が、足しになっているので実質勝利である)

バンド活動が充実

メインでやってる「TRIO the CMYK」というバンド(名前が覚えにくいしググラビリティが低い)で、1枚のEPと1枚のシングルをSpotifyなどで配信した。そのうちシングルの方はセルフレコーディングに挑戦したし、EPのほうはSpotifyの公式プレイリストに選出された。

ルフレコーディング

「2DK」という作品をセルフレコーディングした。

open.spotify.com

自分がベーシックトラックをDAWで作って、鍵盤とギターは各自宅録したファイルを送付してもらい、ドラムは最後にスタジオで生録。ミックス、マスタリングも自分が行った。これはめちゃめちゃ勉強になった。

  • ドラムの録音はスタジオ依存がすごいので、ちゃんとそういうスタジオでやらないとミックス時に死ぬ
    • とくに部屋鳴りはどんだけマイキング工夫したところでスタジオの部屋鳴りがやばければどうしようもない
    • 一方でそういうやべえ録音状態を外科手術でなんとかするテクも覚えられたのでこれはこれでよかった
    • 次回セルフレコーディングするならドラムはちゃんと録れる環境を用意することにした。
  • ボーカルに関しても音の入り口がまじで重要。録れ音がカサカサしてたらもうそっから先はディジタルではどうしようもない。これはアナログ機材にこだわる必要がある部分だと思った。
  • 一方ギター、鍵盤、ベースに関してはDAW上の処理でも結構なところまで詰められる。80点までは行けそう。90点目指すならここもアナログ機材にこだわる必要はありそう。
  • ドラムを最後に録ったのはスケジュールの都合だけど、ドラムは全ての要なのでやっぱり最初に録るべきだな〜〜〜〜〜と当たり前のことに気づいた

ルフレコーディングにもかかわらず、この作品もディストリビューターの公式プレイリストに載ったので、セルフレコーディングでも一定のクオリティは満たせている(出してもディストリビューター公式プレイリストに乗らないのもけっこうあるからね)というのは自信に繋がった。

EPのリリース

「太陽と暮らすシトラス」というEPを作った。

open.spotify.com

これはバンドにとって2枚目のスタジオ作EPとなる。前作での反省を活かして

  • リハスタで練習しているときから、実際のレコーディングとおなじクリック(16分音符で「ココカコ」など)を鳴らして練習する
  • アンプじゃなくてラインでしっかり音を作っておく

あたりに注力して準備をしていったおかげで、かなりスムーズにレコーディングも進めることができたし、実際に前作に比べてかなり意図通りの良い作品になったと思っている。その結果として表題曲の「太陽と暮らすシトラス」がSpotify公式プレイリストに選出され、5,000人以上、10,000回以上の再生、原宿の商業施設でBGMとして流れるなどのいい思いをさせてもらえた。今年一番のいい思い出である。

味をしめて、それ以降配信に出すものはバンドのものに限らず必ずSpotifyの公式プレイリスト入りを狙ったリリースをしているのだけれど、まあとにかく全然入らないですね。Spotify公式プレイリスト入りの壁は厚い。曲の問題もあるとは思うんだけど、やっぱりミックスとマスタリングに関して、自分でもわかるくらいに専業プロの仕事と自分の仕事に差があることもたしかなので、ここを埋めるべく努力したい。

なお、Spotify公式プレイリストに入ってたくさん再生していただけたところで売り上げはリハスタ代2回ぶん程度のものであった。Spotify上での再生数は公開されているので、専業プロの作品を見ては「この作品、Spotifyでの売り上げはn円くらいか……」ということを考えるようになってしまった。われわれTRIO the CMYKは全員、音楽以外の本業の仕事を持っているバンドなので、趣味としてやっていくぶんには十分にありがたい話というか、聴いていただけるというだけでうれしいだけど、専業プロはほんとうに大変だと思う。みんな、応援しているミュージシャンにはじゃぶじゃぶ金を落として、ミュージシャンがビジネスじゃなくて音楽に集中できる環境を守っていこうな。

ユニット活動も充実

音楽仲間のつるえさんといっしょにやっている「錦玉もなか」の活動も、結構充実していたと思う。tmrr recordsから、Spotifyなどに3枚のシングルを配信した。

open.spotify.com

open.spotify.com

open.spotify.com

「雨にブランケット」という楽曲は自分としてはかなり気に入っているのだけれど、このリリースをしたときにはまだまだミックスのレベルが低くて、「今だったらもっと」という気持ちになる。けどつるえさんの歌が本当に素晴らしくて、自分のやりたい音楽をこうやって一緒に、しかも自分にできないこと(歌のことです)をやってくれるひとがいるというのは本当にありがたいことだなあと思う。

来年の展望

来年は自分の編曲・ミックス・マスタリングでSpotify公式プレイリスト入りを目標としたい。あとは感染症の様子次第だけど、やっぱりバンドでライブがやりたいな。まあこれは人事を尽くして天命を待つしかない類の話なので言っても詮ないことではあるのですが。来年も音楽を楽しむ人生を続けたいと思う。

VPoTになった

この10月から、VPoTという肩書がついた。公式な経緯などは会社のブログのほうに書いたのでそちらを読んでいただきたいのだけれど、こちらは個人の日記なので個人の日記レベルのことを書く。

VPoTになるまでは、テックリードという肩書で、社内を見渡して「あ、ここちょっと自分が入っていった方が物事がうまく進みそうだな」というところに入っていっては手を動かすというようなムーブをしていたのだけれど、冒頭に貼った記事のような経緯で、今は手を動かすことよりも、仕組みづくり、組織構造に起因する問題に対する解決となる構造を作ることなどが主な仕事になった。

じつは、ぼくは今の会社に入るときに明確に「CTOやそれに準ずる仕事はしたくない」と伝えた上で採用してもらっている。なのになぜ心変わりをして、いままたCTO業の一部のようなことをやっているか、ということを今日は書きたい。

そもそも、ぼくがなぜCTOやそれに準ずる仕事はしたくないと考えていたかというと、いままで携わってきた仕事の中で、一度CTO的な業務に挫折しているからだ。過去の仕事の中で、「もうここで自分がCTO業としてなにをやっても、これ以上の改善はできない」となってしまったことがある。メンバーマネジメントはそもそも自分に向いてないしメンバーマネジメントと向き合うと自分の精神がボロボロになってしまうことを学んだ。ならば、と、プロダクトを健全に開発できる構造を作り上げることに専念しようとしてみた。自分の考える問題感に対する解決を生み出すような課題設定はできた。けど、多くのステークホルダーを抱えながらその課題を組織の課題として打ち出しきることができなかった。できることはなんでもやろうとしたし実際に自分ができることはちゃんと全力で取り組み尽くしたとは思っている。そういう意味では「やり切った」のだけれど、成果としては「挫折」と言っていいと思う。プロダクトを成功に導いたとは言えないし……。それはひとえに自分の能力不足であったと思うし、もうその能力不足な自分のせいで様々なひとが笑顔でいられなくなるのをみたくなかった。

それなのにどうしてVPoTのポジションを打診されたときに(「しんぺいがやりたくないって言っていた仕事なのはわかってるのだけど……」とぼくに切り出した副社長が、ものすごく申し訳なさそうな顔をしていたのはちょっと面白かった)もう一度挑戦してみようと思えたのか。それはひとえに「いま自分がすごく恵まれた環境にいる」ということに、周りを見渡して気づいたからだ。

ぼくが入社したあとも会社は拡大を続け、エンジニアの数もとても増えた。そしていま周りを見渡すと、ぼくの入社以前からいるメンバーにも、後から入ってきてくれたメンバーにも、それぞれの得意領域においてぼくなんかよりもよほど優秀なアウトプットをどんどん出してくれるひとがたくさんいる。全体最適を考えたときに自分のやるべきことを再度自分に問い直したら、「じゃあぼくは、このひとたちの素晴らしい力が変な組織的な問題によって正しく機能しないみたいな状態を防ぎ、このひとたちの力が最大限に発揮できるような状態を作ることに尽力したほうがいい」とごく自然に思えた。嘘ごめんちょっと見栄張った。「ぼくがVPoTなんかやってる間に、みんなはエンジニアとしてのスキルをどんどん研ぎ澄ませるのに、ぼくはそれでいいの?」って少し思った。まあ少し思ったのはそれはそうなんだけど、それが気にならないくらいにそのメンバーたちのことは好きだし尊敬してるから、最後にはきちんと納得できた。

そして、エンジニアメンバーだけじゃなくて、部署外や経営陣を見渡してみたときに、「このひとたちに一度も理不尽に否定されたことがない」と気づいた。意見が異なるときにも、見えてるものが異なるときにも、いつでもみんな「しんぺい(さん)が言うならそれはそうなんだろう」から始めてくれていることに気づいた。けどそれは「単に鵜呑みにしてぜんぶ受け入れる」ということではなくて「そうなんだろう」から始めた上で、ぼくに見えていない範囲のことを説明してくれて、その上で一緒に問題解決に動こうとしてくれるひとしか周りにいないことに気づいた。

そういうひとたちが「しんぺいにこの責務を担ってほしい」と言ってくれるのであれば、今度は前回よりも少しはうまくやれるかもしれない。少なくとも、孤独に挫折してくことはないはずだ。このひとたちはぼくを助けてくれるし、ぼくに助けを求めている。そう思えたら、自然と「ぼくがやります」と言えるようになった。嘘ごめんちょっと見栄張った。腹くくるまでかなり時間かかった。かなり時間かかったけど、最後にはしっかり腹くくれた。

あとはやっぱり前CTOのささたつさんの存在はぼくにとっては大きくて、ささたつさんがCTO業の片割れをやってくれるなら、互いに補い合ってやっていけるんじゃないかな、と思えた。じつはぼくがVPoTを引き受けたときにはまだVPoEをだれに頼むから決まってなかったんだけど、ぼくは「ささたつさん以外にいないでしょ」と思っていたし、実際ささたつさんを猛プッシュしすぎて「圧がすごい……」っていわれたりもしたんだけど(笑)、目論見(?)どおりささたつさんがVPoEを引き受けてくれたので、まあこれは結果オーライみたいなところはある。

それと、そーだいさん(id:Soudai)が手伝いに来てくれてることもかなり大きい。そーだいさんの声くらい大きい。そーだいさんはぼくが困ったとき、悩んでるときに組織マネジメントの先輩としてすごく真剣に相談に乗ってくれる。その安心感も、ぼくがVPoTを引き受ける後押しをしてくれた。

というわけで、VPoTを引き受けるときの葛藤について、個人の日記を書いた。完璧にやれる自信なんかないけど、その一方で「今必要とされてる役割」だと思うし、「そして今やるなら自分が適任だ」という自負もある。腹くくったので、「やり切った」となるまでは全力投球しようと思う。

コミュニケーションを成立させることはとてもむずかしい

コミュニケーションが成立するためには、双方の発信器官、受信器官(ここで言う器官というのは身体的な器官のことではなく、「メカニズム」くらいの意味だ)が健全に稼働していることが必要条件となることは言うまでもないことだとおもう。片方の受信器官が壊れていたら、とうぜんもう片方がいくら発信したところでその信号はだれにも届かないまま消えていく。これは逆もまたおなじことが言えて、片方の発信器官が壊れていたら、とうぜんもう片方がいくらがんばって受信したところでそれは理解不能なものになるし、そもそも発信されてないものを受信することはできない。いくら耳をすましていても。

いま、双方の発信器官受信器官が健全に稼働していることをコミュニケーション成立の「必要条件」と言ったけれど、ではこれらの条件はコミュニケーション成立の「十分条件」だろうか? ということを考えてみたいと思う。換言すれば、「双方の発信器官も受信器官も健全に稼働しているが、コミュニケーションが成立しない、ということはありうるか」ということについて考えてみたい。少し考えると、「必要条件ではあるけれど十分条件ではない」ということに気づく。仮に日本語しか解さないひとと、英語しか解さないひとがコミュニケーションをしていることを考える。このとき、片方の日本語というルールを使った発信器官と受信器官は健全に稼働しているし、もう片方の英語というルールを使った発信器官と受信器官は健全に稼働している。だけど、当然日本語と英語ではそのままではコミュニケーションが成立しないことは想像にかたくない。

もうちょっと話を抽象化すると、これは「コミュニケーションが成立するためには、双方が同一の "プロトコル" を使った発信器官,受信器官が健全に稼働している必要がある」となる。「プロトコル」とはコンピュータ用語で「通信のお約束ごと」のことで、たとえば「まずは通信を始めたい側が決められた通りの信号を相手に送ります」「信号を受け取った側は決められたとおりの"受け取ったよ"という意味の信号を送ります」「"受け取ったよ"を受け取った側は、"受け取ったよを受け取ったよ"を発信します」みたいなもので、ソフトウェアエンジニアは、この「プロトコル」に沿った挙動をするソフトウェアを書くことで、自分とは別のところにあるソフトウェアと通信を行います(いまこの文章を読んでいるあなたの使っているソフトウェア(おそらくブラウザでしょう)は、はてなブログのサーバーと、事前に決められたプロトコルに沿って通信しているから、単なる01の羅列をこうして文字列として表示できているわけです)。

翻って、現実のわたしたちはどうでしょうか。同じ日本語を使っているはずなのに、なぜかコミュニケーションがうまくいかない。そういうことが日々おこっています。これは、「日本語」というレベルのプロトコルは同一であったとしても、「その意味解釈のしかた」というレベルでプロトコルが異なっている、と考えることができるのではないでしょうか。具体的な話をすると、ソフトウェアエンジニアの多くは、よく「うーん、できなくはないけどやりたくないですね」とか「うーんそれはかなりめんどくさいですね」という発信を行います。この発信に対して、同じソフトウェアエンジニア同士だと「なるほど、これをやることによって、ソフトウェアの保守性が犠牲になったりして、未来の変更が高コストになってしまうのだな、あるいは、高い負荷に耐えられないようなソフトウェアになってしまったりするのだな」と受信することが多い(当然、すべてのソフトウェアエンジニアがそうだとは言いませんが)のではないでしょうか。ただし、これは発信する側の意味解釈プロトコルと受信する側の意味解釈プロトコルが一致しているため、問題なく意思の疎通ができているだけです。このプロトコルを共有しないひとが受信したら「は? 仕事なのにやりたいやりたくないの話すんの? めんどくさい!?」というふうに受信してもなにひとつおかしくはないでしょう。

かなり極端な例をあげましたが、こういうことは毎日そこらじゅうで起こっています。これは当然のことで、意味解釈のレベルでまったく同じプロトコルでコミュニケーションするなんて原理的に不可能なのです。なぜなら、わたしたちはそれぞれに異なった環境で育ってことなった体験をしてきて、その中でじぶんの認知を育ててきています。まったく同じ経験をするなんてことはできないので、多かれ少なかれ異なったプロトコルでコミュニケーションをしているわけです。当然、その違いには濃淡があり、似たようなプロトコルを使う同士ではコミュニケーション上の齟齬はおきにくいでしょうし、逆に全然似ていないプロトコルを使うもの同士ではコミュニケーションを成り立たせることにとても苦労することでしょう。

異なるプロトコル同士でコミュニケーションを成立させなくて良いのであれば楽なのですが、とうぜん人間ですのでそうは行かないことが多いでしょう。家族でも、職場でも、共通の問題に対して別々の立場の人間が協力して立ち向かわなければならないシチュエーションはたくさんあります。ではそのときに、どうやったら上手にコミュニケーションが成立するのか。とうぜん、最初に互いのプロトコルを知り、揃えていく必要があるわけです。しかし、ここでとても大きな問題にぶつかります。プロトコルを揃えるためには、とうぜんそのためのコミュニケーションが必要です。しかし、そのためのコミュニケーションを成立させるには、やはり共通のプロトコルが必要です。これはたいへんに困ったことで、コミュニケーション・プロトコルの問題を解くためには、コミュニケーション・プロトコルの問題を解決しなければならないという再帰的な構造になっているわけです。

これは困った。どうすればいいのか。

しかし、よく考えてみると、コミュニケーション・プロトコルというのは実は多層になっています。同じ日本語というプロトコルを利用していても、意味解釈のレベルでは異なるプロトコル、という例が良い例ですね。「コミュニケーション・プロトコルの問題を解くためには、コミュニケーション・プロトコルの問題を解決しなければならない」というのは、再帰的な構造ではありますが、無限再起、あるいはデッドロックではなく、何度も再帰していくうちに「同じ日本語」だとか、なんだとか、どこかで共通のプロトコルにぶつかることを期待することはできます(ぶつからないこともあるでしょう)(というか細かい話をすると、ほんとうはぶつかることはなくて、「同一ではないが妥協できるところ」が見つかるだけなのだけれど)。

まとめると、異なるプロトコルをしゃべるもの同士のコミュニケーションがうまくいかないときには、プロトコルを揃えるためのコミュニケーションが必要になるが、そのコミュニケーションにもまたプロトコルを揃える必要が出てきて、ここにはものすごいコストがかかるでしょう。というのが、プロトコルの異なるもの同士がコミュニケーションをするための大きな壁です。

そして、この壁を乗り越えるのを難しくしている要素のひとつとして、「相手とうまくコミュニケーションが成立しない」となったときには、相手の「発信器官」「受信器官」どちらかが壊れているように見える、という問題があると思います。同じプロトコル同士でしゃべるときには自分の発信器官も受信器官もうまく動いているように見えます(どっちかが壊れてたらコミュニケーションが成立しないからとうぜんですね)。さらに、「プロトコルが異なっているからうまくコミュニケーションが成立しない」なのか、「相手が壊れてるからうまく成立しない」なのかは、こちら側からは判断不可能です。両方のプロトコルを理解しているひとがはたからみたら判別可能ですが、両方のプロトコルを理解しているのであればそもそも困ってないわけですからね。そういう理由で、「相手とうまくコミュニケーションが成立しないのは相手の受信器官か発信器官が壊れているせいだ」と結論してしまうのはそう不自然なことではない、とぼくは思います。

そう不自然なことではないけれど、それでは問題は解決しないので、コミュニケーション上の問題が起こったけどそれを解決しないといけないときには、「相手が壊れていることを前提にせず、単にプロトコルが異なっているだけなのだと自分に強く言い聞かせながら、根気強く共通のプロトコルにぶつかるまでプロトコル調整のためのコミュニケーションを繰り返す」ということを双方が行わないとだめなわけですね。それってめちゃめちゃに難しいことだと思う。というわけで、コミュニケーションの成立って、そういうめちゃめちゃに難しいことなんだよ、という共通認識をまずは広く持ちたいなあ、という意図で書かれた文章なのでした。

Logic Pro X のver.10.5 にアップデートしたときにFlexPitchの挙動がおかしいのを直す

TL; DR

設定のリセットをして

f:id:nkgt_chkonk:20200522141952p:plain
設定のリセットをして

スケールクオンタイズをクロマチックにする

f:id:nkgt_chkonk:20200522142517p:plain
スケールクオンタイズをクロマチックにする

LogicのアップデートでFlexPitchの挙動がおかしくなった

Logic をアップデートしたところ、Flex Pitchを使っていると

  • ノートを選択したりノートの外側をクリックするとタイムラインが吹っ飛んで「いまどこ編集してたの」がわからなくなってめっちゃストレス
  • ノートを掴んで移動しようとすると半音単位じゃなくてなんかへんなところで全音で移動したりする。たまに半音で移動してわけわからん

みたいな挙動になってめっちゃストレスでした。twitter検索すると困ってるひとが多そう。これらを直す。

タイムライン吹っ飛び問題

これはtwitter検索してたら「設定のリセットでなおる」という噂があったので「まあそんなにたくさんカスタムしてないし、ためしてみるか」と思って設定をリセットしたら直った。

ノートが全音で動く問題

これはFlexPitchの「スケールクオンタイズ」が悪さをしていて、こいつをクロマチックに設定してやるともとの挙動になった。

困っているひとはためしてみてください。