NISA とか確定拠出年金とか

昨年転職したときの話です。 これまで働いていた企業では企業型確定拠出年金の制度がありました。 しかし、新しい職場では年金制度がないので、個人型の確定拠出年金に移換しなければなりません。 というわけで確定拠出年金制度 (DC) について再確認することになりました。

加えて今年から NISA が始まりました。 多少は株の売買もすることはありますが、私自身の本職はあくまで IT 企業に勤める会社員です。 なので、あんまり手間をかけたくはないのですが、かと言って NISA という制度についての基本的な知識がないと損するような気がしてしまいます。

このように NISA や DC の運用を確認したい、そんなときに頼れる参考書を紹介しておきます。 山崎元著「全面改訂 超簡単 お金の運用術」です。

本書では「お金の運用が仕事でもないし趣味でもない」人に向けて簡単でほぼベストな運用方法を紹介することを目的としています。 ここには詳細を書きませんが、第一章の冒頭で早速結論が提示され、投資信託を中心に複数の金融商品を組み合わせた運用が紹介されます。 確かにこれを実践するのは難しくはありません。

そして、そのあとに何故それがベストなのかの説明が続きます。 興味の程度によっては理由付けを軽く流しても良いと思いますが、どの金融商品が投資に向いていて、どれが投資不適格なのかがきちんと説明されています。

更に冒頭に紹介したように NISA や DC、そして生保や資産としての住宅の位置づけなども説明され、本書を通して読むことで一通りのマネーリテラシーを身に着けることができます。 大半の人にはこれで十分な知識であり、かつ大半の人は現状これらを理解できていないというような内容になっているはずです。

興味がある方は、まず NISA と DC についてこの記事を読んでみましょう。 そして、筆者の考え方に納得したら、Kindle 版であればワンコインで買える程度の価格なので是非本書を買って読んで欲しいです。 特に金融機関に普段縁がないものの漠然と金融商品に手を出そうかと考えている方は、必ず金融機関に行く前に本書を読みましょう。 若い方にもおすすめです。

iPhone の無料アプリで耳コピ

耳コピについては以前もいろいろ書きましたが、今回は「THR Session」というヤマハ製 iOS 用アプリの紹介です。 ざっと特徴を書いてみます。

  • ギター/ベースパートの抽出機能とキャンセル機能がある
  • テンポを 100% ~ 50% の範囲で設定可
  • ピッチを半音単位で最大全音上下できる
  • A-B 間リピート機能

ピッチ変更の機能が弱い気がしますが (ベースはオクターブ上げとかしたくなるかも知れないので)、耳コピ用の再生ツールとして基本的な機能は備えています。 何といっても THR のアンプの方を買っていなくてもこのアプリは無料で使用できることが最大の特長でしょう。

ただし、再生専用です。 つまり、iOS 機器用音声インターフェイスを使ってギター入力を iPhone で受けることはできません。 エレキギター (ベース) を合わせて演奏するには iPhone からの出力とギター出力をミックスするための機器が必要です。 もちろんヤマハのお勧めは THR アンプと組み合わせて使うことです!

また、対応機種に含まれていないので、iPad では使えないようです。

THR Session

操作はこちらサイトの「特長」の詳細を見れば大体わかるのですが、音源は音楽ライブラリの中から選ぶことになるので iTunes を使って iPhone に取り込んでおきます。 トグルボタンを右に倒せば抽出 (耳コピ) モード、左に倒せばキャンセル (カラオケ) モードとなります。 ベースの場合は下部右から 2つめのアイコンをタップして「BASS MODE」を選択し、トグルボタンを右に倒すだけで耳コピ作業に入れます。

ギターの場合は拾う (キャンセルする) 音域を「GUITAR HIGH MODE」、「GUITAR LOW MODE」のどちらかに選択します。 また、アンプキャビネットに現れる楕円の範囲を指定することでどのパン位置の音を拾うかを設定できます。

楽器を弾きながら耳コピする場合はパソコンよりも iPhone ぐらいのデバイスの方がやりやすいという人も多いと思うので、興味があれば是非試してみてください。

四本足二段のキーボードスタンドのベストバイは?

キーボードと言っても、コンピュータの入力装置でなく楽器の方のお話です。

いつかは壊れる機材たち

Roland の足鍵盤 Roland PK-7A (主に息子が使用) をヤマハ PF70 という FM 音源ピアノ (笑) と組み合わせて使っていたのですが、PF70 の方はさすがに年代もの (25年物!) の機材で先日お亡くなりになってしまいました。 そこで、PK-7A はシンセと組み合わせて使用することにしたのですが、PF70 の専用スタンドの他は一本足の ULTIMATE AX-48 しかありません。 足鍵盤を使うにはやはり四本足だろうということで、2段で使える現行のモデルを調べてみました。

