moblのサンプルページに

• Your First Application
• Todo List
• Higher-Level Controls
• Styling User Interfaces
• Calling Web Services: Twitter Trends
• Styling User Interfaces

などのチュートリアルがある。
Todo Listは悪あがきプログラマーさんで解説されている。

3つのファイルに記述するだけでリスト表示、新規登録、更新、削除、検索機能を持ったWebアプリを作成することができる。
これはすごい。

// todo.mobl
// todoというアプリケーションを宣言しているのだろう
application todo

// なにやら必要なモジュールをインポート？
import mobl::ui::generic
import model

// ルート画面
screen root() {
  // ヘッダー
  header("Tasks") {
    // ボタンを追加すればデフォで右端に表示される。イベントはあとで追加するscreenを関数のように呼び出す
    button("Add", onclick={ addTask(); })
  }
 // グループってのは複数のアイテムがある要素なのだろうか
  group {
    // あとで定義するTaskに対する取得条件を記述してグリグリとリスト表示する。すげぇ
    list( t in Task.all() order by date desc) {
      item { taskItem(t) }
    }
  }
 // リストの下に検索ボタン。 イベントはあとで定義するscreen searchを呼び出し
  button("Search", onclick={ search(); })
}

// リストでグリグリされる各要素の定義
control taskItem(t : Task) {
  // チェックボックス Taskのdoneフィールドを直接true/falseを切り替えている
  checkBox(t.done, label=t.name)
// コンテクストメニュー  リストの右端のボタン。押すとなかのボタンが表示される
contextMenu {
   // 削除ボタン  イベントで remove関数でデータを直接削除している
    button("Delete", onclick={
      remove(t);
    })
   // 編集ボタン  イベントで あとで定義するscreen editTaskを呼び出し
    button("Edit", onclick={
      editTask(t);
    })
  }
}
// 新規追加画面
screen addTask() {
  var newTask = Task()

  header("Add") {
    backButton()
    button("Add", onclick={
      newTask.date = now();
      add(newTask);
      screen return;
    })
  }
  group {
    item { textField(newTask.name, placeholder="Task name") }
  }
}
// 編集画面
screen editTask(t : Task) {
  header("Edit") {
    button("Done", onclick={ screen return; })
  }
  group {
    item { textField(t.name, placeholder="Task name") }
    item { textField(t.description, placeholder="Task description") }
  }
}
// 検索画面
screen search() {
  var phrase = ""

  header("Search") { backButton() }
  searchBox(phrase, placeholder="Search term")
  group {
    list(t in Task.searchPrefix(phrase)) {
      item { taskItem(t) }
    }
  }
}

// モデル定義   スキーマを定義するだけでローカルストレージにテーブルを作成してくれる
module model

entity Task {
  name        : String (searchable)
  description : String (searchable)
  done        : Bool
  date        : DateTime
}

// 設定ファイル  デバッグを有効にしている。ブラウザのコンソールにログを表示してくれる。運用するときはdebugは解除だ
configuration

debug
title "Todo"

mobl言語ってのはJSONに似たような構造なのだがルールがイマイチよく分からない。
セミコロンの有無など。
関数の呼出には必要なのだろうか。
でもそんなに難しくもないしeclipseで少しはコード補完してくれるので、2、3サンプルをやれば大体わかるはず。

あとはリモートサーバと連携する方法とデザイン変更や画像の扱いがわかればなんとか使えるかな。
ボチボチ、サンプルを見てみよう。

私はWeb系の仕事をしているのが、基本作業はデザイナーとプログラマーで分かている。
デザイナーをHTMLにコーディングし、そこへJavascriptなり、PHPなりJavaなりでロジックを入れてゆく。

しかしユーザーインターフェースの設計が適当すぎるデザインもしばしばある。デザイナーとプログラマでどちらが責任を持つべきか曖昧なところ。

そこで思ったのだが、かっこよいイラストを描けるだけでデザイナーと呼ばれるべきなのか。
かっこよいイラストを作れる人はイラストレーターであってデザイナーではないのではないか。

