ATMでお金をおろすたびに冷や汗が出る思いです

そこでぼちぼちヤフオクで出品しはじめました。

これで少しは延命できればいいのですが…

ヤフオクも結構手間を食いますね。

写真を撮ったり、文言を考えたり、価格設定に悩んだり。

今は発送作業に追われるのも困るので、

”落札されたらラッキー”くらいの少し強気の価格にしてみました。

このブログは匿名にしておきたいので、

今やっていることを具体的に書きにくいのですが、

最近はプログラムの構造よりも、アプリの仕様について悩む事が増えました

どう表示するか、どう操作してもらうか、

どうしたら説明書なしでも理解してもらえるか、

そういう事が決まらないとプログラミングも暗礁に乗り上げてしまいます。

iOS11の電卓の不具合は、

アニメーション効果がユーザーのアクションを阻害したために起きたのだそうです。

応急処置として、アニメーション効果が無効化されました。

”Appleで働く人でもこういうミスをするんだ”という事や、

”こういうミスが誰にも発見されないままリリースされるんだ”という事、

”気付いていたけど間に合わないから黙っていたのかもしれない”という事、

をふと考えます。そして、

完璧じゃなくていいのだ、

不具合があったらアップデートすればいいのだ、

という事に気付かせてくれます。

現在はCALayerに取り組んでいます。

以前UIViewの回転で手を焼いた部分も、

CoreAnimationを使えばシンプルに書くことができそうです。

今回ハマったのは、アニメーションのタイミングを操作する

CAMediaTimingプロトコルの、speed と beginTime、timeOffset の関係です。

普通、例えばタップイベントでspeedを2.0にしてやればそこから倍速に、

0.0にすれば止まってくれそうな気がしますが、実際はそうはいきません

事のはじまりは、アニメーションの一時停止と再開でした。

Appleのドキュメントに次のコード（のObjective-C版）が載っています。

func pauseLayer(_ layer: CALayer) {        let pauseTime = layer.convertTime(CACurrentMediaTime(), from: nil)        layer.speed = 0.0        layer.timeOffset = pauseTime}func resumeLayer(_ layer: CALayer) {        let pauseTime = layer.timeOffset        layer.speed = 1.0        layer.timeOffset = 0.0        layer.beginTime = 0.0        layer.beginTime = layer.convertTime(CACurrentMediaTime(),from: nil) - pauseTime}

これが読めなかったのです。何をやっているんだ？と

特に最後のbeginTimeはなぜ一度0.0を入れているのか、と。

ようやくわかったので、忘れないように図にしてみました。

渾身のタイムチャートです

まずspeed属性の概念から。

speedを指定するとそこから先だけでなく、そこまでの時間軸も全て変わります。

例えば0.0にすると、時間軸の最初から永遠に0なので、初期状態のままになります。

2.0にすると開始時間も半分に早まり、0.5にすると2倍先まで待たされます。

ParentTimeはとても大きい数字になりうるので、実際には動かないも同然です。

そこで、beginTimeやtimeOffsetを使ってこの時間軸をずらします。

beginTimeは親要素の時間軸に則って与えられる数値です。

つまりspeed属性の影響を受けません。

一方 timeOffsetは、speed属性を反映した時間軸を操作します。

正数の場合、beginTimeは先延ばし、timeOffsetはたぐり寄せる側にずれます。

convertTime(_:from:)は、それぞれの時間を渡し合う変換器です。

ここで、あらためて一時停止と再開の仕組みを見てみます。

(a)はspeedのみで操作した場合です。アニメーションは止まりますが、

時間軸はゼロ…つまり初期状態に戻ってしまい、一時停止と言えません。

(b)はtimeOffsetを使って24を初期状態にすることで一時停止らしくなりましたが、

再開しようとすると、終了点が過去になるので、たちまち完了してしまいます。

(c)は再開時にtimeOffsetを元に戻すことで再びアニメーションが動き出しますが、

一時停止していなかったかのように元の時間軸で完了してしまいます。

(d)は再開時にtimeOffsetを元に戻し、さらにbeginTimeを使って、

一時停止していたぶんだけ時間軸を遅らせます。これがサンプルコードの動きです。

 beginTime = 0.0 としていたのは、一時停止していたぶんを知るために、

一時停止しなかった場合の時間(p)を得るためです。

理解はできましたが、結構わかりにくい仕組みです

ムービー編集ソフトのような親切なインタフェースではありませんね

