HTML5でリンクタイプが変わっていた

正直SEO屋が好みそうな話題は触れたくないのだが。

link, area, a 要素の rel 属性で使用できるアドレスと文書の関係を示すリンクタイプ。

MDNを見ると色々書いてあるけど、あれ、glossaryとかcopyrightとかなかったっけ…

と思ってみると、HTML5HTML4で全然違う。appendexとかsubsectionとかもなくなっている。

copyrightlicenseに置き換わった模様。

ブラウザ側で実装されるべき機能が実装されずにいたためか、検索エンジン向けの情報になってしまっていて、ユーザーナビゲーション補助に使えるものがごっそり削除されている。

HTML4のリンクタイプをみんな知っているのかは分からないけれど、分かっているという前提でHTML5から重要そうなのをピックアップしてみよう。

stylesheet

おなじみのstylesheet。 これしか使わない人が圧倒的多数かもしれない。実はaareaにも使える。

next / prev

連続する文書の関係を示すもの。Netscape 6以降はナビゲーションで操作できたけれど、今はそんな効果はなくどちらかといえば検索エンジン向け。

比較的実用的で、モバイル版のOperaはこれをヒントに連続ページとして表示するようにしているっぽい。

index, last, firstは削除予定らしい…困った話だ。使われないからか。

noopener

Window.openerによる元文書へのアクセスを禁じる。

怪しい広告とかの挙動を抑制できるけれど、実際にそのような広告にリンクしている場合にわざわざ書くだろうか?

nofollow

これはリンクを否定的に表現するもの、らしい。外部サイトを示すexternalとの違いがよくわからない。

大きなポイントは、nofollowとついている場合、検索エンジンに対して「被リンクとしてカウントするな」と伝えるものらしい。 言及はしているけれども否定的に言及しているもののランク上げを手伝わないため、あるいは自作自演の被リンク(いわゆるBad SEO)とみなされないため、というものだと思われる。

そうなると意味的ではなくあくまでSEO要素ということになるけれど、それで良いのか。 というか、そもそもHTMLに文書の意味と関係ないSEO要素を盛り込むのは好ましくないのではないのか。

Arial/Helveticaを置換え 読みやすい欧文をウェブに

本当にArialが見やすいと思うのかい?

さて、突然だがあなたに質問だ。

次の画像を見てあなたが読みやすいと思うのはどれだろう。 「見やすい」ではない。ちゃんと英文を読んで、読むのが楽だ、このあと延々百何十ページとこの英文を読むのも苦にならないと思うのはどれか、ということである。

比較1

比較2

比較3

比較4

あなたの心は決まっただろうか?

webでなぜArialを指定したがるのか

Arialが指定されている現実の確認

まずはTwitterのフォント指定を見てみよう。

次にGoogle

Yahoo! Japan。Arialは指定するがHelveticaは指定しない。 MS PGothicが先に指定されているので、かなりArialを指定している意味は恐らく全くない。ヒラギノより先にしている理由もわからず、 これはさすがに技術力が疑わしい。

さらにいえば、フォントファミリーにクォートなしでスペースが入るのも無効なはずなので、技術力完全に駄目なやつでは…?

Mozilla。Zilla Slabはウェブフォントになっている。

Facebook。Helvetica優先でヒラギノ優先なあたり、Facebookはりんご党らしい。

Microsoftコミュニティは日本版でも欧文フォントのみの指定。 それもWindowsデフォルトフォント優先だが、MacデフォルトのHelvetica Neueを優先的に指定する謎のこだわり。

震源地となったMSNは現在は指定なし。私が指摘してから変えた…?

理由と経緯

ArialというフォントそのものはHelveticaの代替フォントである。

Helveticaは1950年代からあるフォントで、すごく使われてきた。PanasonicのコーポレートロゴもHelveticaだ。

Helveticaは現在はライノタイプのフォントで、Macに入っている。 MacはHelveticaを改変したGenevaもあって、割と重用しているようだ。しかもArialもある。

Arialのほうは1982年にRobin Nicholas, Particia Saundersがモノタイプに依頼して制作したもので、Hervetica互換フォントで形は少し異なるものの文字幅は同じ。

ArialはAlternativeを含めればWindowsに古くから収録されていて、Helvetiva互換フォントとして使われてきた。 WindowsのArialはフォント名にHelveticaを含んでいるので、Helveticaと指定してもArialが使われる。

そして代替フォントであったはずが、Arialのほうが美しいとか、WinとMac両方にインストールされているとか1いう理由でArialが主流になっていく。 Arialもポストスクリプトフォントとしてはかなり初期に誕生しているし、当時はあまりポストスクリプトフォントはなかった(し、高額だった)。 指定しなければビットマップフォントが使用される可能性が高く、すごく雑なビットマップフォントが多かったから、Arialの指定は高品位フォントの指定だったといっていい。今の日本の感覚で言うと、モリサワのフォントを指定するような感じだ。特にヒラギノ。

Arialが使える前提に立っていると、UIに使いやすかった。 ボタンはピクセル数を指定しなければならないけれど、その上に載せるフォントに合わせていい感じに調整する機能はなかったから、 「ボタンの上にこの文字を載せるか指定するためにはこの文字がどれだけの幅を取るか特定できなければならない」だったのだ。 当時はDPIも固定だったから、これは表示してしまえば確実に制御できたし、そこでArialが使える前提に立てば簡単に作ることができた。

あと、ワープロ文書でも文字数と改ページの関係でボックスサイズが変わると困ることがある。 ここでもArial前提にしとけばワープロ文書のままで受け渡しができる、というわけだ。 これは今MS Pゴシックの状態でワード文書を送りつける愚か者2と同じような心理である。

ところがだ。HelveticaにせよArialにせよフリーなフォントではない。 そこでサイズが同じ「メトリック互換フォント」がArial以外にも作られることとなる。 これはもう、Helvetica互換というよりはArial互換である。

  • Nimbus Sans (URW)
  • TeX Gyre Heros (Ghostscript)
  • FreeSans (GNU)
  • MS Sans Serif (Windows)
  • Arial (Microsoft)
  • Liberation Sans (Liberation Font Project)
  • Arimo (Chrome OS)
  • Albany (StarOffice)

これでArialに対する互換性をクリアしたわけだ。

和文フォントでも若干そういうものはある。 AAフォントと呼ばれるもの(IPAモナーフォントやMonapoなど)は5ちゃんねる(当時の2ちゃんねる)上でアスキーアートを表示するためのものだが、 梅フォントファミリーがMSフォントメトリック互換であるのは恐らくワープロ文書やメールにおけるレイアウトの都合だろう。

webでの指定の話

CSS登場以前はUI部品のサイズを柔軟かつ明瞭に指定する方法がそもそもなかった。

そのためUI部品にテキストを載せる場合(画像にすると当時は重かった)、レイアウト上「横にいくつボタンを並べる」という都合があり、 これをぴったりに載せる方法がWindowsでもMacでも使えるArialを使う、という方法だった。

これが「WindowsとMacにインストールされているフォントを考慮する」という誤った理解となり、思考停止したままWindowsとMacのフォントをそのまま指定するようになったのが「システムデフォルトの日本語フォントを指定する」問題だ。

挙げ句、MS Pゴシックはまだしもヒラギノとは全くデザインが合わない、単に美しくない状態となるだけの「欧文フォント指定があるから、それを消さずにその後ろに日本語フォントをWindowsとMacで並べればいいよね」という最高に頭の悪いアクションが生まれる、というわけだ。

だが、和文フォントをシステムデフォルトのものを指定するのが 全く意味がない のに対して、Arialを指定することは前述のように多少意味がある。 ただし、現在はCSSを使ってUIサイズを文字サイズ基準で指定できるため、まともなデザインセンスがあるのであれば問題にはならない。 そう、デザインについて数字でしか理解できないエンジニアが解決方法としてフォント指定に走るのはまだわからなくはないが、デザイナーがそれをやったら完全にデザインを投げ捨てているということになる。

