とらきす の ぐだログ

とらきすのぐだログ

ぐだぐだとなんかするブログ。

近況報告というかなんというか

最近ブログに全く触っていないなと思ったので。

というかTwitterもニコフレもここしばらくやってないですね。別に理由がある訳じゃないんですけど、私飽きっぽいので、そのうちきっと使い始めるようになるんじゃないでしょうか。

えー、今は学校の課題でArduino弄ってます。というか、この愚痴を喋りたかっただけかもしんない。
ともかく、Arduinoゲームボーイ音源を再現してみようかと模索していて、今はLR35902(実質Intel 8080)の命令セットを移植している最中です。

目指すはGBSファイルの再生。
プログラムの中で鳴らしても汎用性皆無で面白くないですし、かと言ってオリジナルのフォーマットを作るのは大変。作ったところで、結局はMIDIとかMMLとかからのコンバータも作らないと意味ないですもの。
GBSならそこそこ知名度ありますし、直接レジスタの値取り出せるならその方が楽ですしね。まぁ、GBSファイルをArduinoの中に置いていちいち読み出す訳にもいきませんので、配列にコンバートするソフトくらいは作りますけども。

でもGBSフォーマットって、あれ要するに「これ音鳴らすコードなんじゃねーか?」って部分をごっそり切り取ってるだけじゃないですか。つまり、万全を期するならば、全命令セットを実装しないといけないんですよね。
音源関係の\$FF00〜3F以外の操作は無視するにしても、どう転ぶかわかりませんし。まだきちんと理解できてないのですけど。

それに、結局はGBS入りのヘッダを置いておかなきゃならないので、Arduino Unoなんかではメモリが足りません。Dueだと動作電圧が3.3Vで鬱陶しいので、まぁ、Megaでしょうな。ポチりますか。

あと1週間でGBSファイルの再生まで漕ぎ着けなきゃなりません。まだ出音テストどころか、音源部も碌に実装できていないのに(!?)
ゲームボーイの音源仕様を理解するだけでやたら時間を食いました。

あ、オブジェクト指向は諦めました(笑)
ファイルサイズは別に良いんですけど、パフォーマンスがどうにも。関数呼び出すだけで数クロック持っていかれるとか言うじゃないですか、冗談じゃない。
グローバル変数置いとくのだけは嫌なので、とりあえず全部クラスで囲って静的メンバにします。
あーでも、それだとconstexpr関数が作れないですね。constexpr入りのクラスの作り方がよくわからんのですよ。

音声出力用の2ch汎用DAC、調整つまみ用の2連可変抵抗、イヤホンジャック、ローパスフィルタ用のコンデンサやらコイルやら。
そして何より、4.194304MHzクロックの水晶発振器! これはゲームボーイのCPUと同じクロック周波数です。
Arduinoに付いている水晶振動子は16MHzなのですが、この数値、個人的にはものすごい中途半端だと思うんですよ。2n、これが一番しっくりくる。ゲームボーイ処理の多くが2nHzに頼っているので、これは外せませんね。
ともかく、幾つかの入力クロックを外部クロックに設定すれば良い…のですよね? 多分。

とりあえず、Arduinoは…なんというか、微妙ですよね。

いや、何というか、わざわざC++で書くものではないでしょう。
浮動小数点数演算が遅いだのアレコレ言われておりますが、C++で書けるようにする為、本来はない機能をソフトウェア的に実装するしかなかったのでしょうね。
今でも生産され続け往年の名機ともいわれるZ80だって、浮動小数点数演算の命令なんて持っていませんよ。そもそもAVRはRISCベースなので、もともと多機能じゃないんですよ。

無理に高級言語を使おうとせずに、どうせならアセンブリだけで良かったんじゃないですかね。
C++にしたって、機能が制限されすぎです。マシンスペック的な問題もあるかとは思うのですけど、C++の真髄はSTLにこそあるじゃないですか。I/O系のとかそういうのじゃなしに、vectorとかタプルとか。動的がダメならせめてarrayくらい入れておいて欲しかった。

C#で書きたい〜(無理

C++でも、プロパティ実装してくれたら個人的にだいぶ評価上がるんですけどねぇ。
あとstrong alias。これは、C++17で実装されるんでしたっけ? きっとavr-gccには実装されないんだろうな…(遠い目)
Atmelが買収されちゃった訳ですし、avr-gccの更新有無も心配ですね。しばらく触る事はないだろうがな!

ともかく、ここ数日でC++は書き飽きたので、作り終わったら関数型言語の勉強でもしようかと思っています。

…んー、どの言語にしよう。
純粋関数言語ってなんか…格好いいですよね(単純)。でも、そうなると選択肢がHaskellに限定される。なんか有名すぎてイヤなんですよね、かじるくらいならいいですけど。
Haskellも結局はI/Oモナドで妥協してるんですから、純粋/非純粋の境界線はあまり気にしなくていいのかも。そもそも、私数学嫌いですし。

んじゃま、OCamlかな。
例のHaxeも、OCamlで書かれてるっていうじゃないですか。オブジェクト指向が書けるともいいますし、初心者の私にはちょうどいいでしょう。何より型推論があるのはありがたいですね。

msiファイルのインストールをちょっぴり簡単にするソフトを作った

(しばらくムダ話が続きます。飛ばしたい方はこちらへ)


あなたは、.msiが好きですか?
私は、はっきり言ってキライだね!


なぜかってそりゃ、もちろん面倒だからです。

.exe形式のインストーラなら、右クリックしてコンテキストメニューから「管理者として実行」を選べば済みますよね。ほぼ手間なし。
熟練されたWindowsユーザーなら、インストーラをいきなりダブルクリックなんてしないはずです。アイコンに管理者権限のマークが付いていれば別ですが。この一連の操作が、クセになってしまっているはずなのです。
…私だけじゃないよね?


それなら、.msi形式はどうか?


  1. 管理者権限でコマンドプロンプトを実行する
  2. インストーラをShiftキー押しながら右クリックして「パスとしてコピー」を押す
  3. コマンドプロンプトにパスを貼り付けてEnterキーを押す




