DRYな備忘録

Don't Repeat Yourself.

Pythonでdictionaryの各要素に処理を加えた別のdictionaryをつくる

TL;DR

>>> { k:list(map(lambda s: int(s)**2, v.split('-'))) for (k,v) in src.items()}
{'foo': [1, 4, 9], 'bar': [16, 25, 36]}

f:id:otiai10:20190412125100p:plain

やりたいこと

入力

{
  'foo': '1-2-3',
  'bar': '4-5-6',
}

出力

{
  'foo': [1, 4, 9],
  'bar': [16, 25, 36],
}

みたいなこと。

解決

src = {'foo': '1-2-3', 'bar': '4-5-6'}

dest = {
    k: list(map(
            lambda s: int(s)**2,
            v.split('-'),
    )) for (k, v) in src.items()
}

# {'foo': [1, 4, 9], 'bar': [16, 25, 36]}

知見

  1. dictは、itemsメソッドで、(key, value)のタプルのリストが得られる
    1. 正確には得られるのはdict_itemsであり、appendなどは無いが、リストとして扱う上では困らない
  2. タプルのリストはforでそれぞれ多値を拾うことができる
    1. for (name, age) in [('otiai10', 100), ('otiai20', 200)] のように
  3. map関数でリストのそれぞれの要素に対して処理をapplyできる
    1. ただし、この返り値はmap objectであり、listではないので、list()でリストにしてやる必要がある
  4. 文字列分割はstr.split(delim)
  5. 無名関数をlambdaで作ることができる
    1. ただし、複数行のlambdaをつくることはできない?っぽいので、見通しも悪くなるので関数は別定義したほうがよい
  6. dictの初期化において、keyにも変数を使える
    1. 下記参照
>>> key = 'name'
>>> val = 'otiai10'
>>> {key:val}
{'name': 'otiai10'}

WETな備忘録として

Go1.11でAppEngineをはじめる

tl;dr

これの通りです

うごくやつです

作業環境

% gcloud -v
Google Cloud SDK 235.0.0
app-engine-go
app-engine-python 1.9.83
bq 2.0.41
cloud-datastore-emulator 2.1.0
core 2019.02.15
gsutil 4.36
% go version
go version go1.11 darwin/amd64

Overview

  1. プロジェクトの作成とRegionの設定
  2. ローカルで開発
  3. デプロイ
  4. 確認

プロジェクトの作成とRegionの設定

プロジェクトIDで、ローカルのSDKを設定しておく

% gcloud config set project otiai10-sandbox

ローカルで開発

% mkdir -p $GOPATH/src/github.com/otiai10/gae-go-sandbox
% cd $GOPATH/src/github.com/otiai10/gae-go-sandbox
% vi main.go

main.go

package main

import (
    "fmt"
    "net/http"
    "os"

    "github.com/otiai10/marmoset"
)

func main() {
    router := marmoset.NewRouter()
    router.GET("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hi"))
    })
    router.GET("/hello", func(w http.ResponseWriter, r *http.Request) {
        message := fmt.Sprintf("Hello, %s!", r.FormValue("name"))
        w.Write([]byte(message))
    })

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    fmt.Println("Listening port", port)

    http.ListenAndServe(fmt.Sprintf(":%s", port), router)
}

ローカルでの挙動確認

% go run main.go
Listening port 8080

f:id:otiai10:20190226123753p:plain
http://localhost:8080/hello?name=otiai10

いいかんじ。

デプロイ

app.yamlつくる

% vi app.yaml
runtime: go111

おしまい。

% gcloud app deploy
# もしかすると
# gcloud auth login
# が必要かも

とすると、

Updating service [default]...failed.
ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build 01b7bef8-3e62-4956-9bc6-8e3a4b4cb1fe status: FAILURE.
Build error details: go: finding github.com/otiai10/marmoset v0.4.0
go: finding golang.org/x/net v0.0.0-20190225153610-fe579d43d832
go: downloading github.com/otiai10/marmoset v0.4.0
.
Check the build log for errors: https://console.cloud.google.com/gcr/builds/01b7bef8-3e62-4956-9bc6-8e3a4b4cb1fe?project=199462931903

