2017年1月28日土曜日

OSXでMIDIキーボードの入力信号を取得する方法(完結編)

前回と前々回の記事の続きです。

簡単におさらいしておくと、
・前々回:MIKMIDIを使えば実現できそうだと理解。
・前回:MIKMIDIを使ってnanoKEY2のデバイス情報が取れることを確認。
という感じで、今回はMIKMIDIを使って、nanoKEY2の入力信号をハンドリングする方法の解説です。

先に回答を書くと、以下のような感じで実装すれば、「★ココで捕捉」の箇所で入力信号を捕捉できます。

    MIKMIDIDeviceManager* dm = [MIKMIDIDeviceManager sharedDeviceManager];
    NSArray<MIKMIDIDevice*>* devices = [dm availableDevices];
    for (MIKMIDIDevice* device in devices) {
        NSArray<MIKMIDIEntity*>* entities = device.entities;
        for (MIKMIDIEntity* entity in entities) {
            NSArray<MIKMIDISourceEndpoint*>* sources = entity.sources;
            for (MIKMIDISourceEndpoint* source in sources) {
                NSLog(@"source: %@", source);
                [dm connectInput:source error:nil eventHandler:^(MIKMIDISourceEndpoint * _Nonnull source, NSArray<MIKMIDICommand *> * _Nonnull commands) {
                    // ★ココで捕捉
                    NSLog(@"detected commands: %@", commands);
                }];
            }
        }
    }

以降は、上記の実装をザックリと解説するだけなので、コードだけ見れば分かる人は読まなくても、もう自分のプログラムでMIDIキーボードを入力機器として使うことができますね。

まず、MIKMIDIDeviceManageravailableDevicesで接続されているデバイスの一覧を取得します。
デバイスの実体(MIKMIDIDeviceMIKMIDIEntity)には、
・source endpoint
・destination endpoint
という2種類の情報があり、入力信号を捕捉するにはsource endpointの方を使います。

入力信号の捕捉は、MIKMIDIDeviceManagerconnectInputで対象のsource endpointを指定してあげれば、入力信号が発生した時にeventHandlerがコールバックされるという感じです。

簡単ですね。

で、このプログラムを動作させた状態で、nanoKEY2の「ド」のキーを押してみると、押したタイミングで、XCodeのconsoleに

2017-01-28 18:41:57.014351 VGSKeyboard[36587:9378038] detected commands: (
    "<MIKMIDINoteOnCommand: 0x600000024aa0> time: 18:41:57.013 command: 159 channel 0 note: 48 velocity: 118 \n\tdata: <903076>")

という感じのMIDIイベント(MIKMIDICommand)が発生します。
そして、キーを離してみると、

VGSKeyboard[36587:9378038] detected commands: (
    "<MIKMIDINoteOffCommand: 0x608000029860> time: 18:41:57.549 command: 143 channel 0 note: 48 velocity: 64 \n\tdata: <803040>")

というMIKMIDICommandが発生しました。

つまり、キーボードのキーを押すとcommand 159が発生して、離すとcommand 143が発生するという感じでしょうか。そして、noteで対象の音階が分かるという感じです。

いやー、簡単ですね。このMIKMIDIというライブラリはCore MIDIというframeworkを使っているのですが、直にCore MIDIを叩くよりは大分楽な感じではないでしょうか。

しかも、OSXだけでなくiOSにも対応しているので、入力機器としてブルートゥースMIDIキーボードを使うiPhoneアプリなんかも作れてしまうのではないでしょうか。(今回はスマホ関連のことは未調査ですが)

OSXでMIDIキーボードからの入力信号を取得する(導入編)

前の記事で書いた MIKMIDI を使ってみる件の導入編です。
まず、XCodeで適当なプロジェクト(VGSKeyboard)を作り、CocoaPodsでMIKMIDIを取り込みます。

Podfileを以下のように作成して、

source 'https://github.com/mixedinkey-opensource/MIKMIDI.git'

target 'VGSKeyboard' do
  pod 'MIKMIDI', :git => 'https://github.com/mixedinkey-opensource/MIKMIDI.git'

end