面倒すぎるわ!!!


初見じゃ絶対にわかりませんよ。

右クリックしても「管理者〜」ってのが出てきませんから、普通は「msi形式は管理者権限いらないのかな」と思います。
そしていざインストールを始めてみると、面白い事にエラーメッセージを吐きやがるのです。そしてそのエラーメッセージには、管理者なんて単語は一切入っていないんです。

わかるかこんなもん!!!

そして「msi インストール エラー」とかって検索をかけて、ようやく対処法を見つける… もはや通過儀礼といっても過言ではないでしょう。


慣れてしまえば確かに大した手間ではないのですけど、そうじゃないそうじゃないんですよ

msiexec.exeを起動するには、コンソールからインストーラのパスと一緒に呼び出してやる必要があります。
管理者権限のコマンドプロンプトから呼び出せば、自ずとmsiexec.exeも管理者権限になるという仕組みなのですが…

なんかこう、もっとスマートにできないものなんですかね?

Windows 10なら、スタートを右クリックすればすぐに管理者権限でコマンドプロンプト実行できるようになってますけど、Windows 7だとそれだけでも結構手間がかかるんですよ。

管理者としてインストール」みたいな気楽な感覚で使えたら、私も.msiと仲良くやっていけそうなのに…




EasyMsi

という訳で、EasyMsiというソフトを作ってみました。

どんなソフトかって言うのは、この画像を見てもらえばわかります。

f:id:trackiss:20180918021341p:plain


はい、これだけです。
.msiファイルのコンテキストメニューに「管理者としてインストール」を追加するだけ。

ただそれだけですが、個人的には大満足です。こういう細かいとこに手が届く系大好き。

ダウンロードはこちらからどうぞ。

ご安心ください。EasyMsiのインストーラは、.msi形式ではなく.exe形式です。ウイルスチェックも万全。
そのうちVector様に登録申請しますので、もし申請が通ったらこのリンクは消します。

動作を確認したのはWindows 10 (1803)のみですが、Windows Vista以降のOSであれば、正常に動作するかと思います。少なくとも、Windows XP以前のOSでは動作しません。

動作にはMicrosoft .NET Framework 4.6以降が必要です。Windows Updateを素直に受け取っていればまず問題はないはずです。

インストールに必要なディスク容量は700KB程度。
もしそんなにディスクスペースがないという方がおられましたら、自力でなんとかしてください。

現状、日本語英語に対応しています。インストール時に日本語を選べば「管理者としてインストール(A)」に、英語を選べば「Install as administrator」になります。
それ以外の言語は気が向いたら。



本当に、プログラム的には大した事してないんですよね。マジで数行だけ。
msiexecを管理者として呼び出して、同時にパスを渡してやるっていうシンプルこの上ないコードです。

それよりもむしろ、レジストリの操作とか、あとインストーラの作成に手間取りました。
今回はInno Setupを使ってみた訳ですが、言語によってレジストリ処理を変える方法でずっと詰まってた。結局、命令文にLanguage: xxxオプション付けるだけでした。

それじゃ、iOS 12のアップデートしてきますーノシ

(個人的)最強のプログラミング言語「Haxe」

プログラミング言語

まぁ、もはや宗教ですよね。こういうのって。
そら一長一短はあるでしょうけど、慣れてるものが一番なのは変わりませんよ。

という訳で、下記は「個人的な意見」ですのでね。参考程度にお読みください。


Haxe?何それ聞いた事ない!

Haxe(ヘックス)は、そこそこマイナーなオブジェクト指向+関数型プログラミング言語です。
とはいえ、「関数型よくわからん」って人は、別に関数型構文使わなくても問題ありません。

まずは世界にこんにちはしておきましょう。

// Main.hx

package;

class Main
{
  public static function main():Void
  {
    Sys.println("Hello World!");
  }
}

このコードからだけでも、Haxeの特徴が幾つか見えてくるかと思います。
Haxeシンタックスハイライトまで用意してくれているはてなさんホント神

  1. packageとかいう謎の構文
  2. とりあえず全部クラスで囲っとけ記法
  3. エントリーポイントはMain.hxのmain関数
  4. 型は名前の後に書く

ん、こんなもんでしょうか。
まぁ際立っておかしな部分はないですよね。

ただ、もしかしたらこの特徴を見てハッと思い当たるフシがある人もいるかも知れません。

実はこのHaxe、かの有名なAdobe Flashスクリプト言語であるActionScriptとほとんど同じ構文なのです。
というより、もともとActionScriptの代替として開発された言語だそうで。

また、HaxeはaltJSとしての一面も持ち合わせています。

altJSってのはつまり、JavaScriptがフリーダムすぎるから書きやすくしよーぜ、ってノリで開発された、いわばJavaScriptの亜種みたいなもんですね。
Microsoftが開発しているTypeScriptなんかが有名な例でしょう。

HaxeにもJavaScriptのコードを出力する機能が付いていますし、何ならHaxeから出力した方が10%程早く動作するそうで。
そもそも、Haxeの構文そのものがJavaScriptの標準化であるECMAScriptと似通っています。

というかですね。

Haxeが出力できる言語の一覧を見てみましょう。

多い…多くない?

その結果、Haxeがターゲットとしているプラットフォームの一覧が、こちら。


クッソ画質荒いやん、気が向いたら直しときます

いや…マジで多いって。

ここで重要なのが、ソースコードを出力するという点。つまり、ネイティブコードでのクロスプラットフォームが実現できるという事になります。

それじゃ、出力されたソースコードを元に、更にコンパイルの作業をしなきゃいけないの?それは面倒だよ…

一応、FlashとNeko、HashlinkについてはHaxe単体でのコンパイルが可能ですが、確かに面倒ですよね。

そこでLimeの出番です。

Limeは、ウィンドウ処理や入出力、音声処理などの低レイヤー層を管理するフレームワークです。しかも、ビルド機能付き。
WindowsならVisual C++macOSならXcode…といったように別途ソフトのインストールが必要ですが、シームレスに実行ファイルを作成できるようになります。


Haxeの言語機能

