Subscribed unsubscribe Subscribe Subscribe

黄金時代のような音楽を再現するには何が必要か?

www.youtube.com
このCMを見ながら一般的にアメリカにおけるポピュラー音楽の黄金時代といえば1950年代で、って話をし始めたら、物凄い嫌がられたのだが、これは1940年の映画だったね失礼*1。ってことはビバップ以前だな。
大体1900年代初頭からユダヤ人の音楽家たちが始めたのがアメリカのポピュラーミュージックだろう。今でも思うんだけど、お金がかかっているなあと思うのは、ストリングスやオーケストラが入っている音楽という気がする。結局は人件費だね(笑)。
フィルスペクターや大滝詠一じゃないけど、何度もリハを繰り返して、一発録りってのが一番手間暇かかるし、それを普通にやってた時代の方がお金があるだけに、いい音楽にはなるとは思う。意外といい音楽を作るためにはお金も重要です!アイデアだけだと個人の思い込みと紙一重なので、物凄く才能がある人以外はあんまりいいことないと思う。
で、だんだん皆さんに反感を買うようなことを言い始めそうなのでこの辺で。同じピノキオの映画から誰もが知ってるこの曲を。

Disney's "Pinocchio" - When You Wish Upon a Star
そういえば寝る前に聴く音楽ってのを新しく作る人ってあんまりいないよね。単なるアンビエントじゃなくて、こういう歌入りの。

*1:誰に対して言ってるのかわからないが

冬に不安定な気分になるためのレゲエ

pressuresounds.bandcamp.com
pressuresounds.bandcamp.com
フルート奏者!?のDiggory KenrickとPILのJah Wobbleが組んだユニットがニュールーツの10inchを出しているんだね。今時10inchってなかなかないと思うけど、というか昔から10inchはあまりないか。
Bandcampで試聴できるので聞いてみたけど、なんかDub版より普通のVersionの方がエキセントリックな感じがする。フルートとか木琴とかあの辺の音って若干危険な香りがするね。
あとWobbleが組んでいるのに、ベースの音が意外と小さい。

99.95%と99.999%の稼働率の差は意外とでかい。

昨日その手の話をたまたましてたので。

Amazon Web ServicesAWS)に移行するシステムに“聖域”はない。現時点では計画していないものの、勘定系システムをクラウド化する可能性は十分にある」。三菱東京UFJ銀行執行役員である亀田浩樹システム本部長兼システム企画部長(写真)は日経BP社の取材に対してこう話した。

itpro.nikkeibp.co.jp
勘定系システムをAWSに、って言ってるけど、AWSの可用性理解して言ってるのかな?
aws.amazon.com
AWSSLAを見ると大体稼働率99.95%なんだけど、
稼働率 => 月間ダウンタイム計算ツール
計算すりゃわかるけど、年間4時間半落ちても保証なし、ってシステムでしょ。勘定系システムってそんなに止まってもいいものなのかい?この手の奴だと99.999%かそれ以上の稼働率がデフォだと思うんだけど。
これは冗長化してこのSLAだからね。この状況で、インフラではなく、アプリケーションで99.999%以下を目指すように頑張ります!とか言ったらその方がよっぽどコストかかると思うんだけどなあ。
まあ、単なるリップサービスの可能性高いけどね。つか何でプライベートクラウドを構築しないのか全くわからん。実際にはやってるのかもしれないけど。

実際問題として

オンプレミスのインフラに慣れた人が、AWSを使うと、結構よく止まることが気になるらしい。あとやっぱりAWSは最新のインフラ製品ではなかったりもするので、エンプラ系だとちょっと感覚がずれる。

サチモス絶対褒めたくない委員会で思い出したけど

流線形と組んでやってた一十三十一とかあの辺のシティポップスリバイバル的な奴はどうなったんだろう。結構いいなあ、と思ってたんだけど、それほど話題にならないまま現在に至ってる気もする。
www.youtube.com
冨田ラボが確かにあったなーと思いつつも、うーん実際どうなんだろ。先日私が絶賛したOgre You Assholeよりはメジャーかもしれないが、似たようなもんって気もするし、そんなにだよなあ。
隔世遺伝的にsuchmosが出てきて、世代的に一段下のそっちに全部かっさらわれた印象を受ける。
でもリバイバルっていうのも何だな。私にとってシティポップスリバイバルはU.F.O.のJazzin'なんだよな。
特にLoud Minority。
www.youtube.com

OGRE YOU ASSHOLEを観に行った。

なんか書いてないRvもあると思うんだけど、去年のはもはやめんどくさいのでお蔵入りにしようかな。
https://www.instagram.com/p/BQFuM2Gjehj/
言葉にならないくらい良かった #ogreyouasshole
結論を先に書くと、とてもとても良かった。個人の趣味があるので、誰もが好きな音楽というわけでもないだろうが、PV観て興味がある人は、ライブはもっと良いので、是非とも観て欲しいと思う。
元々、この手の、要するに分かりやすく言うと、CANとかゆらゆら帝国とかああ言う音楽は私は大好きなので、まあ私にとって良いのはある意味当然なんだけど、ライブ慣れしたからなのか、盛り上げる箇所のメリハリが上手になっていた。
以前2014年の年末に同じLiquidで観たのだけど、その頃と比べても今回の方がはるかに良かったと思う。なんせ感動して胸につまったくらいである。そんなの滅多にないのに。*1
www.youtube.com
昔から見ているわけではないのだけど、今回はワンコードファンク色がベース的に多くて、あれ、前からそうだったっけ?と思い、アルバム聴きなおしてみると、そんな印象あんまり受けないな。ちょっとAORっぽくはあるけど。ただ、ライブだと装飾が削ぎ落とされるので、ファンクっぽく聞こえるのかなるほど。そこに絡むスネアのダブ処理が印象的だったけど、なかなか聞けないよなこう言う音楽。ライブダブバンドってmuteももうやらないだろうし、他にもあるのかしら?ギターのエフェクトはダブと言うよりもサイケなので、厳密にはライブダブともまた違うんだけどさ。
曲間がほとんどないので、2時間のわりには曲数多かったようにも思ってセットリストを調べてみるとアンコール込みで19曲か。多いね。
ro69.jp
前回のライブでは実はそこまで印象残ってなかったりするのだけど、これならまた近いうちもう一度観たいなあ。ワンマンかツーマンくらいのやつで。