pod update と pod install を実行すれば取り込めます。
そして、podにより生成されたワークスペース(VGSKeyboard.xcworkspace)を開き、ViewController.mでとりあえず、デバイス一覧を拾ってログに出すコードを書いてみました。

$ git diff VGSKeyboard/ViewController.m
diff --git a/VGSKeyboard/ViewController.m b/VGSKeyboard/ViewController.m
index 6ba3050..e9a5aea 100644
--- a/VGSKeyboard/ViewController.m
+++ b/VGSKeyboard/ViewController.m
@@ -7,13 +7,15 @@
 //

 #import "ViewController.h"
+#import "MIKMIDI.h"

 @implementation ViewController

 - (void)viewDidLoad {
     [super viewDidLoad];

-    // Do any additional setup after loading the view.
+    NSArray* availableMIDIDevices = [[MIKMIDIDeviceManager sharedDeviceManager] availableDevices];
+    NSLog(@"availableMIDIDevices: %@", availableMIDIDevices);

 }

そして、実行してXCodeのログを確認してみたところ、

2017-01-28 15:54:45.962064 VGSKeyboard[34236:9311302] availableMIDIDevices: (
    "<MIKMIDIDevice: 0x608000262100> Bluetooth:
        Entities: {
        }",
    "<MIKMIDIDevice: 0x600000075a40> \U30cd\U30c3\U30c8\U30ef\U30fc\U30af:
        Entities: {
        }",
    "<MIKMIDIDevice: 0x6080002628c0> nanoKEY2:
        Entities: {
            <MIKMIDIEntity: 0x600000075a80> nanoKEY2:
        Sources: {
            <MIKMIDISourceEndpoint: 0x600000051a60> nanoKEY2 KEYBOARD,
        }
        Destinations: {
            <MIKMIDIDestinationEndpoint: 0x608000047890> nanoKEY2 CTRL,
        },
        }"

)

おぉ、ちゃんとnanoKEY2のデバイス情報が取れている。

OSXでMIDIキーボードからの入力信号を取得する方法(模索中)

VGSの技術を応用した音ゲーとか作ったら面白いかもしれない。

という訳で、MacにMIDIキーボードを繋いで、そこから入力信号を拾うにはどうしたものか。

以前、ゲームパッドの入力信号を拾うため、色々と調べてみた結果、IOKitを使えば良いということが分かり、gamepad-osxというライブラリを作りました。
これは、IOKitのHID(Human Interface Device)の接続・切断・入力信号を拾う機能を使って実現しています。

MIDIキーボードも、HIDの一種と言えるので、同じ方式でいけるのでは?

と、思って色々と試してみたのですが、どうもMIDIキーボードはHIDとして認識されないらしい。ちなみに、使っているMIDIキーボードはKORGのnanoKEY2です。このMIDIキーボードは、Logicでは普通に使えているので、OSとしては認識できているようです。

MIDIキーボードはHIDとは別の手段で入力を検出するのかな?

そう思ってGitHubで何か良いものは無いものかと探してみたところ、良さそうなヤツがありました。
https://github.com/mixedinkey-opensource/MIKMIDI

上記を使えば、MIDIキーボードに限らず、MIDIデバイス全般を操作(MIDI信号の送受信)ができるらしいです。コレを使って、MIDIキーボードをMIDIデバイスとしてコンテキストが取れれば、そこから入力信号が取れる筈。

とりあえず、今回は足回りはコレで何とかなりそうだということで、試しに使ってみよう。
使ってみた結果の記事は別途書くつもりです。

Apple開発者アカウントをどうするか

Apple開発者アカウントの更新時期がそろそろ迫ってきました。
が、今回は更新しようか若干悩ましい。
今のところ、更新しない方向で考えています。

最低限、更新できる程度の売上がAppStoreから出ていれば良いのですが、ここ1年間、新作を出していないこともあって、更新費用(12000円)すら稼げていない感じです。ちなみに、過去365日での売上は37ドルと67セントで、収益は26ドルと9セント)

