2015年10月19日月曜日

iOSアプリを単純にOSX移植したらリジェクトされた件

拙作のiOSアプリ(東方BGM on VGS)をMac OS X向けに移植して Mac AppStore へ審査を依頼してみたところ、リジェクトを喰らってしまったので、内容を精査しておきます。

リジェクト理由

  • 2.8 - Apps that are not very useful or do not provide any lasting entertainment value may be rejected
  • 3.4 - App names in iTunes Connect and as displayed on Mac OS X should be the same, so as not to cause confusion
  • 5.1 - Apps must comply with all terms and conditions explained in the Guidelines for using Apple Trademark and Copyrights and the Apple Trademark List
  • 6.4 - Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected

詳細


2.8

We found that your app is primarily songs and is therefore not appropriate for the Mac App Store. Songs and movies should be submitted to the iTunes store. For more information about distributing content in the iTunes store, please see iTunes Partner as a Content Provider. If you own or control the song or movie content for digital distribution, or are an authorized representative, complete the iTunes Connect Online Application.

要は、音楽を鳴らすアプリなら iTunes でやれってことですね。

3.4

The app name to be displayed on the App Store does not sufficiently match the name of the app displayed when installed on Mac OS X.(中略)

これは単純にXCodeのプロジェクト設定をミスっていて表示名とアプリケーション名が不一致だったという感じのもの。大した問題ではありません。


5.1

The app uses 'Mac' in the Installed App Name in a manner that is not consistent with Apple's trademark guidelines. Indicating Mac compatibility in the app name is not necessary for the Mac App Store.

これも 3.4 とほぼ同じ。

ミスっていて表示名に「Mac」の文字が出ていたからダメーという感じのもの。
3.4を直せば直るので、これも大した問題ではないです。

審査に出す時は、アプリ名、表示名、メニューの一番左あたりをよくチェックして正しい名前になっているか確認しましょう。1レビューあたり1週間ぐらいの待ち時間が発生するので、趣味ならともかくお仕事とかでこういうミスをすると痛い。(私は趣味でやっているから何も問題ありませんが)

6.4

The user interface is not of sufficient quality. Applications that provide a poor user experience are not considered appropriate for the App Store.
Your app appears to be a mostly unmodified port of your iOS app.
The Mac OS environment is significantly different from the iOS environment, and it is important that your app be a great app on Mac OS X. Multiple windows, windows that resize or go full screen, and control functionality for mouse and keyboard, are some of the many features customers expect in a Mac OS X app, and it's important that your app look and work well in a Mac OS X environment.
For app design information, see the Apple Human Interface Guidelines. The HIG provides in-depth guidance on the characteristics of a great Mac OS X app, and describes the appropriate technologies and interface elements Mac OS X provides to add to your app.
Also available is Programming with Objective-C, a guide to getting started with the Objective-C programming language.


長いですが要約すると iOSアプリの単純移植はダメー とのこと。
Apple Human Interface Guidelineをよく見て、Mac OS Xアプリらしいデザインにせよとかそんな感じの指摘。
言わんとすることは分かりますが、そういう指摘するなら Mac OS X で iOS アプリを動かせれるようにしてくれませんかね?と言いたい。
それならこの指摘は素直に頷けるのですが、それができない現状でこういう指摘をされると、若干モヤっとした感情が生まれなくもない。

2.8 の件は私のアプリ固有の問題ですが、この6.4の指摘に関しては、同じ轍を踏んだ人が結構多いんじゃないだろうか。

さて、どうするか

とりあえず、東方BGM on VGS の Mac OS X版 はお蔵入りにします。
主に 2.8 が致命傷。
実はこの規約、iOSアプリの審査基準にも同じ項目があるので、iOS版の東方BGM on VGSがそれを理由にリジェクトされても何ら不思議はないことだったりしますが。

