2014-02

2014-02-02 

Death Gothic Doom

先週リリースしたアルバムの事を全然紹介していないので、ちょっとだけ紹介する。俺としてはあんまり自分の作品についてあれこれ解説したくないクチなのだが、まあせっかくの1stアルバムだし、ちょっとアルバムの作られた背景について解説してみようかと。個別の楽曲に付いては昨日のツイートを参考に。

このプロジェクトはそもそも自分で聴くようの音楽、つまりあまり供給がなくてかつ自分で聴きたいような音楽を作ろうと思って始めたのが発端であった。Djent系プログレッシブメタルとかメロディックデスメタルとかそういうのは普通に供給があるので、むしろやってる人の少なめな音楽、即ち90年代初頭のデス・ドゥーム〜黎明期のゴシックメタルに焦点を当てようと思ったのが切っ掛けだった。

去年の10月末に"Desecration"のデモ版をsoundcloudで公開したのがこのプロジェクトの最初の活動だったが、その時点で既に他の曲のアイディアはあって、具体的には"The Blind Leading the Blind", "Angel's Bane", "My Vengeful Dream"といった曲を書き始めていたし、残りの曲も構想は概ねあった。その時点で構想になかった曲は"Vestiges of Despair"だけだったと記憶している。それらの曲の中には今回収録しなかった曲も含まれているが、それらもいずれ何らかの形で公開するつもりだ。

作曲自体は去年の12月の時点でほぼ終わっており、あとは録音してミックスしてマスタリングしてといったところだったが、まあ大変だった。これまでも単発の曲をそうして公開してきたことはあったが、8曲も一気に仕上げる作業は当然初めての経験だった。曲ごとに極端に音質が変わったりしないように、でも画一的にならないように気を配らねばならず、自分でもこの点はできているかどうかあまり自信はない。仕事が忙しくなったのでヴォーカルトラックの録音が先月の半ばまでかかってしまい、最終的なリリースが先月末だったのだが、多分収録曲数を増やしたりとかもっと作り込んだりとかしていたらリリースできなかったんじゃないかとか思っている。

そんなこんなでできたのがこの"Death Gothic Doom"だが、まあタイトルの通りである。デスメタルの禍々しさ、ゴシックメタルの陰鬱さ、ドゥームメタルの重々しさをミックスした音楽であり、要するに日本に市場があるとは到底思えない音楽である。というかデス・ドゥームという音楽は世界的にも廃れているような状況で、何故かというと、

などと別の音楽に発展解消しており、もっといえばメロディで抑揚を付けにくい上にテンポの縛りもある本来のデス・ドゥームは手法的に行き詰まりがちで、伝説的なデス・ドゥームバンドのWinterはアルバムとミニアルバムを1枚出して解散している他、Paradise Lostを筆頭としたPeaceville勢はゴシックメタルを築き上げたり、Katatoniaのように最終的にオルタナティブ・メタルになったりした。実際俺のアルバムも中身をよくよく見てみれば本来の意味でデス・ドゥームと言えるのは多分"Desecration", "The Blind Leading the Blind", "Chosen Misery"ぐらいだろう。

そういうわけでもしも次があるとしても本来の意味でのデス・ドゥームになるかは不明だったりする。

2014-02-03 

JavaFXはprismによるハードウェアアクセラレーションが有効な状態では、可視な状態でプロセスに存在できるCanvasのサイズに上限がある。この上限は単一のキャンバスの大きさというだけでなく、例えばそれなりの大きさのキャンバスを複数枚みたいな作り方をしても引っかかる。以下のコード片を動かしてみればわかるはず。

for (int i = 0; i < 8; i++) {
  Canvas c = new Canvas(4096, 2160);
  grp.getChildren().add(c);
  c.getGraphicsContext2D()...;// 何か適当に描画
}

得に何も設定をいじっていない場合、grpをセットしたSceneがレンダリングされている間にcom.sun.javafx.sg.prism.NGCanvasでNullPointerExceptionが発生して死ぬはず。ちなみに8回ではなく7回にしたり、あるいはsetVisible(false)でいくつかを不可視にすると問題なく動作するはず。

どういうことかというと、デフォルトの状態ではJavaFXというかprismエンジンはキャンバス用のメモリを256 * 1024 * 1024バイトまでしか確保しない。もっともそれだけ確保すれば普通のソフトウェアでは十分と言えばそうだが、業種・業務によっては巨大なモニタにそこそこ込み入ったオブジェクトを描画する必要があり、そのためにレイヤーを分けて描画していてなおかつ作りがちょいとタコだとその制限にブチ当たる可能性が出てくる。JavaFXは普通メモリをキャンバスのサイズ * 4で確保するので、先の例では4096 * 2160 * 8 * 4で283115520となり、これは1024 * 1024 * 256=268435456を上回る。