まず、Haxeは静的型付け言語です。
先ほども書きました通り、変数名やメソッド名の後に型を指定します。

// 32bit整数型
var i:Int = 5;

基本型はInt32(Int)、Int64、Float、Boolのみのようです。
Intは環境に関わらず32bitとなるようです。
Floatは倍精度、つまりはCにおけるdouble型ですね。
一応、符号なし整数型としてUInt型も定義されているようですが、非推奨となっています。

インスタンスの生成や、配列の作成時にも型を指定します。

// インスタンスの生成
var c:Test = new Test();

// 整数型配列の作成
var a:Array<Int> = new Array();

まぁ、でもいちいち書いてたら面倒ですよね。インスタンス作成時とか。

という訳で、もちろんあります型推論

var i = 5;
var c = new Test();
var a = [0];

メソッドの引数なんかにも型推論が使えますが、こちらはあまり推論の精度が良くないし、わかりにくくなるので使わない方が良いでしょう。

そして、Haxeだとこんな書き方ができちゃいます。

var a = [for(i in 0...10) i];

// [0,1,2,3,4,5,6,7,8,9]
Sys.println(a);

// Success
Sys.println(if(a.length == 10) "Success"; else "Failure";);

そう、Haxeではif文やfor文などが式として使えてしまうのです!
これがものすごく便利。
偶数だけを順に格納したければ、

var a = [for(i in 0...10) if(i % 2 == 0) i];

// [0,2,4,6,8]
Sys.println(a);

はたまた、

var a = [for(i in 0...4) i * 2];

// [0,2,4,6,8]
Sys.println(a);

と書けば良いのです。すごいっしょ?

ただ、Haxeだといわゆるforeach方式のfor文しか使う事ができません。逆順も不可能です。
つまりHaxeのfor文では、Cでいう所の

// C
for(int i = 10; i > 0; i--) {}

みたいな事ができないという事になります。


…forがないなら、whileを使えばいいじゃない!

var i = 10;
var a = [while(i > 0) i--];

// [10,9,8,7,6,5,4,3,2,1]
Sys.println(a)

いや、でもこれだと別に変数用意しなきゃなんでちょっと良くないですね。他になんか良い方法ないんやろか。

それと、新しい言語を習得するときにかなりのネックとなる多次元配列。これ、言語によってかなりバラつきありますからね。構文も概念も。

まず、Haxeには多次元配列という概念はありません。
その代わり、配列の中に配列を入れる事が可能です。JavaScriptと同じですね。わかりやすくて実に良い。

また、連想配列を作る事も可能です。

var a =
[
  [0, 1, 2],
  [for(i in 0...3) i],
  [
    "ぜろ" => 0,
    "いち" => 1,
    "に" => 2
  ]
];

// 全て 2
Sys.println(a[0][2]);
Sys.println(a[1][2]);
Sys.println(a[2]["に"]);

正確には、連想配列はMapオブジェクトとして実装されています。上記のは省略記法。

まぁ、他にも色々と便利な機能がてんこ盛りです。すげぇっすよ。


言語独自の機能があるって聞いたけど

Haxeには、どんな言語に出力しても使えるHaxe標準ライブラリのほか、言語独自のライブラリも幾つか含まれています。
C++なら標準ライブラリが移植されていますし、JavaScriptならjQueryが移植されています。当然、他の言語に出力する時には使えません。

特に、Haxeの唯一のマルチメディア機能と言っても過言ではないFlash API。これも、Flashでしか使えない機能となっております。残念。


が…あるッ…
OpenFLッ…


何それ

OpenFLは、Flash APIHaxeに移植するフレームワークです。Limeを下敷きに動作します。

…というか、Limeのリンク踏んでくれた方なら気づいたと思いますが、そもそもLimeはOpenFLの一環で作られたものです。

しっかし、Flash APIならマルチメディア系で出来ない事ほとんどないですよ。ゲームだってどんとかむです。

例えば、OpenFLを使って作られた有名なゲームにPapers, Pleaseがあります。
入国審査をするゲームですね。
どうやら映画化が決定しているらしく、Wikipediaに個別記事まである。そんなに売れてたんだあのゲーム。

それと…こちらはややマイナーですが、Evolandというゲーム。
初めは2Dのピクセルに始まり、次第に3Dポリゴンへと変わっていくというかなり特殊なゲームですね。
続編のほかモバイル版もリリースされており、まさにHaxeフル活用って感じです。

まぁ、デベロッパであるShiro Gamesの創立者の一人は、Haxe開発者であるNicolas Cannasse氏ですので、当然と言えば当然ですけどね。

また、OpenFLを使った2DゲームエンジンHaxeFlixel(ヘックスフリクセル)があります。

Flash向けのゲームライブラリであったFlixelを、Haxeに移植・改変したフレームワークですね。
今はまだあまり有名なゲームはないようですが、結構な数のゲームが作られています。見たところ、モバイル端末向けのゲームが多いようです。これもHaxeだから成せる技。


Haxeの開発環境

現状では、FlashDevelopVisual Studio Codeがベストな選択肢かと思います。

FlashDevelopの場合は標準でHaxeをサポートしていて、新規プロジェクトの作成も簡単に出来ます。
ただ、私が普段使い慣れていない為か使いにくかったです…申し訳ない。

Visual Studio Codeの場合、vshaxeというサードパーティの拡張プラグインを使う事になります。
しかしサードパーティとは言え、頻繁に更新されていてかなり信頼性は高いです。シンタックスハイライトやオートコンプリート、エラー診断、コンパイルなどなど、一通りの機能は揃っています。
というか、Haxeコンパイラそのものに構文を解析したりオートコンプリートしたりという機能が備わっていますので、それを利用している形になっています。C#のRoslynとVisual C#の関係性みたいなもんですかね。ですので、精度で他に劣るという事はないでしょう。

Limeのプラグインも別途公開されていますので、VSCodeから直接 実行ファイルの作成まで出来てしまいます。
vshaxe単体でも、JavaScriptだったりNekoだったりならコンパイルは可能ですが。