四本足のキーボードスタンド

一昔前 (何年前?) で四本足と言えばヤマハの LG-100 をオプションの LGA-100 と組み合わせて 2段にするのが標準的だったと思います。 ところが、残念ながら LG-100 は生産終了しており、ヤマハの現行品で 2段にできるものは無いようです。 2段、3段にシンセを積んだキーボーディストがいるようなバンドはいまどき流行らないようなので仕方ないのでしょう。

KIKUTANI の KS-101 + AD-25 という組み合わせを見つけましたが、カスタマーレビューと AD-25 の写真を見るとアダプターの取り付け部が不安です。 結局、K&M の 18950 + 18952 にすることにしました。 そして、セッティング後がタイトルバックの写真です。 (全体がわからなくてすみません。周囲をお見せできる状況でなく…)

幅や高さ、上のキーボードの角度調整など十分納得できるレベルで、剛性も問題なさそうです。 足の先端は角度が自由につけられ、またネジで長さの微調整もできるのできちんとセットすればガタつくことはありません。 スタンドを補強するバーのアダプター用として使わない側の穴はキャップでふさぐことになりますが、これを入れるには結構力が必要なので、ハンマーで (できれば木などを当てて) 軽くたたいて入れます。

一つだけ注意点があって、前後があるので間違えずに組み立てる必要があります。 メーカーステッカーが貼ってある方が前かと思っていたらそうではなく、18952 を止めるためのネジ穴が後ろになるようにしなければなりません。 私はこれを間違ったため、穴塞ぎキャップを取るのに手こずりました。 18952 と組み合わせたことによって、どうせ 2つは不要になるので、ドリルで穴を開けてペンチで引き出しています。

参考までに四本足以外のタイプについてコメントしておくと、X型はやはり一本足同様足鍵盤との組み合わせは厳しいでしょう。 HERCULES KS410B は良さ気でしたが幅が足りませんでした。

オールドスタイルなのでしょうが、自分の買った 18950 + 18952 の組み合わせにはとても満足しています。

git-svn と GitHub を使ったワークフロー

WordPress のプラグイン開発で WordPress.org の Subversion リポジトリと GitHub を使っているのですが、最近ようやく git-svn を使ったワークフローをどうやったら良いかがわかってきたので要点をまとめておきます。

git-svn のワークフローのポイント

基本的なワークフローはここに書いてある通りです。 ポイントは以下の点です。

  • git svn dcommit は master ブランチで行う
  • リリース時に master、remotes/origin/master、remotes/trunk が同じコミットを指すように心がける
  • そのためには、リリース時は git svn dcommit してから git push する
  • Subversion リポジトリへのコミット回数を減らすには git merge –noff を使う。

リンク先記事は英語ですが、コマンドを自分で打ってみれば何をやっているかわかると思います。 –no-ff や –ff オプションについてはこちらの記事がとてもわかりやすいです。 私が WordPress プラグイン開発で使用している具体的なコマンド例についてはこちらの記事をご覧ください。

どこでつまづくのか

git svn dcommit を実行したときに新たなコミットがつくられてしまうので、git のリモートブランチ感覚で remotes/trunk を扱うとまずいのです。 git commit –amend と似た動作と言えばわかるでしょうか。

次の図のようにブランチ master と work が同じコミットを指した状態で master 上で git svn dcommit をすると master と work は分岐した異なるコミットを指すようになります。

git-svn-dcommit
git svn dcommit 時の動作

このような動作なので、Subversion 追跡ブランチを作ってその上で git svn dcommit を行うと master と remotes/trunk が平行する状態になって困ります。 ですので、必ず master ブランチ上で git svn dcommit を行い、その後に git push origin master を行います。 このあたりを意識できないと git-svn をうまく使えません。

既にぐじゃぐじゃなんですけど

では、頑張って直してみましょう。 master ブランチでは Subversion trunk の最新版に更に修正が加わっているものとします。 git svn dcommit 時に reset されてしまうので、差異がないとうまく行かないと思います。

work ブランチを作って master をマージします。 -s オプションでとにかく master を正としてマージします。

$ git checkout -b work trunk
$ git merge -s recursive -Xtheirs --no-ff master

work ブランチ上で作業するのもポイントで、逆に最初 master 上で work ブランチをマージしてしまうと git svn dcommit を実行したときに ‘Transaction is out of date’ と怒られたりします。

必要であれば次のコマンドでメッセージを変更したコミットを作っておきます。 merge の時に –edit オプションを指定しても良いです。