一応これはシステムプロパティのprism.maxvramで設定を変えることが可能だが、そもそもこの制限にブチ当たるような作りは大抵の場合設計に問題があるのでそこを直した方が良い。例えば分割する必要のないレイヤーは分割しない、タブのようなUIで切り替える場合など、ユーザーに見せないオブジェクトはsetVisible(false)を設定するなど。

この辺はcom.sun以下のソースコードを読んで発見したが、どっかに情報がまとまってないかね。ざっと調べた限りじゃ見つからなかった。

2014-02-10 

Scream Out Fest 2014に行ってきた。当然目当てはPeripheryだったが、そのPeripheryが想像以上に凄くて大満足。いや、他のバンドも健闘していたし、The Word Aliveなんて前に音だけ聴いたときは好みからちょっと外れるかなあと思っていたのがライブ見たらかなり楽しめたのが収穫だったりしたんだが、やっぱ他がスクリーモやメタルコアやってるなかでプログレメタルやってるバンドが出てきたら、そりゃ演奏力が違いすぎるわけでねえ。そんなバンドが中間に出ちゃダメだろう。ヘッドライナーでもないのにアンコールが巻き起こったあたりでその盛り上がりはわかるだろうというか、あの後に出たFear, And Loathing in Las VegasとThe Devil Wears Pradaはたまったもんじゃないよなあ。

それでPeripheryのライブだが、まず目が釘付けになったのはドラムのMattで、CD音源の時点で怒涛のドラミングだったがライブで見るとさらに圧巻というか、超シンプルなセットからあれだけ芳醇なビートを叩き出せるのは紛う事なき変態。そこにトリプルギター+ベースギターの轟音が乗るのにメロディの輪郭が潰れずリードギターがしっかり聴き取れるあたりでアンサンブルの構築能力の差が他のバンドとあり過ぎた。(他はリードギターが聴き取りにくい場面が多かった。)

あとライブで実際に見てみると案外Mishaのワンマン体制ではないというか、むしろリードギターは結構な部分でMarkが中心になっていた感じだった。厳密にはテクニカルなソロ、テーマのメロディ、エフェクトをかけた特殊サウンドなどなどを分担している感じで、確かにバッキングのサウンドを薄くせずに多彩なギターワークをライブで再現するにはトリプルギターは合理的だ。ちなみにそのMarkは写真で見ると単なるオタクにしか見えないのにライブだとえらい格好良くてビックリ。というかMisha、開幕でいきなりMarkにキス→Markがお返しとかやってたんだけどあいつら本当に仲いいな。

Spencerは時折フェイクを使ってはいたものの概ねヴォーカルラインを崩さずに歌っていて、スクリームから一般的なテノールの最高音を越える高音までライブでもしっかり歌えていた。Peripheryって活動開始自体は2005年と結構前なんだけどデビュー作を出したのは2010年で、その理由の一つはずっとヴォーカルを探していたんだとか。確かにアンダーグラウンドでこんだけ歌えて音楽性にマッチするヴォーカルを見つけるのは大変だったろうな。

セットリストは以下の通り。

  1. Muramasa
  2. Ragnarok
  3. Scarlet
  4. Have A Blast
  5. Jetpacks Was Yes!
  6. Face Palm Mute
  7. Make Total Destroy
  8. Masamune
  9. Icarus Lives!

2ndの曲を中心に、1stの代表曲といっていい2曲を追加した感じ。他にも聴きたい曲はあったが、まあフェスなんで。最新ミニアルバムのClearの曲はやらなかったが、そもそもあれメンバーそれぞれが自由に作った曲を集めた企画盤みたいなもんで、曲によってはメンバーが演奏してなかったりするんで、やっぱこういう場での優先順位は低いのだろう。しかしこれは単独公演のチケットを取り損ねたのが悔やまれるな。

やはりハイライトはちょうどショウの半ばに配置されたJetpacks Was Yes!で、この曲はヴォーカルもギターもメロディが本当に美しく、Spencerの高音ロングトーンから繋がるMishaのギターソロは間違いなく現時点での彼のベストソロだろう。

ちなみに同系統の曲のErisedも大変な名曲だが、この曲のギターソロはJohn Petrucciがゲストで弾いているのでライブでやるのは難しいか。それにしても曲の後半、サウンドエフェクト(というかエフェクトかけたギター?)+Mattのドラムソロ→JPのギターソロの流れは圧巻。アルバムだとそこからシームレスにエレクトロな小品のEpochに完璧な形で繋がり、むしろSpencerのヴォーカル中心の前半+ドラムソロとJPのソロの中盤+Epochの3部構成で1曲というのがあるべき姿だったんじゃないのかなあと思ったりも。