言われたとおりエラーログ見に行くと、

f:id:otiai10:20190226134218p:plain
上記のエラーログ

GCR(コンテナレジストリ)へのイメージのアップロードで403を食らっているような雰囲気がある。ためしに、コンテナレジストリのコンソールに行くと。

f:id:otiai10:20190226134342p:plain

ふむ。Quick Startのドキュメントをよく見ると

Before you begin

Use the GCP Console to create a Google Cloud Platform project, choose a region where you want your application's resources to be located, and enable billing:

https://cloud.google.com/appengine/docs/standard/go111/quickstart#costs

とある。たぶん、AppEngineが使うストレージとは別に、GCRが使う領域を追加するのに課金の有効化(金がかかるとは言っていない)が必要だと思われる。ので、ここ https://console.cloud.google.com/billingから、このプロジェクトの課金を有効化して、再度GCRを見に行くと、

f:id:otiai10:20190226134743p:plain

見えるようになった。気を取り直して、

% gcloud app deploy
# 中略

Deployed service [default] to [https://otiai10-sandbox.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

いいかんじにコマンドは成功した。

確認

f:id:otiai10:20190226135054p:plain

いいじゃん

雑感

DRYな備忘録として

tigが「dyld: Library not loaded」とか言うので、ソースからコンパイルして使う

背景

tig好きなんですよ。だけどbrewから入れようとしたら以下の症状になるんで、手元でコンパイルすりゃいいか、となりました。

qiita.com

tigとは

これ

github.com

tigの良さについて過去に備忘録書いてるかと思ったら書いてなかったので、自分使いの例で言うと

  • tigとすると、git logがめっちゃ見やすく出るやつ
    • jkカーソル移動でpatchの内容も開ける
  • tig blame とかすると、line by line のblameだけではなく、当該blameを含んだpatchが見れるので、意図をblameできる

みたいなやつです。とにかく入れてみてtigと打ちましょう。

f:id:otiai10:20190116100954p:plain
tigの図

ゴール

参照

ログ

brewで入れちゃったものがある場合、まずこれ

% brew uninstall tig

ソースの取得

# このへんは気持ち。手元コンパイルするツールはこの中においてるだけ。
% mkdir -p ~/opt/src
% mkdir -p ~/opt/bin
% cd ~/opt/src
% git clone https://github.com/jonas/tig.git
% cd tig

コンパイル

% make
# ログからは分かりづらいが、成果物の実行可能ファイルが
# src/tig に配置されている。

確認

% ./src/tig --version
tig version 2.4.1-7-g93ea970
ncurses version 5.7.20081102
readline version 8.0
%

いい感じ。PATH通す

% ln -s ./src/tig ~/opt/bin/tig
% export PATH=${HOME}/opt/bin:${PATH}
% which tig
/Users/otiai10/opt/bin/tig
% tig --help
tig 2.4.1-7-g93ea970

Usage: tig        [options] [revs] [--] [paths]
   or: tig log    [options] [revs] [--] [paths]
   or: tig show   [options] [revs] [--] [paths]
   or: tig blame  [options] [rev] [--] path
   or: tig grep   [options] [pattern]
   or: tig refs
   or: tig stash
   or: tig status
   or: tig <      [git command output]

Options:
  +<number>       Select line <number> in the first view
  -v, --version   Show version and exit
  -h, --help      Show help message and exit
%

おしまい。

DRYな備忘録として

Travis-CIによるイベントホームページ自動デプロイと告知ツイートの自動化 #YUKEMULI

背景

自分が関わっているイベントのホームページをGitHubで管理、GitHub Pagesでホストしているんですが、

  1. masterブランチが更新されたら自動でデプロイしたい
  2. ホームページの更新内容ってほとんど「イベントに関する新しい情報」に他ならないので、これを自動で告知としてツイートできればいいのではないか

という気持ちがありました。

TL;DR

1月19日(土)に鶴見のスーパー銭湯でDJイベントやるから風呂入るついでに顔出してくれるとそれはとってもうれしいな!

yukemuli.dance

Hugoによる静的サイト生成

前々より、僕自身は「GitHub PagesでホストするんならJekyllでいいじゃん、カスタマイズしやすいし」派だったのですが、 いかんせんJekyllだとGitHub Pages用にすぐ使えるテーマが少ないという問題があります。自分でTheme書けるんだったらJekyllで十分良いと思うんですけどね。

そこでちょっと前に話題になったHugoです。Hugoというのは、静的サイト生成ツールであり、Markdownで書いといたらいい感じのHTML吐いてくれる、みたいな雑な理解です。

gohugo.io

Goで出来てるとかビルドが早いとかは顧客価値ではないと思うので置いといて、特筆すべき点は、そのThemeの開発しやすさ・自作Theme開発後簡単にデリバリできるエコシステム、結果として利用可能なテーマが豊富にあるというところだと思います。

実際、今回はデザインに関してはベースになるテーマをオーガナイザDJのたこっぷ氏に選んでもらい、すきまき先生アートディレクションのもと、僕が実装する形だったので、ある程度テーマができていて選択肢が多いhugoが良いかという技術選定でした。

HugoとTravisの連携と自動デプロイ

ただし、Hugoは(今のところ)GitHub Pagesにサポートされていないため、自動でGitHub Pagesに反映(便宜的にこれをデプロイと言ってます)するためには、たとえばindex.htmlを更新するコミットをCI上で作成 & Repoにプッシュするという要件が発生します。

その点、Jekyllはめっちゃ楽なんですよ、ビルド済みHTMLをコミットする必要が無いので。

ここでHugoのGitHub Pagesへの自動デプロイの詳細は解説しませんが、インターネッツに参考例がゴロゴロしているのでぜひ厳選のうえご参考ください。

強いて注意点があるなら、

  1. コミット&プッシュするアカウントのSSH PRIVATE KEY を、Travisが提供する暗号化を施してプロジェクトに含める必要がある
  2. 以前にJekyllによってGitHub Pagesがビルドされたことがあるリポジトリには.nojekyllという空ファイルをコミットしJekyllを使わないことを明示する必要がある

という2点が重要な知見でした。

ホームページ更新内容と「告知」の概念

さて、一方で「イベントの告知」というオペレーションについての知見なのですが、これは常々巧いなあと思っているとーま先輩から着想を得ました。

彼はイベントの情報を一挙に公開せず、小出しにすることにより告知機会そのものを増やし、自然と露出・拡散が促されていました。

「段階的に情報を小出しにする」という特徴は、gitのコミットに非常に親和性があると思われます。

そこで、コミットメッセージを告知サマリとすることでコミットログから告知文言を自動生成するという結論に帰着し、これを実装しました。

このへん👇

github.com

今後の展望

もちろん、コミットメッセージを告知サマリにする、ということは「適切なコミット単位」を意識し、意味のあるコミットログを積み重ねていくことに他なりません。ので、開発やっててとてもたのしいです。

それと同時に、不可避的に「告知する必要の無い開発案件のコミット」も発生するので、今後はこれを除外していく仕組みも必要かと思われます。

現時点では、コミットメッセージに DONOTANNOUNCE: みたいなのをつけたらそのコミットメッセージは告知ツイートに含めない、みたいなのでいっかなーって思ってる。

あと、コミットログの取得→リリースアナウンス、みたいなワークフローはわりと他のプロジェクトでも使うので、インターフェースを整えてこれをnpmパッケージに切り出すのも面白いかな、と思います。

まとめ 告知

1月19日(土)に鶴見のスーパー銭湯でDJイベントやるから風呂入るついでに顔出してくれるとそれはとってもうれしいな!

yukemuli.dance

前半はまったり寝転がったりできる「宴会モード」。後半はVJもつけて「クラブモード」となります。会場の「ラクスパ鶴見」がふつうに良いスーパー銭湯なので、スーパー銭湯をメインディッシュに、ちょっと顔出してくれるだけでもオッケーっす!

お待ちしてます ;)