$ git commit --amend

さて、master ブランチを使って git svn dcommit を実行しましょう。

$ git checkout master
$ git merge --ff work
$ git svn dcommit
$ git push origin master

この後 work ブランチは消去してしまっても構いませんし、以下のようにリセットしておいて次のマージ時に使ってもよいでしょう。

$ git checkout work
$ git reset trunk

いかがでしょうか? これでやっと git-svn に悩まされることなく WordPress プラグイン開発に専念できそうです。 この手順は Subversion と Git で平行管理していたソースを統合するときにも使えるように思います。

最後にお約束の宣伝ですが、Standard Widget ExtensionsThin Out Revisions をよろしくお願いします! (まだまだこれからですが、) 着々とユーザーも増えております (SWETOR)。

新しいテーマに切り替えました

このサイトのテーマを TwentyFourteen に切り替えました。 このテーマを使う方のためにメモ書きをしておきます。

Twenty Fourteen の機能

こちらの公式ページに使い方が説明されています。 日本語訳もありますが、1/9 現在では英文混じりなので最初から英語で読むのが良いような気がします。 日本語ではこちらの記事がとても参考になります。

ポイントとしては、

  • 3 カラム構成にできます
  • タイトルバーと左サイドバーにメニューを配置できます
  • 「おすすめコンテンツ (Featured Content)」を選択しておくとホームページに表示することができます

色の変え方

WordPress 3.8 のプレーンインストールだとタイトルバー&左サイドバー&フッターの色は黒のままで変えられません。 何で標準機能としてつけておかないのかよくわかりませんが、この部分の色をカスタマイズするための Fourteen Colors というプラグインがあります。 これを入れてカスタマイズしちゃいましょう。

同じテーマを使っていても色とメニュー、ウィジェットの配置、さらにアイキャッチ画像の選択でやはり個性が出ちゃいますね。

Jetpack と組み合わせた時の不具合

1/9 現在、Twenty Fourteen を Jetpack と組み合わせると Featured Content が表示されないという不具合が生じています。 次のバージョンで修正されるとのことです。

一応先のフォーラムリンクの中に暫定修正版の zip ファイルが紹介されていますが、アルファ版なので自信のない方は正式リリースを待った方が良いと思います。

スクロール時のサイドバー固定

拙作 Standard Widget Extensions を TwentyFourteen に対応させました。 このサイトのサイドバーの動作はこのプラグインによるものなので、興味のある方はは是非ダウンロードしてみてください。

TwentyFourteen のサイドバーは TwentyThirteen までのテーマと比べて以下のような特徴があります。

  • 2つのサイドバーだし、
  • ネガティブマージンを採用していてレスポンシブ Web デザインのために値がパーセント指定だったりするし、
  • padding とか z-index とか使ってるし!

この辺に対応するために苦労しました。 ただし、実際に TwentyFourteen に切り替えてみて、まだまだ改善の余地はあるような気はしています。 このサイトもプラグインも微妙な動作は調整していきますので、よろしくお願いします!

2014年が始まった!

2013年の我が家はいろいろなことがありました。 最近は簡単に実名に結びつく状態になっていて、家族のことを書くのは気がひけるので自分のことだけ言いますが、昨年は転職しました。 40代半ばでの転職だと周囲に驚いてくれる人も多いです。

転職したことが良かったのかどうかは、しばらく経たないとわかりません。 なので、結局はその選択で後悔しないかどうかを考えて動くしかないのだと思います。 リスクとリターンを考えて、転職するリスクとそのまま残るリスクのどちらを取るかということですね。 転職についてはそのうちエントリにします (2013年のやり残しです)。

1年前のエントリを見ると、そこに書いている目標はほとんど達成できていない気がします。 しかし、ここには書けなかった「転職、あるいは仕事のけじめ」という目標は達成できているので、気分は清々しいです。 その分、このブログはおざなりにされていたのですが、今年は 2013年の目標を継続して今度こそ達成できるようにしたいと思います。

ブログに時間をかけられなかった理由はもう一つあります。 WordPress プラグイン開発の方に時間を取られていたのです。 WordPress (特に自分のプラグインの動作に関わる部分) の変化が速かったので、それに合わせてバージョンアップするのに時間を取られました。 お陰様で、ご利用いただいている方の数は増えており、反応も良好なのですが、いまだキャズムを超えていませんw ようやっと日本語公式ページも用意しましたので (その1その2)、このエントリを読んだ WordPress 使いの皆様は是非一度 Standard Widget ExtensionsThin Out Revisions をお試しいただき、お気に入りの際は是非 SNS を使って拡散を!