Passengerは元は別プロジェクトのHaunted Shoresで発表された曲だが、これはPeripheryのライブでもやって欲しい。いや元はHaunted Shores用のScarletもライブでやってるわけだしさ。

あー、本格的にPeripheryの事しか書いてない。

2014-02-15 

仕事がクソ忙しい事もあってろくに日記の更新ができていない。ってかやっぱり俺はSIerに向いてないんじゃないか。

まあそれはともかく、ちょっとbandcampの料金体系について書く。これは購入者側には一切関係なく、bandcampで楽曲を売る側とbandcampの間の話。(いやbandcampの手数料が購入者側にかかると思っていた残念な理解力の人がいたんで、一応。)

この手のDL販売サービスのビジネスモデルは、死ぬほど大雑把に分けると以下の二つになる。

作品を配信するのに金がかかるタイプ
Amazon MP3とかCD Baby、tunecoreなどはこれ。事業者側はとりあえず収益になるし、売る側としても大ヒットすれば最初にかかった以上の金はかからない。一方で全然売れないと赤字。
売上から一定の手数料が差し引かれるタイプ
いわゆるレベニューシェア。bandcampはこれ。全然売れなくても赤字にはならないが、大ヒット時には前述のタイプよりは儲けが少なくなる。

bandcampでは売上があがる度に売上金額の15%(DL販売の場合)が未払い手数料としてチャージされていく。例えば10ドルのアルバムが売れたら1.5ドルがチャージされ、もう1DLで合計3ドルといった形。このチャージされた未払い手数料が1回あたりの取引額を上回った場合、その時の売上はミュージシャン側ではなくbandcamp側に行くことになる。例えばアルバムを7DLほど売ればチャージ金額は10.5ドルなので次の売上は全額bandcampに行ってチャージ金額は0.5ドルに減少する。個別の売上に手数料がかかるのではなく、ある程度売れてから差っ引かれるというのがポイントだ。

これが例えばtunecoreだと、1年間アルバム1枚を配信するのに4,980円かかる。CD Babyは49ドルだがこちらは期限は特にないのかな。仮にアルバムを10ドルで売るとして、bandcampよりもCD Babyなどの方が得になるのは33枚売れてからだが、ろくにプロモーションもできない超どマイナーな自主制作ミュージシャンがそんなにアルバム売るのって大変ですよあなた。俺のアルバムなんて未だに片手で数えられるほどしか売れてないからな。ついでに書いておくと、俺は7ドルでアルバムを売っているのでCD Babyの方が得になるための枚数はもっと多い。

こうして考えると、bandcampの方が概ねマイナーミュージシャンには優しいだろうな。CD BabyなどはiTunesや7digitalなど他のサービスと連携したりもしているが、俺に限って言えばクソみたいなリージョン制限を設けるようなスカム野郎の運営してるサービスで自分の曲を配信したくないので、別にその点はメリットに感じない。

2014-02-21 

前にも書いたが、JavaFXは(特に8からは)いろいろと便利な機能があるし、見てくれも割と良いし、描画スレッドが独立して多少パフォーマンスは良くなったし、Swingなんかよりは好きなGUIライブラリなのだが(MVPやMVVMで作るには理に適っていると思う)、しかしこれでミッションクリティカルな業務アプリを作りたいかと言われるとそれは別というか。いやまだ全然足りてないでしょ、機能も安定性もドキュメントも。特にドキュメントの欠如はかなり致命的で、PerformanceTrackerやPulseLoggerの使い方とかJavaFXのVRAM容量の設定みたいな情報、俺が最悪の場合はJavaFXのソース読んだりして発見してたからな。というか世界的にその辺のパブリックな情報が未だに無く、どうも俺しかその辺の詳細を書いてない。そりゃ普通に考えりゃ使えんわ。

その辺目を瞑ってGUIライブラリとしての機能性をみると、未だにメッセージボックスが標準で用意されてない辺りからいろいろ察してほしい。いや便利なコントロール類もあるにはあるが、探してみれば粗がある。Sceneのキャプチャ画像が簡単に取得できるのは良いのだが、ウィンドウ(Stage)の装飾まで含めたキャプチャは取得できず、その辺を取得するにはAWTに頼らねばならないのが辛い。またLinuxでCompizが有効な状態ではウィンドウの装飾がキャプチャできないので、そのような環境では潔く諦めるか、あるいはStageの装飾をUNDECORATEDにしてUndecoratorのようなやり方で自前の装飾を作るというハックが必要になる。AWTのfuckな部分とJavaFXのsuckな部分が合わさるとこうも不快な思いをすることになる。

