2016年01月

AQUOS PAD で MVNO テザリングできた

SH05GNTT docomo 2015 夏モデルの 7 インチタブレット「AQUOS PAD」(SH-05G、シャープ製)を入手。

AQUOS PAD のスペックは公式サイトに記載があるが、主なものは、
  • ディスプレイ:7.0 インチ IGZO(1200×1920)
  • CPU:Snapdragon 810(MSM8994)オクタコア(2GHz×4+1.5GHz×4)
  • メモリ:2GB
  • ストレージ:32GB
  • 重量:216g
  • 防水・防塵

テザリングの様子docomo のタブレット・スマホは、格安 SIM だとテザリングできないものがほとんどだが、AQUOS PAD(SH-05G)は格安 SIM(IIJmio)でテザリングができた。

右の写真は、AQUOS PAD(左側)をルーター側としてテザリングし、Wi-Fi 接続しかできない Nexus7-2012(右側)でインターネットアクセスしている様子。

手順は以下。写真類はクリックで拡大する。

手順

  1. WiFiテザリングを設定AQUOS:[Android 設定→無線とネットワーク→もっと見る→テザリング→Wi-Fi テザリングを設定]で、あらかじめルーターとしての設定を行っておく。ネットワーク名とパスワードを好きに設定する。
  2. APNAQUOS:[Android 設定→無線とネットワーク→もっと見る→モバイルネットワーク→アクセスポイント名]で、APN が MVNO(IIJmio)になっていることを確認する。
  3. テザリングONAQUOS:画面上部のドロワーで Wi-Fi テザリングを ON にする。この時、(テザリングではないほうの)Wi-Fi は OFF になるが気にしなくて良い。
  4. Nexus7:[Android 設定→無線とネットワーク→Wi-Fi]で、手順 1 で設定したネットワーク名を探し、接続する。

テザリング中以上で、テザリングにより、Nexus7 でインターネットにアクセスできるようになった。

もちろん、引き続き AQUOS もインターネットにアクセスできる。右の写真で、左上の渦巻きがテザリング中であることを示している。

接続中Nexus7 が AQUOS に接続すると、AQUOS 側のドロワーの表示が「Wi-Fi テザリングが有効です:1 台接続中」となる。

テザリング中のモバイルネットワークテザリング中は、AQOUS の[Android 設定→無線とネットワーク→もっと見る→モバイルネットワーク]で、「アクセスポイント名」がグレーアウトされて変更できないようになっている。

なお、一度、AQUOS のインターネットアクセスができなくなってしまったことがあった(Nexus7 もダメ)。この時は、APN 設定が sp モードに変更されていた。APN を IIJmio に戻すことで解決した。

余談だが、旧型の AQUOS PAD(SH-08E)は MVNO でのテザリングができない。

おすすめプログラミング言語を考える(UTAU プログラマー向け)

「UTAU プラグインを作ろうと思うんだけど、プログラミング言語は何が良いんだろう?」

このようなお悩みをたまに見かけますので、今回はそれを考えてみます。

ちなみに、UTAU 以外で既に十分なプログラミング経験のある方は、普段お使いの言語で作れば問題ありません。プラグインの仕様や、各言語での実装例(半音上げプラグイン大会のエントリーなど)を見れば、あっという間に作れるでしょう。

ここでは、あまりプログラミング経験のない方のために考えることにします。

言語選びのポイントは以下です。
  • 世間で人気の言語であること
  • GUI が作りやすいこと
  • プラグイン利用者側の追加ソフトインストールが不要であること
各項目について、次節以降で詳しく見ていきます。

世間で人気の言語であること

夢も希望もない話かもしれませんが、初心者であるほど、長いものに巻かれるほうが無難です。

世間で人気の言語(利用者が多い言語)であれば、入門書や入門サイトも数多く存在しますし、ハウツーやトラブル対策の情報も豊富です。あなたがトラブルに見舞われたとして、人気の言語ならば、他にも多くの人が似たような経験をしているはずなので、すぐに対応策を探せるでしょう。

逆に、マイナー言語の場合、そもそも開発環境自体のバグが残っていたりすることもあり、余計なトラブルに巻き込まれかねません。