仮にOSX版を諦めずにやるなら、汎用的なVGS MML playerみたいな感じにするとかになると思います・・・それなら有料で販売することもできちゃいますね。(Mac AppStoreじゃ大して売れないでしょうけど)

なお、東方BGM on VGS は OS X移植を諦めますが、とりあえず何本かリリースした実績を作っておきたいので、今度はInvader Block 2で審査に出そうと思います。

まだ審査には出してないけど、既に作ってあります。
Invader Block 2の Mac OS X版
(画面は開発中のものです)
(ちなみに操作はキーボード専用)

2015年10月14日水曜日

東方BGM on VGS for Mac OS X(リリース予告+α)

そこそこ人気がある拙作のスマートフォン用アプリ「東方BGM on VGS」が、近日 Mac AppStore でリリースされます。(昨日審査に出しました)

という訳で、プレスリリース的な記事でも書いておこうかなと。
リリースされたら私のTwitterアカウント(@suzukiplan)の方で連絡します。

iTunes Connect の管理画面
(OSX版とiOS版がちょうど並んでいたので撮影)
Mac OS X(以下、OSX)版は、iPhone版よりもアイコンが若干小さくなります。

これは、iTunes Connectで私が管理する際のトラブル防止が目的なのですが、iPhoneアプリと違って、OSXアプリはこれぐらいのサイズの余白を取らないと不恰好になってしまうというユーザ目線上の理由もあったり、なかったり。

画面は4inch版のものがベースになっています。
4inch版との違いは、画面上部の時計バーと画面下部の「SUZUKI PLAN - Video Game System」というロゴパネルが無いことぐらいです。(あとは、キーボードのカーソルキーでリストを操作できたりします。キーボード操作については今後拡充予定)

プレスリリース的なものはこんな感じかな。
あとはいつものように駄文を書き綴っておきます。

・・・以下、駄文・・・

iOSアプリをOSXへポーティングする事例って結構少ないっぽい。
そんなに難しく無いのに不思議ですね。

OSX対応よりも遥かに簡単にできるiPad対応(ユニバーサル対応)をやっていない私がそういうことを言うのもなんですが^^;
iPadの存在意義ってイマイチ分からないんですよね。一応iPad miniのRetinaモデルを持っているのですが、電子書籍(漫画)専用機としては優秀だと思うのですが、それ以上でもそれ以下でもない。だから、私は意図的にユニバーサル対応を避けています。(プロモーション的な意味では対応した方が良いけど)

iOSもOSXも同じ Cocoa という仕組みの上に乗っかっています。

タッチデバイス(iOS)とキーボード+マウス(OSX)という入力デバイス上の違いから、OSX用のアプリをiOSへ移植するのは結構大変です。しかし、その逆であれば割と容易にできます。

逆方向の移植(iOSからOSXへの移植)が容易な理由は、OSXには Magic Trackpad が標準で付いているためです。

Windowsのノートパソコンしか触ったことが無い人にとって「トラックパッド」に良い印象を持っている人は少数派かと思います。実際、私もノートPCを買うといつも最初にすることは「とりあえずトラックパッドをOFF」でしたし。アレって使い難いし邪魔なんですよね。マウス最高!

・・・などと思っている時期が私にもありました・・・

Mac(MacBookシリーズ)標準のトラックパッド(Magic Trackpad)は、Windowsのトラックパッドとは次元が違うレベルで使い易いです。具体的にはタッチデバイス(iOS)と同等以上の直感的な操作ができます。そのため、iOSからOSXへの移植はMagic Trackpadの利用を前提にすれば容易だということになります。

まぁ、iOSのUIKitがOSXでは使え無い(代わりにAppKitを使う)といった細かい技術的な事情も幾らかありますが、その辺は技術力がある人なら何とでもなることなので、然して大きな障壁ではありません。(OSX関連技術をググろうとするとiOS関連技術が出てくるのは少々厄介でしたが。「ちがう...お前じゃない」という場面が幾度となくありました)