新作を作ろうとする意欲はまだ有るのですが、今作っているものはPC(Windows+Mac)向けで、MacであればAppStoreよりはWindowsとセットで出せるSteamとかの方が良いと思っていて、それならApple開発者アカウント(正確にはAppStoreでの配信権)を維持する必要がありません。

仮に更新しなかった場合、SUZUKI PLAN製のアプリをAppStoreから新たにインストールすることができなくなります。念のため、最近のダウンロード数をかなり久々にチェックしてみましたが、東方VGSとかはまだ1日平均100ダウンロードぐらいされているらしい。東方強い。

2017年1月23日月曜日

若者の酒離れ

私は酒をほぼ飲みません。
だたし、下戸ではないです。
ビールは苦いからあまり好きではないですが、日本酒であれば、美味しいものは美味しいと思っていたりします。ですが、飲むのはほぼ飲み会限定で、飲み会が無ければほぼ飲みません。稀にコンビニで買って飲むことがありますが、それも、数ヶ月に1回あるか無いかという頻度です。
「若者の酒離れ」みたいなキーワードの記事をチラホラ見るので、これは恐らく私に限ったことではなく、世間一般で起きている現象らしい。

【参考記事】
進む若者の酒離れ 20代男性の4割が「月に1回も飲まない」理由
http://www.zakzak.co.jp/society/domestic/news/20161231/dms1612311000006-n1.htm
若者の「酒離れ」は必然! そもそも日本人の約半数は酒が弱いので「無理やり飲ませてた今までが問題」
若者の「酒離れ」は本当だった! 飲食店はノンアルコール飲料で若者を呼ぶ時代になる?

お酒といえば、そういえば主にビール類等の酒税がもうすぐ変わるとか。

ビール類酒税55円に統一へ 10月めど メーカーと本格協議 来年度税制改正

今まで境界があやふやだったビール類(ビール、金麦、第三のビールなど)の酒税が統一され、その結果、ビールの税額は若干安くなるが、金麦や第三のビールは高くなる(ビールと同じ税額になる)らしいです。

発泡酒(ビールなど)、醸造酒(日本酒、ワインなど)、蒸留酒(ウィスキー、ウォッカ、焼酎など)などの製法毎に税率が別れる感じになるとか。これ自体はシンプルで良いねと他人事のように思っています。

この改定は、「メーカーと協議した上で決定」しているということは、国にとっては税収、メーカーにとっては売上がこれで上がると踏んでいるんでしょうけど、それで(税収・売上が)上がるのか割と疑問です。

少し話しが逸れますが、酒に関する法律の話しで、よく「免許を持っていない人が酒を造るのは違法」といったことを聞きますが、これは、酒税法7条で酒を製造するには免許が必要だからと規定しているためです(同法で罰則も規定されています)。
そういえば、昔自宅で梅酒みたいなものを作っていた気がするが、あれは違法なのかな?と思ったのですが、梅酒とかについては合法らしい(国税庁のHPのQ&Aを参照)。
以下、全く根拠の無い妄言を書きますが、私は、この法律で免許が必要とするものを「製造」ではなく「販売目的での製造」などにした方が、税収も売上も伸びるのではないだろうかと考えています。

酒に税を掛けたり、製造を免許制にするのは、世界的には割と普通なことですが、日本で酒の製造を免許制にしたのは明治32年から(参考)と、割と歴史的に見て浅かったりします。江戸時代やそれ以前にも普通に酒屋はあった筈なので、もっと前からあったのではないかと思っていたのですが、明治以降の近代化という名の「西洋かぶれ化」のムーブメントの過程でようやく誕生したものなんですね。

酒の製造免許を取ることは、設備を準備するのが難しい関係で個人ではほぼ無理ですが、酒を作ることそのものは割と簡単なようです。まぁ、実際に作ったことが無いから分からないですが、コチラのサイトでどぶろくの作り方を確認した限り、素人でも作れそうです。(当然、クオリティの高いものを作れるかは別でしょうけど)

で、仮に酒の個人製造が合法化された場合、酒を飲む人は皆個人で酒を作って飲むから税収は落ちるか?高度成長期より前の物質が豊かでなかった頃と違い、現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろうと思います。