他にもバグが結構多いというか、例えばアイコン化したStageをtoBackで背面に送らずにそのStage上のコンポーネントを更新していると、異様な回数のGCが発生する。回避にはtoBack呼べば良いだけなので、そうなってしまう理由は調べていない。またそうなる詳細な条件も調べていない。FXMLでSplitPaneを使って画面を半分に分割しようとすると綺麗に分割されない事があったり、Stageをhideした状態でコンポーネントを更新するとよくわからん挙動を見せたり、ある程度仕方がないとはいえ結局OS毎に全然挙動が違ったり、何というかいい加減にしろよと言いたくなることが多い。ブチ当たった不具合の半分ぐらいは仕様かもしれんが、ドキュメントがアレなのでよくわからない。

あとこれを持ち出すのはアンフェアかもしれんが、com.sun.glass.ui.Robotで画面キャプチャが取れないのは一体何の冗談なんだ。マウスクリックなんかは普通に動くのに。いやそんなもん使う方が悪いといえばそうだが、だったらjavafxパッケージの方をもっとどうにかしてくれよ。

2014-02-26 

んー、まだ確定的な事がわかっているわけではないが、JavaFXをハードウェアアクセラレーションが有効な状態で動かしている場合、例えばアプリケーションスレッドで物凄い高頻度でコンポーネントを更新したり、あるいはめちゃくちゃ時間のかかる描画処理の最中にコンポーネントの更新を何度も行ったりすると、レンダージョブすら作られずにレンダースレッドの処理がスタックする模様。検証コードは面倒なので載せないが、800x800ぐらいの領域に小さい矩形を数万個並べて1ms間隔で回転させるみたいなプログラムで際限は可能。

pulseすら発生していないのでおかしいなと思ってJavaFXのソースを読んだが、Pulse Loggerはログの内容をバッファに溜め込んで描画処理終了時に書き出すというやり方でログを吐いているので、普段なら頼りになるPulse Loggerがまったく使い物にならない。ソース読んで解析したところ、レンダージョブ自体はThreadPoolExecutorとして実装されていて、それ自体はリフレクション経由でJavaFXのToolkitから取ってこれる。レンダージョブすら作られないというのはそのスレッドプールの状態を監視して発覚した事だが、具体的にどこでスタックしていてどうすれば確実に回避できるかはまだわかっていない。

ちとヒューリスティックな解決方法なのであまり好みではないが、レンダースレッドがスタックしないようにコンポーネントの更新タイミングを変えるのが多分一番手っ取り早い。現状で問題になっているのはクソ重い初期化処理の最中に別のスレッドが処理を始め、それがアプリケーションスレッドに制御を渡してコンポーネントの更新というところなので、そこで初期化処理中にウェイトをかけてコンポーネントの更新だけを一旦スキップすれば問題はないはず。画面の更新終了タイミングがjavafxパッケージ以下のAPIでわかるのなら、それをトリガーにコンポーネントの更新再開でいいのだが、あいにくcom.sun以下のPerformanceTrackerでしかわからないので、本番のアプリでそれを使うのはいろいろと問題がある。

2014-02-27 

昨日のちょっとした続き。描画処理がスタックしたあたりでスレッドダンプを取ってみたら、どうもJavaFXがレンダージョブの同期を取るところが問題だった模様。JavaFXはWindowオブジェクトの数だけCountDownLatchに値を設定してそれで同期を取っているのだが、描画処理がスタックしてる状態ではどうもそのCountDownLatchがいつまでも0にならないのか、そこで処理が止まっているようだ。この辺はまあ例によってリフレクションで状態を見られそうなので、気合でデバッグできなくもないかもしれない。

あとこれLinux環境特有なのかアプリの作りか分からんが、Popupをそこそこの頻度で生成しても発生して、しかもPopupはWindowオブジェクトのため生成プロセスがアプリケーションの立ち上げと概ね同じなせいか、そこで固まるとアプリケーションごと、最悪ウィンドウマネージャーを巻き添えにしてハングして、なんというかもう全面的にダメ過ぎる。こりゃミッションクリティカルな業務には無理と判断されても文句はいえんだろう。

2014-02-28 

昨日書いたアレ、事情がわかった。JavaFXをPulseLoggerを有効にして走らせて、それでウィンドウ操作でスタックした場合にPulseLoggerの状態が不正な状態になり、PulseLoggerがNullPointerExceptionで死ぬ→レンダージョブが死ぬ→いつまで経ってもCountDownLatchが減らないという流れでのハングだった模様。ウィンドウの生成プロセスは多分関係ないが、ウィンドウ操作に起因して処理がスタックした場合、多分JavaFXだけの管轄ではない部分が巻き添え喰らってハングするので、プロセスまるごととかで固まるんだろう。

というわけで、PulseLoggerの設定を切るとアプリケーションそのものが固まる問題は回避できる。レンダージョブがスタックする問題はそれとはまた別なので、まあこっちはそんな負荷かけるなで落ち着きそうではある。