基本的に「なり」のデザインになっていれば特に指定する必要はないのだが、UI上(好ましいことではないが)ボックスの中に入っていないテキストなどを書く必要がある場合はArialを指定するのは意味のあることである。 もちろん、その場合でもGoogleがしているように

とするのが適切。

ただし、google検索においてArialの指定が必要かどうかは疑わしい。 ただし、英語で検索するとGoogle検索の結果はArialの場合は2行であるため、2行に内容を詰め込むためには詰め詰めのフォントを使わせたい、というのがあるのかもしれない。そうでないフォントを使うと3行になったりするからだ。 その意味では「ゆるやかに意図を使える指定」ということで、ある意味妥当である。

Google検索の英語での結果 (Raleway)

このArialと汎用のサンセリフを指定する方法は日本語であっても有効である。 日本語はユーザーが設定したサンセリフ体が使われるだろうし、設定していなくても適切な日本語フォントが選択されるため、全く問題ない。

だが、そんなことを理解せず、思考停止してArial > Helvetica > MSPゴシ > ヒラギノにしているサイトが あんまりにもあんまりにもあんまりにも多い ので、3現実的に美しく読みやすく表示させようと思ったら、 「ArialとHelveticaとMS Pゴシックを置き換える」必要がある。

FontConfigに関してはウェブブラウザは当該フォントがFontConfigのエントリ上存在する(物理的にはなくてもいい)場合にその第一候補だけを取得するので、Arialに複数のフォントを設定しても駄目。 そのためArial+MS Pゴシックで合成されることを前提とした設定を行う、ということになりそうだ。

せめて日本語サイトで欧文フォントを指定していなければArialを英語専用で考えることができるのに、langも使わずまぜおって…

UI部品がArialでないと困るという場合でも、それはUI部品をクラス指定して、あるいはUI部品のタグで指定してフォントを指定すべきで、bodyに指定すべきではない。

デザイン的に指定したい (今の時代にデザイン的にデフォルトフォント、かつArialを指定したいとかセンスが死んでるけど4) 場合も「共通で入っている」とかじゃなくウェブフォントにすべき話だ。 和文フォントは大きすぎるため非常に迷惑になるが、欧文フォントは小さいので結構平気なもの。 Roboto, Open Sans, PT Sansあたりはキャッシュされている可能性が高いので、自前ではなくGoogle Fontsあたりを指定するのが良い。

なおWindows

Windowsでは標準でSerifやSans-serifを置換えることができないけれど、 Google ChromeもFirefoxもフォントの設定ができるし、している人は多い、少なくともユーザーにはその自由があるのでやはり強制はすべきでない。

Arialは本当に見やすいか?

冒頭の画像は

  1. Oxygen-Sans
  2. Arial
  3. Sen
  4. Input Sans Narrow

である。 私はInputが圧倒的に読みやすい。

見て気づくかと思うが、Arialはボックスに対して黒い「太めフォント」であり、極めて文字間を詰めた「詰め詰めフォント」である。 ある意味ではMS Pゴシックと類似の特性と言っていい。

Arialは「詰め詰めのフォント」であるため、代替は意外と難しい。 実際にArialは日本語フォントと比べpx数の決まったUI上に載せることが多く、サイズが違うフォントはUIからはみ出すケースが少なくないのだ。

そこでSans-Serifフォントから適当に見繕って表示させてみた。 Arialはとってもプロポーショナルなので文によって長さは大きく変わるが、おおよそこんな感じになった。 なお、試したフォントは200弱ほどあった。

サンセリフフォントの比較 (1)

サンセリフフォントの比較 (2)

サンセリフフォントの比較 (3)
サンセリフフォントの比較 (4)
サンセリフフォントの比較 (5)
サンセリフフォントの比較 (6)
サンセリフフォントの比較 (7)
サンセリフフォントの比較 (8)
サンセリフフォントの比較 (9)
サンセリフフォントの比較 (10)
サンセリフフォントの比較 (11)
サンセリフフォントの比較 (12)
サンセリフフォントの比較 (13)

この中からArialの代替になりそうなフォントを比較してみる。

Arialと代替フォントの比較

割と小さなところにも使われたりする(例えばTwitterのスクリーンネームとか)ので、グリフが小さいフォントは割とツライ。 UIフォントとして人気の高いUbuntuとOxygen-Sansは幅も似たようなもので優秀に見える。

私はlやtの字形がカーブしてくれているほうが見やすいように感じる。ここにはabilityみたいな縦棒いっぱいの単語がないが、 ぱっと見に字形を区別しやすいフォントが日本人には望ましいのではないか。日本語にはあまり「ぱっと見に字形を区別できない字が並ぶ」ということがないし、単語を字形で判断しようとするので、スペースで区切られた単語単位で識別して字は見ないという習慣があまりないためだ。

そう、日本人は日本語に慣れているが、日本語と英語では性質が違う。 日本語では一文字あたりの意味価値が高く、文字の識別が重視される。対して英語は単語感覚なので、どちらかといえば「単語の形」で見ていて一文字ずつはあまり見ていない。

Arialは詰め詰め黒々であり、単語の形で見るのであればなんとなく見やすいかもしれないが、ちゃんと文字がどう並んでいるかを識別しようとするとコストが高い。もうちょっと離すか、細くするかしてほしいし、字形も区別しやすいようにしてほしい、と感じるわけだ。 しかし字を離すと幅が増えてしまう。 TwitterのスクリーンネームなどでもArialが使われてしまうため、グリフ自体を小さくするとそれはそれで見づらい状況になる。

普通のCondenbcedでも厳しいくらい幅が狭く、代替を考えるのも難しい。

なお、字形の差については実はあまり問題がない。読みやすいフォントに代替するのであれば問題になるのは幅であり、例えばSans-serifではなくSerifを選択しても構わない。 ただし、それはデザイン的にArialが選択されている場合には違和感があるかもしれない。

Arialの代わりを探せ

もう少し長文で比較する。Arialがちょうど3行になっている。

Arialと代替フォントの比較 詳細(1)

Arialと代替フォントの比較 詳細(2)

デザイン的にも幅的にも差を小さくしたいのであればUbuntu、またはOxygen-Sansが有力候補だ。 Ubuntuは若干幅広、Oxygen-Sansは細字で詰めているため幅は逆に詰まる傾向がある。

また、リストに入れ忘れてしまったがSource Sans Proはかなり優秀な候補だ。 Source Han Sans Proの日本語部分でもあるため、かなり使いやすい。合成フォントとして人気の高いOpen Sansはやや幅が増えるが、こちらも優秀。

字形が違うものはどうだろうか。 Overlockは英文なら読みやすいのだが、日本語の中に混じっていると結構読みづらい。 Ralewayあたりだと変化が激しく若干の違和感があるが、不自由はない感じになる。

個人的に良いと思えたのはFira Sansだった。SenやAmikoもなかなか魅力的だが、幅の差がちょっと大きい。 今のところFira SansとRalewayとSenで迷っている感じだが、どうも私にはRalewayが良さそうである。

あとはもう好みの問題だ。だが少なくとも、Arialが他のなにより素晴らしいとは私には思えない。

設定例

メトリック互換

メトリック互換フォントに何を使うかはお好みではあるけども。

いい感じに表示する

和文はDPI100程度ならばさわらびゴシック、DPI150程度ならばMMCederがいい感じだった。


  1. もちろん、Helveticaで指定しても両方で使えるのだから、これを言う人は知恵が足りない。

  2. 相手がWindowsでない可能性、相手がMS Pゴシックを持っていない可能性についてわずかでも考えたのだろうか? 相手のことについて思索を巡らせず、自分に問題がないから構わないと考えるのはこの上なく愚かである。

  3. そんなこと言ってこのサイトも…と思っているみなさん。 あんまりCSSいじりたくなかったけど、直しました。アップデートでまた直すことになるのかなぁ。一応追加CSS側で上書きするようにしてはいる。

  4. 「英語のオーソドックスでキレイなフォントを指定したい」場合、RobotoあるいはOpen Sansが現代の主流。 現代は選択肢も豊富で、改良も続けられてきたので、Arialはさすがに古い。