TOIBE_201601人気の言語は、TOIBE が定期的に測定しています。クローズドソースも含め、世界で使われている言語を推定しているランキングです。古めの言語の順位が上がってしまう傾向にありますが、十分参考になります。2016 年 1 月のランキングでは、以下の順位です。
  1. Java
  2. C
  3. C++
  4. C#
  5. Python
  6. PHP
  7. Visual Basic .NET
  8. JavaScript
  9. アセンブラ
  10. Ruby
Java は最近ずっと 1 位をキープしています。パソコンの世界だけ見ると Java で作られたアプリはそこまで多く感じられませんが、スマホ(Android)アプリは Java がメインであり、スマホ開発が盛んになっていることの現れでしょう。

C と C++ は順当に高ランキングを獲得していますね。歴史の長い言語なので、直近の勢いという意味ではそれほどではありませんが、しっかりしたライブラリなどの多くは C/C++ ですし、普段使っているようなパソコンソフトだけではなく、裏方(ドライバ、ライブラリ、ファームウェア等)としても様々な場面で使われています。

4 位の C# はメジャー言語の中では後発組です。短期間でランキング上位にのしあがったのは、マイクロソフトの影響力が大きいです。とはいえマイクロソフトの影響力 があるのはパソコンの世界の話で、スマホではあまり影響力はありません。スマホ全盛の時代に高ランキングを獲得しているのは、C# そのものの良さがあるからでしょう。

5 位の Python は、日本ではそこまでメジャーではありません。プロの求人ランキング(横軸)を見ても、マイナー言語と同等の求人件数しかありません。しかし、世界に目を向ければ、Google 先生が Python 押しであることが大きな追い風となり、ホットな言語と言えます。

6~10 位は、アセンブラを除いてお手軽系の言語が並んでいます。

これら 10 言語をおすすめ言語候補として、以降でさらに絞り込んでいきましょう。

GUI が作りやすいこと

ほとんどの UTAU プラグインには GUI(ウィンドウやボタンなどの画面)が必要になってきます。GUI を簡単に作れるかどうかは、生産性に大きく影響します。

言語ランキング 1 位の Java は初期の頃から GUI に力を入れてきており、GUI は作りやすいと言えるでしょう。私自身は Java での GUI 開発経験はありませんが、例えば Java の統合開発環境として使える Eclipse であれば、RAD ツール(GUI をドラッグアンドドロップで簡単に設計できるツール)の Swing Designer が標準搭載されているようです。

言語ランキング 2 位の C での GUI 開発は地獄です。仕事でやむを得ずというのならともかく、UTAU プラグインの GUI を作るために C を用いるのは正気の沙汰ではありません。

言語ランキング 3 位の C++ での GUI 開発は微妙です。

C++ 開発環境の鉄板である Visual Studio において、GUI 開発は以前よりはマシになりました。RAD ツール付きの Visual Studio が無償で利用できるようになったためです。しかし、付属の C++ ライブラリの使い勝手は悪く、慣れるまでにかなりの時間を要するでしょう。

別の C++ 開発環境として C++Builder が挙げられます。優秀な RAD ツールで、効率的に GUI 開発が行えます。しかし、価格が高いこと、バグが多くサポート力も弱いこと(昔のセキュリティーホールが放置されたままになってたります)、(言語としてではなく)ツールとしてのユーザー数が少ないことから、おすすめはできません。

言語ランキング 4 位の C# および 7 位の Visual Basic .NET(以降 VB.NET)は GUI の開発がやりやすくなっています。開発環境は C++ の時と同じく Visual Studio ですが、使い勝手は大きく異なります。C#・VB.NET の場合は GUI が作りやすいように整備されており、また、付属のライブラリ(.NET)も扱いやすいです。

言語ランキング 5 位の Python は、標準では GUI の開発は大変です。RAD ツールとしては Monkey Studio が利用できるようですが、日本語の情報がほとんどありません。しかし、IronPython という、.NET と組み合わせたバージョンの Python は、GUI を開発しやすくなっています。ただし、日本語の情報はあまり多くないようですので、プログラミングに不慣れな人が挑戦しようとすると困難が待ち受けるでしょう。