エラー回避のための安全策が大半を占めますが、

その次くらいに多いのがLivePhotoというキーワードです。

私の実機はiPhone6なので、LivePhotoが何なのかしばらくわかりませんでした。

6s以降の静止画撮影はLivePhotoモードがデフォルト設定なんですね

どちみち、うちには動作環境がなく、確認のしようもないので、

LivePhoto関連は削ってみようと思います。

そうすると静止画撮影に関しては、

AVCapturePhotoCaptureDelegateの実装ということになり、

書籍のサンプルプログラムと大差ない規模に近づきます。

残りは動画モードで、これがちょっと難解です

マルチスレッドを使っているのは、ユーザーの操作感の向上のためで、

状態の取得や設定の変更が完了するまでの間、

画面が止まったり真っ暗になったりしないようにする、

「待たされている」という印象をユーザーに与えないようにする、

という工夫だと思われます。

なのでこのテクニックも、無くてはならないわけではないようです。

（実際、プロセッサが非力なデジタルカメラでは結構モタつきますしね）

ただ、コードを眺めているとパターンが何となく見えてきます。

ビューやコントロール部品はメインスレッドからアクセスして、

入力にしろ出力にしろ、何かしらのデバイスを相手にする時は

別スレッドのシリアルキューに投げ込まれています。

カメラアプリは、カメラユニットから入力して、ストレージに出力しますから、

ほぼすべての処理が別スレッドになっています。

それでコードが複雑に見えるのでしょう

書籍に載っていたサンプルプログラムでも動くのですが、

理屈もわかっておきたいので、

Appleのサンプルプログラム「AVCam」の解読に取り組んでいます。

AVCamの方は、とにかくエラー処理（回避）に重点を置いていて、

そこでスレッド処理がふんだんに応用されています。

DispatchQueueはObjective-C時代にちょっとかじった記憶はあるのですが、

いまだ直感的に理解することができません

ちなみに、写真品質の画像をキャプチャすると（つまり写真を撮ると）、

設定しなくても勝手にシャッター音が鳴ります。

最初それを知らずに、自分もAudioToolboxでシャッター音を鳴らしていたので、

その挙動に悩んでしまいました。

今さらカメラアプリかよという感じですが、まぁ一番ポピュラーなので

それとサウンドツールと、ジョークアプリみたいなものの３つに絞りました。

今日はちょっと必要があって久しぶりにPerlでスクリプトを書いたのですが、

もう感覚が全然違っていて、

文尾のセミコロンや、if文の条件式の括弧などでエラーを連発しました。

Swiftの感覚まで狂うのが怖いので、今はPerlに触れたくないです

とりあえずこんなものをアップしてみます。

WAV生成関数に手を加えて、波形とエンベロープを選べるようにしました。

ステレオというのは、デチューン効果です。透明感のある音になります。

ノイズはホワイトノイズを合成します。

正弦波はもっともマイルドな音色なので、マイクで拾いづらいです。

シンセサイザーアプリを作るわけではありません。

波形編集ソフトを持っていないので、これで自前のサウンドファイルを作って、

操作音に使います。

こんなところに凝る必要はまったく無いのですが、

インタラクティブに作れたらいいなと思って。

こんなふうに寄り道してしまうのが私の悪い癖です。

私の人生を象徴しています…

試験勉強をするために部屋の片付けから始める、というやつです。

それにしても眠いです

最近ちょっと意気消沈しているように感じます。ストレスもたまっているかも。

８月は寝る間も惜しいほど面白かったのですが…。

ここ数日は、オーディオファイルを生成する関数を、

より汎用性のあるものに書き換えています。

すると、8bitオーディオでは表面化しなかった”エンディアン問題”が出てきました。

”問題”というか”面倒”ですけども。

最初はAppleにちなんでAIFFを選びましたが、

今のApple製品はすっかりインテル系なので、

２バイト以上の数値はいちいち並べかえなければなりません。

それをSwiftの仕組みの中でやるのがまたまわりくどいのいです

無駄な処理をするのは気持ちが悪いので、いっそこだわりは捨てて、

WAV（RIFF）で新たに関数を作っています。

そうすると、懸案となっていたFloat80型も必要ないのです。一石二鳥

ちなみにOSXの通知音は今でもAIFFです。伝統なんでしょうね。

週末は天気が悪いようなので、

また引きこもってモチベーションを高めたいです。

サウンドポートを直接叩く方法がわからないので、