ConoHaのCPUは本当に速いのか試してみた

ConoHaの5周年イベントで@hironobu_sさんが「ConoHaはCPUが速いので」という話をしていたので、「本当に速いんだったら使いみちが増えるなぁ」と思って試してみた。

だいたいこういうときはLinuxカーネルをビルドするものだけど、それはちょっと私のConoHaインスタンスには辛いものがあるので、zsh-gitをビルドしてみた。 ビルドはzsh-gitを一旦ビルドしたあと、パッケージを削除して再度makepkgする方式だ。

1GBしかメモリのないConoHaではtmpfsに置くのは難しいため、公平を期すためストレージ上に配置してビルドした。 ただし、Proliantに関してはIDE HDDで低速であるため、tmpfs上に置くこととした。

マシン CPU メモリ ストレージ 結果
ThinkStation P720 (Performance) Xeon Silver 4114 *2 16GB DDR4 (tmpfs) 58.85s user 16.15s system 63% cpu 1:57.77 total
ConoHa 1GB SSD Vdisk 68.20s user 18.65s system 67% cpu 2:08.76 total
ThinkPad X1 Carbon Core i5-7200U 8GB DDR4 SATA3 SSD +LUKS 85.58s user 31.33s system 73% cpu 2:38.57 total
自作 A10 7870K 32GB DDR3 SATA3 SSD +LUKS 86.29s user 27.51s system 73% cpu 2:34.90 total
Z400 Xeon W3565 20GB DDR3 SATA2 SSD +LUKS 94.57s user 27.29s system 74% cpu 2:44.22 total
ThinkStation P720 Xeon Silver 4114 *2 16GB DDR4 NVMe SSD +LUKS 101.57s user 49.95s system 80% cpu 3:08.84 total
Proliant microserver Turion II Neo N54L 4GB DDR3 (tmpfs) 146.95s user 46.53s system 84% cpu 3:50.16 total

えぇぇぇ…

まず、超高性能マシンであるところのP720が異様に遅い。 CPU利用率は高くても8%、周波数は800MHzのままで、凄まじい余裕を見せつける…のはいいけれど、とにかく遅い。

そこでもう我慢ならぬとcpupower frequency-set -g performanceしてtmpfsを解禁してやってみた結果が1位のものだ。 この場合でもCPU利用率は0.5%未満で、辛いものがある。

さて、X1 Carbonが積んでいるのは前世代のCore i5で、ラップトップとしては標準的な性能といっていいと思う。 A10 7870Kは今のデスクトップ用Core i3と同じくらい、Xeon W3565もだいたい同じ感じだ。

この感じだとConoHaと同等というと、6コアのi7でないと厳しいのではないか、というくらいConoHaが速い。

P720とProliantが採用するのはサーバー用プロセッサだ。ProliantのTurionは激安サーバーに使われているもので、イマドキちょっと見ない。 一方、P720が使用しているのは最新のサーバー用プロセッサで、4114を2基搭載するサーバーというと、結構な高級サーバーである。例えばHPE ProLiant DL360 Gen10がXeon Silver 4114 *2という構成だが、776,000円である。

つまりConoHaはちょっと自分では持つのは厳しいコンピュータくらいの性能がある。 コンピュータがマニアックな趣味の人でなければちょっと買えない、実用的なコストパフォーマンス的には買わないようなコンピュータ並の計算力を持っているということになる。

これまでConoHaが「あれ、なんか速いな」と思うことはあったのだが、それでもそんなに計算リソースが割り当てられているとは思っていなかったので、あまり負担をかけないようにしていた。 ぶっちゃけ、AURパッケージはローカルでビルドしてパッケージをアップロードしていたくらいだ。

しかしここまで速いと、AURパッケージのビルドくらいなんということはない(メモリ的に厳しいところもあるが)、どころか、「計算用のノードとしてConoHaインスタンスを立てる」ということが成り立つレベルである。

こうなると使いようがすごく広がるし、感覚的にも全然違う。

おみそれしました…

LG Gramがあまりにも素晴らしかった

LGはキライなんだけどこれは…

LGから出ている新しいラップトップ、Gram。 あまり話題になっていないけれど、私はかなり注目していた。

ポイントは15.6インチだ。 13.3インチ、14.0インチに関してはZenBookやThinkPadといったライバルと比べこれといったアドバンテージを感じない。 性能が高いわけでも、値段が安いわけでもない。 いや、正確に言えば13.3インチに関しては結構軽いモデルもあるのだが、低性能グレードに限られる。1 コンピュータとしてのLGの知名度のなさから、注目すべき要素に乏しくスルーされがちな印象だ。

だが、15.6インチはちょっと異次元である。 なんといっても15.6インチでも13.3インチとあまり重量が変わらない。

13.3インチの性能の高いグレードだと1kgをかろうじて切る程度だが、15.6インチはわなんと1.1kgを切る(!)のだ。 これは、14インチとしては驚異的に軽量なThinkPad X1 Carbonよりも軽く、一般的に15.6インチが2kgはあることを考えれば完全に新ジャンルと化している。

そして試してわかったことは

  • 全方位ほぼ隙がない
  • もし私がラップトップを購入しようとしていたなら即決だった
  • サイズによって全然違う

ということだ。

なお、一応強調しておくが、この記事はPR記事ではないし、私はそもそもLGがそんなに好きではない。 というか、ディスプレイの品質がよくなかったこと(廉価モデルであるためかもしれないが)、故障に対する対応がひどかったことから、「LGのディスプレイは二度と買わない」と心に決めているくらいだ。

だが残念なことに(本当にディスプレイではがっかりし、今でもとても怒っているので、製品がよかったりするとジレンマを発するという意味だ)私が今まで使ったスマートフォンの中で最も良かったのは、LGのスマートフォンだったりもする。

私としてはLG製品はもう嫌だ、というくらいなのだが、さすがに15.6インチで1.1kgと言われれば黙ってはおれぬ。 これは試すしかないと実際に触ってみた。

全モデル共通の話

軽量

まず、LG Gramはその名を関するだけあって軽い。

13.3インチ、14インチともに1kgを切り、15.6インチに関しては1.1kgを切る。

いずれもバッテリーが小さく、軽量なモデルも用意されているが、パーツグレードも低く設定されているようだ。 軽量なモデルは13.3インチで840g、15.6インチでは1kgを切っているようだ。だいたい100gちょっと軽い感じだろうか。 13.3インチは最軽量ではないが、14インチ及び15.6インチは文句なしの最軽量だ。

バッテリーマイレージ

また、軽量モデルとしては非常に優秀なマイレージである。 13.3インチの軽量モデルも10時間ということなので、UH75に比べれば長い。

そして、標準モデルのほうでは13.3インチが27時間、15.6インチモデルは23時間と「はぁぁぁ!?」と言いたくなるようなロングマイレージを実現している。

そんなにロングマイレージどこで使うんだ…と思うかもしれないが、実は結構な意味がある。

第一に、実際にはそんな時間もたないので、長時間外で作業したりする場合は足りる足りないの境目になるケースがある。 これは、自由電気を持ち歩くかどうかの差になり、重量と大きさに響く。

第二に、バッテリーは徐々に持たなくなっていくということだ。 バッテリーに余裕があればバッテリーを気にせず使うことができる期間が伸びる。ラップトップはバッテリーが寿命を決める可能性はそれなりに高いのでかなり意味が生まれてくる。