言語ランキング 6 位の PHP と 8 位の JavaScript はウェブ専用のプログラミング言語なので、今回は除外します。

言語ランキング 9 位のアセンブラでの GUI の開発は……理論上は可能ですね。しかし現実は無理でしょう。

言語ランキング 10 位の Ruby での GUI 開発は、Python と似たような状況です。標準では GUI は作りづらいものの、.NET と組み合わせた IronRuby があります。ただし、IronRuby の開発は止まっており、Python よりも状況は悪いです。

以上により、人気の言語でかつ、標準で GUI 開発を行いやすいのは、Java、C#、VB.NET であることがわかりました。

プラグイン利用者側の追加ソフトインストールが不要であること

UTAU プラグインを使うために、プラグイン以外にも別途あれもこれもソフトをインストールしてください、だと、プラグイン利用者としては不便ですし、インストール作業を面倒くさがってプラグインの利用を諦めてしまうことも多いでしょう。

まず Java ですが、実行ファイルを生成することはできず、別途、JRE(Java Runtime Environment)と呼ばれる追加ソフトが必要となります。残念。

とはいえ、ウェブブラウザのプラグインをインストールする際に一緒に JRE を入れている利用者もいますので、減点要素はそこまで大きくありません。

C#、VB.NET は実行ファイルを生成できます。別途 .NET Framework という追加ソフトが必要となるのですが、Windows に初めからインストールされていたり、あるいはすでに別のソフトを使う際に利用者が自分でインストールしていたりと、たいていの場合はインストールされていることでしょう。とはいえ、.NET Framework のバージョン違いによってインストールが必要になることもあり、減点要素はゼロではありません。

以上により、これまで絞り込んだ言語の中で、この項目を完璧に満たせる言語はありません。

総合評価

ここまでで、有力候補は Java、C#、VB.NET の 3 つに絞られました。この 3 つに順位を付ける場合、私は以下のようにします。
  1. C#
  2. VB.NET
  3. Java
Java は実行ファイルを生成できないので 3 位。実際に UTAU プラグインを配布する際に、一手間必要になってきます。それとは別に、Java は起動が遅いので(一度起動してしまえば早いのですが)、プラグイン利用者がちょっとイライラするかもしれません。

C# と VB.NET を比較すると、機能としては同等なのですが、C# の方が簡潔にプログラムを記述できます。また、よく言われることとして、VB プログラマーの質が低いというのがあります。VB で開発していると、ネットの「知恵」が実は微妙な情報で、それを信じてドツボにハマる、というリスクがあります。

以上により、UTAU プラグインをこれから開発するなら、最もオススメのプログラミング言語は「C#」という判断にいたします。

懸念事項としては、「プログラミング経験の少ない人が C# にチャレンジするのはハードルが高くないか」という問題です。順当に C やあるいは軽量系スクリプト言語の方が習得しやすいかもしれません。とはいえ、UTAU プラグインを作るのが目的であれば、それらの言語では目的を達成するのが困難というのがこれまでの流れです。

これから C# を勉強しはじめる場合、きちんとした書籍を購入して、体系的に C# を理解するのが結局は一番近道だと思います。C# に限りませんが、プログラミングの概念をきちんと理解するのはなかなか大変で、ウェブの Tips をつまみ食いした程度ではその場しのぎの知識しか手に入りません。

とはいえ、まず少し作ってみたいんだ、という場合は、
はいかがでしょうか。GUI アプリを C# で実際に作ってみることができます。また、
の C# の実例(エントリー 3、15、22、27(GUI))も参考になるかと思います。C# 言語の詳細については、プログラミングの基礎的な知識を前提としていますが、

がオンラインの情報としてはまとまっていると思います。


余談

今回は C# 押しということになりました。確かに C# は素晴らしい言語です。
  • 他の言語の良いところを取り入れていて使いやすい
  • GUI・ネットワーク・同期プログラミングなど周辺のライブラリも充実かつ整理されている
  • Visual Studio の支援機能がずば抜けて強力(他の環境を使う気になれないくらい)
しかし、つまるところプログラミング言語なんて何でも良いというのもまた一理あるところです。