おまけ

一昨年のライブだとこんな感じ。
www.youtube.com
これはNeu!の印象が強すぎるきらいがあるけどね。

*1:因みにその時のライブレビューは書いてなかったようだ。こう言う時もあるので、書いといたほうが確かにいいな。徐々に記憶力がなくなっていることもあるし。

サーバサイドJavaScriptは何故流行することになったか。

どこかで書いたもののリライト。

何故JavaScriptなのか?

JavaScriptがサーバサイドで使われるようになったのは、おそらくWebSocket対応によるC10K問題が現実的になったからだろう。
これは昔から知られている問題で、Apacheのような普通のWebサーバだとスレッド毎にメモリを消費するマルチスレッドモデルだが、スレッドスタックのメモリサイズはサーバ毎に固定のため、コネクションが固定化されるWebSocketモデルでは本当に問題になるのだ。
スタックサイズがどこで決まっているのかというのを具体的にいうと、以下のstacksizeの箇所である。後は、ApacheなどのWebサーバの設定にもあるが。

user$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 2560
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 709
virtual memory (kbytes, -v) unlimited

TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
これを解決するにはイベント駆動型モデルにするしかなく、nginxはそうした問題を解決するためのWebサーバであるが、この上で動作させるには、同様のイベント駆動型言語の方が望ましい。
そのため、サーバサイドでJavaScriptを動作させるというのが流行することになった。

JavaScriptは、ノンプリエンティブマルチタスクという、まるでWindows3.1のようなアーキテクチャで動作しており、10年前には主にクライアント側の性能問題により個人的には酷い目にあった記憶があるが、あれから10年経ち当時非常に苦労したイベント駆動型のメリットが活かせる箇所がついにやってきたということだろう。

因みに、C10K問題は嘘ではなくて、実際スループットが10000tpsを超えると極端に辛くなる。
普通、サーバのボトルネックはCPUやメモリの限界だと思う人が多いだろうがこのレベルになるとそんなことは全然なくて、まずカーネルパラメータのチューニングが必須なのは良いとしても、TCPセッションのNIC引き当てでパケットドロップしたり、メモリのバスネックに引っかかったりする。
大体の場合、NIC周りでどうにもならなくなることが多い。GbE使い切るのは稀。

補足、またはセッション管理時の問題

また、Webサーバだと割とセッション管理を利用することが多いだろうが、セッション情報をノード間レプリケーションを使っていることが多くて、それだとスケールアウトする際に、レプリのリバランスが問題になって、単純スケールアウトほどの性能が出ない。
例えば、10000tps/1台でるサーバだったとして、このような構成だった場合、2台に増やしても20000tpsを捌けることはない。大体15000くらいであろう。勿論更に台数を増やすと、リバランスはどんどん問題になっていく。これを防ぐためには、セッション管理用のメモリDBを別に構築するか、セッション管理を使わなくするというどちらかの方式しかない。このレベルのスループットではL7スイッチは使えない。L7スイッチが使えるのは精々3桁tpsである。
いくらRestfulなAPIだからステートレスだと言っても、認証問題が出てくると、セッション情報を持たざるを得ないであろう。普通、そこまで冗長性のことを考えて、アプリケーション設計できないしね。
ここでも安易にスケールアウトさせることができないC10K問題が問題となり得る。

2017年になりました(もう一ヶ月くらい前に)

fake-jizo.hatenablog.com
1年以上前のこのエントリが伏線なのだが、ついにマカーになったのである。一体いつからPCが壊れていたのかという感じだが、さすがにiPhoneだけでは厳しくなってきた。iPhoneだと決まったサイトしか見なくなるし。
で、困っているのは色々あるのだが、今まで使っていたアプリが使えなくなることである。特に画像管理ソフトをずっと探しているのだが、なかなか見つからない。画像編集なんてする気は無いのだ。単に画像ビューアと削除と移動が簡単に出来ればいいだけで、それ以上のことは求めていない。ただ、trackpadを使いたくないのでキーボードショートカットは使いたい。
私はirfanviewが欲しいだけなのに。かなり難しいようだ。
Lightroomオススメらしいけど、15000円もするのならそりゃ出来るだろ。ふざけんなあほか。
とりあえず試したもの。

PhotoScape X

ファイル削除のショートカットキーが効かない。そもそもファイル移動がない。

ToyViewer

だからファイル編集したいわけじゃないんだよ!というか動く気配がないけど。

Pixy

最初に全ファイル読み込みに行くところがそもそもダメ。

http://photo-mini.com/save-mac-photos-to-external-hdd/
とりあえずこれでローカルのSSDからNASに追い出して対応して見たが、なんか中途半端だなあ...。
副産物として、
https://itunes.apple.com/us/app/photos-duplicate-cleaner/id592704001?mt=12
重複ファイル削除にずっと悩んでいたのだが、凄い役に立った。