PCの出荷台数は年々下降傾向なので、そんな中PC OS(OSX)をサポートをするのは、一見するとナンセンスなことかもしれません。でも、やっぱりスマホはスマホでしかないし、タブレットではPCの代わりにはなれないと思う(何故ならiOSやAndroidなどのスマホOSベースだとサンドボックス感が強すぎる)ので、結局のところPC OSは無くならないと思います。

役割は確実に減るでしょうけど。

ただ、私にとっては普及しているかどうかなんてあまり関係無くて、作りたいモノを作っていられれば幸せです。最近、スマホゲームを作る熱がすっかり冷め切ってしまい、新作を全然作っていませんが、OSXでゲームを作れる足場は固まったから、OSX向けゲームでも作ってみたい欲求が結構ありました。だから、実験を兼ねて東方VGSをポーティングしてみた感じです。

次は、Invader Block for Mac OS Xでも作ってみるかー。
新しいプラットフォームに対応したら、先ずはInvader Block 2を作ってみるのはSUZUKI PLANの伝統行事になりつつある。

ちなみに、Invader Block 2の現時点のバリエーションは、
・Invader Block初代(Windows + DirectDraw)
・Invader Block for ファミコン
・Invader Block 2(初代VGS)
 - Windows
 - Android
 - iOS
・Invader Block 3(VGS mk-II)
 - Windows
 - Android
 - iOS
・Invader Block for HTML5(JS初見の状態から2日で作ってみた版)
※ファミコン版とHTML5版は非公開

対応プラットフォーム別に見てみると、
・Windows
・Android
・iOS
・ファミコン
・ブラウザ
という感じか。
まだまだ少ないな。
増やさなきゃ。

2015年10月3日土曜日

東方BGM on VGSができるまで

東方VGSの収録曲数が100曲を超えてしまった。

いや、こんなに続くとは思ってなかったです。

記念に何かやろうと思ったけど、特に思いつかなかったので、どういう経緯で東方VGSが誕生したのか書いてみようと思います。

書き終わってみると、既視感みたいな感じのものをもの凄く感じたので、既に似たような記事を書いたことがあるのかもしれませんが、細かいことは気にせず...

時は2011年末、

Windowsでシェアウェアのゲームを出すも、1本も売れず、当時流行し始めたスマホでゲームを出せば売れるんじゃないかと考え、スマホでどうやってゲームを作るのかを調べてみることにしました。

iPhoneならObjective-c

ふむふむ。

Mac経験が無い私は、Objective-cなんて1ミリも知らなかった(Next Step開発時に作られたということなら知っていた)けど、Cの名を冠するものなら当然Cでも書けるだろうということで、悪くない。

まぁ、言語は別にどうでも良かったのですが、しかし、Mac必須というのがアレだったので、いつか対応しようと思いつつ、とりあえずAndroidで作ってみることにしました。

AndroidならJava

・・・クソだな。

まぁ、言語は別にどうでも良かったのですが、Javaでゲーム開発とかねーから!! ということで、ガワだけJavaで作り、メイン部分をC言語で作れるゲームエンジンを作ることにしました。
ガワ・ネイティブならぬ、中身・ネイティブです。
どうでも良いことですが、AndroidのJavaで作られたアプリのことを「ネイティブアプリ」って呼ぶのが未だに慣れない。「Javaで作ってるならネイティブじゃないじゃん!」と突っ込みたくなる。

その時書いた設計図が下記。
ゲームエンジンの設計図
(ガワ部分の設計は含んでいない)

VGE ; Video Game Engine です。

この落書きみたいな設計図で、現在のVGSの原型となるゲームエンジン(VGE)を作り、そこで動くゲーム第一弾として、以前DirectXで作ったEeePC専用ゲーム「Invader Block」の続編を開発。(あっさり完成)