一つ、お知らせです。 この年初でブログタイトルを「Hetarena.com」から「ヘタレな趣味の道」に戻しました。 せっかく、Twitter で記事の紹介をしていただいても、「Hetarena.com」がページタイトルに入っていると誤って Hetarena.com ホームページのリンクを辿ってしまう可能性があるのです。 まあ、Hetarena.com としても流行らなかったので良いでしょう。

固定読者がほとんどいないこのブログにこんなエントリを書いて意味があるかわかりませんが、自分としては区切りの意味合いもあります。 こんな感じで 2014年もマイペースにやっていきます。 今年もよろしくお願いします!

VMware Player の NAT ネットワークを極める

VMware Player では仮想ネットワークに「NAT」、「ホストオンリー」、「カスタム」、「LAN セグメント」などの種類を選ぶことができます。 ゲスト OS に検証用のサーバー OS を入れてセットアップする際に、更新モジュールをダウンロードする等の理由で外部と通信したいことは多いと思います。

外部接続を行うという点では「NAT」を選択するのがお手軽ですが、ゲスト OS がどのように外部へアクセスするのかが気になります。 ここでは NAT の設定に絞り、この時の挙動を詳しく知ることで様々な場面に適用するためのヒントをまとめます。 実際のところ、NAT ネットワークを押さえておけばいろいろな用途で使うことができます。 なお、この記事は Windows 版 VMware Player 6.0.1 を前提として書いています。

ネットワークの構成

下図は NAT 仮想ネットワークの構成イメージを図にしたものです。

VMware NAT network

仮想セグメントのネットワークアドレスは 192.168.203.0/24 となっていますが、これは VMware Player のインストール時に自動的に決まるもので、必ずしもこのアドレスになるとは限りません。 192.168.0.0/16 の中から割り当てられると思いますが (少なくとも私はそうでした)、あくまでも一例です。

割り当てられるのは /24 ネットマスクのアドレスで、第 4オクテットの .1 がホスト OS に、.2 が仮想ルータに割り当てられるようです。 ゲスト OS から見たときにホスト OS へはこの .1 のアドレスでアクセスします。 また、外部へアクセスする際は仮想ルータをデフォルトゲートウェイとして用います。 更に .254 で DHCP サーバーが動作 (※追記参照) しており、外部アクセスに必要な DHCP パラメータがゲスト OS に提供されます。 従って、ゲスト OS は DHCP クライアントの設定がされていれば何も考えずに外部と通信できます。

仮想ルータ

仮想ルータの動作についてもう少し見てみます。

  • 仮想ルータはゲスト OS のために NAT を行います。 ゲスト OS の通信は、外部から見るとゲスト OS の物理インターフェイスの IP アドレスで通信しているように見えます。
  • ゲスト OS 用の DNS サーバーがこの仮想ルータ上で動いています。
  • 仮想ルータ上の DNS サーバーは受け取った名前解決要求をホスト OS の設定に従って解決します。 ホスト OS のリゾルバを使って解決するという言い方でも良いと思います。 つまり、ゲスト OS としては仮想ルータを DNS サーバーとして使えば後はうまく動作するということです。
  • DHCP サーバーの設定はホスト OS の ProgramData\VMware\vmnetdhcp.conf に書かれています。

ホスト OS のインターフェイス

さて、ホスト OS からはネットワークアダプタとして VMnet1 と VMnet8 という名前のアダプタが見えます。 VMware Player をインストールすると、これらのネットワークアダプタには静的に IP アドレスが割り当てられます。 このうち VMnet8 が図中の赤の NIC に相当します。 このネットワークアダプタについて補足説明します。

ゲスト OS とホスト OS 間の通信はこのアダプタを介して行われます。 例えば Windows 環境であれば「start \\192.168.203.1」などのコマンドでゲスト OS からホスト OS の共有フォルダにアクセスできるということです。

また、このネットワークアダプタを無効にするとゲスト OS とホスト OS の間の通信はできなくなりますが、隣の仮想ルータは生きたままです。 つまり、ゲスト OS のネットワークアダプタ VMnet8 を無効にしてもゲスト OS は NAT で外部と通信できてしまうということなので、注意が必要です。

ちなみに VMnet1 は NAT 構成では使用しないので無効化して問題ありません。

ゲスト OS に固定 IP アドレスを割り当てたい時

ゲスト OS は普通にインストールをすると DHCP クライアントとなってしまいますが、固定アドレスを割り当てたいときもあると思います。 これを行う方法は 2つあります。

  1. 先の vmnetdhcp.conf の内容を確認し、DHCP の対象になっていないレンジから割り当てる。
  2. DHCP で割り当てるのはそのままにし、MAC アドレスを使って DHCP サーバーから割り当てる IP アドレスを固定する。