第三に、バッテリーを消耗する状況が存在するということだ。 例えばプレゼンテーションやデモンストレーションなどで輝度を上げて動画を回し続ける、という状況などは驚くほどバッテリーを激しく消耗する。 デモンストレーションの準備に時間を費やし、そのままイベントでデモンストレーションを行い、ここで指摘を受けた点を直す…などとすると結構バッテリーを使う。 こういうことをやると結構苦しくなる。私のThinkPadはバッテリーマイレージとしては15時間ほどだが、これはかなりギリギリだ。 しかも私は輝度を下げて、キーボードイルミネーションもつけず、Wi-Fiも切って作業するから、気にしないで使うと多分足りなくなる。 Gramほどのバッテリーマイレージならば余裕をもって対応できるだろう。

さらにUSB PDを使った急速充電もサポートしている。 私は放浪しながら作業する…ということをした経験もあるが、充電タイミングが少ないためどうしてもバッテリーが不足しがちになる。 そんな人はまずいないと思うが、それほどまでにタフな状況にも対応してくれるだろう。

ちょっと注目したいのは、軽量モデルのほうはMobileMarkで測定しているのに対し、標準モデルのほうはJEITA2.0測定であることだ。 ただ、この両者は結果にあまり違いはなさそうだ(60-70%程度だそうだ)。

メモリがモジュール式

ThinkPad X1 Carbon, XPS13, Spectre13といった軽量コンパクトのラップトップはメモリはオンボード式になっているのが常識になっている。

ところがgramは超軽量モデルなのにメモリはモジュール式。普通に組み替えられる。びっくり。

コンパクト

スリムベゼルは今どきの高級機の証だが、ThinkPad X1 Carbonよりも薄い。

つまり圧倒的にフットプリントは小さい。13.3インチなんて小さすぎて困惑する。

なお、Hauweiみたいに無茶なことはやっていないので、ちゃんとウェブカメラは上側についている。

タフ

MTL-STD 810G クリアである。

これ、すごいことだ。 ラップトップって割と壊れるもの、というか壊してしまうものだと思っているので、このタフさは嬉しい。 こういうタフモデルって結構な付加価値になっていることが多いのだ。

どの試験項目もなかなか見ものだが、衝撃試験は数少ない意味のある方法だといっていい。 通常、衝撃試験はまっすぐ落とす。これは堅牢性を謳っているThinkPadやLet’s Noteでもそうだ。

MIL-STDの試験では面、縁、角で26回テストする。 ラップトップを飛ばしてしまうときってひねり回転しながら角から落ちることが多いので、普通のラップトップがやっている試験はあまり意味がない。

なお、MIL-STDには残念ながら天面加圧試験がない。 一番壊れることの多いポイントなので、ちょっと気になりはする。

実用的な端子

Spectre13なんて「USB Type-Cのみ」なんて時代を先取りしすぎた端子だったりしたのだが2、Type-Aが2端子(15.6インチは3端子)、Type-Cが1端子、microSDスロット、HDMI、ヘッドセット。

Type-Cを充電に使うため、Type-Cがもう1端子ほしかった感はある。

USB Type-Cは珍しく明記されているDP Alternativeである。

RJ-45のアダプタが付属する点も良い。ただし、付属するのは100BASE-TXだ。 これは悪い点ばかりではない。なぜならばLinuxではUSB 3.0 1000BASE-Tアダプタで安定して動作するものがないからだ。

Wi-Fiはa/b/g/n/acとこちらも良好。BTは4.1と若干控えめ。

カメラはHDである。

音はテストできなかったが、一応ステレオスピーカー。 DTS Headphone X搭載だ。これは、私が今使っている ASUS Zenfone 4 Selfie Proにも搭載されているのだが、非常に良好な結果を得られている。

唯一の欠点であるディスプレイ

sRGBカバー率96%。

ThinkPad X1 Carbonが97%、X1 CarbonとXPS13のHDRモデルは100%である。 安物だと70%とかひどいのもあるので、一応クリエイター向けとは言えるかもしれないけれど、完全にクリエイター向けではない。 単にちょっとキレイな液晶に過ぎない。

だが、なぜかグレアなのである。これが唯一の欠点といっていい。 見た目には美しいが、実用的なラップトップとしてはかなり大きな欠点だ。

13.3インチ、14インチのおはなし

最大の違いはキーボードである。

13.3インチのキーボードは不快である。 右側が若干詰まっているデザインは許すとしても、いわゆるぺたぺたキーボードだ。

14インチはレイアウトも普通で、フィーリングも悪くない。 許由範囲だと思う。

ここから本番。15インチ

めちゃ軽い

基本的に同じ重量なら大きい方が軽く感じるものだが、15.4インチで1.1kgというのは完全に未体験で、以上なほど軽い。 UH75みたいなふっとばしそうな軽さではないけれど、ThinkPad X1 Carbonをはじめてさわったときの「かるっ!!」という気持ちを思いだす。 X1 Carbonに慣れた今ですらだ。

キーボードは良好

ThinkPadのキーボードは最高であり、ラップトップで比肩するものはないが、 Gram 15インチのキーボードはなかなか良い。

ストロークが深めでしっかりとストローク感があるため、非常に重量のある15インチ、17インチクラスのキーボードと同じような感触、 特別良いわけではないがモバイルラップトップの一般的なキーボードと比べれば大変良い。

右側のキーが詰まっている形状で、「ほ」「へ」「ー」のみ3列詰まっているのだが、 驚いたことにミスタッチはほぼなかった。配置が上手い具合になっているのだろう。

むしろミスタッチはカーソルキーでテンキーを探ってしまったことのほうが多い。 テンキー付きはエンターが探せない機種も多いので、キーボードには良い点がつけられる。

タッチパッドはクリッカブル

これもポイントが高い。

なぜならば、クリッカブルの場合クリックエミュレーションを切ることができる。 クリックエミュレーションを入れていると「カーソルがふっとぶ」現象が起きるが、クリックエミュレーションを切っているとポインターが移動するだけでボタン動作しないためこれを避けられる。

さらに、タッチパッドのオンオフ機能もある。 ただしこちらは一般ユーザーでやると、機能はするがエラーが出る。

Core i7/16GB RAMが選択可能

15.6インチモデルのみCore i7が選べる。 16GBモデルはコストコ限定だが、グレードアップオプションは別にある。

非常にいいボディ

しっかりしていて、どこを持っても歪みはない。

また、蓋はマグネットになっていて、しっかり閉まるようになっている。

デザインもいい

真っ白って最近そこそこ見るような気もするけれど、なかなか良い。 美しいデザインだと思う。

まぁ、ディスプレイ下にでかでかとロゴをいれたりしないことを覚えてくれるとより良いが。 天面はgramロゴで、こちらはなかなか良い。

結局隙がない

ちくしょう、すごくいいじゃねぇか…

本当にすごくよくて、欠点といいったらグレアパネルくらい。

ThinkPad大好きな私でも即決レベル。値段も悪くない。

15.6インチでこれはちょっとずるい、というくらい新ジャンル。 プレゼンテーションやデモンストレーションに使うときは15.6インチっとても良いし、なにかと捗る。

思わぬ伏兵が現れたものだ。


  1. もちろん、本当はバッテリーが小さいから軽いのだが、基本的に4GBメモリのグレードになっているようだ

  2. 現行モデルはUSB-Aもある。

Pandoc Markdownで任意の要素にクラス/IDを指定する

2017年初頭に追加されたがPandoc ユーザーズガイド (日本語版) には反映されていない機能。

従来もヘッダー及びフェンスコードブロックにはクラスやIDを書くことができたが、汎用のdiv/spanで書けるようになっている。

任意のブロック (div)

次のように書くことでdivで囲んで someclass クラスを付与することができる。

また、次のようにして someId IDを付与することができる。

クラスとIDの両方をつけることもできる。

任意のインライン要素 (span)

同様にインラインでもつけることができる。

インラインコード

インラインコードでもつけられるようになった。

蘇ったFreetype2 Infinality

Archの人たちは本当に熱心だ。

Infinalityといえば、フォントの美しさにこだわるLinuxerにとってかけがえのないキーワードであり、定番テクニックだった。