VSCodeは(一応)テキストエディタなので比較的動作も軽く、他の言語をササッと書く時にも便利です。
HTML/CSSに関してのみはBracketsの方が良いと思いますが、それ以外で専用IDEがない言語なら、だいたいVSCodeで間に合います。JSONとかね。

それに知ってる方も多いとは思いますが、ついこの間にGithubMicrosoftに買収されましたよね。VSCodeには以前からもGit連携機能が搭載されていましたが、今後はよりGithubに密接した機能が追加される事でしょう。期待です。

そして何より、VSCodeWindows/macOS/Linuxに対応しています。アレです、最近流行りのElectron製アプリです。
FlashDevelopはWindows専用なのが一番の難点と言えましょう。


Nekoって?

Nekoは、2005年あたりに登場した比較的若い言語です。

一応は言語仕様を持っており、中間言語に変換して、Windows/macOS/Linuxで動作するVM上で実行するタイプの言語なのですが、Haxeから変換して踏み台として使用される事が多いと思います。
そもそもNekoの開発者はNicolas Cannasse氏(また出た!Haxeの開発者)ですし。

しかしそのお陰とあって、PC向けのソフトウェアを作るのならNekoを選択しておけば間違いはないでしょう。


Hashlinkって?

Hashlinkは、2年前くらいに突如として登場した言語です。

というか、Haxe Foundationがお送りするHaxe専用VMですまたかよ

Neko VMと何が違うのかと言いますと、まずこちらはiOSAndroidにも対応しているらしいという点。
そして描画にSDL2を使用しており、独自のUIライブラリも将来的に提供されるそうです。
また、静的型付けになった事でよりHaxeとの親和性が向上していたり。

しかし、新参といってもなかなか侮れません。既にHashlinkで作られたゲームが幾つかリリースされています。

まず、お馴染みShiro GamesのNorthgard。すげー3D。かなり売れているようですね。
そしてDead Cells。ドットのハクスラですかね?こっちもなかなかの高評価。

ただね…情報が少なすぎる!!
日本語の情報がとかじゃなくて、英語の情報も超少ない。公式サイトとかGithub関連除いたら、ほぼ皆無と言って良いと思います。
Githubの方も、ドキュメントはたった数ページ。チュートリアルはありませんので、何を書けば良いのかわからない状態。

ドキュメントが充実していけば、かなり今後に期待できそうですね。


とまぁ色々と書いてきましたが、私自身もまだまだ勉強中です。
マクロとか、ほとんど理解してません。
結構厳格な言語ですので慣れるまで大変かもしれませんが、それを含めても素晴らしい言語ですよ。使おう!

そんな訳で、ざっくりとHaxeの紹介でした。


Haxeフレームワークメモ

(個人的)最強のWindows向け高音質音楽プレイヤー「Dopamine」【+日本語化パッチ配布】

宣伝: このDopamine含めた「.msi」形式のインストーラをちょっぴり使いやすくするソフトを作ってみましたので、よろしければどうぞ

trackiss.hateblo.jp


追記: 2.0 Preview 2の日本語訳ファイルはこちら

更新が途絶えてはや3かg…

さ、3ヶ月!? マジかよ、そんなに経ってたとは思わなかった。

えー、あのですね。私がブログをやっているのは、時々湧き上がってくる文章書きたい欲を解消する為なんです。
でも、とある超大型記事の準備やらSCP財団の執筆活動やらで、文章書く機会が最近多くてですね。私の中で、かなり満足してしまっていたんですよ。
それにしたって、そんなに放置してたとは…反省。

でも多分、今後もこんな感じだよ。許せ。

というわけでお茶を濁す為に、最近(今日)見つけたWindowsの音楽プレイヤーをご紹介します。
かなり良いソフトなんですけど、国内じゃあんまり知られていないようで。こうなったら布教するっきゃないって事です。


PCの音楽プレイヤーソフト。
かつて、私もいろいろと探してまいりました。

iPhoneの音楽プレイヤーアプリを探していた時期もありましたが、今の私のiPhoneは16GBしかないので曲など入れられる訳もなく。
ちなみに、私はRadsone使ってます。純正のミュージックアプリも悪くないのですが、謎に重いんですよねあれ。

私は、PCの音楽プレイヤーとして、結構長い期間iTunesを使っていました。
これが、わりかし使いやすかったんですよね。特にiPhoneユーザーだと。
勝手に変なジャケット拾ってきてふざけんなってなった事もあったりでちょいちょい不満は持っていたんですが、ビジュアライザが綺麗だったのであまり気になってませんでした。

んで、ある日音楽ファイルの整理をしていて、MPC-BEで再生したり色々していましたら。

あれ、iTunes音質悪くね?