ヒャッハー!
これで、スマホアプリがC言語で作れる!
まぁ、言語は別にどうでも良かったのですが(ry
初めてAndroidで動いた時の映像
(色がバグってるしアス比も狂ってる)
完成したInvader Block 2のリンクを貼っておきます。
宣伝は基本。
Android版(SUZUKI PLANのスマホ対応アプリ第一弾)
iPhone版(iPhone対応アプリ第一弾として1年後にリリース)

この時点のVGSには、音楽を再生する機能がありませんでした。

スマホって容量がちっさいし、回線もおっそい。
だから、AACとかOGGとかで音楽を鳴らすのはありえない。
いや、他のベンダーさんは皆そうやって音楽を鳴らしているんでしょうけど。

でも、他所は他所、ウチはウチ。

という訳で、小さな容量で音楽を鳴らす仕組みを作る必要があると考え、ソフトウェアシンセサイザー方式でチープな音源機能を実装して、そのプロトタイプを開発してみました。
独自音源のプロトタイプ
(ウインドウタイトルを気にしてはならない)
音を鳴らす仕組みはこれで完成。
  • サンプリング周波数: 22050Hz
  • ビットレート: 16bit
  • モノラル
  • 波形メモリ音源方式
  • 波形は三角波、ノコギリ波、矩形波(「たんけいは」ではなく「くけいは」ですが、プロト開発時は「たんけいは」と呼んでいたらしい。恥ずかしいw)の3つ
波形については、最終的にノイズを加えて4つになりましたが、その他の仕様はプロト開発時のものが現在でも使われています。

あとは、これに対応した逐次的に音を鳴らすための仕組み(サウンドドライバ)を実装すれば、音源システムが完成します。

サウンドドライバの開発知識は無かったので、MXDRVのソースを眺めて仕組みを読み取り、 サラの状態から綺麗に再設計するリバースエンジニアリング→リエンジニアリングという手法で設計。

最後に、このサウンドドライバに喰わせる音楽データを作るツールが必要です。

音楽データには、独自規格のMMLを採用。

最初はMIDIとか色々考えたけど、汎用規格ってなんかカッコ悪い。

全部独自設計するなら当然規格も自分で作るよね?

などと、意味のわからないことを考えながらMMLの仕様を、ジックリ小一時間ぐらい掛けて書いて、1週間ぐらい掛けてコンパイラを開発。
初期の頃に書いたMMLの仕様書
(サンプルMMLのヘッダにコメントで記述)
※完成後の仕様とは大分異なる

この、頭の天辺から爪先まで全て独自仕様で固められた謎の音源システムの名称を、私は Video Game Sound system(略してVGS)と呼ぶことにしました。そして、VGSはVGEと合体して「Video Game System」という名称になりました。

なお、AtariのVCS(Video Console System)をオマージュした名前のように聞こえるかもしれませんが、それは単なる偶然です。ゲームエンジンとして目標にしていたのは、どちらかといえばVCSではなくPCエンジンです。私はPCエンジンで育った人間です。PCエンジンの凄いところはデザインです。デザインとは見た目のことではなく、コア思想という設計思想のことで(中略)

そんな訳で、本当は VGエンジン という名称にしたかったのですが、VGエンジンという名称の製品(※車のエンジン)が既に世に存在していたからVGSにした感じです。(カテゴリが違うから商標上の問題は無かったと思うけど、念のため)

若干話しが逸れましたが、完成したMMLコンパイラのテストを兼ねて、数曲作曲。そして、それらを鳴らすサンプルアプリを作成しました。
音楽再生用のサンプルアプリ

おわかりいただけただろうか

これが東方VGSの原型です。
実はこれ、VGS Chiptune Music という名称で、Android Marketで公開していました。

まぁ、評価はアレです。

「音楽はクソだな!星5だ!」(フランス語で)

などと、罵られました。

これは、「お前の作曲の 腕が残念だけど、仕組みは面白い」的な意味だったのだろうか?フランス語はあんまりよく分かんないです...

なぜか、インドネシアで好評でした。
なお、日本では殆どダウンロードされていません。
ちなみに、非公開にしてあるので、もう手に入らない幻のアプリです。
(私の端末には普通に入っているけど)

その後、この音源機能が追加された新生VGSを使って NOKOGI Rider を開発。
NOKOGI Rider(開発中の映像)
そして、VGSをiOSへ移植して、iOS版のInvader BlockとNOKOGI Riderをリリース。

結果的にInvader BlockもNOKOGI Riderもそんなに沢山売れなかったものの、VGSの音源システムについては面白いという自信があったので、VGSを使って音楽を配信するアプリを作ってみることにしました。

そうです。

それが、WTC1 on VGSです。
VGSで作った音楽配信アプリ
(現在も公開中)

ついでに、音楽が好きだった東方Projectの楽曲も二次創作という 体でお借りして、東方BGM on VGSも作ってみた感じです。

最初は紅魔郷の全曲が揃ったら辞めるつもりでした。

何故なら、物凄く大変なので。

物凄く大変ではありますが、とりあえず、「1週間で1曲づつ追加していく」というマゾマゾしいルールを設け、本業の仕事もしながら、まるで連載作家のようなマゾマゾしい生活を実践することにしました。

そして、いよいよ紅魔郷が全曲揃って東方VGSを辞めれる!となった時は、本当に嬉しかったです。これでようやく人間らしい生活に戻れると。しかし、辞めてみて湧いてきたのは、達成感とか充実感ではなく、この マゾ・ライフが終わることの空虚感 でした。

私はアンチ嫌儲な人間です。タダ働きなんてまっぴら御免です。そういう性格の人間なので、収益化をした上で成功していれば、達成感や充実感があったかもしれませんが、東方VGSについては、収益化を一切せずに続けていたので、それらの満足感を得られることが無いことはある程度想定済みでした。

では、この空虚感は一体何なのか。

じゃぁ、妖々夢と永夜抄も全曲揃えて確かめよう

そんな悪魔の囁きに唆され、続ける事を辞める事に失敗。

どういう訳かアプリもすごく人気があったことも、辞め時を逃した大きな要因のひとつです。未だによく分からないのですが、VGSの音源はゲームのオマケとして作った「鳴れば良い」というレベルのチープなモノなのに、そのシンプルな音色は多くの人を惹きつけました。

一体どいうことなのか。

私に音楽の才能があるとは思えません。
音楽ではなく、効果音に対する拘りは結構あるのですが、それは恐らく普通の人の感覚と大分違います。同僚などに、私のゲーム効果音に対する見解を熱弁すると、大抵の人は「何言ってんだコイツ?」みたいな顔をします。私の見解は、まず「ゲームとは効果音である」という所から解説が始まります(中略)

要するに、一般ウケできるようなモノではないだろうと思っています。

それはさておき、いよいよ妖々夢と永夜抄も全曲揃ってしまった時は、流石にもう人間らしい生活に戻ろうと決めて、最終バージョン(1.00)をリリース。

マゾ・ライフが終わることの空虚感」の正体は結局謎ですが。しかし、恐らくこれはクリエイターが本質的に求めているモノなのだろうと考えることにしました。何故なら、クリエイターさんは皆、苦しみながらソレを楽しんでいるように見えるので・・・釈然としない思いはあるものの、これ以上の追求は身を滅ぼすだろうという危機感が強かったので、後ろ髪を引かれつつも、一旦身を引くことに成功。

しかし、最終バージョンをリリースしてから半年ぐらい経った頃、iOS8で(OS側のバグが原因で)東方BGM on VGSが起動できなくなってしまう不具合が発生しました。そして、この不具合を対策するついでに曲も追加してアップデートしたことを契機に、再び曲追加を復活させて、現在に至ります。

不具合対策だけすれば良かったのに、敢えて曲追加をする茨の道を復活させた理由は、新しい方向性が見つからずに迷っていたためです。だから、今は 次の一手を模索する間の繋ぎ という位置付けで、東方VGSを続けています。

なお、スマホで新たなゲームを出すのは(今は)得策ではない と思っています。
だから、今は新作をつくっていません。

というのも、パズドラとかモンストとかの登場で、スマホゲーム市場が望ましくない方向に成熟してしまったので。別にパズドラやモンストが面白くないと言っている訳ではありません。カスタマにそれらが受け入れられているなら、それで良いじゃない?と他人事のように思っています。

それでは何故、パズドラやモンストみたいなのが出てくるとマズイのかというと、娯楽産業というのは結局のところ可処分時間の奪い会いで、パズドラとかモンストみたいな感じの運営モデルのゲームには終わりが無いから、結果的にカスタマー流動性に淀みが生じることが良いない事だと思っています。

運営モデルは当たればデカイので、運営モデルで新たなモノを出す価値ならあると思いますが、当然ながらリターンがデカイが故に、リスクも更に大きいです。少なくとも、企業レベルの体力が無いと入り込む余地がありません。一番厄介なのはプロモーションで、これはスマホ黎明期の頃のような小手先の手段ではもうどうにもなりません。

だから、そのような状況下で、私のような個人が新作を出すのは自殺行為同然だから、新作を作れないということになります。

SUZUKI PLANが当初広告モデルを頑なに拒んでいた理由は、広告モデルはそういった悪い方向への加速を促す側面があると感じていたためです。広告モデルでマネタイズする感じの会社は、最初の内はそこそこ儲かるかもしれないけど、次第に儲からなくなってすぐに倒産するだろうと思っていて、事実今はそんな感じになり、死屍累々としている頃合いだろうと思います。(仮に今、真剣に個人でゲームを作って公開するなら、Steamとかでやった方が良いハズ。Steamはスマホアプリ市場と違って、運営型ではなくパッケージ型のモデルが今の所主流なので、未来がありそうな気がします。スマホアプリ市場と同じ道を辿る可能性も五分じゃないかとも思っていますが)

プロモーションはマーケティング上そこそこ重要な位置付けのものなので、広告モデルそのものを否定するつもりはありませんが、少なくとも運営型のライバル企業にカスタマを流し、小銭を貰っていくスタイルのアプリ広告はダメなパターンです(パッケージを売るための広告ならアリだと思うけど)。その点は敢えて割り切り、稼げる時に稼ごうとする人がウジャウジャ出てくることも、ミスディレクションを進める大きな要因のひとつだったと思っています。

東方VGSは、そんな厳しい環境の中で割と上手く立ち回っていると思います。
東方VGSの戦略はシンプルにニッチ戦略です。

具体的には、
  1. 運営型モデルのゲームと共存できるプロダクトにする
  2. iTunes(やApple Music)には無いコンテンツだけを供給する
  3. リーダーが真似できない特異性を保っている
といったことを意識して、WTC1 on VGSを作りました。

東方BGM on VGSは、戦略とかそういったものは一切考えず趣味に走って作ったものですが、WTC1 on VGSのシステムをそのまま使っている関係で、自動的にその戦略も引き継がれている感じです。(引き継がれているというより、意図せずに進化している感じなのかも)

未来の話しについて

唐突ですが、ここで東方VGSの未来の話しについて。
とりあえず、続けていくのが物凄くツライです。
しかし、続けていきたいと思っています。
そこで、ツラくならないようにする為の策を考えます。
だからといって、ガイドライン的にダメなことは絶対にやりませんが。

2015年8月15日土曜日

ソフトシンセの作り方(7) - VGS-SAL

VGSのソフトシンセ(波形メモリ音源)の開発で得られた知見を元に、PCやスマートフォンで動くソフトシンセの作り方を解説していきます。一冊の本が書ける程度の分量なので、幾つかのパートに区切って解説していきます。このシリーズを一通り読めば、サウンドプログラミングについて全くの素人でも、PCやスマホなどのプラットフォームで動くオリジナルのソフトシンセが作れる程度になります(たぶん)

なお、このシリーズで扱うプログラミングの例題のビルドには、パソコンが必要です。OSは私が使っているMac OS X向けに解説を記述しますが、Linux(※ALSAに対応しているもの)やWindowsでも問題ありません。

今回は、VGS-SALについて解説します。

VGS-SAL

前回の記事で紹介した低レベルAPIのひとつひとつを解説すると、それだけで膨大な量の解説が必要になってしまいます。そこで、低レベルを直接叩くのではなく、VGSSALSound Abstraction Layout)を利用することにします。
VGS-SALは、WindowsDirectSound)、LinuxALSA)、MaciOSAndroidの低レベルAPIを抽象化したものです。これを用いることで、全OS共通実装で「波形直書き」の実装ができます。