この推測が正しければ、免許制度を製造から販売に変えても税収と売上は変わらないということになります。

しかし、酒造りにも「モノをつくることの楽しさ」みたいなものはある筈で、実際、それを巡って起きた裁判(通称、どぶろく裁判)なんかもあったりしたようです(参考)。この裁判は結局国が勝っています。ですが、モノをつくることに対する欲求は、食欲や性欲などと同じぐらい人間の根源的欲求みたいなもので、それを法で縛るのはどうなんだろうと。勿論、規制する必要性があるのであればともかく、果たしてその必要性は有るのかがイマイチよく分かりません。そして、割とこういう所で本来発生している筈の需要の原体験みたいなものを潰してしまっていることがあるので、それによる上積み分が「税収も売上も伸びるのではないだろうか」と思っている根拠です。
つまり、昨今言われている「若者の酒離れ」の根本的な原因は、その需要の原体験みたいなものを潰したことによるものだろうという風に考えている訳です。

まぁ、額にしてどんくらいとか全然分かりませんが。ついでに、参考で出したどぶろく裁判の主旨によると「個人に製造を許すと税収が減ると予想される」とのことなので、判例ベースで考えれば、先述した現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろうという私の考え方は、最高裁判所のお墨付きで間違っている(と予想される)ということになります。

2017年1月18日水曜日

Lv28のフルコンとか

ありえんわ〜

などと思っていたが、アッサリと取れてしまった。
今朝寝起きの半トランス状態だったのでスクショ等は撮り忘れた模様

現在、78/96曲フルコンが取れているので、残り18曲。

内訳は、
・Lv25以下: 44/44曲(フルコン率100%)
・Lv26: 27/33曲(フルコン率82%)※あんきらはまだ分母に入れていない
・Lv27: 6/12曲(フルコン率50%)
・Lv28: 1/7曲(フルコン率14%)
という具合。

Lv28の残り6曲をフルコンが難しい順に並べると、
・TOKIMEKI (rank: C)
・キノコ (rank: C)
・トワレ (rank: C)
・M@GIC (rank: B)
・LENGE (rank: A)
・Trancing Pulse (rank: A)
ですが、これは人によってかなり割れるらしい。

上記の並び順は、単純に現時点のコンボランクが低い(=フルコンまで遠い)順に機械的に並べたもので、今朝フルコンを取った「あんずのうた」は、LENGEとTrancing Pulseの間(だから、フルコンを取れた順としては順当)。

余談ですが、「半年ぐらいプレイしていれば全曲フルコン取れるんじゃね?」とか思って始めたのですが、当初想定よりやや遅い & 半年で全曲は無理かもしれないと思い始める。かつて、キーボードマニアにハマっていた頃は、もっと短期間でバキバキ上達していたのに。衰えたのかなぁ...

2017年1月14日土曜日

SSS(廃人レース)

PRP1000に到達して、晴れてSSSランクを目指すレースの参戦権利を獲得。
ありがとうオーバーロード
改めてルールを確認してみたところ、
1000位以内・・・だと・・・
イベントの報酬と同じく2000位以内かと勘違いしていたけど、これだとかなりキツイな。

前期(2016.12)のボーダーは、
なるほど、821万か。

1曲あたりの獲得ファン数を平均5000人ぐらいとすると、
・ボーダー到達までに必要なプレイ数 = 1642回
・1日あたりの平均プレイ数 = 約53回
1曲平均2分ほどなので、1日あたりだいたい2時間プレイすればボーダーを超えられそう。
まぁ普通かなという感じですが、これを1ヶ月フルで続けるのは、やはり中々しんどいな。M@GICのフルコン安定化とか、普通の人が取らないシフトに夏休みを取るなどして全力で走るなどの工夫が必要かもしれない。

まぁ、ボーダーは人間レベルの争いなので、廃人レースというほどのものではないけど、上位陣は控えめに表現して狂っている。
6000万とかね。
平均獲得数を多めに見積もっても9230プレイぐらい必要な筈だから、時間換算で308時間ぐらいとか。休み無しで1日あたり10時間程度プレイしているとか、これなんてブラック企業?というレベルです。

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...