って気づいた訳です(遅
MPC-BEはASIOに対応していて、それで聴いてみたら全然音が違ってビックリ。
しばらくの間使ってたせいで、iTunesの音質に毒されてしまっていたんですね。

そんなこんなで次に使い始めたのが、TuneBrowserです。
ASIO対応なので音質は申し分なかったですし、見た目も気に入っていました。
ただ、途轍もなく重かった。
使いながらネットサーフィンとかしてるとしょっちゅうノイズ入ったりするんです。何というか、うちのPCでは使い物にならんレベルだった。
それと、シェアウェアですし…いや、学生にとっては、決してはした金じゃありませんからね。
ちゃんとしたソフトウェアにはお金を払いたいですけれど、同じ事が無料でできるならそっちを使いたい派。中途半端かよ。まぁ、そんなもんですよね。

そんな経緯で、今回の本題。

Digimezzo様のフリーソフト(しかもOSS)「Dopamine」の紹介です。

029_dopamine_01

029_dopamine_02

まず、見ての通りインターフェースが綺麗です。
最近、ソニーが何やらハイレゾ対応の音楽プレイヤーソフトをリリースしていたようですが、やっぱりUIがものすごい時代遅れ感あるんです。すごく安っぽい。
一方こちらは、ここらで流行りのフラットデザイン。スッキリとしたインターフェースで、超クールです。
まぁ、まさにWPFアプリですよと言わんばかりのUIなんですけどね。だが、それがいい

029_dopamine_03

029_dopamine_04

このように、iTunes風のアートワークプレイヤー表示も可能。

さらにさらに、

029_dopamine_05

こういうマイクロプレイヤーの他、

029_dopamine_06

こんな小さなナノプレイヤーもあります。あまり画面を占有したくない時に便利ですね。

029_dopamine_07

なんと10バンドイコライザも内蔵。しゅごい。

029_dopamine_08

設定も、結構細かい所までできちゃいます。アートワークに応じてテーマカラーを変える機能とか、オシャレで良いじゃないですか。あまり精度は良くないみたいですが…

その他、オンラインで歌詞やアーティスト情報、アートワークを取得する事もできます。Last.fmとの連携も可能。

音質面で言うと、DopamineはWASAPI排他モードに対応しています。
WASAPIってのは、最近のWindows(確かVista以降)でのみ使えるオーディオドライバです。
これを排他モードで使用すると、他のアプリケーションの音が一切聴こえなくなる代わりにミキサーを通さなくなるので、音質が向上するのです。
そこらの音楽プレイヤーソフトよりは、高音質と言えるでしょう。

私はGithubの使い方を理解していないクソ雑魚ですので、将来の私がGithubを使いこなせるようになっている事を信じ、ここに要望を書いておきます。

  • ASIOに対応して欲しい
  • ジャケットが1:1じゃない場合、引き伸ばさないようにして欲しい
  • キーボードショートカットのカスタム機能が欲しい
  • ソートを使いやすくして欲しい
  • リスト中で、再生中の項目は背景の色を少し変えて欲しい
  • 曲どうしの空き時間をもう少し短くして欲しい

いやぁ、ちょっと駆け足になってしまいましたね。
今テスト期間中なんで、許しておくれ。

えー、さてここからが本題です(ぇ

このソフトウェアは、2018年06月06日現在、日本語に対応しておりません。

あれれ? ちょっと待ってよ!
このブログに載っている画像だと、確かにUIが日本語で書かれているよ! これは、何かがおかしいに違いない!



はい。
というわけで、日本語訳しました。こちらに日本語ランゲージファイルを置いておきましたので、ご自由にお使いください。
DopamineのインストールフォルダにあるLanguagesフォルダ(標準だと "C:\Program Files (x86)\Dopamine\Languages" もしくは "C:\Program Files\Dopamine\Languages" )にぶち込むと使えます。

ただ、修正の為にちょくちょく更新してますので気をつけてください。
2018年06月15日 15:05 に更新しました。更新内容は、細かい修正のみです。

なお、既に製作者であるDigimezzo様へ当ファイルを提供(見てくれたかどうかはわかりませんが)してありますので、うまく行けば公式に採用されるかも知れません。
お返事がなかったので、もうプルリクエストしちゃいました。あれで良かったんだろうか。Github初心者なんで不安です…
無事マージされたっぽいので、そう遠くないうちにリリースされるでしょう。

それじゃ、またいつか。


追記:
篠DさんにMusicBeeについて教えて頂きました。

いや、もちろんMusicBeeの存在は知ってたんですよ?
かつてはWindowsの音楽プレイヤーと言えばコレ、みたいな立ち位置でしたからね。
ただ私の中で、そのMusicBeeは数年前で止まっていたのです。

今になって使ってみたら、かなりモダンな見た目に変わっていてビックリ。機能面にしても、Dopamineの方が優っているとは言い難い…どころか、全部負けてる気がします。ASIO対応してますし…確かに音が鮮明に聴こえてきます。

ただ、個人的にはやっぱりDopamineのデザインが好き。ザ・WPFな感じの、超シンプルデザイン。良いと思いません?

あ、ちなみにマテリアルデザインはあまり好きではありません。
いや、マテリアルの記号的なデザインや、アクセシビリティは別に良いんですけど。というか、フラットデザインの短所を上手くカバーしていて、全然悪くないと思っています。素晴らしいとさえ思います。

ただ、最近のGoogleがごり押してくるあのビビッドカラーマテリアルデザインが嫌いです。
何というか、見にくいし、安っぽく感じます。ユニバーサルデザインに配慮するのは、もちろん大事な事でしょう。それにしたって、流石に単調化しすぎでは?と思います。
鮮やかな色と、それに反発するかのような全く異なる色。それらが画面を埋め尽くしているのを見ると、それだけで何だか疲れてきます。
アイコン等のごく小さい部分であったり、いっその事マップのような巨大な一要素の中で使うのであれば、そのデザインも意味を持ってくるでしょう。しかしヘッダ等の大きくかつ他と区別されるべき要素にビビッドを取り入れられてしまうと、むしろ見にくく感じてしまいます。あくまで個人的にですけど。

その点だけで言うと、Appleのデザイン規則は良い塩梅に収まっていると思います。Appleは、個々の小さな要素を目立たせる為に部分的にビビッドカラーを取り入れているだけであって、大きな要素はモノカラーを基調とした清潔で落ち着いた雰囲気に留めています。
更に言えば、Appleビビッドカラーを取り入れる時に、背景色として黒を好んで使います。膨張色である白の上にビビッドを乗せてしまうと、互いに主張が強くて圧迫感が強くなります。その点、黒であれば、全体に引き締まった印象に加えて映えるビビッドとで、上手くバランスが取れると思うのです。
私自身Apple製品はあまり好きではありませんが、ことデザインに関しては常にトップを走り続けている存在だと考えています。
いやまぁ、私がモノカラーとパステル調好きなだけかもしれませんけどね。

閑話休題(遅ぇよ

WASAPIの方が音に丸みがあって聴き疲れしなさそうなので、ガチで音楽鑑賞する時はMusicBee、そうじゃない時は…みたいな感じで、その辺上手く使い分けていこうかと思います。


さらに追記:
Dopamine 2.0のプレビュー版がリリースされました。

使いやすくなってはおりますが、プレビュー版というだけあってまだ細かい部分の調整が済んでいないようですね。
ライトテーマの設定が起動時に適用されなかったり、曲の情報が下の方まで見れなかったり。
私は新しいもの好きなので、こっち使ってますけど。実用には十分耐えうるレベルです。

まぁ、一応日本語訳しておきました。
こちらからダウンロードしてください。
1.x系列への日本語ランゲージファイルの後方互換性はありませんので注意してください。

Preview 2がリリースされた為、標準で日本語に対応致しました。(パチパチパチ
ただ、Preview 1更新分までしか反映されておりませんので、こちらからPreview 2向け日本語翻訳ファイルをダウンロードしてください。

でも、Preview 2、なんか不安定なんですよね~。
例えば、プレイリストがアルバム名順に再生されてしまったり…
私はまだしばらくPreview 1で使っていこうかなと。

という訳で、Preview 1の日本語翻訳ファイルはこちらからどうぞ。ちょい更新してあります。

隙あらば自分語りする記事 〜 同人誌編

書く事がなかった

というわけで(?)、自分語りシリーズ第1弾。好きな同人サークル・同人誌を挙げていきます。

まあ冗談は抜きにしても、無性に自分語りしたくなる事ってあるじゃないですか。ありません?
ブログってそういうもんですし。

私も初めのうちはどのサークルさんを選べば良いのかわかりませんでしたし、ちょっとは参考になるやも。

とは言っても、同人誌歴はあまり長くないので有名どころばかりになります。

あ、あと必然的に東方関連になります。


ふあん亭

フラリ(旧・フラリ通る)さん、米泥棒さんの2人()によるサークル。

大御所さんですね。これは譲れない。

ここまでしっかりとしたギャグ描けるサークルはなかなかありません。ストーリー構成が上手すぎる。

そんでもってシリアスも良い。最強かよ。

長くやっているだけあって絵柄がコロコロ変わっていますが、特に中期のふとちゃんがかわいい。

多分初めて読んだのは、ACID CLUBさんとコラボしたサークル「ACID CLUB VS ふあん亭」の「アポカリプス」ですかね。
ぶっ飛んだ内容にメチャクチャ笑わされました。そこから既刊買い漁りましたね…

ギャグだと「なにこれ」とか「PATCHOULIS」「TENGU OVER」が好きですね。
あと、これはギャグかと言うと少し微妙ですが「地上の玉兎は何見て跳ねる?」がすごく好き。てゐがいい性格してるぜ…!

シリアスなら「日帰り怪綺談」「彼女の遺失物」「回帰談」の3部作。これは一度は読んでおくべきだと思う。
それと「想起の途」。

想起の途はPixivで公開されているので見てみては如何でしょう。


うり畑牧場

まくわうにさんのサークル。

まず、絵が好き!

のんびりしたストーリーも好き!

神子えもん好き!(錯乱

…えー、神子好きになったのは確実にこのサークルさんの影響ですね。間違いない。

このサークルさんの同人誌には、幻想少女達だけでなく普通の人間が登場する事が結構ありまして。あぁ、人間も普通に暮らしているんだな〜って思うわけですよ。
こんな幻想郷なら行ってみたいですね。
ふあん亭さんのは嫌だもん。絶対危険でしょ。

オススメは「蛮酌」「蛮酌二軒目」ですかね。ばんきっきが人里に住んでいるというだけあって、人里の描写が多くてすごい親近感。ちょっとばかし飯テロですけど…


ALISON航空

ALISONさんのサークル。

…えー、知ってる人は知ってるよね?
ニコニコとか、その筋では有名な方ですので…

まぁ「その辺」の話はジャンルがニッチ過ぎるので置いておくとしまして、ぜひ読んでもらいたいのが「宇宙の死を見た不老不死」。

Twitterとかでちょっとばかし話題になった記憶かありますが、ほんとに面白い。天才かと。
こればっかりは読んでもらわないとわからないですね。

同人誌として発行もされていますが、元々はニコニコ静画で公開されていたものですので無料で読めます。読め。


poprication

べにしゃけさんのサークル。

レイマリと言えばこの人、って感じ。

きゃっきゃうふふしてる話も多いですが、シリアスがこのサークルさんの本領。
寿命ネタなど、かなりヘビーな話も多いです。
幻想少女故の苦悩が垣間見えます。霊夢視点が多いですかね。

少女漫画タッチな絵も好み。

総集編が委託頒布されていますのでそちらを読んでみると良いと思います。


プレカレデウム

女王陛下さんのサークル。

せいしんの人。
非常にKENZENです。主に危ない方向で。
この人のせいで新たな世界が開けました(恍惚

あ、陰キャ霊夢もいいぞ。

現在の主な活動はニコニコ静画Twitter等がメインですが、H30春季例大祭に初参加するとの事。

ちょー楽しみ。
お金ないから行けないけど。

誰かに代行してもらおう。


個人的メモ: 「SCP財団」二次創作のライセンスまとめ

(2018/01/28 ライセンスの「例」がCC BY-NC-SA 3.0になっていたので修正)
(2018/01/26 日本語訳ページの利用について加筆)

"超"収容違反も開催する事だし、多少は需要あるでしょ(適当)

えー、間違ってたらコメントでご指摘願います。ホントに。
不十分な部分もあるかもしれませ…いや、あるね。確実に。多分。

まぁ要約みたいなものですんで…ご勘弁。
イベント参加とかしたい人は本家のライセンスガイドも目を通しておこうね。


警告

「SCP財団」の二次創作は例外なく以下の条件に従う必要があります。

  1. SCP-111、SCP-173、SCP-1926の画像、及びSCP-1926の本文は営利利用できません。これは「金銭傍受が発生する同人活動」においても同様です。
  2. 上記3つを除く全ての「SCP財団」コンテンツはクリエイティブ・コモンズ 表示-継承 3.0(CC BY-SA 3.0)ライセンスの下に提供されます。後述する「継承」により、これは二次創作作品に於いても例外なく適用されます。このライセンスに於いて遵守すべき要素は以下の通りです。
    • BY (表示)
      このコンテンツを利用して作られた派生作品は、このコンテンツの名称とその所在、著作者名を併記しなければなりません。
    • SA (継承)
      このコンテンツを利用して作られた派生作品のライセンスは、このコンテンツのライセンスに準じなければなりません。

これらを要約すると、以下の4つが「SCP財団」二次創作に於いて遵守すべき条件となります。

  • SCP-111、SCP-173、SCP-1926の画像を利用し金銭を受け取る行為をしない
  • SCP-1926の本文を利用し金銭を受け取る行為をしない
  • 親作品の名称、所在、著作者を表示する
  • 作成した作品のライセンスにCC BY-SA 3.0を適用する

SCP-111、SCP-173、SCP-1926について

上記の条件に従うと、例えば「SCP-111、SCP-173の名称及び本文のみを利用する(SCP-1926の場合、名称のみを利用する)」のであれば「営利利用は可能」という事になります。

しかし、なるべく不要なトラブルを避ける為に、金銭傍受が発生する可能性のある二次創作物に於いてはこれら3つのSCPの利用そのものを(その利用範囲に関わらず)自粛する事をお勧めします。


親作品情報の併記について

原則として「SCP財団」のコンテンツは(上記例外を除き)CC BY-SA 3.0ライセンスの下に提供されています。

よって「SCP財団」の二次創作では、「BY(表示)」に基づき以下を表示する必要があります。

  1. SCPナンバー
  2. 該当ページのURL
  3. 著作者名

例を以下に示します。

 "SCP-682" by Kain Pathos Crow
  (http://scp-wiki.wikidot.com/scp-682

これはあくまで一例です。必要な要素さえ満たしていれば書式は問われません。

※注意

「SCP財団」日本支部に於いて翻訳作業が成された他国版「SCP財団」コンテンツの日本語訳を二次創作に利用する場合は、日本支部に於ける「該当ページのURL」と「翻訳者名」を表示する必要があります。

一方で、2017年に行われた「SCP財団」日本支部と非公式日本語訳Wikiの統合に伴い、非公式日本語訳Wikiから日本支部へ転載されたコンテンツを利用する場合は、非公式日本語訳Wikiに於ける「該当ページのURL」を表示する必要があります。
これは「統合以前の日本語訳コンテンツの著作権は全て非公式日本語訳Wikiに帰属する」事に起因するものです。

利用するコンテンツが統合以前に日本語訳されたものであるかどうかは、該当ページの「履歴」より確認する事ができます。
rev.0に非公式日本語訳WikiのURLが貼付されている場合、そのコンテンツは非公式日本語訳Wikiより転載されたものである事を示します。表示するURLにはこれを用います。
また、統合以降に日本語訳された(日本支部にて翻訳作業が行われた)コンテンツの場合、同様の方法で翻訳者名を確認する事ができます。rev.0に表示されるユーザー名がこれに該当します。

なお、非公式日本語訳Wikiでは匿名で翻訳作業が行われていた為、非公式日本語訳Wikiより転載されたコンテンツについて、表示する著作者名は「匿名」としてください。

ただし非公式日本語訳Wikiは現在閉鎖されている為、統合以前の日本語訳コンテンツを利用する場合、「著作権の所在を明確にする」事はできても、その「コンテンツ自体にアクセスする事ができない」という若干の矛盾が発生します。
ライセンス上必要な事ではありませんが、日本支部のURLも「転載先」などとして併記しておくと良いでしょう。


ライセンスについて

「SA(継承)」に基づきこれら「SCP財団」二次創作作品はCC BY-SA 3.0ライセンスの下で提供しなければなりません。
よって「この作品はCC BY-SA 3.0ライセンスの下で提供されている」事を表示する必要があります。

以下に例を示します。


クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下に提供されています。


これは、クリエイティブ・コモンズの公式ホームページより発行されるHTMLコードを利用したものです。
これに限らずとも、CC BY-SA 3.0ライセンスが適用されている事が判別できるようであれば書式は問われません。

ちなみに「非移植(Unported)」とは、このライセンスは万国共通の規定の下で策定されたものであるという事を示すものです。
これとは別に各国の法律に合わせて改変された「移植(Ported)」ライセンスも策定されていますが、多くの国に於いてはバージョンが古いままになっています。例えば、現在の日本に於ける移植版CCライセンスの最新バージョンは2.1です。
また、最新のCCライセンスバージョンであるクリエイティブ・コモンズ4.0では移植/非移植版というシステムそのものが廃止され、全て国際版へ統合されました。

これらの事情により、CCライセンスと言えば非移植版を指す事が殆どである為、一般に「非移植」の表記はしなくとも問題になりません。


その他注意すべき事リスト

  • 「金銭傍受の発生する活動」には当然YouTubeやブログ等の広告収入も含まれます。SCP-111、SCP-173、SCP-1926を取り扱う場合は広告収入が発生しないようにしておきましょう。
  • "Tale"はその性質上、基底となるSCPコンテンツや世界観の上に成立します。つまり、"Tale"はあくまで二次創作作品、要するに「非公式」です。"Tale"を二次創作に利用する場合はこの事を念頭に置いておきましょう。
  • SCPに限らず、二次創作は元となる親コンテンツがあってこそ成り立ちます。特にSCPに於いては、親となるコンテンツは無料で公開されているものになります。それを利用した上で(制作費の回収を除く)金銭的な利益を得る事はあまり勧められる行為ではありません。この事を理解した上で有償での販売/頒布を行いましょう。

"SCP-111" by Adam Henderson
http://scp-wiki.wikidot.com/scp-111
"SCP-173" by Moto42
http://scp-wiki.wikidot.com/scp-173
"SCP-682" by Kain Pathos Crow
http://scp-wiki.wikidot.com/scp-682
"SCP-1926" by DrBerggen
http://scp-wiki.wikidot.com/scp-1926

This webpage is licensed under Creative Commons Attribution-ShareAlike 3.0 License.

個人的メモ: 描画関連の処理系・ライブラリ

あくまで個人的なメモみたいなものだよ。
需要?知らんな…

そんでもって多分どこかしら間違ってるよ。やったね。


まずDirectXってなにさ

化け物(Microsoft)が作った化け物。要はマッチポンプ
基本的にWindows向けで、それでなければXboxとか。これが地産地消ってやつか(違

要約すると、高品質な2D / 3D描画に加え、音声処理等のマルチメディア機能、その他入出力なんかをごっそり包括する巨大API

このうちDirect3Dが3D描画のフレームワークで、OpenGLと主に競合するのはこの部分。

んじゃOpenGLはなんなの

純粋に描画機能のみをサポートするマルチプラットフォームAPI
Javaはこれに頼りっきり。macOSもだいたいコレ。勿論Windowsでも動く。

そしてAndroid向けアプリはだいたいJavaで書かれてる訳で、つまりはこれもOpenGL
でも、デスクトップ向けのOpenGLをそのまま使うのは無理があるので、モバイル向け実装のOpenGL ESが使われる。iOSもたいていコレ。

んでもってJavaScriptと組み合わせて使うWebGLというブラウザ向けの実装もある。やべーなこいつ。

結局どっちが良いの?

どっちでもいいれす(^q^)

強いて言うならば、Windowsオンリーでいいなら断然DirectX。まぁ仕方ないね。

でも、そもそもDirectXOpenGLもそのままだと複雑すぎて扱いにくいので、普通はライブラリなんかを仲介する訳で。
そんで今の時代はもうワンソース / マルチプラットフォームが当たり前になってきている訳で。

つまり、DirectXだのOpenGLだのはそんなに気にしなくてもおk。動きゃいいんだ、動きゃ。

長い。3行で。

Windows = DirectX or OpenGL
macOS, Linux = OpenGL
iOS, Android = OpenGL ES


DXライブラリ

動作環境:

開発言語:

Windows版はDirectXAndroid版はOpenGL ESのラッパー。
どちらかと言うと2D向け。でも3Dもイケる。 Windows版に限り、C#向けに変換したパッケージもある(ただし一部の機能が制限される)。
基本的な機能のみを揃えるローレベルな設計方針により、めちゃくちゃ処理速度が速い。
下手にゲームエンジンを使うよりかは断然速い。はず。

あと、PS4/PS Vita向けのソフトウェアも作れるらしい。


SDL

動作環境:

開発言語:

  • C++
  • and so on...

Direct3D / OpenGL (ES)のラッパー。WindowsでもOpenGLが使用できるらしく、アンチMicrosoft派の人でも大丈夫(ぇ
設計方針としてはDXライブラリと同じくローレベル。
また、音声や入出力なんかを扱う為の補助ライブラリもある。

数多くのバインドが存在。現状ではAda、C#、D、Go、LuaOCamlPascalPython、Rust向けにバインドされている。
あくまで公式ではないので更新具合に注意。


Hot Soup Processor

動作環境:

開発言語:

BASIC風のHSP言語を使い、簡単に、手軽にソフトを作る事のできるツール。
基本的にはWindowsのみ対応。
一通りの2D / 3D描画、音声処理等を内包する。
独自のIDEを持つが、そもそもの言語仕様含めて評判はあまり良くない。
でも、ネイティブのGUIを何故か簡単に書けてしまう。Win32APIも比較的簡単に叩ける。やろうと思えば何でもできる。

実行時にはHSP Dishというランタイム上で動作する。
このランタイムはLinuxiOSAndroidWebGL向けに移植されている為、各環境にて実行が可能。

また、Javaアプレットのプログラムに変換するHSPLetというコンバータも付属する。


Processing

動作環境:

開発言語:

大御所。別名「Proce55ing」。
スケッチ感覚で手軽に書ける専用IDEが特徴。
Processing言語なるその実態は、あれこれ手を加えたJavaのライブラリ群。Javaって事はつまりOpenGLって訳だ。

JavaScript向けのバインドも存在する。


openFrameworks

動作環境:

開発言語:

OpenGL等の名だたる著名ライブラリ達のラッパー。
あくまで各ライブラリをグルー(接続)したり使いやすくする為のもの。
用途としてはアートや教育等、Processingに近いものがあるが、専用IDEがない分こちらの方が上級者向け。

マルチプラットフォームは一応できるけどかなり面倒。openFrameworks自体を自分でリビルドしないといけないらしく、ビルドターゲットを弄ったりあれこれ試してみたが、エラーの嵐でビルドできなかった。


Cinder

動作環境:

開発言語:

openFrameworksと同じ方向性のライブラリ。
でもCinderはどちらかというと芸術目的で使用される事が多いらしい。あとiOS対応。

ただ、日本語の情報が圧倒的に少ない。


Siv3D

動作環境:

開発言語:

なんでもアリのゲーム/アート向け多機能ライブラリ。
DXライブラリやopenFrameworks等の比較的ローレベルなラッパーとは異なり、少ないコードで色々作れるようにするというのがコンセプトらしい。
このライブラリ自体も比較的モダンな実装となっている(私見)。
日本語の情報も比較的豊富。


OpenFL

動作環境:

開発言語:

ほぼFlashActionScript風の言語仕様を持つHaxeを使う上、APIFlashソックリ仕様。
でも、HTML5だのAIRだのを使った似非マルチプラットフォームではなく、きちんとネイティブコードで吐き出してくれるところがミソ。
んでもって、やっぱりAIR(要はFlash)でも書き出せる。しかもその状態で各OSネイティブのGUI使える。何でもアリかよ。

多分、WindowsではDirectX(場合に応じてOpenGL?)を、macOSLinuxではOpenGLを用いている。また、内部的にSDLを使用しているらしい。
iOSではObjective-Cに、AndroidではJavaに変換しているとの事。

これにHaxeUIというライブラリ(Adobe Flexに心なしか似ている)のOpenFL対応版を組み合わせると、ネイティブのGUIだって作れちゃう。
2Dゲームに特化したHaxeFlixelもある。あのそこそこ有名な3DエンジンのAway3DもOpenFL版アリ。

ただ、日本語の情報が致命的に少ない。多分Cinderより少ない。
あと、基本的に日本語入力ができない。HaxeUI使えば、FlashAIRあたりでできる。当然HTMLも。他は知らん。