sal-sample

vgs2リポジトリの sample/sal-sample ディレクトリにVGS-SALを用いたサンプルプログラムが格納されています。
このサンプルプログラムでは、VGS-SALを用いて440Hzのサイン波を鳴らし続けます。
サンプルプログラムは、ターミナルで以下のコマンドを実行すれば、ビルドできます。
$ cd ~/vgs2/sample/sal-sample/ && make
sample/sal-sample ディレクトリに格納されている makefile と saltest.c を見てみましょう

(1)makefile

  • saltest.cをビルドする手続きが書かれています

    (2)初期化: init_sound_cli

    • SALの初期化をします
    • cliとは Command Line Interface(コマンド) の略です
    • Windowsの場合、GUI用の初期化処理が別にありますが、その点についての解説は省略します
    • UNIXOSの場合、CLI用とGUI用の間に違いはありません

    (3)終了: term_sound

    • SALが用いているシステムリソースを解放します
    • かならずプログラムの最後で呼び出すようにしてください

    (4)バッファリング: sndbuf

    • 一定間隔毎にSALからコールバックされるバッファリング処理です
    • C++で実装する場合は、必ず extern "C" で宣言するようにしてください
    • 引数 buf : 波形情報を格納するバッファです
    • 引数 size : 波形情報を格納すべきサイズです
    • buf の内容を変更する処理は、必ず lock()  unlock() で囲まなければなりません
    • 上記サンプルでは、440Hzのサイン音 が鳴り続けることになります

    (5)バッファリング処理の内容

    sndbuf  lock()  unlock() で囲まれた範囲(バッファリング処理)の実装内容をもう少しブレイクダウンして見ていきましょう。
    1行目: for(i=0; i < size16; i++, ptr++) {
    2行目:    *ptr = (short)(sin(r) * 16384);
    3行目:    r += PI2 / (22050 / 440); /* 440Hz */
    4行目: }
    1行目
    • size16  引数buf (8bit array)  16bit array とした時の長さです
    • そして、i = 0  size16-1 の間、ptr をインクリメントしながらループすることになります
    • ptr  引数buf  16bit array にしたものです
    • ptr のインクリメントとは、__サンプリング周期のインクリメント(+1Hz)と等価ですね
    2行目
    • sin(r)  16384 にした数値を ptr に代入しています
    • sin関数 の戻り値は -1.0  1.0 の範囲の実数です
    • なので、ptr に代入している値は -16384  16384 の範囲の値です
    • つまり、この 16384 というマジックナンバーは 鳴らす音の大きさ を意味しています
    • 16bit -32768  32767 の範囲の数値なので、限界音量の 50% がこのプログラムで鳴らす音の最大音量となります
    3行目

    • r  2π ÷ ( 22050 ÷ 440 ) で加算しています
    • r  スタティック変数 なので、関数が return しても値が維持され続けます
    • そのため、sndbuf が呼び出され続けると 440Hz のサイン波 が発音され続けることになります

    追記
    umm...
    ここから先はコードベースの解説が多くなるのですが、bloggerだと結構辛いので、GitBook辺りを使ってイチから書き直すか。

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

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