2 の方法については次節で説明します。

DHCP サーバーのカスタマイズ

ではゲスト OS に割り当てる IP アドレスを固定化するために DHCP サーバーの動作をカスタマイズしましょう。 やり方は以下の通りです。

  1. ゲスト OS 上でコマンド (ifconfig とか ipconfig とか) を使ってインターフェイスの MAC アドレスを確認します。 ここでは MAC アドレスが「00:0C:29:AA:BB:CC」だったものとします。
  2. vmnetdhcp.conf を編集します。 host VMnet8 のブロックの次に以下のように追加します。

    host CentOS {
      hardware ethernet 00:0C:29:AA:BB:CC;
      fixed-address 192.168.203.50;
    }
    
  3. ファイルを保存後、ホスト OS の「VMware DHCP Service」を再起動します。

これで私の環境ではゲスト OS に固定の IP アドレスを割り当てることができました。 好みの問題でしょうが、ゲスト OS の IP アドレスは DHCP を有効にしたままで vmnetdhcp.conf で管理した方が楽かも知れません。

なお、仮想ネットワークのネットワークアドレスを変更するには、このファイルの変更の他にレジストリの編集が必要なようです。 私はそこまで必要なかったので試していません。

まとめ

というわけで NAT 仮想ネットワークを使用してわかったことをまとめてみました。 このあたりが理解できると「ネットワーク接続 = NAT」の設定を利用しやすくなるのではないでしょうか。


追記 (2014/11/29)
初版では DHCP サーバーは仮想ルータ上で動くと書いていましたが、DHCP サーバーのアドレスは別であることに気付いたため内容を修正しました。

Cubase スコア機能の Tips 集

Cubase のスコア機能を使うときの Tips 集です。 個人的なメモ書きをもとにざっくばらんに書いてみました。 Cubase 7.5 で動作確認していますが、他のバージョンでも使える機能がほとんどだと思います。 目的ごとにまとまった記事を読みたい場合は、スコア関連の他の記事を探してみてください。

音符の置き方
基本ですが、音符はクリックして置くのではなく、マウスボタンを押したままドラッグして位置を調整するとうまく置けます。 それと初期設定では表示が細かいのでページ倍率を拡大しておきましょう。
小節番号を隠したい
スコア設定の「プロジェクト」-「記譜方法」の「小節番号表示の間隔」を「オフ」にします。 値の入れ方がわかりづらいですが、この項目は上下矢印キーで変更できます。 ただ、それでうまく「オフ」にできないときは「-1」を入力しましょう。 また、レイアウトを開き直さないと変更は反映されないようです。
臨時記号
異名同音は音符選択後、ツールバーの「#」や「♭」を押すことでどの記号をつけるか選ぶことができます。 ここに今一つ意味がよくわからない「?」ボタンもありますが、これを使うことによって、次の小節で元の高さに戻った時の「♮」(ナチュラル) を明示的に表示することができます。 個別にナチュラルを設定するのが面倒な時はスコア設定「プロジェクト」-「臨時記号」で「親切な臨時記号の長さ」を 1小節に設定しておくと幸せになれます。
バンドスコアの楽器表示順
バンド (あるいはオーケストラ) スコアの楽器の並び順はプロジェクトウィンドウの並びとなります。 スコアだけ並び順を変更することはできないようです。
コードトラックからコード名を表示
「スコア」-「高度なレイアウト」-「コードトラックを表示」でコードトラックに設定済みのコードをスコア内に表示することができます。 しかし、初期設定ではフォントサイズが今一つかも知れません。 これはスコア設定の「プロジェクト」-「コード記号」から変更できます。 なお、「maj7」か「△7」かとか、「m7」か「-7」かみたいな表記の指定は「環境設定」の「イベント表示」-「コード」で設定できます。
Adobe PDF への出力
最近は Cubase で作った譜面を PDF 化して iPad の piaScore に送ってスタジオ練習時に使ったりしているのですが、これは Cubase の設定ではなく、Adobe 製品の設定についてです。Cubase からの印刷で Adobe PDF へ出力先を変えて PDF 化しているのですが、このとき、Adobe PDF の設定で「システムのフォントのみ使用し、文書のフォントを使用しない」をアンチェック+「高品質」すると良いと思います。

いろいろ設定するといい感じのスコアに仕上がるのですが、様々な設定を毎回やるのは面倒です。 ですので、初期設定の終わったプロジェクトをテンプレートとして保存しておきましょう。 「ファイル」-「テンプレートとして保存」で保存すれば、新規プロジェクト作成時に保存したテンプレートを選択できるようになります。 また、Windows の場合、保存したテンプレートは以下の位置にあります。