FreeType2が2.7になったとき、同時にInfinalityも消滅した。

これは、FreeType2がInfinality相当のフォントレンダリングを取り込んだから…でもあるが、実は作者失踪のため、でもある。 FreeType2がInfinality相当のサブピクセル計算方法を取り込んだから十分だと考えたのか、それともやる気を失ったのか、いずれにせよ公式にInfinalityの役割を終了することなく…つまり、Infinalityのまざまな機能は取り込まれなかったが計算式だけは取り込まれる形でInfinalityは消滅した。 もちろん、Infinalityはそれ以前に終わっていたのだが、FreeType 2.6の間は機能していた。2.7になって互換性がなくなり、機能しなくなったのだ。

これに対して不満を持つ人は多かった。

まず、Infinalityが終了したことに気づかず、トラブルに巻き込まれた人、というのがとても多い。

そして次に、FREETYPE_PROPERTIES="truetype:interpreter-version=38"は十分ではないと考えた人もまた、いたのだ。

実際、私もFreeType 2.6 InfinalityからFreeType 2.7になってフォントレンダリングの質は落ちた、と感じた。 だが、upstreamの方針ならそれもまた致し方なし…と考えたのだ。

しかし、そうではなかった。 FreeTypeはInfinalityの機能を取り入れる予定はなかったし、別にInfinalityパッチが不要のものになったわけでもなかった。

そしてついにFreeTypeパッチは蘇った。

AURにあるfreetype2-infinalityはFreeType 2.9に対応した新しいInfinalityパッチつきFreeTypeである。 cairo-infinality-ultimate, fontconfig-infinality-ultimateが新たなる対応ソフトウェアとして登場している。 なお、Java用のInfinalityパッチとlib32のFreetypeパッチは投げ捨てられたままだ。

freetype-ultiamte5はInfinalityではない、さらに別のパッチである。 TomaszGasior氏の作で、Infinalityを使わず、直接にFreeTypeにパッチを当て、Infinality Ultimate5相当のレンダリングを得ているという。 fontconfigやcairoにinfinalityパッチを当てる必要もない、なかなか効率的なパッチだ。

FreeTypeはClearTypeのフォントレンダリングを取り込もうとしているらしい。 だが、特許上の問題から今のところ難しいらしい。

この機能自体は実装はされていて、しかし有効にできないオプションとなっている。

Technically, no. The patents cover the whole process of generating and displaying sub-pixel images. Since the font engine doesn’t do the display part, it cannot infringe. Apart from that, FreeType has provided the capability of converting vector shapes into un-filtered sub-pixel images for a long time.

By default, FreeType’s scan-line converter returns ‘gray’ sub-pixel images, where for each pixel the color components are equal (this is, R=G=B). The result is visually identical to gray anti-aliasing and cannot infringe any of the ClearType patents.

Similarly, the LCD-specific filtering API is disabled by default, which means that it returns an error and doesn’t alter sub-pixel images.

You can override these limitations by activating option FT_CONFIG_OPTION_SUBPIXEL_RENDERING in FreeType’s ftoption.h configuration file, but you should do that at your own risk.

この機能を(自己責任において)有効にした状態でビルドしたものがfreetype2-cleartypeである。

そしてこのいずれも、最も劣悪にまで落ちてしまったLinuxのフォントレンダリングを改善してくれる。

リスク順に考えてみよう。

freetype2-cleartype

特許上の問題がある。設定オプションを変更しているだけなので、Infinalityパッチ環境で2.7に上がったときのような問題は起きないと思われる。

技術的には最も安全。特許状の問題は、個々の環境で有効にする分には問題はない…?

freetype2-ultimate5

小規模なパッチで、取り残される心配は作者が投げない限りはなさそう。

動作もinfinalityに比べれば軽く、戻すのも比較的簡単。 ぜひともupstreamに取り込んで欲しい逸品。

freetype2-infinality

fontconfigとcairoにも依然としてパッチを当てる1必要がある。 動作も重く、やや不安定。

現状では問題なく動作しているが、リスクは最も高いように思われる。

freetype2-ultimate5とinfinalityパッチは関係がないはずだか、freetype-ultiamte5 + fonconfig-infinality-ultimate のほうが美しいように感じた。

なお、これらのパッケージはAURのものであり、Arch、あるいはAURを利用する他のディストーション(Anterogos, Manjaro)以外においては導入は難しいかもしれない。


追記。実際に比較してみた。

設定を全くせずにインストールだけするとfreetype2, freetype2-cleartype, freetype2-infinalityの結果は全く同じだった (composite -compose Difference afile bfile difffileidentify -format "%[mean]" difffileで確認)。

freetype2-ultimate5は異なるレンダリングをしている(見た目にも明らかに濃い)が、fontconfig-infinality-ultimateによる違いはなかった。

繰り返すが、これはあくまで「設定は一切せずに」比較している。

ただ、結局はfreetype2-ultimate5がよさそうだという感触なのだが。

FreeType2 ClearType option
FreeType2 Ultimate5 patched

  1. FontConfigのほうはpatchというか、/etc/fonts/conf.avail.infinalityを作ってこれにリンクを張るものだけれども

Webページを単一のHTML (data, BASE64形式) に保存する

webページを保存するのにwgetは便利なのだけど、最近のウェブページは非常に複雑なので大量のファイルが生成されることがある。

もちろん、単純には

$ wget -p -k -E URL

でいいのだけど、ちょっと使いづらい。 単純にページを保存したい場合には、「そうじゃないんだよなぁ」と思うことがある。

あるいはテキストページなら

$ w3m -dump URL > file

という手もあるけど、これも画像が入っていたりレイアウトされていたりすると「そうじゃない」となる。

mhtmlは扱いづらいし、せっかくdata形式で埋め込めるのだから、画像やCSSを埋め込んだHTMLファイルを作ってほしい。

なんかないものかと探したところ、zTrix氏によるwebpage2htmlというプログラムが見つかった。

これがなかなか秀逸。

python webpage2html URL > file

でいいので話が早い。依存関係もpipで解消できる。 (requirements.txtも用意されている)

自動化が困難な場合にはwgetと組み合わせて二手間ほどかければ大丈夫だろう。

完成度はそこそこ。 今わかっている問題としては、サーバー側でcharsetを返さない場合、HTML内に書かれていたとしても文字エンコーディングを識別できず文字化けする。 指定もできない。

Pythonは内部文字エンコーディングに変換するため、ここでバグってしまうのだろう。 やっぱりwgetで落としてきて自前ウェブサーバーで指定するような手間が必要になる。

すごくいいツールなので、ぜひ育てていってほしいところ

メッセージフォームのサポート (Nginx + FastCGI + spawn-fcgi + Rack + Ruby)

あらまし

Mimir Yokohamaでついにお問い合わせ方法として「メッセージフォーム」が追加された。

なにがついになのか、なにをドヤっているのかと思うかもしれない。 まぁ、ドヤってはいないのだが。

実は私はかなり長い間ウェブアプリケーションをほとんど作っていない。 そして、今まで私が作ったウェブアプリケーションは、専用サーバーを持つサーブレットタイプか、もしくはCGIだった。

馬鹿にされがちなCGIだが、利便性は高く、頻繁にアクセスする性質を持たないアプリケーションには適している。

そして、そもそもウェブアプリケーションを作っていなかったのは、私が「事前生成戦略」の研究と実験に注力していたからで、 どちらかといえばウェブアプリケーションからは離れる方向にあった。 そして、ウェブアプリケーションを必要とするとしても大部分は静的ページとして提供できる方式を目指していたため、CGIで十分事足りたのである。

ちなみに、これまでウェブサーバーは

  • Apache
  • lighttpd
  • delegate
  • Nginx

という経過をたどっている。 Apacheは言うに及ばずlighttpdとdelegateはApacheよりもCGIが簡単だったので、「ほぼCGI」だった。