最初にメジャー言語で絞り込みましたが、情報収集にもっと労力を注ぎ、不足するところは自分で考えることにすれば、マイナー言語でもいいわけです。例えば Lazarus は無料で GUI を簡単に構築できます。Lazarus に限定するとユーザー数は多くありませんが、Lazarus は言語としては Object Pascal でありそこそこの順位にいますから、悪くない選択肢かもしれません。

今回 1 位と 2 位の C# と VB.NET を比較した場合、VB.NET の良いところは一つも無いと言っても過言ではありませんが、C# と 3 位の Java を比較した場合、UTAU プラグイン以外にも目を向ければ、Java のいいところもたくさんあります。将来 Android アプリも作りたい、ということであれば、その準備を兼ねて Java を選択する、ということも考えられます(逆に Android アプリを C# で作る方法もありますが)。

世界の潮流で言えば、Python は「来てる」言語です。Google のクラウドサービスで何かしようとしたら Python は有力でしょう。その意味では、IronPython も挑戦しがいがあるかもしれません。

C# ももちろんですが、他の言語にも是非目を向けてみてください。

唄詠のこれまでと 2016 年以降の予定

誰でも簡単に、UTAU 音源におしゃべりさせられるツール「唄詠」。

同様のことを行えるソリューションがいくつかある中で、唄詠の特徴を再掲すると、
  • 漢字かな交じり文を書いて再生ボタンを押すだけ、というシンプルな操作で読み上げが可能。
  • 調声作業が一切不要なので手間がかからない。
  • UTAU 音源そのものを使用して発音するので、声のイメージが UTAU に近い。
  • ほぼリアルタイムでの読み上げが可能。

唄詠は 2014 年 1 月に産声を上げて以来、着実に進歩してきた。昨年(2015 年)のトピックを振り返ってみると、以下のようになるだろうか。

まずは、新しい調声プラグイン「やまなみ」のリリース。当初の調声プラグイン「ダブルフラット」は非常にロボロボしい発音を特徴としていたが、やまなみは、ニュートラルな読み上げをコンセプトとしている。調声プラグインが 2  つに増えたことで、表現の選択肢が広がった。レーシングゲーム「幻走スカイドリフト」の実況動画は、やまなみを使ってアフレコをしている。

調声プラグインはどなたでも開発可能で、SDK も公開されている。

2015 年は唄詠を取り巻く環境にも大きな変化があった。

UTAU 音源配布者から唄詠への「いいね」である唄詠使用支援中タグを作っていただいた。詳細は支援サイトをご覧頂きたいが、UTAU 音源配布者も UTAU 利用者も、お互いがおしゃべりを楽しめるような仕組みを作っていただいている。

現時点でタグの件数は 200 以上にのぼるが、1 つのツールにすぎない唄詠に対して、これほどのご支援をいただいていることは、言葉では表せないくらいの喜びである。

そのようなご支援へのお礼も兼ねて、かつ、UTAU のおしゃべりをさらに便利にすべく、UTAU 音源 声質検索サイトをオープンした。

UTAU 音源の数は膨大だが、「しゃべった場合の声の雰囲気」を重視して希望の音源を探せるサイトは、これまでほとんどなかった。本サイトは、UTAU 音源声質アンケートの結果や、声の雰囲気を表すタグなど、声質を重視して音源を検索できる数少ないサイトである。サンプルボイスも登録可能で、また、唄詠と連動しているので、利便性も高い。

登録は自由に行えるので、新しい音源や既存音源のサンプルボイスなど、積極的に登録していただけると助かる。

最後に、地味ではあるが「セキュリティーアップデート」も重要な出来事だった。以前の唄詠は、開発環境である C++Builder に由来する脆弱性があったが、これを解消した。安全性の向上もまた、快適な利用のために重要であると考える。

以上が、2015 年の振り返りとなる。

さて、2016 年以降の唄詠の予定であるが、主なものは以下のようになっている。

まずは、第三の調声プラグインの開発。より実用的なしゃべりを目指して、現在研究を行っている。複数のかたにご協力頂いた実験データを基に、さらに唄詠を進化させたい。とはいえ、これはかなり時間のかかる作業で、1 年間では終わらないかもしれない。本丸の攻略には時間がかかる。