DRYな備忘録として

さようなら、CWL

このエントリは、 Common Workflow Language (CWL) Advent Calendar 2018 - Qiita の25日目です。

tl;dr

CWLって何よ

2017年4月にベルリンから逃げ帰って、某大学研究所に研究員として就職しました。当初は、自分が持ってるバイオインフォの個人事業で独立しようと思っており、半分はその営業・コネクション作りのつもりで行ったのですが、なんやかんやでそこで働くことになってました。今にして思えば、よい判断だったと思います。理由は最後のほうで書く。

ゲノム解析のプラットフォーム構築、あるいはその技術検証」というようなミッションで、ゲノム解析の実情・課題国内のスパコンの利用実態、日本および海外のクラウドサービスの利用状況、Docker / Singularity を用いた仮想化・再現性の担保などの研究?実装をしました。

そんな中、国際学会でもにわかに注目を集めていたのが「Common Workflow Language」略して「CWL」です。

CWLって何よ、っていうのは、この辺見たらよろしい。

世界中のゲノム解析作業者(←そのすべてが「バイオインフォマティシャン」とは限らないところがミソ)がそれぞれのスパコンのスペックで、秘伝のパッケージがインストールされた環境で、秘伝のシェルスクリプトを丹念につくりあげて論文を発表するも、当然それでは再現性が無かったりしてどーなのよ、となるのを「じゃあ統一記法があったらいいんでしょ」って発想で「Common」な「Workflow」の「Language」を 作りたかったらしい 作ったのが「Common Workflow Language」です。