だが、時代は変わった。NginxはCGIをそもそもサポートしない。 私も新しい時代に対応する必要がある。

ちなみに、この作業は次の仕事のための実戦テストという意味合いもあった。

方針を考える

最も話が速いのはFastCGI Wrapである。

NginxはFastCGIをサポートしている。 FastCGIはプログラムをデーモンのように起動しっぱなしにする。

だが、通しで実行するプログラムとデーモンではそもそもの前提が違う。 そのためCGIプログラムをFastCGIとして動かすのはそれなりにハードルが高い。

そこでFastCGI Wrapの登場である。 FastCGIとして利用されるプログラムをFastCGI Wrapにする方式だ。 このラッパープログラムは要求に合わせて都度CGIプログラムをCGIインターフェイス経由で起動する。 結果的にFastCGIの意図は無視して従来型CGIを動作させるようにするというものだ。

この方法は結構出てくるのだが、基本的には既存のCGIプログラムを動作させる話である。

個人的な感覚としては、無駄なプロキシを噛ませるような方法を使ってまでCGIに固執したくない…というか、実はfcgi-wrapってそれなりにめんどくさい。

だったらFastCGI直というのもありかなぁ、と考えるわけだ。

ところが、やっぱりFastCGIはデーモン状のプログラムを想定しているわけで、やはり前提が違う。 要求として割と複雑なのか、デーモン化に関してはspawn-fcgiに担ってもらって、さらにRackを使う、というのがどうやら主流らしい。

だいぶ話が複雑になってきた。

サーバーはNginxである。NginxはFastCGIインターフェイスを経由してFastCGIプログラムにパラメータを渡し、応答を受け取る。

FastCGIプログラムはデーモンである。 Rubyでは次のようにしてFastCGIプログラムを書くことができる。

あるいは、CGIライブラリ互換インターフェイスを使うことで、#each_cgiの中身はまるっきりCGIと同じにすることもできる。

spawn-fcgiはこのデーモン部分を担う。 つまりeachしてる部分を担ってくれるわけだ。

プロセスとしてCGIインターフェイスで起動するわけではないので、fcgiwrapほどの互換性はない。 感覚はCGIに近いが、インターフェイスは意識する必要がある。

Rackはミドルウェアと呼ばれている。これはまずFastCGI抜きで話そう。

Rackはインターフェイスを担っている。 今までプログラムはCGIなり、あるいはFCGIなり、さらには各種フレームワークやサーブレットの様式(例えばSinatraとか)で書いていた。

Rackはこれらの違いを吸収するモジュール設計のものだ。 Rackに準拠したプログラムを書いておけば、たとえ愛用のフレームワークがディスコンになっても、サーバーが変わっても安心、というわけだ。

だが、Rack自身はサーバーではないからサーバーがいるのだが、Rack組み込みのサーバーというのはもう完全にRuby世界の住人だ。 だってRackはRubyのWebアプリケーションインターフェイスだから。

Passengerというソフトウェアがあって、これはwebサーバーのモジュールとしてRackに対応する。 Apacheでは比較的簡単だけれど、Nginxだと結構きつい。

そこでRackに対応したサーバーを立ててサーバーとサーバーでやりとりさせる、という方式がすごく現代的。 直接にRack経由でプログラムとやりとりするのはRackに対応したサーバーだけれど、Rackに対応したサーバーにwebサーバーとしての機能を持たせると大変なので、「本物のwebサーバーに矢面に立ってもらって、RackサーバーはあくまでRack対応に特化」というわけである。

Rackに特化したサーバーとしては(別にRackだけではないんだけど)、Webrick, Mongrel, Puma, Thin, Unicornあたりがある。

しかしRackでやりとりする方法があればいいので、FastCGI + Rackという方法もある。 それはRack側でFastCGI経由で受け取って、応答するためのハンドラが用意されている。

つまり、Unicornのようなサーバーを立てる代わりの手段としてFastCGIが使える。 FastCGIもデーモンを必要とするので別にFastCGIにすることで間に挟まってるものを減らす効果はない。 ただ話が楽になるだけである。

Unicornはむちゃくちゃ速いので、UnicornでUnixドメインソケットを使えば形式とししてはspawn-fcgiでUnixドメインソケットを使っているのと一緒だし、やっていることははるかに高度になる。 これが超モダンなやり方である。

が、あえてのFastCGI。 理由は管理する要素数を減らすためである。必要がないのにいかついものを使うことはしない。 これはサーバー運用のコツでもある。

なお、Rackに関してはかなり情報が少ない。 なんらかのフレームワーク…というか、ほぼRailsのバックエンドとしてのRackの話だけで、Rack単独の話ってない。 そして、FastCGIを使う話もない。これもだいたいなんらかのアプリケーションが「使ってる」あるいは「使わせる」話になる。

なんというか、みんなそんなに自分でプログラム作るってことをしてないのか… 世の中エンジニアたくさんいるのに、WordPressとRailsだけで満足なのか…

そんなわけで情報が猛烈に足りていない中、FastCGIとRackについて勉強することになったわけだ。

なお、Nginxでアプリケーションとやりとりする方法に関してはDiscourceで散々やったので経験済みだ。

なぜRackなのか

もちろんこのことからもわかるようにRackはなくても構わない。 spawn-cgiも使用せず単独のFastCGIアプリケーションを開発するのは容易である。

私が気にしたのはRubyのfcgiライブラリは2013年から更新が止まっているとい点だ。 また、Arch LinuxではfcgiライブラリはAURにもなく

# gem install --no-user-install fcgi

とするよりない。

ベーシックな機構であるFastCGIそのものが廃止になるようなことは考えにくいが、NginxのCGIの扱いのように消極的なサポートへと変遷する可能性はある。 その場合にアプリケーションの書き直しが発生してしまう。

Rackは現在主流であり、新規採用例も多い。 Rackが廃止になると影響を受ける範囲も非常に広いので今後10年は安泰だと思われる。

そこでFastCGI+Rackという構成にしたわけだ。 この場合でもRackはFastCGIをネイティブサポートしているわけではく、fcgiライブラリを使ったハンドラを同梱しているだけなのでfcgiライブラリは必要となる。実はこれを回避したかったのだが、結局はできなかった形だ。

とはいえ、この状態であればFastCGIを捨ててUnicornに移行するのも難しくはない。

とりあえずやってみる

Nginx

location / {
    root /var/www/testapp;
    fastcgi_pass /var/run/fcgi-testapp.sock
    fastcgi_index testapp.rb;
    include fastcgi_params;
}

Rack Application

Requestのほうはインターフェイスに絡むけれど、 Responseは単純に#finishでRackに沿った配列を返すための便利クラス。なくてもいい。

spawn-fcgi

# spawn-fcgi -U http -s /var/run/fcgi-testapp.sock /var/www/testapp/testapp.rb -n

試してるうちは-nつきにしてフォアグラウンドで実行するのが楽

実用的にする

起動スクリプト

forkingなので停止・再起動の制御のためPIDファイルを作る。

Systemd Unit

[Unit]
Description = FastCGI Rack Test Application
After = nginx.service

[Service]
Type = forking
PIDFile = /var/run/fcgi-testapp.pid
ExecStart = /usr/local/sbin/fcgi-testapp.bash
ExecStop = kill $MAINPID

[Install]
WantedBy = multi-user.target

forkingなので$MAINPIDがそのままでは使えないため、PIDFileで指定しておく。 Nginxのあとに起動しておいたほうがいいような気がしたけど、なくても構わない。 アクセスが激しい場合は逆にNginxの前に起動したほうがいいだろう

spawn-fcgi自体にはアプリをリロード、再起動するような機能はない。

おまけ

S-NailがSubjectも本文も、UTF-8をちゃんとエンコードしてくれるのですごくびっくりした。

「mailxとは違うのだよ!!!」ってことか。 さすがSMTPやPOPやIMAPにも対応しているだけのことはある。