既存の調声プラグインのレベルアップも図っていきたい。最近の UTAU 音源は語尾息や表情音源などを搭載し、表現力が高まってきている。そういう要素を取り入れて発音できるようになれば、面白いのではないだろうか。また、よく使われるフレーズ・文章などは、定型文として予め最適な調声をほどこしておくと、効果的かもしれない。もちろん、無声化や疑問文対応などの基本的なところは着実に進めていきたい。

特定のアプリとの相性問題ではあるものの、現時点では、YMM と組み合わせた時の発音があまりよろしくない。このあたりも改善に取り組んでいきたい。

今後とも、唄詠をよろしくお願いします。

関連リンク


大盛況だった半音上げプラグイン大会の振り返り

半音上げプラグイン大会UTAU プラグインの作り方は開発者ごとに異なり、その違いを見てみると楽しく勉強になるのではないか、ということで始まった「半音上げプラグイン大会」。UTAU プログラマーの祭典です。2015/12/11~12/31 の 3 週間開催。

ニッチなイベントなので、そもそも参加してくださる方がいるのか不安でしたが、蓋を開けてみれば大盛況で、なんと 24 件ものエントリーがありました。単に「半音上げる」だけのシンプルなプラグインが、いろいろなプログラミング言語やアルゴリズムで、24 パターンも登場したということです。

本記事では、そんな大会の様子を振り返ってみたいと思います。大会レギュレーションは、以前の記事を参照して下さい。

蛇足ですが、UTAU のメニューに半音上げる処理はありますので、実用上は、半音上げるプラグインは必要ありません。

目次


エントリー一覧