ユーザーディレクトリ\AppData\Roaming\Steinberg\Cubase バージョン番号\Project Templates

バージョンごとにフォルダが作成されるので、 Cubase をバージョンアップしたときはこれらを移行させなければなりません。

Cubase 7.5 新機能紹介ビデオ視聴メモ

最近の Cubase の機能解説公式ビデオは YouTube で公開されています。 既に Cubase 7 関連のビデオについては日本語字幕もついており、初心者のとっかかりとしても中級者以上が新機能を知るためにも活用できる状態です。

今月 Cubase 7.5 がリリースされましたが、こちらについてはまだ日本語字幕はありません。 とりあえず、新機能紹介ビデオのうちの 4本についてメモをつくったので公開します。

この記事は動画内の画面操作の内容を把握するためのメモであり、正確な翻訳ではありません。 また、記述は英語と日本語混じりですが、修正の手間をかけずそのままにしてあります。 ご了承ください。 (気になる方は、いずれ日本語字幕が公開されるのでしょうからそちらを待ちましょう)

TrackVersions

歌の出だしでどちらのドラムパターンが良いかドラマーとプロデューサーの間で意見が分かれたとします。 これまでの比較方法は、複製して頭のみ変えたバージョンのトラックを作り、ミュートを切り替えて比べることでした。 これをトラックバージョンでやってみます。 プロデューサーが気に入ったバージョンをフォルダートラックに突っ込み、「=」をクリックしてグループ編集を有効化します。 Duplicate Version を選んで複製バージョンを作り、冒頭のみ演奏・録音し直します。 区別できるように各バージョンに名前をつけることができます。

このように余計なトラックは不要で、簡単に2つのバージョンを切り替えることができます。 オーディオトラックだけでなく様々なトラックでも Track Version の機能を使うことができます。

次の例では New Version を選んで2つめのバージョンを作成します (2:37 ~)。 それぞれのバージョンの前半と後半を組み合わせたいときはでバージョン間でカット&ペーストができます。 それぞれのバージョンをオーディオファイルにエクスポートするのも簡単です。

インスペクター上のメニューよりワンクリックでバージョンを切り替えることができます。 バージョンからレーンを作ったり、逆にレーンからバージョンを作ることができます。 バージョンの切り替えは Ctrl-Shift-H, Ctrl-Shift-G で簡単にできます。 Assign Common Version ID を選んで共通の ID を振っておけば、Select Track with Same Version ID を選ぶことで複数のトラックのバージョンを一気に切り替えることができます。

Track visibility management

MixConsole だけで使えていたチャネル選択表示機能がプロジェクトウィンドウでも使用できるようになりました。 MIDI のみ、ドラムトラックのみ等のトラックの種別ごとに表示/非表示を切り替えるプリセットが用意されています。 この機能はトラックの多いプロジェクトに有効です。

インスペクターの Visibility タブで白丸が表示されるトラック、黒丸が隠されるトラックです。 マウスクリックの他、インスペクターエリアで矢印キーと Enter キーを使って簡単に表示/非表示を切り替えることができます。 Shift キー + クリックでそれ以外のトラックを一括で非表示にできます。 複数のトラックを選択後、丸をクリックすれば選択されているトラックの表示/非表示を切り替えることができます。

Create Configuration で表示/非表示状態を保存しておくことができます。 複数の設定を作って簡単に切り替えることができます。 「ファイル」-「キーボードショートカット」でキーコマンドを設定しておけば更に簡単に切り替えらます。 ここでは 2つの設定にそれぞれ Ctrl + Alt + 1、Ctrl + Alt + 2 をアサインしてみます。

表示/非表示状態の設定はプロジェクト固有の設定、キーコマンド設定は複数のプロジェクトで共通の設定です。

一度保存した設定を変更するには Update Configuration で更新できます。 設定名称前の星印は変更されているという意味です。 Synch with MixConsole で MixConsole の表示もプロジェクトウィンドウの状態にリンクさせることができます。 1度にリンクできるのは 1つの MixConsole のみで、異なる MixConsole を選択すれば既存のリンクはなくなり新たなリンクのみとなります。

Filter (特定のトラックタイプで表示) は簡単な選択方法ですが、Visibility Agent (条件で表示) を使うとさらに柔軟な選択ができます。 表示/非表示切り替え操作は Undo/Redo できます。 プリセットの条件では不足する場合はプロジェクトロジカルエディターで自分の Advanced Agent を作って表示/非表示を切り替えることができますよ!