ここの部分(MIMEエンコーディング)も自分でやるつもりだったので、かなり省力化された形。

今回の構築は他にも色々やったのだけれど、共有して意味のある部分はこれくらいのものだろう。

P720 * Windows 10 にDTM環境を構築した

Windows 10でDTM環境を作った

前回の記事の流れで諦めてWindows 10のDTM環境を作った。

Windows 10でDTM環境を整備

もう、すごくめんどくさくて、これに何日使ったかわからない。

色々と買い揃えている人ほどではないが、全部入り上位パッケージを買うタイプなのでこれはこれでひと財産という感じである。

環境としては

  • Cakewalk SONAR X3 PRODUCER
  • FL STUDIO PRODUCER Signature Bundle
  • Internet Ability 2.5 Pro
  • KOMPLETE 9 ULTIMATE
  • Air Music Technology Xpand! 2
  • Air Music Technology Hybrid 3
  • CeVIO Creative Studio 2 初回限定盤パッケージ (6.1アップグレード)
  • Soundspot Nebula

という構成になっている。

Windows 10 * SONAR X3 Producer

Windows 10上でSONAR X3 Producer自体は動作する。

ただし、動作しない(みつからない)プラグインがいくつかある。 dllをレスキューすればいける、みたいな話もあるのだけど、全プラグインを把握しているわけではないので確認はできていない。

SONAR X3をWindows 7上で使っている人はWindows 10に移したら完全には動作しない可能性を考えたほうがいい。

SONAR X3 Producerに付属しているAddictive DrumsなどはSONARとは独立してそのまま利用することができる。

非常に使える戦力なので、ぜひ活用していきたい。 今のところ一番イケてるドラム音源だと思う。

スタイリッシュになったものの難易度の上がったFL Studio 20

Macに対応したりして注目を集めるFL STUDIO。 変化が大きかったのでしばらく12と併存でいくのかと思いきや、バッサリとリリースと同時に12を切ってきた。

今までの使い方がわかっている人にとってはアクセスしやすくなって素晴らしいのだけど、そうでない人にとっては操作方法のヒントが激減した。

まぁ、デザイン重視なのはFLの伝統でもある。

プリセット設定ができてわかりやすくなったプラグインはインストールプラグインと扱いが異なるためわかりづらくなった。 インストールしたプラグインの操作はFile Settings -> Manage plugins -> Start Scanとやったあと、Plugin Database -> Installed という流れになっている。

ちなみに、私はSignature Bundle使いなのだけど、いつもバージョンがあがったあとアクチベーションするとPRODUCER - Signature Bundleと表示されるようになるのが好き。

FL STUDIO 11 のときは背景はFL-chanだったし、読み上げもしてくれていたのに、 12からはなくなってしまって残念。

なんだか懐かしいAbility

Singer Song Writerといったら初心者御用達のDAWだったし、割と舐められてた気がするのだけど、Abilityになってスタイリッシュになった。

SONARが終わったときに異様なまでのセールでAbilityが出ていて、まさにこういう事態(DTM環境のWindows 10化が避けられない)のために買っておいた。 いつも通りというか、最上位のAbility 2.5 Proである(パッケージ的には2.0)。

ちなみに、私はSinger Song Writerは使ったことがない。

もう一言で言うと

すごーく、シーケンサっぽい。

私はもともとXGWorksを使っていて、MIDIを組むのがお仕事だったりした。 当時はレコンポーザとかがあった。 そしてその他のライバルとしてRolandが売っているミュージ郎というパッケージがあって、それにシーケンサとしてSinger Song Writerがバンドルされていた。 ミュージ郎はそのうちCakewalkと組んでCakewalk(こっちはソフト名)をバンドルしたバージョンを出して、その後CakewalkがSONARになった。 RolandがCakewalkと組んだからインターネット(これは会社名)が出ていったのか、それともインターネットがSinger Song Writerの商品力で勝負しようとしたからRolandが見放したのかはわからないけれども。

Singer Song Writerはそれなりに波乱に満ちた歴史があって、wikipediaの記事を読むと面白いかもしれない

YAMAHAだってSOLがあったからXGWorksというとお手軽MIDIソフトだったのだけれど、販売面でいうとミュージ郎のほうビキナーパック感があった。 ちなみに、プロでSOL使っている人はすごく少なかった。当時はオーディオ化がコンピュータで完結しなかったので、オーディオになったあとの面倒をみるところをMIDIを組んでいるソフトでやる必要がまったくなかった。 ほぼProToolsの独壇場だったけれど、Cubaseを使っている人はまぁまぁいた印象。MIDIの組み方としてはSOLよりXGWorksのほうが簡単だったので、XGWorksを使っているプロはそこそこいた。

そんな歴史を語ってしまうほど、Abilityには当時の匂いがした。 洗練されていない四角いアイコンが並んで、操作方法も表示方法も現代的な視覚性を持っていない。 とにかく表示を並べる昔のままのスタイルだ。

少しはCubaseやStudio Oneを見習えというべきなのか、それともいやよくぞこのまま貫いてくれたと言うべきなのか。

だが、古臭いけれどなんとなく直感的で良い。 15分ほど触っただけだけど、なんとなくつかめたような気がする。

SONARはかなり気に入っていたので、それより良いものになるかはわからないけど。

Ability 2.5 の UVI GrandPianoModelD はかなり面倒

わかりづらくてかなり手こずった。

UVI WorkstationはKONTAKT PLAYERみたいなもので、これ自体はなにもない。 サウンドバンクの母艦になるものだ。

SSWのアカウントを発行するまではAbilityを起動してアクティベーションするところまでは済ませておくこと

  1. SSWのサポートセンターのマイページに行く (メールのリンクから行ける)
  2. パスワードをリセットする (Abilityから登録した時点でパスワードが発行されていない)
  3. マイページのリンクからBFD EchoとGrandPianoModelDのダウンロードを行う
  4. これらはPDFファイルのアーカイブになっているので展開する
  5. UVI Workstation サウンドバンクインストールガイド を読む
  6. ここに書かれていることを無視して 「UVI workstation ダウンロード」で検索してアプリを入手する
  7. UVI Workstationをインストールする。このときiLok License Managerもインストールされる
  8. しかしiLok License Managerは動作しないので、License Suport Installerを別途インストールする (iLok License Manager起動時にインストールするように言われる)
  9. iLok License Managerを起動する
  10. UVIのマイページから製品登録を選択し、iLokのアカウントと接続を選択してiLokのアカウントを作る
  11. iLOk License Managerでログインする
  12. 製品登録の画面でアクティベーションキーを入力、iLokアカウントに接続を選択してログイン、その状態で次へをクリックする
  13. マイプロダクトからGrandPianoModelDをダウンロードする
  14. rarファイルになっているので展開して、C:\Program Files\UVISoundBanks以下に展開して得られたファイルを配置する
  15. UVI Workstationを起動する

最高にめんどくさい。

BFD Ecoはそんな変なことはないので大丈夫なはず。 もっとも、ドキュメントから導入するのは変わらないけど。

Air Music Technology のアクティベーション

プラグインスキャン時にアクティベーションになる。

iLokも利用可能。

Nebulaは…

なんとシリアルナンバーすらない。

ものすごく安売りしてることが多いけど、商売っ気なさすぎないか。

CeVIOはスタンバイ

CeVIOは初回限定パッケージを入手済み。

ONEはまだ買ってないので、とりあえず今年中にさとうささらの曲を書くのが目標だ。 本当は使い慣れたSONAR上でさくさくっとやるつもりだったのだけれど、ソフトウェアが変わってしまったので厳しいかもしれない。 FLでやってもいいけれど、実はFLのほうもあまり自信がない。

EDMジャズみたいな曲を作りたいなと思っているのだけど、そういうのはとにかく時間がかかるので、 いつもどおり音数の少ない曲をとりあえず書こうかな、と思う。