正直しんどい

「お、じゃあいっちょCWLの思想信条を理解するのも兼ねて、エンジンをつくってみよじゃないの」と思ってGoによるシンプルなエンジンの実装を始めたんですけど、これがまた、しんどい。色々な概念をモリモリにしてしまって、仕様が収集つかなくなってる感じがあります。

細かいことは、去年 Webプログラマから見た「CWL」の功績と罪過 - DRYな備忘録 でガッツリ書いたのでここでは詳細は割愛しますが。

すっげー乱暴に言ったら、哲学が先行しており、実践がついてきてなくね?という感じです。

帰納的アプローチ

CWL自身も「いや、ウチは別に絶対的な統一記法を発明しようとしているわけちゃうよ?」「他にもいろいろあるからええやつ選んだらええんちゃう?」という態度です。

であるのであれば、無理にCWLに追従するのではなく、独自のワークフロー記法を作るぐらいの勢いでやるのがいいんじゃないかと思うんですが。

そのとき、CWLのように「かくあるべき」から降りてきて、途中途中に要求を吸収していくようなやり方ではなく、それぞれの参加者がそれぞれの業務フローに特化したソフトウェアをまずつくり、共通概念を抽出していくような、いわば帰納的なアプローチを取るべきだ(あるいはCWLはそういうアプローチを取るべきだったのではないか。まあそれをやるにはワールドワイドすぎるとは思うけど)と思うわけです僕は。

そんなわけで、ってほど必然性は無いんですが、僕は仕事の一環で「クラウドサービス上で任意のワークフローを動かし結果だけを得るエンジン」を作っておりました。「hotsub」っていうんですけど。

名前が某ポルノサイトに酷似してるってツッコミを受けました。ポルノだけに。

12月は無職でした

もちろん、業務フローに特化したエンジンを作ると、そこそこ長所短所・得手不得手があり、なんとなく職場ではこの "hotsub" 使われずじまいだったので、いちおう目標であった論文だけ(インターネットジャーナルですけど)投稿して、11月末に退職、ターンエンドと相成りました。

転職活動のほうは、各方面に迷惑をかけつつも、1月からちゃんと就職できることになりました。ありがとうございました。

となると12月無職になるわけですが、友人各位はご存知のように(?)当方は貯金など一切無く、12月どうやって行きていけばいいのかワカラン、仕方ないので持ち前のコネクションとコミュ力ゲノム解析の単発受託などをやり糊口を凌いでおりました。

そう、まさにこの "hotsub" を使ってね!