Workflow Enhancements

ヒットポイント検知

Cubase 7.5 では自動ヒットポイント検知が簡単になりました。 スレッショルドレベルを調整してウィンドウをクローズします。 オーディオファイルが録音されたりインポートされたときに Cubase はヒットポイントを自動的に計算します。 ヒットポイントは音楽的に意味のあるタイミングを示します。 ヒットポイントはタイミング調整や移動に使用できます。 最少レングスを設定することで、ボーカルトラックに適切な (短すぎない) 間隔のヒットポイントを作成できます。 Alt + N と Alt + B でヒットポイントを移動できます。

ドラムを録音したオーディオトラックのタイミング調整をしたりエンベロープをつけたいとき、「ヒットポイント位置でオーディオイベントを分割」を実行し、クオンタイズをかけたり、個別に音量やフェードイン/フェードアウトを設定できます。 ヒットポイントの計算には時間がかかるので、環境設定で無効化することができます (「編集操作」-「Audio」)。 自動化されて使いやすくなった、ヒットポイント機能を活用しましょう!

Re-Record (2:56 ~)

トランスポートバーの一般録音モードで「再録音」を選んでおくと録音時に更に録音ボタンを押せばすぐにやり直しの録音を始めることができます。 最後のテイク以外もプールのごみ箱の中に残されています。 この機能はオーディオトラックだけでなく MIDI トラックでも使用できます。 (いろいろ、大げさなことを言っていますが、機能はシンプルなので省略)

スコア機能 (5:21 ~)

スコアエディターでキーエディターと同等の MIDI 機能が使えるようになりました。 コードエディット機能も使えるようになり、コードを入力したり、転回させたりドロップさせたりもできます。 キーエディターと同等の MIDI 機能を持ったことで、スコアエディターを更に活用いただけると思います。

Instrument (t)rack 2.0

Cubase 7.5 ではインストゥルメントトラックが複数の MIDI 入力に対応したので、これまでのようにインストゥルメントトラック vs. インストゥルメントチャネルの使い分けを悩まなくて済みます。 HALion Sonic SE 2 のインストゥルメントトラックを作成したあと、MIDI トラックを作成すると、既にこのトラックのアウトプットに HALion Sonic SE 2 が選ばれて次の MIDI チャネルに設定されています。 HALion Sonic SE 2 で 2つめの音色を選び、追加のアウトプットをアサインします。

複数のトラックを選択しておけば、それらをまとめてトラックプリセットとして保存できます。

インストゥルメントトラックと VST インストゥルメントラックの関係も緊密でわかりやすくなりました。 インストゥルメントトラックのインスペクターでマルチアウトのオーディオ出力を追加して有効化することができます。 (昔はラックからしか行うことができませんでした)

Groove Agent SE 4 でマルチアウトを設定し、各パートの出力を振り分けてみます。 MIXConsole できちんと振り分けられているのが確認できます。 アウトプットチャネルの名前を変更することもできます。 それぞれ独立してエフェクトや EQ をかけることができます。

トラックに戻って Beat Designer をインサートします。 これらをトラックプリセットとして保存します。

空のプロジェクトで先ほど保存したトラックプリセットをオープンしてみます。 マルチアウト、Beat Designer、チャネルストリップ全部が一つのプリセットとして保存できているのです!

インストゥルメントトラックとして追加したインストゥルメント (Track Instruments) とラック上で追加したインストゥルメント (Rack Instruments) は区別されて共にラック上に表示されます。 このようにシングルビューで把握できるようになりました。 ラック右上の三角ボタンでクイックコントロールを表示することができます。 また、クイックコントロールのツマミ上のコンテキストメニューよりオートメーショントラックを表示することができます。 ラックインストゥルメントについてはクイックコントロールに表示するパラメータを指定できます。 「Learn CC」で MIDI コントローラーのコントロール番号を学習することもできます。

デバイス設定画面で確認できるように「VST クイックコントロール」には独立して専用のリモートコントローラーを割り当てることができます。

WordPress のリビジョン機能の変更について

WordPress で 2年以上メンテナンスされていないリビジョン削除プラグインを使用しているという記事を最近どこかで見た気がするので、それはマズいという話を書いておきます。 以前も WordPress のリビジョン機能についての説明記事を書いたことがありましたが、この後 WordPress のバージョンが 3.6 に上がった時にリビジョン機能に大きく変更が加えられました。 その WordPress 3.6 リリースのタイミングで公開しようとして下書き放置のままになっていた新たな説明記事を、警鐘目的でこのタイミングで完成することにしたのです。