#エントリー(敬称略)言語ソースコード
1HaruqaUWSC表示 DL
2
なでしこ
表示 DL
3SHINTA
C#
表示 DL
4
bizz
Lazarus
表示 DL
5
masao
C++
表示
6
bizz
Lazarus
表示 DL
7
masao
C
表示
8
Haruqa
UWSC
表示 DL
9
Haruqa
UWSC
表示 DL
10
大兄P
Java
表示
11
bizz
HSP
表示 DL
12
山岸
Java
表示
13
masao
C++
表示
14
大兄P(#10 の修正)
Java
表示
15
ばわめ rwxr--r--
C#
表示(メイン クラス
16
あさくら・ふにょし
Electron
表示(HTML JavaScriptDL
17
あさくら・ふにょし
バッチファイル
表示
18
Haruqa
JScript
表示
19
とりフラ.ust.vvv
ExcelVBA
表示
20
masao
C++
表示
21
あらいふ
Python
表示 DL(ソース バイナリ
22
Haruqa
C#
表示 DL
23
飯香
条件設定プラグイン
表示
24
飯香
BF プラグイン
表示

典型的な半音上げプラグインの動作

まず、UTAU プラグインそのものの概要をおさらいしておきましょう。

一般的なアプリケーションにおいて「プラグイン」というと DLL 形式のものが多いですが、UTAU の場合はそうではなく、UTAU プラグインは実行ファイル(.exe)などの形式となります。

UTAU プラグインの仕様は公式サイトなどに書かれていますが、UTAU 画面上でユーザーが選択した音符の情報を、UTAU が一時ファイルに書き出します。UTAU プラグインはその一時ファイルを読み込み、音符の情報を変更して、一時ファイルに書き戻します。プラグイン実行後、UTAU が再度一時ファイルを読み込んで変更内容を確認し、UTAU 画面に反映する、という流れです。

一時ファイルは INI ファイルの形式となっており、1 つの音符の情報が 1 つのセクション(UTAU ではセッションと呼んでいます)にまとめられています。例えば、音程が「ド」(C4)で歌詞が「い」の四分音符だと、以下のように出力されます。

[#0001]
Length=480
Lyric=い
NoteNum=60
Intensity=100
Moduration=0

NoteNum が音程を表していて、数字が大きいほど高音になります。60 なら C4、61 なら C#4 というように、1 増える毎に半音上がっていきます。

つまり、「半音上げプラグイン」であれば、NoteNum を読み、NoteNum の値を 1 増やしてから、一時ファイルを上書きすれば、目的を達することができるわけです。

次節以降で、今回エントリーされた内容について、私の分かる範囲で解説していきます。

解説:C#

まずは、エントリー No.3、私が作成した C# 版の半音上げプラグインについて。

処理方法は単純で、一時ファイルを全行読み込んでから、NoteNum を探し、値を 1 増やしています。

注意すべきは、[#PREV][#NEXT] という特別なセクションです。UTAU は、ユーザーが選択した音符の「前後の音符」の情報も一時ファイルに出力し、その内容が [#PREV][#NEXT] セクションに記載されます。[#PREV][#NEXT] セクションの内容を書き換えてしまうと、ユーザーが選択してない音符の情報が変わってしまうことになるので、避ける必要があります。

セクション行を解析する際に、選択範囲の音符セクション([#0001][#0002]……)かどうかを判定し、結果をフラグとして保持しておきます。NoteNum が出てきた時にフラグを確認し、フラグが立っている場合のみ、処理を行うことで、[#PREV][#NEXT] セクションを避けています。

メモリ上で NoteNum の変更を終えた後、全行を一気に一時ファイルに書き戻しています。

別の C# エントリーとして、ばわめ rwxr--r-- さんの No.15 があります。

この実装では、一時ファイルへのアクセスを INI ファイル解析クラス(をカスタマイズしたもの)を用いて行っています。これにより、メイン側では処理をセクション単位で遷移させることができるようになり、また、NoteNum の値も簡単に取り出せるようになっています。

音符セクションかどうかの判定には正規表現を用いており、確実な判定が行えます。

C# はもう 1 つ、Haruqa さんの No.22 もあります。

この実装も No.15 と同様、一時ファイルへのアクセスを担当するクラスを用いていますが、こちらはイチから作成したクラスとなっており、音符のプロパティーをそれぞれ専用のメンバー変数で保持する仕様となっています。

解説:C++

C++ は masao さんが 3 エントリーされています。

ますは No.5

本人コメントでは、先ほどの No.3 C# 版を移植しただけとありますが、処理方法はかなり進化しています。

一時ファイルを一行一行読みながら作業するのですが、まず、音符セクションが出てきた場合に、その行を「出力バッファ」に溜めます。また、NoteNum が出てきた場合にも、音程を半音上げてから「出力バッファ」に溜めます。それ以外の場合は、出力バッファに溜めません。

結果として、最小限の変更箇所のみが「出力バッファ」に溜まり、それを一時ファイルに書き戻しています。これにより、書き戻す一時ファイルがコンパクトになります。

[#PREV][#NEXT] を除外するフラグの考え方は No.3 と同様ですが、判定方法が賢くなっています(No.3 はかなり手抜きでした)。

次に No.13

こちらは、一時ファイルの取り扱いを楽にする Lib UTAU を用いて実装しています。

一時ファイルの解析を Lib UTAU が行ってくれるので、[#PREV][#NEXT] を除外するのも簡単で、プログラムが非常にシンプルになっています。Lib UTAU の SectionNotesNormalBegin()~SectionNotesNormalEnd() の間だけ処理を繰り返すことで、自動的に [#PREV][#NEXT] が除外されます。

最後に No.20

Lib UTAU と同様の自作ライブラリを用いて実装しているとのことで、No.13 同様、プログラムが非常にシンプルになっています。

自作ライブラリは非公開のため内容は不明ですが、セクションとキーバリューペアの関連性も保持しているようで、使いやすそうです。

解説:C

masao さんは No.7 で C 言語版も作成されています

基本的な考え方は No.5 C++ 版と同様ですが、「出力バッファ」を使わずに、代わりに、逐次「テンポラリファイル」(UTAU の一時ファイルとはまた別のファイル)に書き出しています。C 言語は文字列(に関わるメモリ)の扱いが面倒なので、出力バッファを使わないほうが楽だと判断したのでしょう(違ってたらすみません)。

最後に、UTAU の一時ファイルを削除して、代わりに、プラグインが出力したテンポラリファイルを一時ファイルにリネームして完了です。

C 言語はファイルや文字列の扱いが煩雑なのに、非常にスマートにプログラミングされており、masao さんの技術力の高さがうかがえます(私はこんなにスマートに実装できません)。

解説:Java

Java はお二方がエントリー。

No.12 の山岸さんは、処理の流れとしては No.7 の C と近しい感じになっています。

C とは異なり、Java は文字列を手軽に扱えるので、全体的にコードがすっきりしています。また、音符セクションかどうかの判定や、音高行の判定に正規表現を用いており、スマートに判定ができています。

エラー処理が入っている点も見逃せません。本大会はプラグインの実運用が目的ではないので、エラー処理が入っていないエントリーも多いですが、実際にプラグインを開発する際にはエラー処理は必須になってきます。きちんとエラー処理を行う山岸さんの堅実さがうかがえます。

No.14 の大兄 P さんは、一風変わった処理の流れになっています。

最初に一時ファイルを 7 行読み飛ばしているのは、[#VERSION][#SETTING] といったセクションを読み飛ばす意図だと思われます(違っていたらすみません)。

その後、[#PREV][#NEXT] を避けつつ、NoteNum を 1 上げています。

No.14 は修正バージョンで、当初は No.10 でのエントリーでした。自分のソースコードを見直したり、他人のコードを参考にしたりしながら、ブラッシュアップしていくのも、プログラミングの醍醐味ですよね。

解説:Python

No.21 のあらいふさんは Python で作成されています

行毎に処理を進めていくのですが、「セクション開始待ち」なのか「NoteNum エントリー待ち」なのかという「状態」を保持しておき、状態に応じて、解析を実行する関数を切り替えています(関数ポインタ方式)。

「セクション開始待ち」では、セクション名を見て、音符セクションであれば、「NoteNum エントリー待ち」に状態遷移します。

「NoteNum エントリー待ち」では、NoteNum の行が来たら音程を 1 上げて、「セクション開始待ち」に遷移します。

ファイルの存在確認や、音程の上限確認など、エラー対応関連も充実しています。

解説:UWSC

これまでは、プログラミング言語人気トップ 10 に入るような超メジャーな言語の実装を見てきましたが、ここからは、もう少しいろいろな言語を見ていきましょう。

UWSC では Haruqa さんが 3 件エントリーしています。

今回の大会である意味一番驚いたのが No.1 の UWSC です。このプラグインは、一時ファイルを一切使いません。UTAU を操作し、UTAU のメニューから「選択部分を上へ移動」を実行することにより、半音上げを実現しています。UTAU 本体を操るプラグインというわけです。

No.8 は一時ファイルを使いますが、一時ファイルの書き換えは、メモ帳を操って行っています。

No.9 は普通に一時ファイルを更新しています。

解説:なでしこ

巽さんが使ったなでしこは、日本語でプログラミングが行える言語です。

処理方法としては、いったんすべての NoteNum を 1 上げたあとで(UTAU とは別の)テンポラリファイルに保存し、その後、テンポラリファイルから UTAU の一時ファイルに書き戻す際に、[#PREV][#NEXT] を除外しているようです。

個人的には、「B はそれ」という禅問答みたいは表現が、日本語プログラミングっぽくて好きです。

解説:Lazarus

オープンソース版の Delphi ともいえる Lazarus(言語としては Object Pascal)は、bizz さんが 2 件エントリーされています。

No.4 はオーソドックスなバージョンで、処理の流れは No.5 の C++ とほぼ同じです。

変わり種は No.6

半音上げるという処理を、音程を上げるのではなく、ピッチベンドカーブをいじることによって実現しています。ピッチベンドは PBW や PBY といったパラメータをかなり処理する必要があり、ソースコードの量からもその大変さがうかがえます。

「やり方は 1 つではない」ということがよくわかる実例です。

解説:HSP

bizz さんはもう 1 つ、HSP でもエントリー。

HSP は構文が簡単な手続き型スクリプト言語ですが、コンパイルが可能なため、利用者側は HSP のインストールが不要です。小規模なゲーム開発に人気なイメージがあります。

HSP は目的語を省略できるタイプの言語のようで、内容がいまいち読み取りにくいのですが、処理の流れとしては、No.3 C# 版の全行書きだし型に近いのではないかと見受けられます(違っていたらすみません)。

解説:Electron

あさくら・ふにょしさんは Electron でエントリー。私は今回の大会で初めて Electron の存在を知りましたが、HTML + JavaScript で(ローカルで動く普通の)アプリを作れる環境のようです。Web でバリバリコーディングしている人が、ちょっとしたツールを作る場合などに重宝しそうです。

実装は、最近の JavaScript らしくラムダ式を用いています(幹となる部分)。

処理内容としては、最初に「セクション名」と「キーバーリューペア」のペアをすべて解析して連想配列に格納します(連想配列の入れ子のようなイメージ)。本記事冒頭の一時ファイルで言えば、{#0001={Length=480, Lyric=い, NoteNum=60}} みたいな感じです。JavaScript の柔軟な型の利用が活きています。

その後、音符セクションについて、NoteNum を 1 上げてから、テンポラリファイルに書き戻します。

解説:バッチファイル

あさくら・ふにょしさんはバッチファイルでもエントリー。

いにしえの MS-DOS 時代から省力化ツールとして親しまれているバッチファイルですが、UTAU プラグインとしても使えるのだと思うと、隔世の感があります。

さすがに高度な関数は使えないので、読み飛ばすセクション([#PREV][#NEXT] など)は列挙して対応していますが、バッチファイルだけでも文字列の扱いや音程計算がきちんと行えており、驚きの内容になっています。私は、バッチファイルでこんなにうまく実装できるものとは知りませんでした。

UTAU プラグインとしてだけではなく、日々の作業の省力化のためにバッチファイルを書く際にも非常に参考になる内容になっています。

解説:JScript

UWSC の Haruqa さんは JScript でもエントリー。JScript は JavaScript 互換ですが、JavaScript 単体では通常行えないファイル出力などが可能です。

処理の内容としては、一時ファイルを一行ずつ読み込みながら、NoteNum であれば半音上げつつ、バッファに溜めていきます。最後に、一時ファイルに書き出します。

解説:ExcelVBA

とりフラ.ust.vvv さんは ExcelVBA でエントリー。いわゆるエクセルマクロです。

処理の流れは、No.12 の Java と近しい感じになっています。VBA は Visual Basic for Applications という名前の通り、BASIC 言語の流れを汲んでいますが、ファイルオープンの構文などはまさに BASIC 感に溢れています。

さすがにエクセルファイル直接は UTAU プラグインとして使えないようで、実際に使う際には、バッチファイルと組み合わせているようです。

解説:既存プラグインのパラメーター設定方式

さまざまなことが行える既存の UTAU プラグインに対して指令を与えることで、半音上げるという作戦もあります。「プラグインを開発する」のではなく、「既存のプラグインでまかなう」というイメージですね。

飯香さんの No.23 は、条件設定プラグイン(亜麻)を、すべての音符に対して半音上げるという条件を設定して起動しています。

また、No.24 は、特定の効果を持つ音符の配置を予め BF プラグインに読ませてから、再度 BF プラグインを起動することで、半音上げを実現しています。BF は恐らく Brainfuck のことだと思いますが、難解なパズルです。

まとめ

「半音上げる」。ただそれだけのことなのに、まさに十人十色の実装になりました。

行ごとに文字列的な処理をしていく方法が主流でしたが、人や言語によって実装方法はさまざまでした。また、セクションとその値を有機的に捉えたうえで半音上げるプラグインもいくつかありました。

さらには、音程ではなくピッチをいじるプラグインや、UTAU プラグインの概念を根底から覆すプラグインまで登場しました。

他人のプログラムを見ると言うことは非常に勉強になりますが、今回はシンプルで身近な UTAU プラグインを題材としたことで、より一層そのことが実感できたかなと思います。

ご参加くださった皆様、本当にありがとうございました。

遅刻組

締切は過ぎましたが、投稿いただいたものをこちらに掲載させていただきます。

関連リンク


更新履歴

  • 2020/03/28 [28]~[30] 捕捉

月別アーカイブ
記事検索
最新コメント
  • ライブドアブログ