（というか、おそらく許可されていないと思うので）

任意の周波数でAIFFファイルを生成する関数を作り、

システムサウンドに登録して再生させるようにしました。

懐かしいPSGのビープ音

ビットレートはとりあえずモノラル／8bit／48kHzに固定しています。

サンプリング周波数をケチるとデューティ比が一定しないので、

矩形波でも音が濁るんです。

苦労したのは、やはりSwiftのポインタ型の理解で、

C言語ライクにメモリを操作できるようになるまでがなかなか大変でした。

それからAIFFの規格には、サンプリングレートの指定に

「拡張倍精度浮動小数点」という80ビットのデータ型が出てくるのですが、

そのFloat80型がSimulatorでは動いたのに、実機ではエラーになるんです

どうやらiOSではサポートされていないらしく、

その部分の10バイトは決め打ちとなりました。

Swiftの仕様にも今回は特にストレスを感じました

・ベキ乗の書き方（x^8とか、x**8などと書けない）

・for文の逆回しの書き方（レンジを7...0などと書けない）

・文字の抜き出し方（抜き出すのが2文字以上になると途端にコードが増える）

伝統的な構文をたくさん変革したくせに、そのわりには気が利かないというか…。

前回使ったAudioServicesPlaySystemSoundや、

AudioServicesAddSystemSoundCompletionは将来、非推奨となるそうです。

代わりに AudioServicesPlaySystemSoundWithCompletionを使うように、

とあります。

早速書き換えてみると、なんと、いとも簡単…

　　　　AudioServicesPlaySystemSoundWithCompletion(1108, myCompletionBlock)　　}　　func myCompletionBlock() {　　　　print("in completion")　　}}

”こうならいいのに”という望みが叶えられていました。

あのドツボは何だったのか

サウンドの再生に成功しても失敗しても、処理を終えると呼んでくれるようです。

不要なら nilを指定できます。

どうも回り道が多いというか、道草が多いというか、

今週末でSwift歴１ヶ月になりますが、このペースではちょっとまずいです…。

システムサウンド自体は１行で鳴らせます。※マナーモードは解除

　AudioServicesPlaySystemSound(1108)　// シャッター音

鳴らし終えたときに呼ばれるコールバック関数を

AudioServicesAddSystemSoundCompletiondeで登録しようとして、

つまづきました

C言語のように、関数名がその関数へのポインタを表すのは Swiftも同じですが、

ここにはグローバル関数を指定しなければいけませんでした。

private func myCompletionCallback(ssID: SystemSoundID, clientData: UnsafeMutableRawPointer?) {    print("didPlay")}class ViewController: UIViewController {　　　　︙        AudioServicesAddSystemSoundCompletion(ssID, nil, nil, myCompletionCallback, nil)        AudioServicesPlaySystemSound(ssID)

AudioToolboxはC言語で実装された非同期の処理で、メンバー関数だと

鳴り終えた時のコールバック先が有効だという保証がない、という事ですかね。

Swiftの中だけならARCが効くので、メンバー関数を渡すこともできます。

これに気付くのに１日かかりました

「Swiftではポインタの書き方が違うのかも」と勘違いしてしまったからです。

ちなみにクロージャだとこうです。

　　　　AudioServicesAddSystemSoundCompletion(ssID, nil, nil, myCompletionCallback, nil)        AudioServicesPlaySystemSound(ssID)　　}　　let myCompletionCallback: @convention(c) (SystemSoundID, UnsafeMutableRawPointer?) -> Void  　= {(ssID, clientData) in　　　　print("didPlay")　　}

画像ファイルを用意しなくても、任意のサイズ・色・名前のスプライトを

表示できるようにしました。

実際には、任意のUIImageを生成する関数を作って、

そのUIImageでSKTextureを用意し、SKSpriteNodeを初期化しています。

SKShapeNodeでない証拠に、SKActionの scale(to:duration:)が効いています。

スプライトを動的に作ると、

プレイヤーが自機を細かくカスタマイズできるというメリットもありそうです。

（私はまだまだゲームは作りませんけどね）

ここではランダムに生成しているので、

偶然にFTPとかDIYとかJBLとか出てくるとフフッとなります（暗い…）

見ているとスプライトにもひかえめな奴とずうずうしい奴がいて面白いです

小さいけどしぶとい奴とか、大きいのにすぐ飛んでっちまう奴とか。

そしてどれもいつかは必ず消えてしまいます

NHKｷﾀ━━━━━━!!