このままでも「hotsub」を使って受託をこなすのはドチャクソ便利なんですが、やはりソフトウェアというのは、実際に運用してみて始めて洗練されていくもので、いろいろな課題や要望が見えてきました。

そのうちの一つが「hotsubというエンジンに依存しないジョブインターフェースの定義」であります。

この延長に「ワークフロー記述方法」が透けて見えており、かなり手応えを感じます。(時すでに退職おそし感)

今後の展望

すでにhotsub*1がCWLの実行を部分的にサポートしているのですが、今後はさらにhotsubが完全に「CWLのクラウド上実行のエンジン」となっていく展望は具体的に見えているのですが、いかんせん俺はもうバイオインフォ関係ない人になっちゃう。

加えて、CWLのコミュニティ活動の一環として上記 yacle*2の実装も、時間さえあれば進めていくつもりですが、もちろん給料など出ないのでありますから、牛の歩みになってしまうと思われます。

興味関心としても、上記のように「CWLは絶対のワークフロー記述方法ではない」という立場ですので、今後は僕は「CWLの動向をかなり遠くから見守りつつ、興味範囲でエンジンの実装と、独自ワークフロー記法の発明を進める」という感じになっていくと思われます。

まとめ

ドイツから帰ったとき、いきなり個人事業に集中していたら、たぶんこんなに業界のことを知れなかっただろうし、ネットワークもつくれなかったと思う。特に、CWL界隈・ワークフロー界隈・ワークフローミートアップのお歴々には、ソフトウェアへの貴重なご助言・フィードバックをいただき、彼ら無しでは僕はきっとバイオインフォで一切成果を出せなかったとすら思います。マジで。

なんかまともな謝辞になった。

まぁ、まとまらないんですけど、まとめると、「さようなら、CWL」となります。

WETな DRYな備忘録として

TypeScriptとExpoで始めるReactNativeアプリ開発

背景

Expo SDK v31 から、標準でTypeScriptをサポートしているらしく、ホンマかいな、というエントリです。

ゴール

  • Mac上のシミュレータで、アプリが動く
  • ソースコードがTypeScriptで書かれている

うるせえ動くもん見せろ

はい

github.com

以下、ログなので読まなくていいです。

簡単なアプリの作成

% expo --version
2.4.0
% expo init
? Choose a project name: MyTypeScriptRNApp
? Choose a template: blank
[17:33:56] Extracting project files...
[17:34:02] Customizing project...

Your project is ready at /Users/otiai10/proj/react-native/MyTypeScriptRNApp
To get started, you can type:

  cd MyTypeScriptRNApp
  expo start
% cd MyTypeScriptRNApp
% expo start

# 中略
  To run the app with live reloading, choose one of:
  • Sign in as @otiai10 in Expo Client on Android or iOS. Your projects will automatically appear in the "Projects" tab.
  • Scan the QR code above with the Expo app (Android) or the Camera app (iOS).
  • Press a for Android emulator, or i for iOS simulator.
  • Press e to send a link to your phone with email/SMS.

# とのことなので、 i と打つ

f:id:otiai10:20181120173814p:plain:w300

くっそ簡単やんけ。

以下、遊び心。