たとえば市販車の場合、保安基準も満たせない公道も走れないような車を”デザイン”して評価されるか。
たとえば建築物のデザインをして、地震への強度や使い勝手もままならない設計をして評価されるか。
たとえば飲食店を”デザイン”して、消防法や衛生面の問題で営業できないような店を作って評価されるか。

されるわけないな。

もっとまともに設計せんかい！と思うことは多いのだが、カッコよいイラストを描いてくれる自称デザイナー様の意を汲み取って、ユーザーインターフェースを作るのはやはり実際にモノを作るエンジニア側の仕事であるなーと最近になって痛感するのであった。

デザインもプログラムも出来る人はスゴイ。うらやましい。私もそうなりたい。
いつまでも「俺知らね」ではすまない！精進せねばならぬ。

でもね、でもね、どんなコントロールがあるか知っておこうね！
せめて、せめて、どんな解像度のディスプレイに表示されるか考えようね！
お絵描きじゃないからね！！

AndroidMarketのデベロッパーコンソールの件数をGoogleDocumentにスプレッドシートに記録してるのだが、
3月31日からダウンロード数が増えているので、すごく影響があるみたい。

私のアプリは２つともアンドロイダーさんに掲載してもらってるけど、Xperiaで動作確認が取れたアプリはXperiaマークがついていた。すごい・・。
んでAndroboiceは動作するらしい。よかったよかった。
しかしToyCamではうまく動作しないらしい。

調べたところXperiaではカメラのプレビューサイズで480×320を設定できないようだ。[320x240][640x480]は設定できるっぽい。
ToyCamはカメラのプレビュー映像のひとコマを保存するだけのアプリである。
最近つけたトイカメラ風のエフェクトはおまけである。あとで加工できるし・・。なんとかしなきゃ。

SDKで動的にカメラのプレビューサイズに設定可能な値一覧を取得できないか調べると、
Camera.Parameters.getSupportedPreviewSizes()って素敵なAPIがあるじゃないか！
でもこれ、API　Level5からなんだな。XperiaはAndroidOS1.6=API　Level4だからこのメソッドは使えない。

なにか良い方法はないものか、と考えた。
んでカメラプレビュー用のSurfaceViewのSurfaceHolder.CallbackのsurfaceChanged()で

// Camera  mCamera
Camera.Parameters cp = mCamera.getParameters();
mCamera.setParameters(cp);
String[] sizes = {
		"176x144",
		"240x160",
		"320x240",
		"480x320",
		"640x480",
		"800x480",
		"854x480",
};
for (String size : sizes) {
	String[] s = size.split("x", 2);
	cp = mCamera.getParameters();
	cp.setPreviewSize(Integer.parseInt(s[0]), Integer.parseInt(s[1]));
	mCamera.setParameters(cp);
	cp = mCamera.getParameters();
	Camera.Size sz = cp.getPreviewSize();
	Log.v("", size + " is " + size.equals(sz.width + "x" + sz.height));  // OKならtrue ダメならfalse
}

こんなふうにしたらプレビューに設定してもよい値が取得できそうだ。
サイズのリストはここにあった。これはG1用のソースかな。。たいていQualcomm製のチップだからいけるかな。

OS2.0以降と以前で処理を切り分けて値を取得する何かを仕込む作業をしないといけない・・。
OS2.0以降でもアプリ開発のターゲットがOS1.5からだったとしたら、どっちみち
Camera.Parameters.getSupportedPreviewSizes()
を使って設定可能の値リストを取得することができない。
だからリフレクションしてメソッドを掘り出さなければいけない。
そこのところの詳しいやり方は「羅針盤」や「PICTRHYTHM」などで有名なテックファームさんのブログ記事
「NexusOneでAPIDemos/CameraPreviewが落ちる件」で取り上げられていた。この記事をありがたく参考にしてToyCamをアップデートしたい。トホホ。

サブタイトルは「開発で困ったときの解決アプローチ」である。

原著があり、タイトルは「Unlocking Android A Developer’s Guide」というらしい。
サンプルコードも原著のサイトからダウンロードするようになっている。

内容は入門用というわけではなく、アプリを開発した経験がないと難しいかな。
ページは索引も含めて464ページ。イラストは少なく、コードと解説がギッシリである。