WordPress 3.6 では GUI だけでなく内部的にも大きな変更が加わっているのですが、まずは先の記事からの差異をまとめます。

WordPress 3.6 になっても変わらないこと

以前の記事で書いている内容のうちの以下の点は WordPress 3.6 以降でも変わっていません。

  • 自動保存は 1世代のみ。
  • リビジョンが作成されるのはポストテーブル (wp_posts) 内容のみ。 wp_postmeta や wp_term_relationships などの関連テーブルは (プラグイン等を用いない限り) リビジョンが作成されない。
  • 通常の一記事表示ではインデックスを使用した検索になるので、ポスト数が増えても検索時間は比例して動作が遅くなることはない。

WordPress 3.6 から変わったこと

さて、肝心の何が変わったかですが、GUI の変更については言わずもがなで以下の点が変わっています。

  1. 現行の投稿と同一内容のリビジョン (ここではコピーリビジョンと呼ぶ) を持つようになった。
  2. 投稿を修正せずに「更新」を実行しても新しいリビジョンは作成されなくなった。デフォルトでは更新時に Title/Content/Excerpt が同じであればリビジョンは作成されない。

特に問題となるのは 1. です。 冒頭の話に戻りますが、WordPress 3.6 のリリースは今年なので、2年以上放置されているプラグインは当然この変更に対応できていません。 ですので、本来必要なコピーリビジョンまで削除してしまい、その結果何らかの不具合が起こる可能性があります。 一般的に言って、内容を見て判断できないのであれば 2年以上放置の警告が出ているプラグインには手を出さない方が良いでしょう。

更新処理の変化

ここからは先は拙作 Thin Out Revisions を WordPress 3.6 に対応させたときに調べた内容を整理したものです。 WordPress の実装に興味がある方はどうぞ。 そうでない方も Thin Out Revisions はきちんと WordPress の更新に対応しているということはご理解いただき、是非一度このプラグインを試してみてください (とりあえず宣伝)!

では、コピーリビジョンを持つようになったことで投稿の更新処理がどのように変わったかを見てみましょう。 下の図は WordPress 3.5 までの更新処理を DB のレコードレベルで表したものです。 同じ内容は同じ色で表しています。

Update flow 3.5

一度だけ更新を行った投稿は図中 1. のようにリビジョンを一つ持ちます。 これを更に更新したときはまず 2. のように投稿の内容をコピーして新しいリビジョンを作成してから 3. のように入力内容で投稿を更新処理します。

これが WordPress 3.6 になると下の図のようになります。

Update flow 3.6 一度だけ更新を行った状態では、図中 1. のように 2つのリビジョンが作成されています。 更新処理も 2.、3. で示すように先に投稿を更新し、後からそれをコピーして新しいリビジョンレコードを作成します。 コピーとレコード更新の順序が 3.5 までと比べて逆になっていることがわかると思います。

3.5 以前で作成した投稿+リビジョンのマイグレーション

3.5 以前のバージョンから 3.6 (恐らく 3.7 も) にアップグレードすると、特に明示的な操作を行わなくても既存の投稿について自動的にコピーリビジョンが作成されます。 これは WordPress をアップグレードするタイミングではなく、管理画面での投稿に対する操作のタイミングで行われます。 処理の実体は _wp_upgrade_revisions_of_post という関数で、wp_posts テーブル内各リビジョンの post_name が *-revision-v1 に変更され、コピーリビジョンが作成されます。

ただ、私の場合、自動マイグレーションがうまく行った投稿とうまく行かない投稿がありました。 バージョンアップは 1度きりのことなのできちんと調べませんでしたが、とりあえず Thin Out Revisions ではコピーリビジョンを持たない投稿があると警告するようにしておきました (再度、宣伝!)。 投稿編集画面でこの警告が出たときは、一度何も変更せずそのまま更新ボタンを押すことをお勧めします。

ついでに変更有無のチェックについて

更新時の変更有無のチェックは、デフォルトでは Title/Content/Excerpt が比較されると書きましたが、他の項目も加えるには _wp_post_revision_fields フィルターを作成して調整します。 そもそも変更有無にかかわらずリビジョンを作りたいという時は wp_save_post_revision_check_for_changes フィルター関数を作って false を返すようにします。 詳しくは wp_save_post_revisions のコードを読んでみましょう。

最後に

しつこいですが、最後に宣伝させてください! Thin Out Revisions はきちんと WordPress のバージョンアップに対応しています。 間もなくリリース予定の WordPress 3.8 では管理画面のビジュアルが変わるのですが、これへの対応も近々リリースする予定です。 また、リビジョンにメモをつける便利な機能もついています。 是非一度使ってみてください!