--- a/App.js
+++ b/App.js
@@ -5,7 +5,7 @@ export default class App extends React.Component {
   render() {
     return (
       <View style={styles.container}>
-        <Text>Open up App.js to start working on your app!</Text>
+        <Text style={{fontSize: 120, fontFamily: "Courier"}}>Foo Bar Bla Bla</Text>
       </View>
     );
   }

こんなすると、

f:id:otiai10:20181120174710p:plain:w300

こんななる。

TypeScriptにしていく

github.com

公式にサポートしているらしいので、いっちょ適当にやってみる。

% npm install --save-dev typescript

# tsconfig.jsonをつくる
% ./node_modules/.bin/tsc --init
# 拡張子変えるだけ
% mv App.js App.tsx
% expo start

f:id:otiai10:20181120180434p:plain:w300

めっちゃいけてるやんけ。

開発環境ととのえる

エディタに、 @types がもろもろ無いというお叱りを受けている。

f:id:otiai10:20181120180643p:plain

このままではなんのためのTypeScriptやねん、という感じなので。

% npm install --save-dev \
  @types/react \
  @types/react-native \
  @types/expo

f:id:otiai10:20181120180939p:plain

jsxね。

--- a/tsconfig.json
+++ b/tsconfig.json
@@ -6,7 +6,7 @@
     // "lib": [],                             /* Specify library files to be included in the compilation. */
     // "allowJs": true,                       /* Allow javascript files to be compiled. */
     // "checkJs": true,                       /* Report errors in .js files. */
-    // "jsx": "preserve",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
+    "jsx": "react-native",                    /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
     // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
     // "declarationMap": true,                /* Generates a sourcemap for each corresponding '.d.ts' file. */
     // "sourceMap": true,                     /* Generates corresponding '.map' file. */

f:id:otiai10:20181120181551p:plain

TypeScriptっぽいことをしてみる。(返り値の型を定義しただけ)

--- a/App.tsx
+++ b/App.tsx
@@ -1,14 +1,26 @@
 import React from 'react';
-import { StyleSheet, Text, View } from 'react-native';
+import {
+  StyleSheet, Text, View,
+  TouchableHighlight,
+} from 'react-native';

 export default class App extends React.Component {
   render() {
     return (
       <View style={styles.container}>
         <Text style={{fontSize: 120, fontFamily: "Courier"}}>Foo Bar Bla Bla</Text>
+        <TouchableHighlight onPress={() => this._showTime()}>
+          <Text>What time is it now?</Text>
+        </TouchableHighlight>
       </View>
     );
   }
+  _showTime() {
+    alert(this._getText());
+  }
+  _getText(): string {
+    return (new Date()).toLocaleString();
+  }
 }

 const styles = StyleSheet.create({

f:id:otiai10:20181120182142p:plain

いいですね。

DRYな備忘録として

速習 React 速習シリーズ

速習 React 速習シリーズ

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

Learning React Native: Building Native Mobile Apps with JavaScript (English Edition)

Learning React Native: Building Native Mobile Apps with JavaScript (English Edition)

Mac上で「歌声りっぷ」を使う【Boot Camp】【Windows10】

背景

  • ある曲のボーカルを抽出したものが欲しい(公式のオフボーカルは手元にある)
    • Ableton Live でオフボーカルトラックの逆位相をオリジナルトラックにぶつける方法でボーカルを抽出しようとした
      • あんまりうまくいかない
    • PhonicMind で1曲だけ利用枠購入してボーカルを抽出しようとした
      • 曲調によってはうまくいく
  • Macだけど「歌声りっぷ」も使ってみて、品質を比較したい

※ 本エントリ末尾に、実際に聞ける形で結果の比較があります。

概要

  1. MacBoot Campで、Windows10を使えるようにする
    1. Windows10のプロダクトキーをAmazonで購入しとく
    2. Windows10のISOファイルをダウンロードする
    3. Windows10のインストールと起動+初期化
  2. MacWindowsを選択的に起動する
    1. 電源オフ状態 → Mac / Windows の選択
    2. Mac起動時 → Windows
    3. Windows起動時 → Mac
  3. 「歌声りっぷ」を利用可能な状態にする
    1. ソースのダウンロードとlzhの解凍
  4. 「歌声りっぷ」の使用
    1. 16bitのwavでなければいけない
    2. 実行!

手順の記録

1. MacBoot Campで、Windows10を使えるようにする

1-a. Windows10のプロダクトキーをAmazonで購入しとく

箱でも変えるっぽいけど、オンラインコードで買ったほうがいろいろ楽だと思われ。僕はこちらをポチった。金無いけど。

購入が完了して「注文履歴」→「注文の詳細」で「ライブラリに移動」すると、プロダクトキーが表示されてる。

f:id:otiai10:20181019151248p:plain

f:id:otiai10:20181019151947p:plain

このプロダクトキー、携帯のカメラなりでメモっとくのがいいです。1-cでWindowsをアクティベートするとき、当然ながらこの画面をこのPCで開く術が無いのでw

1-b. Windows10のISOファイルをダウンロードする

上記で購入したものは、Windowsをマシンにインストールしてアクティベートするときに必要な「プロダクトキー」であり、WindowsのOSそのものではないので、OSのソースコードをダウンロードしてくる必要があります。まあまあデカい。

1-c. Windows10のインストールと起動+初期化

Boot Camp Assistant」という標準でMacに入ってるアプリケーションを使って、上記でダウンロードできたWindows10のISOファイルを元に、Windows10をこのマシンにインストールする。必要なソフトウェアのダウンロードなどを含むので、ある程度太い回線につないで実行するのがよいかと思われます。

f:id:otiai10:20181019154341p:plain

インストールが終わると、Windowsでの再起動を提案されるので、Yesです。

Windowsが立ち上がり、言語やキーボードレイアウトなどを聞かれたのち、プロダクトキーを入力する場面になるが、それはもう1-aで購入しているので、それを使う。

f:id:otiai10:20181019155155p:plain

2. MacWindowsを選択的に起動する

2-a. 電源オフ状態 → Mac / Windows の選択

support.apple.com

以上。

2-b. Mac起動時 → Windows

support.apple.com

以上。

2-c. Windows起動時 → Mac

これが問題で、ほんまは「右下の△」→「ひし形マーク」→「OS Xでの再起動」を選択したらBootCampできるらしんだけど、macOS High Sierra からどうやらそれが動かないらしいので、

2-aと同じ方法を取る、つまり一度シャットダウンするよりほかなさそう。

参考: itkhoshi.com

3.「歌声りっぷ」を利用可能な状態にする

無事、MacでWindows10が動くことが確認できたので、つぎに「歌声りっぷ」を調達する。

3-a. ソースのダウンロードとlzhの解凍

ソースそのものはここでダウンロード可能

www.vector.co.jp

ただ、落としてきたものがlzhファイルで、この解凍ソフトウェアがデフォルトで入っていないので、

forest.watch.impress.co.jp

これを落としてきて、ショートカットをデスクトップに作成して、そこに「歌声りっぷ」のlzhファイルをドラッグアンドドロップすると、無事、解凍され、中に.exeファイルがあったので、これをめんどくさいのでそのままデスクトップに移動した。

4. 「歌声りっぷ」の使用

4-a. 16bitのwavでなければいけない

GUIめんどいので、MacなりLinux環境で、ffmpegCLIをつかった

# オリジナルトラックとオフボーカルトラック両方用意する
% ffmpeg -i ./original.mp3 -acodec pcm_s16le original.wav
% ffmpeg -i ./offvocal.mp3 -acodec pcm_s16le offvocal.wav

4-b. 実行!

Google Driveかなんかに入れて、Windowsに渡して、歌声りっぷする。した。

結果の比較

Phonic Mind
Ableton Live
歌声りっぷ

結論

  • 今回のケースでは「Phonic Mind」が段違いに性能悪いように聞こえるが、曲によってはバッチリ抜けることもある
  • 「Ableton Live」で自分で頑張る場合には、ここからさらにEffect/Filterなどでならしていく余地があるし、やっぱり楽
  • 何も設定いじらず、「歌声りっぷ」が今回は最も良い結果になった。がんばってWindows環境構築してよかった

謝辞

どうしても歌声りっぷ使ってみたいという今回の検証にあたって、大好きなトラックメーカーであるハナカミリュウさん、DJの先生であるKAZZONE大先生、間接的ではありますがCoNoSyuNya氏、にたいへん助けていただきました。ありがとうございます。

なお、今回がんばってアレしたソレで、はじめてのマッシュアップトラックをつくって、来たる 11月2日(金曜日)の Sound Sandbox vol.3 で流そうと画策しています!どうぞ遊びに来てください!

soundsandbox.tokyo

で、完成したもの

上記のイベントでかけた。マッシュアップたのしい。

soundcloud.com

DRYな備忘録として