Androidの概要・eclipseを使った開発環境・ユーザーインターフェース・IntentとService・データの永続化関連・ネットワーク関連・電話機能関連・通知関連・マルチメディア（内OpenGLESに10ページ）・GPSをしっかりと解説していて、そのあとサンプルアプリケーションの作成やネイティブアプリケーションのビルド方法（NDKが出る前のやり方）となっている。

そして、監修者付録として AppWidgetの作り方・AsyncTaskの解説・AndroidNDKの解説がある。

さらっと読んだだけだが濃いぃー内容だった。何度も読み返すことになりそうだ。

これまでAndroidの開発入門書を2冊読んだけど、まだまだ知らないことが沢山あるのだなと思った。
入門書と日本語のWebの情報でもなんとかアプリは作れてしまうがアプリ開発者なら読んでおいて損はない。

音声データを再生するときに早送りにしたり、ゆっくり再生すると声が高くなったり低くなったりする。
再生するスピードを変えずに声の高さだけを変えることをピッチシフトと言うらしい。

やり方はいろいろあるようで、音声データを短い時間に区切って間引いたり、かさ増ししたりして音データをつなげなおすと音程が変わる方法や、フーリエ変換で音の周波数を求め、周波数を変更して逆フーリエ変換で戻してやる方法があるようだ。

Androboiceではとりあえず間引いたりかさ増しする方法で実現している。

音を1オクターブ高くするには周波数を2倍にすればよいらしい。だから短い時間に区切って音データを半分に間引いて、間引いたデータを区切ったデータの後ろにくっつけて長さを同じにする。それを全てのデータ分実行すると再生速度そのままで1オクターブ高い音が作れる。

0,1,2,3,4,5,6,7,8,9
を
0,2,4,6,8,0,2,4,6,8
にする

これで2倍の高さの音になる。

この「0,1,2,3,4,5,6,7,8,9」って音の幅はどれくらいかというと8000Hzで約33msec分で240サンプル分を間引き処理してつなげている。

0,1,2,3,4,5,6 .....237,238,239,    240,241,242,243, ... 7998,7999
これを
0,2,4,6, ... 236,238,0,2,4,6, ... 236,238,      240,242,244, ... 7996,7998
こんな具合で1秒間の処理おわり

238と240のつなぎ目は滑らかにならないので雑音のようになるのだが、なめらかにする処理は省略した。分からないので。

なぜ30msecで区切ることにしたのかというと、自分の声を録音して波形編集ソフトで変換してみて、大体30msecくらいならうまくいくかなーと思ったから。人の声は大体300Hzくらいなので1秒間に300回なんらかの波が繰り返されていることになる。んで30msecなら6回から10回くらい繰り返しているので、「これなら加工しやすいだろう」となんとなく感覚で決めた。

まあ、waveデータを加工して音作りをしている人にとっては大したことないのかもしれないが、良い勉強になった。

フーリエ変換バージョンもあるのだが、1秒の音を変換するのに9秒くらいかかってしまう。これではFFTとは言えないくらい遅い。
floatの配列を使って演算しているのだが、これがボトルネックなのだろう。FixPointで計算するかJNIを使うしかないかもしれない。
また勉強することが増えた。

前回の続き。

で、AndroidでPCMデータの再生

AudioTrackクラスで前回rec.rawとして保存した生PCMデータを再生できる。以下コード

// 各種例外処理は略
// サンプルレート 8kHz
int SAMPLE_RATE = 8000;
// オーディオトラック取得
audioTrack = new AudioTrack(AudioManager.STREAM_MUSIC,
		SAMPLE_RATE,
		AudioFormat.CHANNEL_CONFIGURATION_MONO,
		AudioFormat.ENCODING_PCM_16BIT,
		AudioTrack.getMinBufferSize(SAMPLE_RATE,
									AudioFormat.CHANNEL_CONFIGURATION_MONO,
									AudioFormat.ENCODING_PCM_16BIT) ,
		AudioTrack.MODE_STREAM);