ただ、ずっと思っていたことがあって、 プロになってからとにかくがんじがらめで曲を作ってきたから、 プロになる前みたいに、好きなように音を並べて音楽を作りたい。 楽器がどうとかじゃなくて、とにかく音を並べて音楽にしたい。

多分、CeVIO曲はそんな曲になると思う。

なお、CeVIO CS 2のときは機能らしきものはほとんどなかったのだが、CS 6になってなんかちゃんと音楽制作ソフト感ある感じになった。 なお、CS6になっても相変わらず出力オーディオは選択できない。

なお、なぜ2の次が6なのかは全く不明。VOCALOIDを追い越すためか???

あと、IAはトークがCeVIOでソングはVOCALOIDなので、PVではCeVIOでVOCALOIDの宣伝をする。

アクティベーションとライセンス管理

基本的には各メーカーのユーザーアカウントと結びつける方式。

XLNやNIは専用のアプリを使ってインストールやアップデートの管理も行う。 この方式はなかなか優秀。

iLokも以前のような凶悪なものではなくて、メーカーでユーザーアカウントは登録するものの、 マシン管理はiLokのアプリケーションで行う、というような形になっている。

マシン管理は厳しく行うもの(ディアクティベーションが必要)とゆるやかに行うもの(使わなくなった環境はそのまま使わなければいい)に分かれる感じ。

ただしCeVIOはやたら厳しく、使いにくい方式をとっている。

TASCAM

シリアルナンバーとは別の認証コードを発行。 インストール後は直ちに認証コードを入力しないと使えなくなる。

認証コードはユーザー登録と製品登録を行うことで発行。 一度発行したあとはそのコードをディアクティベーションなしで利用できる。 利用状況はチェックされる。

Image Line

ソフト上からログイン、あるいはマイページから登録用ファイルを獲得して登録。

ユーザーアカウントと結び付けられる。

Internet

メールとURLを使った登録とダウンロード、そしてインストール時にシリアルナンバー入力。

マシン同定に使用するデバイスをシステムドライブとネットワークインターフェースカードから選べる。

XLN Audio

専用アプリで管理。

ディアクティベーションはマイページから行うものの、専用アプリから通知してくれる。 マシン管理が簡単でとてもうれしい。

ただし、ソフトウェアごとではなく、専用アプリ単位でのアクティベーション。

Native Instruments

専用アプリで管理。

マシン管理はチェックのみで、特にディアクティベーションは不要(古い環境がそのまま使っていなければ破棄されたものとされる)。

Air Music Technology

ユーザーアカウント、あるいはiLok。

UVI

iLok。

昔のように専用ハードウェアは必要ない。

BFD

ユーザーアカウント。

ダウンロード時に認証される。 マシン管理はあるのか不明。

Soundspot

多分ない

Celemony

「鬼畜Melodyne」とか呼ばれていた。

インストール時ユーザーアカウントとの結びつけだけれども、ディアクティベーションがアプリ上からしかできない仕様で、マシンが壊れるとメールするしかなかった。

最近はしれっとマイページからディアクティベーションできるようになっている。

CeVIO

現状もっとも鬼畜。

ユーザーアカウントと結びつけるタイプだけれども、認証を起動ごとに行うため、ネットがない環境では起動不可。 さらに、CeVIOのサーバーが落ちてることがまあまああるため、そのときも利用不可。

Lenovo ThinkStation P720 に Windows 7 をインストールする

なんとかしてP720でWindows 7を使う

私が音楽のお仕事するときの環境は以前としてその中核にSONAR X3が据えられているため、Windows 7が欠かせない。

ThinkStation P720は将来性を考えてWindows 10モデルを選択したが、手元にあるリテール版Windows 7 Professionalのライセンスを利用してWindows 10, Windows 7, そしてLinuxという構成にするのが私の目論見であった。

Skylake-SPプロセッサはWindows 7を使うことができる最強にして最終のプロセッサである。

だが、これはかなりの困難に阻まれた。

もちろん、Windows 10は(いささかの問題はあれど)動作するし、Linuxもなんら問題はない。 だが、Windows 7に関してはインストールディスクから起動すると “Starting Windows” の表示と共に停止してしまうのだ。

様々なトライをしたがうまくいかず、Windows Updateを適用したディスクの作成を試みた。

内容としてはここここを参考にしたが、そのままは適用できなかった。 特にIE11関連はアップデートの配布がされていなかった。

とはいえおおよそ必要と思われるものを統合した。

だが、これでも問題が発生した。

Legacy (BIOS) なら起動できるのだが、UEFIだとUEFIアプリケーションを見つけてもらえない。 bootx64.efiの用意もしたのにだ。

調べたり質問したりしたのだが、解決には至らなかったので、結局UEFI Onlyでの運用を諦めてハイブリッドブートとした。

さて、これでインストーラが起動するようになったのだが、残念ながらUSB2.0ポートにつなぐ場合(P720はキーボード/マウス用ポートのみがUSB2.0)を含めてUSBデバイスが一切反応しない。

幸いにもPS/2ポートが存在しているので、これを利用する。PS/2-USBアダプタは機能しなかったため、PS/2キーボードを新規に購入した。

これでWindows 7は起動するのだが、まともに動かない。 とにかくドライバがない。そして何も動かない。

仕方ないので別のマシンから SCCM Packages For Windows 7 (64-bit) – ThinkStation P720, P920 をゲットして、CD-Rに焼いて展開する。

そう、USBもイーサネットコントローラも動作しないのでCD-Rだけが頼りなのだ。

この状態でC:\DRIVERS以下にドライバファイルが配置された状態になるので、デバイスマネージャからドライバの場所の指定でここを指定すればインストールできるようになる。

大量の動作しないデバイスがあるためかなり大変な作業である。

Windows 7をP720にインストールした状態

とりあえず2つのネットワークコントローラとUSB(4つある)をインストールすればWindows Updateもできるようになり、楽な進行になるだろう。 USB3.0ルートハブにUSB2.0ハブがぶら下がっている格好であるためUSBマウスが動作しなかったのだが、USB2.0ハブのほうもWindows 7はドライバーを持っていなかった。

実際は全部をインストールしなくてもよかった(ある段階でCPU内蔵機能に関しては残りすべて導入されていた)が、Windows Updateと並行するのでなかなか複雑なことになる。

注意点としては、「Blink系ブラウザはシステムがフリーズする」。 原因はわからないが、とりあえずブラウザはFirefoxに限る、ということになりそうだ。導入作業でChrome, Vivaldi, Sleipnirなどを使って作業しようとするとハマることになる。

Windows 7 は動いたが、断念せざるをえず

「特定のタイミングでフリーズする」という問題が「ASIOなどでの音声再生時」に発生したことが致命的で、どうすることもできないので断念することとなった。

そもそもWindowsは音楽制作専用である。他にWindowsを使う機会はない。 厳密に言えばそこから派生した作業もWindowsですることになるが、中核になるのは音楽制作であり、それがなければWindowsはいっそなくても構わない。

だからASIOでの音声再生でフリーズする、というのは音楽制作に使用できないということであり、私としては全く価値がない。

記事としては「Windows 10 プリインストールなP720でWindows 7を動かす」というテーマだからここから先は重要ではないとも言えるんだけど、私としては10日程度を無駄に費やしてここからがスタート地点ということになる。

とりあえずDTM系ソフトウェアは2台に対してアクチベーションが可能なものが多いので、P720 Windows 7は諦めて、 Z400 Windows 7とP720 Windows 10に対して構築していく方針としている。

P720のWindows 7もASIOで落ちたりしていたのだが、アップデートで落ち着いたようだ。

SONAR X3は残念ながらWindows 10では動かない部分がある。 D-Proが動かなかったような気がする…D-Proは私の主力なのでなくなると大変痛い。

(D-ProはどのみちSONAR以外では利用できないようになっている)

DTMの話は続きとして書いていたのだが、主旨の全く異なる話になったため、分割する。