// 録音したファイル取得
File recFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/rec.raw");
InputStream is = new FileInputStream(recFile);
// バイトデータの配列
long length = mOutFile.length();
byte[] byteData = new byte[(int)length];
// ファイルのデータを全て読み込み
int offset = 0, numRead = 0;
while (offset < byteData.length
		&& (numRead = is.read(byteData, offset, byteData.length - offset)) >= 0) {
	offset += numRead;
}
is.close();

// 出力
audioTrack.play();
audioTrack.write(byteData, 0, byteData.length);

コードはここを参考にした。
これでスピーカーから音が出る。
が、しかしDroidとかMilestoneとかG1とかで動かないらしい。
AudioTrackが取得できない条件があるみたい。サンプルレートが問題なのだろうか。
手元にないのでわからんが。。。2.0のエミュレータでは動くのだが・・・まいった;(

AudioTrackとAudioRecordクラスは指定したフレームごとにコールされるリスナを登録できるらしい。
それを使えば録音・再生のシークバーとかを実装できるのかな。うまくいかないのだが・・。

なんにせよ情報が少なすぎる・・。Audioまわりを詳しくまとめた書籍があったら買うのだが。

前回の続き。

で、Androidでどうやって録音するか。

AudioRecordクラスでは前回の音データが取得できる。以下コード。

// サンプルレート 8kHz
int SAMPLE_RATE = 8000;
// フラグ
isRecoding = true;
// プロセスの優先度を上げる
android.os.Process.setThreadPriority(
          android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
// バッファサイズを求める サンプルレート8kHz  モノラル 16ビット/サンプル
int audioBuf = AudioRecord.getMinBufferSize(SAMPLE_RATE,
                     AudioFormat.CHANNEL_CONFIGURATION_MONO,
                     AudioFormat.ENCODING_PCM_16BIT) * 2;
// レコーダの取得  サンプルレート8kHz  モノラル 16ビット/サンプル
AudioRecord audioRecord =  new AudioRecord(MediaRecorder.AudioSource.MIC,
                           SAMPLE_RATE,
                           AudioFormat.CHANNEL_CONFIGURATION_MONO,
                           AudioFormat.ENCODING_PCM_16BIT,
                           audioBuf);
// バッファ
byte[] buffer = new byte[audioBuf];
// 録音用ファイル取得  SDカード状態チェック略
File recFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/rec.raw");
recFile.createNewFile();
// ファイル書き込み  例外処理略
FileOutputStream out =  new FileOutputStream(recFile);
// 録音開始
audioRecord.startRecording();
// フラグが落ちるまでループ  例外処理略
while(isRecoding) {
	// バッファを読み込んで書き込む
	audioRecord.read(buffer, 0, audioBuf);
}
// 終了処理 例外処理略
audioRecord.stop();
out.close();
out = null;

実際はスレッドなんかで実行してフラグで録音ループを抜ける。これでSDカードにrec.rawってファイルができる。
ファイルの中身はサンプルレート8000Hz、1サンプルあたり16ビット、モノラルのバイトデータ。ヘッダ情報のないWindowsのwavファイルのデータチャンクのところ。これにRIFFとかfmtチャンクを加えればwavファイルの出来上がり。
逆に言うと、サンプルレート8000Hz、1サンプルあたり16ビット、モノラルのwavファイルの先頭からヘッダ情報の40バイトをちぎったのと同じデータなのだ。

んで、1サンプル16ビット＝2バイトずつデータが並んでいて、16ビットなので65536段階の強弱の信号が記録されている。
16ビットでサンプルした場合は、符号付き(-32768 ～ +32767)であらわすらしい。 無音は 0。
8ビットでサンプルした場合は、符号なし（0~ +255）無音は128であらわす。

8ビットの場合はそのままJavaのbyte型の変数の配列に1サンプルずつデータが入っているが、
16ビットでサンプルした場合はエンディアンに気をつけないといけない。
取得できるデータはwavファイルと同じリトルエンディアンであるらしく、前8ビットには下の桁、後ろ8ビットには上の桁（2進数的に）
が収まっている。

byte[] buff = new buff[2];
リトルエンディアン 16bitの1
前8ビット    後ろ8ビット
00000001  00000000        // 2進数
0x0100                    // 16進数
buff[0]  == 0x01
buff[1]  == 0x00

リトルエンディアン 16bitの32767
11111111  01111111       //  2進数
0xFF7F                    // 16進数
buff[0]  == 0xFF
buff[1]  == 0xF7

リトルエンディアン 16bitの-32768
00000000 10000000        //  2進数
0x0080                     // 16進数
buff[0]  == 0x00
buff[1]  == 0x80

このようにバイナリエディタなんかでダンプしただけではパッと見て分かりにくいデータなのだ。
これが分かるまで苦労した。バイナリデータは触ったことなかったし。
Windowsの電卓ソフトの関数電卓モードを活用させてもらった。

んで、上のサンプルで保存したrec.rawファイルにヘッダをつけてwavファイルにする。以下コード

// WAVヘッダをつけて保存
// 各種例外処理略 チェック処理略
public void addWavHeader() {
	// 録音したファイル
	File recFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/rec.raw");
	// WAVファイル
	File wavFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/rec.wav");
	// ストリーム
    FileInputStream in = new FileInputStream(recFile);
	FileOutputStream out = new FileOutputStream(wavFile);

	// ヘッダ作成  サンプルレート8kHz
	byte[] header = createHeader(8000, (int)recFile.length());
	// ヘッダの書き出し
	out.write(header);

	// 録音したファイルのバイトデータ読み込み
	int n = 0,offset = 0;
	byte[] buffer = new byte[(int)recFile.length()];
	while (offset < buffer.length
			&& (n = in.read(buffer, offset, buffer.length - offset)) >= 0) {
		offset += n;
	}
	// バイトデータ書き込み
	out.write(buffer);

	// 終了
	in.close();
	out.close();
}

// Wavファイルのヘッダを作成する（PCM16ビット モノラル）
// sampleRate  サンプルレート
// datasize データサイズ
// これなんかもっとキレイに書けると思うが 。。 Ringroidのソースなんかキレイかも
public static byte[] createHeader(int sampleRate, int datasize) {
	byte[] byteRIFF = {'R', 'I', 'F', 'F'};
	byte[] byteFilesizeSub8 = intToBytes((datasize + 36));	// ファイルサイズ-8バイト数
	byte[] byteWAVE = {'W', 'A', 'V', 'E'};
	byte[] byteFMT_ = {'f', 'm', 't', ' '};
	byte[] byte16bit = intToBytes(16);					// fmtチャンクのバイト数
	byte[] byteSamplerate = intToBytes(sampleRate);		// サンプルレート
	byte[] byteBytesPerSec = intToBytes(sampleRate * 2);	// バイト/秒 = サンプルレート x 1チャンネル x 2バイト
	byte[] bytePcmMono = {0x01, 0x00, 0x01, 0x00};		// フォーマットID 1 =リニアPCM  ,  チャンネル 1 = モノラル
	byte[] byteBlockBit = {0x02, 0x00, 0x10, 0x00};		// ブロックサイズ2バイト サンプルあたりのビット数16ビット
	byte[] byteDATA = {'d', 'a', 't', 'a'};
	byte[] byteDatasize = intToBytes(datasize);			// データサイズ

	ByteArrayOutputStream out = new ByteArrayOutputStream();
	try {
		out.write(byteRIFF);
		out.write(byteFilesizeSub8);
		out.write(byteWAVE);
		out.write(byteFMT_);
		out.write(byte16bit);
		out.write(bytePcmMono);
		out.write(byteSamplerate);
		out.write(byteBytesPerSec);
		out.write(byteBlockBit);
		out.write(byteDATA);
		out.write(byteDatasize);

	} catch (IOException e) {
		return out.toByteArray();
	}

	return out.toByteArray();
}
// int型32ビットデータをリトルエンディアンのバイト配列にする
public static byte[] intToBytes(int value) {
	byte[] bt = new byte[4];
	bt[0] = (byte)(value & 0x000000ff);
	bt[1] = (byte)((value & 0x0000ff00) >> 8);
	bt[2] = (byte)((value & 0x00ff0000) >> 16);
	bt[3] = (byte)((value & 0xff000000) >> 24);
	return bt;
}

これでSDカードにrec.wavってファイルができるはず。あとは標準の音楽ソフトかパソコンで再生すればOK牧場。
WAVファイルを保存してゴニョゴニョできるソフトはそんなに多くないので、うまくやれば人気のアプリになりそう。
3gppとちがって加工しやすいし。3gpのフォーマット読んだだけで心が折れそうになったし・・。

PCでWAVファイルとかゴニョゴニョしてた人たちには大したことないかもしれないが、苦労した。
良い勉強になった。
はて、次はAudioTrackで再生の予定。

AndroidではAudioRecordとAudioTrackという方法でマイクの音を音データにしたり、音データをスピーカーに送ることができる。
その前にまず、そもそも音データってなに？ってところから始まる。他のOSとかで音データを触ったことがないから。

音ってのは空気の振動で、コンピュータで音データを扱うということは空気の振動を0と1に置き換えること、0と1の信号を使って空気を振動させることになる。 私の理解では。

大きな音がマイクに入ると、大きな電流がコンピュータに流れ、小さな音だと小さな電流がコンピュータに流れる。

コンピュータは流れてきた電流を一定時間ごとにデータを記録していく。大・小・大・小・中・大・小・・・・などと。

実際には20,000 ・-20,000 ・ 200 ・100 ・ -100 ・・・・みたいな感じで。

記録した音データに何らかの処理をして、マイクの逆パターンでスピーカーに大・小・大・小・中・大・小・・・・と電流を送れば音が出る。

サンプリングレート

一定時間ごとにマイクからの電流を計測して記録する（サンプリングする）けど、どれくらいの間隔で記録するかは『1秒間に何回記録するか「Hｚ　ヘルツ」』であらわす。

音楽CDだと1秒間に44,100回＝44100Hz。他にも22,050Hzとか16,000Hzとか11,025Hzとか8,000Hzとかがよく使われるみたい。実際の音波はもっと細かいけど連続毎秒44,100回記録しておけば、それ以上記録してても人間の耳には違いが分からないらしい。

ビット/サンプル  BitPerSample

マイクから流れてくる電流を記録するときどれくらいの細かさで記録するかは16ビットとか8ビットとかがよく使われるらしい。

それぞれ、65,535段階か256段階。16ビットとか8ビットはコンピュータでデータを扱いやすい。音楽CDは16ビットらしい。

だから、モノラルでサンプリングレート44100Hzで16Bit/Sampleで10秒間録音したら、データサイズは

1チャンネル x 44,100回 x 10秒 x 16Bit = 7,056,000Bit = 882キロバイトになると。

ステレオでサンプリングレート44100Hzで16Bit/Sampleで80分間録音したら、データサイズは

2チャンネル x 44,100回 x 4,800秒 x 16Bit = 6,773,760,000Bit =846,720キロバイト(約800MB)になると。

80分のCD-Rの容量と大体あったので、こんな考えで間違ってはいないだろう。

これらのデータを切ったりつなげたりすれば、マイクからの音にエフェクトをかけられると思った。つづく。

画像にエフェクトをかけるには括弧のなかに数字がたくさん並んでいる

こんな式とか出てくる。

ToyCamなんかはほとんどコピペみたいなものだから苦労はしなかったが、トイカメラ風のフィルタ処理を追加しようと気軽に考えていたのは間違いであった。改めて画像処理・音声処理・映像処理アプリはすごいと思ったのである。

オーディオにエフェクトをかけるのもフーリエ何とかで音データを解析したり加工したりするみたいだ。わけ分からん・・・。
RingroidのソースコードやSoundTouchとかいうライブラリのソースコードも見てみたが、そもそもファイルフォーマットから勉強しないといけないと知った。

iPhoneではカメラアプリやオーディオ系のアプリが充実していてとても楽しそうだ。それに、画像や音は世界中の人にとってわかりやすいと思う。Android普及にはそんなアプリが増えることも重要だと思う。
モテアプリっていうのかな？女の子に
「みてこれ！スゴイっしょ！」
って言えるアプリ。

DSPといえばメモリーとかと一緒に購入するWindowsを思い浮かべたり、マトリックスといえばキアヌリーブスのあの映画を思い浮かべたり、エンディアンのことをインディアンの仲間だと思っているようではいけない。
基本的なところから勉強していかなければ・・・・と思った今日この頃。