2012年12月11日火曜日

【Android】bindView内でHandlerを使うとposition:0のbindViewが大量に呼び出される

bindView内のHandlerでUI処理を行うとpositionが0のViewをバインドさせるような処理が呼ばれてしまう.
positionが0というのはListViewなら一番上のリスト,GridViewなら一番左上のリストである.
この現象はbindViewのHandler内でUI処理を行わない場合は起きない.
…が,そもそもUI処理を行わないのにHandlerなんて使わない.

それがどのくらい大量に呼び出されるかというと,コードにも依るかもしれないが
読み込んだリストの倍の数だけposition:0のbindViewが呼び出される.
1列に3個Viewが並んだGridViewだとすると通常のViewがリストの分,3つ呼び出されて,
その後にposition:0のViewが6個呼び出される.

Handler内でUI処理を行なう場合でも
ImageView.setImageResource()やTextView.setText()だけを行った場合はこの現象が起きない.
View.setVisibility()はViewが変更されれば現象が起きるが変更されなければ起きない.

謎だ.

いろいろ調べてると何箇所かでViewの高さをwrap_contentにしてると重複して呼び出されるよって書いてあるけど
fill_parentでもなる.
dp指定でも起こるうえに設定したheightが見事に無視された.

bindView内でHandlerを使うということはそれなりに重い処理(画像処理,ネット接続等)を別スレッドで行なって
処理完了後にUIに反映させるんだろうが,
こうやってムダなbindViewが呼び出されるとその分スレッドが作られてリソースを圧迫することになる.
ユーザーがファストスクロールしまくると
メモリ圧迫⇒オーバーフロー死
することになる.

fastscrollをオフにしたら問題が起こるほどではないんだろうけど
グリッドにバインドするアイテムが万単位にもなるとfastscrollオフは完璧に地獄になる.

これを抑えることができればスレッド数も1/3に抑えられてメモリリークのリスクも圧倒的に減るのだが.
最低でも強制終了はよろしくないので


対応その1(対策ではない)
設置スレッド数の上限を決めてしまう方法

このようなかんじでスレッド開始前にスレッド数確認して乱立していたらスレッドを追加しない
という方法は採ることはできるが…
スクロールを止めた画面は描画されないことに成りかねない.
それに機種によって限界は違ってくるし,バックグラウンドの状況によってもどうなるかは分からない.
強制終了よりはマシというレベル.

既にキューに並んだスレッドを間引くことができればまだ何とかできそうだが
Thread.stop()などが非推奨になっているためそれもできず.
要らないスレッド殺してえ…

対応その2
UIとの整合性が保たれていないスレッド
つまりバインドすべきViewはとっくに通り過ぎた場合なんかは
スレッド内の重い処理に到達するまでにreturnしてやる.
そしてさっさとスレッドを消化してやる.

スレッドの乱立を防止するわけではなく,立ってしまったスレッドに対しての後手策なので
ほんとうに足掻き程度だけど.

根本原因のbindView乱立が起きなければ問題は緩和されるのに.
全然わからん.

こういうbindViewでスレッドを設置して処理させるという作り方をしたのがそもそも間違いなのだろう.
bindView内の処理を大幅に見直すことにする.
が,こういう現象があるよという知見程度に.

2012年12月5日水曜日

【Android】SimpleDateFormatのタイムゾーンに注意


日時を文字列で取得する際にハマったこと.

日時を文字列で取得する際に
SimpleDateFormatクラスを使うことが多いと思う.

SimpleDateFormatクラスではフォーマットを指定して,時刻情報を与えてやると
フォーマットに合わせて整形された時刻情報が文字列で取得できる.

そこでよく使われるRFC1123形式と呼ばれる
Wed, 21 Jan 2009 10:09:52 GMT+09:00
こういったフォーマットのデータを取得したいとする.

そのためのフォーマット情報が
DateUtilsクラスにパターンが既に用意されている.

String org.apache.http.impl.cookie.DateUtils.PATTERN_ASCTIME = "EEE MMM d HH:mm:ss yyyy"
String org.apache.http.impl.cookie.DateUtils.PATTERN_RFC1036 = "EEEE, dd-MMM-yy HH:mm:ss zzz"
String org.apache.http.impl.cookie.DateUtils.PATTERN_RFC1123 = "EEE, dd MMM yyyy HH:mm:ss zzz"

この3つがあるようだ.
至れり尽くせりである.

つまりこんなかんじでLong値ミリ秒UNIXタイムデータをRFC1123形式の文字列に変換できる.


ここまでは特に問題ないと思っていた.
というか,結果の文字列をUIに表示させるだけなら問題ない.
しかし,複数機器を跨いでフォーマット情報をキーに変換を行う場合問題が起こることがある.


上記のソースを使用して複数端末に時間情報を喰わせる.
すると機種依存かAndroidバージョン依存かは知らんが違うフォーマットで返ってくることがある.

欲しいのは
Wed, 21 Jan 2009 10:09:52 GMT+09:00
こういうフォーマットである.
しかし,一部機種で
Wed, 05 Dec 2012 09:48:26 JST
こんな情報が返ってきた.
タイムゾーンの表示がちがう.

UIに表示させるだけなら問題ないが,
連携する機器が【JST】を理解できなければそれはエラーである.


サーバーがGMT基準しか受け付けない場合
なおかつタイムゾーンがそんなに重要でない場合は

ハードコーディング.
こんなかんじでやっつけても大丈夫だと思う.

2012年12月3日月曜日

【Android】CursorでIllegalStateException


IllegalStateException: Couldn't init cursor window
とログを吐いてアプリが強制終了した.

原因はくだらないことだがカーソルを開いたままクローズしていなかったからだった.
メモリ不足のようだ.

このログが吐かれた場合は
・カーソルを開いて処理して…を繰り返すルーチンがある場合はちゃんとclose()してるか確認
・query()時に取得条件を増やすことで不要なデータは除去してメモリの圧迫を緩和する
ことに留意すべきである.

原因が前者であれば対応は楽だが,後者であればどれだけ対応しても場合によってはメモリ不足に陥る可能性が残るため
カーソルの扱い方の変更も視野に入れたほうがいいかもしれない.

2012年11月29日木曜日

【Android】各Activityの親について


AndroidアプリでActivityを複数持つ場合.
アプリとしての一貫性を保つためにすべてのActivityの親となるクラスを作っていた方がいい.
というか,作っていて当然というレベルであろうか.
同じ処理をあちこちに書くと修正の時に大変だし.

というわけでこういうクラスを作成した.



ここではAndroidの基本となる動作を簡略化してるだけだが,
アプリによってはこういったクラスがとてつもなく拡充されることだろう.
たとえばインターネット接続するアプリならバックグラウンドに行った瞬間にコネクションを切るだとか
フォアグラウンドに戻ってきた時にWiFi接続確認するだとか.
スキンを変更できるアプリなら画面作成時にSharedPreferencesから値を引っ張ってくるとか.
アプリのトップ画面への遷移もメソッド一発で実現できると楽なものである.

関係ないが管理している別のアプリでのSuperActivityクラスは1000行を超えてしまっていた…

2012年11月27日火曜日

【Android】ファイル名に使えない記号


Androidでファイル名に使えない記号は
> < : * ? " / \ |
です.
こんなかんじで全角に変換するなりなんなりで処理してあげましょう.


2012年11月21日水曜日

【Android】リブートした:Removing dead content provider: settings

オンキョーの古いAndroidタブレットTA117Cがリブートしくさった.
このタブレット自体は買い物でVeiwSonicのgTabletとかいうものの国内流通版とかいう話だが
そんなことはどうでもいい.


01-07 15:05:29.683: I/ActivityThread(1003): Removing dead content provider: settings

こんなログを吐いて死んだ.
Androidが再起動した.
ログを辿って行くとあらゆるサービスをServiceManagerが停止させて
起動中のアクティビティをActivityThreadが停止させて
それからリブートしているようだ.

よくは原因が分からないが
Removing dead content providerという文句に身に覚えが.
MediaStore…ContentProviderに登録している動画をギャラリーではなくファイラー(ESファイルエクスプローラー)から削除してしまったのだ.

つまりは多分ContentProviderというDBにエントリはあるものの,
動画本体は存在していない状態を作り出してしまった気がする.

しかしログを見ても再起動前にMediaScannerが動いていたようには見えないし
実際のところ何故リブートしたかは全く不明.

【Android】WebViewが倒せない


AndroidのアプリにWebViewを入れた.
DDMSでスレッド一覧を見た.

WebViewCoreThread
WebViewWorkerThread
CookieSyncManager
http*(←複数)

というスレッドたちが作られた.

その後,アプリを終了させるまで何をやってもこのスレッドたちを消すことができない.

WebViewをもつActivityを切り替えた
WebViewをもつActivityをfinish()した
WebViewインスタンスにnullを入れた
WebViewインスタンスをレイアウトからremoveView()した
WebViewインスタンスをdestroy()した
リフレクションからWebViewのonPauseを呼び出した

とりあえず調べてでてくるだけ試した.
でもこのスレッドたちは消えてくれない.
邪魔だ.
解決してない.しなさそうだ.

ステータスがwaitだからまだいいものの.

2012年11月15日木曜日

【Android】レイアウトを載せたダイアログの幅がwrapしてくれない

Androidのレイアウト.
どれだけ学んでも完璧にはいかないものである.

今日はレイアウトをセットしたAlertDialogの幅が
レイアウトにwrapしてくれないという問題で結構ひっかかっていた.

作ろうとしていたのはインテント送信先アプリ一覧ダイアログ.
iOS6のOpen Inみたいなレイアウトで3x3のグリッドをダイアログに表示させたい.

まず載せるレイアウトがこれ.
dialog_app_list.xml

そしてダイアログを表示させる元のjavaクラスがこれ.
MainActivity.java

本来ならGridViewに対していろいろ処理を行うんだろうけど
そんなことしなくても現象が発生するし
そういうことを書くとコード可読性が下がるから必要なモノだけ.

すると,こういう表示になる.
wrap_contentしているはずのLinearLayoutがAlertDialog全体に引き伸ばされている.
LinearLayoutとGridViewのbackgroundはこのために設定している.
つまり,この緑色部分に3x3のアイコンが並んでいると想像して欲しい.

我々が望んでいるのは画面幅に引き伸ばされたダイアログではなく
GridViewの幅ぴったりなダイアログである.
横幅いっぱいになるならレイアウト諦めて横一列にアイコンを並べられるだけ並べるとか
アイコンとアイコンの間隔がいっぱい開いたダイアログとか
そういったことはしないのである.
ここは見栄えのいい3x3にこだわろう.

ちなみに,LinearLayoutを潰して
dialog_app_list.xmlをGridViewだけのレイアウトにした場合
つまりこう変更すると

layout_widthの値を無視して
GridViewの幅が画面全体に引き伸ばされた.
つまり横幅いっぱいのAlertDialog全体が緑色に成った.
いちいち引き伸ばして…いらんおせっかいである.


どこを調べてもろくな情報がなかった.
悩みまくった結果,問題の本質はAlertDialogにあったらしい.
AlertDialogにsetViewするとレイアウト幅は何を指定しようと
画面幅まで引き伸ばされるようだ.
しかし,setViewしないAlertDialogはそういったことはない.
こういったときは一個上の親にお世話になりにいくべきか.

というわけでAlertDialogを使わずにDialogを使えば解決した.
ダイアログにセットするレイアウトはLinearLayoutを含んだ元のレイアウトに戻している.
ダイアログを表示するMainActivity.javaはこうなった.

するとちゃんとレイアウト幅に合わせたダイアログが表示された
…が!タイトル領域がデフォルトで表示されていて邪魔である.
サブクラスのAlertDialogが表示しないことが可能なのでDialogでも可能なはずである.

このタイトル領域はDialog.setContentViewする前に
Dialog.requestWindowFeature(Window.FEATURE_NO_TITLE);
とすれば消えてくれる.
つまり一行加えてMainActivity.javaはこうなって

表示が意図通りのものになって安堵した.

2012年11月14日水曜日

【Android】ListView/GridViewでGraphical Layoutにレイアウトを反映させる方法

AndroidのUIをeclipse上で組んでいくときに
Graphical Layoutといってレイアウトをeclipse上でプレビューする事が出来る機能がある.

まぁこれはAndroidを触ったことがあれば常識なのだが.
一応前口上としてこういうの書かないといけない感に襲われるから書いた.

このGraphical Layout,当該XMLに書いてあることしか表示できないので
javaコード上でレイアウトをinfalteするListViewやGridViewはそのままでは
全く違うレイアウトが表示されてしまう.

例として画像,テキスト,ボタンの3つを1つの列に表示させるListViewを考える.
その1列分がこのview_list_item.xml

それをバインドするactivity_main.xml

しかし,activity_main.xmlのGraphical Layoutは

こんな感じに表示される.
view_list_item.xmlをバインドするのはjavaコード上なので当然である.
これをちゃんと表示させるためにはactivity_main.xmlのListViewを少し修正すればよい.
activity_main.xml

変更点は
xmlns:tools="http://schemas.android.com/tools"

tools:listitem="@layout/view_list_item"
の2文を追加したこと.
この指定によってGraphical Layoutが

このように表示される.
よかった.



GridViewも同様である.
画像の上にチェックボックスをもたせたViewをGridViewに列挙させる.
1アイテム分のビューがこのview_grid_item.xml

で,それをバインドするactivity_main.xml

するとこう表示される

ListViewのときと同様に
xmlns:tools="http://schemas.android.com/tools"

tools:listitem="@layout/view_list_item"
の2文を追加してやればいい.
ただし,ListViewと違い,1点だけ気をつけなくてはいけないことがある.
それがGridViewのオプション
android:numColumns
である.
横に何個アイテムを並べるかというオプションで,
画面幅が様々なAndroidでは並べられるだけ自動で計算して並べてくれる
android:numColumns="auto_fit"
を使うことが多いと思うが,
このままではGraphical Layoutが認識してくれない.
Graphical Layoutが認識してくれるようにするためには
android:numColumns="-1"
としなければならない.

つまり,activity_main.xmlはこうなる.

ちゃんと表示された.

ちなみに
http://developer.android.com/intl/ja/reference/android/widget/GridView.html#attr_android:numColumns
によれば,auto_fitと-1はjava上では同値ということらしいが,
Graphical Layoutは-1でないと通じないようだ.
For input string: "auto_fit"
とかいって怒られる.
ハナシの分からんやつである.

一方,この値が-1のままだと今度はコンパイラに
Integer value out of range (at 'numColumns' with value '-1').
などと怒られてしまう.
そのため,レイアウト確認時は-1,それ以外はauto_fitに戻す必要がある.
うーん,馬鹿だ.

【Android】Buttonの背景に画像を指定するとレイアウトが崩れる


Buttonの背景に画像を使うとレイアウトが崩れる…
wrap_contentしてくれない…
そんなことに一瞬だけハマってしまった.

activity_main.xml

文字数が2文字,5文字,20文字のボタンを作っている.
それぞれ上から
・通常ボタン
・backgroundに色(#999999)を設定したボタン
・backgroundに9patch画像を設定したボタン
layout_width="wrap_content"を指定しているのに
文字数が少ない【OK】のボタンの時に
幅が広くなってしまっている.

こうやって並べるとなんとなく理由は分かると思うが
OKとキャンセルだけで組んでたときは
なんでOKとキャンセルとが等じ幅になるんだ!
とパニックになっていた.

理由は簡単.
背景に使っていた画像が
こんなやつだったため.

9patchというものは背景に設定したアイテムが広ければうまい具合に拡大してくれるが,
狭い場合には縮小はしてくれないようだ.
そのため,OKという文字列はこの9patch画像に対して
文字数が少なすぎて,wrap_contentできなかったのだ.

ボタン画像やインプット画像を作る場合は
幅の狭いもの画像を作るべきである.
9patch画像をこれに差し替えると
ちゃんとwrap_contentされた.


今回は関係ないけど背景が色指定の場合は
極限を目指したかのようにとてつもなく狭いため,
paddingを設定しないと見るに耐えないUIになる.

2012年11月12日月曜日

【Android】ListViewタップ時に勝手に表示される背景色を殺す


アプリケーションを個人で一人で作ってる時は
俺が仕様だとそれで済むのかもしれません.
しかし,チームで作ってるとなるとそういうわけにもいかず,
デザインチームがこうしてくれと言われたら本当に無理な場合を除いてそう実装しなければいけません.

今日はそんな感じでListViewを使ったメニューを作っていくなかで,
背景色に困った場合をスキットで紹介しましょう.

開発者を 開
デザイナを デ
と表記します.

デ「今度作ってもらうアプリのメニュー画面は拡張性や項目の表示/非表示にソフトで対応できるようにリストで作ってもらいたいです」
開「ふんふん,ListViewを使ったメニューActivityね.把握」

~1時間後~
開「こんなかんじで」
デ「いいじゃないっすか」
デ「メニューは文字だけじゃなくてボタン画像も表示します」
デ「これが通常状態で」
デ「これが押された状態です」


~30分後~
開「こうなりますね」
デ「いいですね,でも青いの邪魔ですね.なんですこれ」
開「AndroidでListViewの項目押されたら出てくるやつですね」
開「機種によって青だったり黄だったり橙だったりいろいろです」
デ「消せます?」
開「できますよ」

~数分後~
開「リストの背景白く塗りつぶすとこんなかんじです」
デ「塗りつぶし…だと…」
デ「メニューの背景…できた…」
開「背景…単色じゃないの?なんでマンデルブロ…」

~数分後~
開「そりゃこうなりますよね」
デ「ですよね」
開「マンデルブロ?」
デ「マンデルブロ」

~数分後~
開「これじゃダメ?」
デ「限りなく惜しいんだけど青いの消せません?」

さて,開発者くんはデザイナくんの要望に答えようと頑張りましたが
どうしてもListViewの選択色が邪魔でしかたありません.
背景が単色じゃないので塗りつぶしも出来なくなりました.
最初はListViewをカスタムして何とかできないかと思ったみたいですが
よのなかそんなにあまくはなかったのです.

しかし,解決法はありました.
1.ListViewのアダプタを拡張
2.各項目をバインド(getView)するときに各項目にクリックリスナをセットする
3.クリックリスナでリストの指定番目をクリックする動作を行う
これだけ.
3についてはabsListViewクラスにperformItemClickという関数があります.

まずはActivityのレイアウト.
activity_main.xml

次に通常時/タッチ時に切り替わる文字色とボタン画像
color_tapped_text.xml

list_menu.xml

そしてListViewのそれぞれの項目となるレイアウト
view_list_item.xml

最後にこのActivity自身である
MainActivity.java

これでUI上でListViewをタップした時に
view_list_itemのFrameLayoutがフックというかインターセプトして
ListView自体にタップ情報を通知しないようになりました.
そのため,選択色が表示されなくなりました.
また,MainActivityAdapterのgetViewで設定しているクリックリスナ中で
performItemClickメソッドを使い,親ListViewの指定番目をクリックしています.
遠回りをわざわざしているように見えますが,UIでクリックしているわけではないので
ListViewの選択色は表示されません.

重要なことなのですが,タップをインターセプトしたのはFrameLayoutなので,
その下の画像と文字色をタップ時に変更させたい場合は
view_list_item.xmlでしている通り,ImageViewとTextViewに
android:duplicateParentState="true"
オプションを追加する必要があります.

これで
開「こうなりました」
と言えるようになりました.

2012年11月1日木曜日

【Android】MediaStoreにサムネイルを作成させる

MediaStoreというAndroidがネイティブで持っているDBを使うと画像一覧が作りやすくなる.

Android自身が暇な時にSDカードの中を覗きに行って勝手に新しい画像を探してきて
DBに追加,サムネイルを作成してくれる.

いちいち手動でサムネイルを作成しなくても本体が作成してくれているから
その分の時間が省ける.
つまりはリスト描画の高速化が見込める.

たぶんこんな流れになっている
MediaScanner
⇒SDカード内の画像を収集,MediaStoreとサムネイル作成キューに追加

MediaProvider
⇒サムネイル作成キューを処理する

これらがAndroidで知らない間に行われている.
手元のXperia(SO-01B)で確認したところ,
MediaScannerが4枚画像を収集するぐらいの時間で
MediaProviderが1枚サムネイルを作成する.

つまり,DBへの画像追加が終わってもサムネイルは全て作成されていない.

なおサムネイル作成キューは電源を落としても消えないようだ.

MediaStoreに登録されている画像のサムネイルを取得しようとするとどうなるのだろうか.
リストに描画しようとサムネイルを取得する.
MediaStore.Images.Thumbnails::getThumbnail ()
というメソッドで取得するのだが,MediaStoreにサムネイルがない場合は律儀にも作成してから返却してくれる.
つまりそこで時間がかかる.

今回はそんなファイルたちのサムネイルを作成していこうと思う.
なお,うまいやり方が見つかるまでの一時しのぎのつもりである.

このクラスをActivity内に追加し,呼び出すとプログレスダイアログを表示し,
MediaStoreを片っ端から見ていってサムネイルがない画像のサムネイルを作成させる.

これで片っ端からサムネイルを作成していくことができる.
画像リストを作るがカーソルがあたってからサムネイルが作成されてその時々に描画を待つくらいなら
寝てる間に全て作ってくれたほうが嬉しいという場合にどうぞ.

なにか他にうまいやり方あればいいなぁとは思うが.

2012年10月25日木曜日

【Android】ArrayListのforループでエラーが起きて死ぬ


ArrayListのforループでエラーが起きて死ぬ

ArrayListのコレクションをforループで回して
その中で必要か不要かを判定して
不要ならループ内で消してしまうと死んでしまう.

例えば

こんなことをすると

java.util.ConcurrentModificationException
   at java.util.AbstractList$SimpleListIterator.next(AbstractList.java:64)

というエラーが起きて死ぬ.

残念ながらスマートではないけど違う方法をする必要があるようだ.

こうしてやる必要があるみたい.
本当はもっと違うところも書きたかったんだけど
まずは簡単なほう.

2012年10月22日月曜日

【Android】プログレスダイアログのバーを2つにする

ファイルのコピーなどでダイアログ中に2つのプログレスバーを表示したいという需要があるかもしれない.
Androidが持っているProgressDialogはとてつもなく便利なモノではあるが,
ただ単にAlertDialogを継承してそこにプログレスバーと文字に依る進捗表示を付け足しただけである.

プログレスバーにはセカンダリ値が設定でき,一応は2本のバーを同一軸上に表示させることができる.
しかしこのセカンダリ値の最大値を個別で設定することはできず,プライマリの最大値を用いることになる.

例えば,ファイルをコピーするときに進捗ダイアログを表示させたい.
プログレスバーを2本用意し,
片方には 送信したファイル数/送信済みファイル数 の進捗
もう片方には 処理中ファイルの送信済みバイト数/ファイルのバイト数 の進捗
を表示させたい.
こういった場合,最大値がそれぞれ違うためAndroidのプログレスバーを適用できない.

いや,使うことはできなくはないのだが.
最大値を100(%)にして
片方には 送信したファイル数(%) の進捗
もう片方には 処理中ファイルの送信済みバイト数(%) の進捗
をプログレスバーに与えてやれば確かにプログレスバーの動作としては問題ない.

しかし,文字で表示される進捗は
○○% 進捗/最大値 というフォーマットで固定されているため
X% X/100
という重複した内容が表示されることになる.
更には,セカンダリバーの表示はプライマリバーの後ろに,同じ太さで表示されるため
プライマリバーがセカンダリバーの進捗を追い越すとセカンダリバーが見えなくなってしまう.

当然ながら上に重なって表示されるバーは下のバーより細くなくては両方見えない.

というわけで,AndroidのProgressDialogのソースを元に2本のプログレスバーを表示するダイアログを作ってみた.

まずはリソース.
/res/layout/view_dual_progress_dialog.xml



このソースではセカンダリバーが上に細く表示されることになる.


次に,セカンダリバーがプライマリバーと同じ色だと見えないし,
バー背景が見えていたらプライマリバーが欠損してるように見えるので
セカンダリバーの色を変更する.
/res/drawable/progress_secondary.xml



実機ではプログレスバーが何色に表示されるかは機種ごとに違うため,
プライマリバーも同様の方法で変更した方がいい.
実際にこの例の緑だとサムチョンギャラクシーSIIで色が被ってしまった.


そして本体のjava
DualProgressDialog.java



最低限の実装しかしていないので,AndroidのProgressDialog同等の実装をしたいのであれば
ここに追加していけばいい.


なお,このDualoProgressDialogの使い方は通常のProgressDialogとほぼ同じになっている.
違う点というと,
円形進捗バーの存在がないので,
setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
をする必要がなくなったという点と
セカンダリプログレスの最大値を設定する必要がある
という点.
この2点である.

2012年10月19日金曜日

【Android】twiccaに画像インテントを投げてもアップロードできない

twicca
Androidのtwitterクライアントで100万ダウンロード以上,45,000レビューあって評価4.5という人気アプリ(2012/10月現在)
そのtwiccaに自分のアプリから画像をインテントで投げてtwiccaからつぶやいてみたい.
そういう需要があるかもしれない.

しかし,twiccaへのインテントの投げ方はどうやらお作法があるらしい.
普通に作ってインテントを投げてもtwiccaは画像をアップロードさせてくれない.


まず1点.
twiccaへ投げるmimetypeはちゃんとファイルに即した形式で投げる必要がある.
"image/*"などというワイルドカードは避けるべきである.
twiccaではこんなインテントは受けた瞬間に落ちるようだ.


twiccaへ投げるお作法でもう1点.

たとえばこんなかんじでtwiccaへインテントを投げる

File _file;
String _mimetype;
///////////////////////// 別のところで_fileと_mimetypeを設定

private void sendIntent () {
Uri uri = Uri.fromFile(_file);

Intent intent = new Intent (Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_STREAM, uri);
intent.setType((_mimetype != "") ? _mimetype : "image/*");
startActivity(intent);
}

やってることは単純.
ファイルからURIを取得してそれをインテントとして投げている.

他のだいたいのアプリはこれできちんと受け取ってくれるのだ.
でもtwiccaはクリップボードに画像がありますよマークは出るのだが
アップロードボタンを押しても反応しない.


さて何故でしょう.
ちなみにAndroid標準ギャラリーから送った画像はtwiccaは正常にアップロード出来て
開発者の友達,ESイメージブラウザから送った画像は今回と同様にアップロード出来ない.


ここから推測するに,twiccaはcontentスキーマしか処理していない.
contentスキーマというとContentProvider用のスキーマ.
URLがcontent://から始まる.

一方,上のサンプルでtwiccaへ投げたURLはFileパス.
FileパスのURLはfile:///から始まるのである.

ちなみに同一画像についてギャラリーとESイメージブラウザからインテントを投げてもらって
受け取ったURLが以下のとおりである.

// ギャラリー
URI: content://media/external/images/media/2003
// ESイメージブラウザ
URI: file:///mnt/sdcard/DCIM/Camera/20121015_200741.jpg

同一画像だが,全く違うURLをくれた.


あくまで俺の勝手な推論だが,
twiccaはcontentスキーマしか処理してないと考えられる.

画像を受け取るアプリケーションの理想としては
他アプリからインテントを受け取ったときに
URLの先頭を確認してcontentから始まっていたらfile形式のURLに変換するか
もしくはfileから始まっていたらcontent形式に変換するかをして
両URLに対応するのが望ましいと思うが,実際にcontentスキーマしか対応していないのなら
送り側がfileスキーマからcontentスキーマに変換してやるしかない.

しかしそうすると逆にfileしか対応していないアプリに対してエラーを出させることとなる.
投げる側は1つのURLしか投げられない.


ちなみにcontentとfileの相互変換については他サイト様を参考にされたし.
http://yagni.jp/android/interconversion_between_file_and_content


2012年9月16日日曜日

HWシーケンサー

ないのですか?
HWシーケンサーの需要.

少なくとも僕は欲しいと思うのですが.

何年も前から言い続けていることではあるのですが.
僕はQY100を持っています.
作曲のメインです.僕は打ち込みで曲を作る.

確かにもはやソフトウェアシーケンサーが主流.
というか,DAW環境だとシーケンサーの機能もMTRの機能もなんでもある.
しかし,PC上で動くソフトウェアであるがために,
鍵盤での入力以外にもマウスや他のインプットにも対応しないといけないというUI上の制約があり,
それがかえって鍵盤での入力を難しくしている.

僕が欲しいのは
・気軽に持ち運べて(これはMBAやVAIO type Pでもできるけど)
・鍵盤がついていて
・すぐに起動する
作曲環境.

PCだとカフェで作曲するのとか難しいんだよ.
鍵盤も持ち運んでたらただの変な人じゃん.
嵩張るし.

QY100は2000年に発売されたHWシーケンサー.
もう12年も前の機種になるが,それが未だに第一線である.
メモリーカードはスマートメディアという過去の規格である.
つまり,もはや記録することができない.
しかも本体メモリーが揮発性メモリーであり,
スーパーファミコンROMのようにボタン電池を内蔵していて,
電池が切れると本体にも保存できないという今から考えるととてつもない素敵仕様.
そして内蔵メモリーの限界が案外低く,曲を作りこむと一曲もたずにメモリーフルになってしまう.
さらには外で使うとなると馬鹿でかいACアダプタを持ち運ぶか,
単三電池6本というエネルギー食いである.

12年前だぜ.
携帯だって「パカパカ」以前のストレート機だらけだし,
着メロが3和音とか言ってたし,
ようやくカラー液晶が携帯で普及し始めた時代.
PS2の発売された年といえば聞こえはいいが
Windows 2000の年といえばものすっごく微妙だろう.

今,QY100のようなHWシーケンサーを作るとすると
・パネルのバックライト及び必要ないけどカラー液晶化も可能
・小型軽量化
・消費電力の削減, 充電池の採用
・内蔵メモリーは不揮発性フラッシュ
・外部メモリーはSDカード
・PCとUSBで接続可能
・音源拡張

これぐらいは余裕で積むことができるだろう.
UIさえ十分にリッチであればVSTプラグインにも対応できるだろう.
応答が早ければMIDIキーボードの音源モジュールとしても使えるんじゃね.
正直ギター用エフェクトとかそういうどうでもいい機能はどうでもいい.
HWシーケンサーとして正統進化を遂げたHWシーケンサーを見てみたい.
もう,無理なんですか?

2012年9月10日月曜日

【ピコーン】下らないこと思い付いた【やめろ】

そういえばエレドラのパッドって圧電素子だけで作れるんじゃね?って思い立って
ググってみたらその通りでどうやら簡単に作れそうだ。
そして俺のTD-4KSにはクラッシュ2用の端子が一個余ってる。
さらにはうちにはトレーニング用のメッシュパッドが一個ある。

シンバルにはならねど、ハイタムがわりに増設できんじゃね?と。

うん、まぁその前にベースシンセだな。
可哀想に放置しっぱなしだ。
週末に新しい半田鏝買ってきたからさっさとベースシンセ終わらせて次行くぞ!

ゴムパッド入手できればシンバルにもなるよな。
はて、どうするか。

2012年8月2日木曜日

【Windows Metro プログラミング】アプリバーのボタンについて

Windows8のメトロUIで右クリックをすると上や下から表示されるかもしれないこのアプリバー.
実装的には必須ではないし,現に組み込まれていないアプリも多い.

そんなアプリバーのこのボタン.
ソースのどこを見てもこんな画像がない.
誰だよこいつって思いながら探しまくること幾星霜.

リソースファイル(Common/StandardStyles.xml)を見てみると


    <Style x:Key="MailAppBarButtonStyle" TargetType="Button" BasedOn="{StaticResource AppBarButtonStyle}">
        <Setter Property="AutomationProperties.AutomationId" Value="MailAppBarButton"/>
        <Setter Property="AutomationProperties.Name" Value="Mail"/>
        <Setter Property="Content" Value=""/>
    </Style>


こんなふうに書かれている.
ContentのValue値がなぜ□なんだろうと思っていたのだが,
実はこれは四角ではなく,トーフだった.
つまり文字化け.

特定のフォントにすれば実態を見ることができる.

その特定のフォントというのがSegoe UI Symbolというフォント.

つまりは,アプリバーの◯に囲まれた絵のようなボタンは
絵ではなく文字だった.

逆に言うと,そういう絵文字を使わなくとも
Value値を"あ"なんかにしたら◯に囲まれた"あ"がボタンになる.

Metro Styleでは◯に囲まれたアイコンがボタンという意味を持っているようだ.

VSでこの特殊文字を入力するためにわざわざMS-IMEに切り替えて
IMEパッドからキャラマップを表示させることになる.
私用領域のところにアプリバーで使われるようなアイコンが格納されている.

文字だとは思わなかったから10分ほど呆然としたよ.
Windows Phone開発者なら当然だったのかな?

知識ゼロから始めるとこんなものだね

2012年7月30日月曜日

Windows8 Metroで起こったこと

仕事でWindows8RPを使ってて起こったこと.

まず一つ.
Windows Metro画面からMetro用IEが消えた問題.
原因は簡単.規定ブラウザをIE以外に設定したから.
何も考えずにいつもどおりFireFoxにしてしまっていた.
規定ブラウザはIEにしていないとMetro用IE使わせないぞというMSのお心配り.
イラネーヨ

もう一つ.
Metro用各アプリのテキストボックスで日本語が入力できなくなる問題.
これも原因は同じようなもの.
IMEをMS-IME以外に設定したから.
Google IME使おうとするとMetroでは英字しか入力できん.

これはRTMには本当にどないかしてほしい.
開発者としてでなくユーザーとしての願いだ.

Metroとデスクトップは完全分断するんじゃなかったのかよ.
Metro用ブラウザ(サンドボックス外のアクセス権限)は他のブラウザメーカにも明け渡すとは聞いたけど
IMEはこのままじゃダメでしょ.ATOKとか使ってる人多いでしょうに.
少なくともMetroの時は勝手にMS-IMEに切り替わるとか(理想は設定IMEをフルで利用できることだけどね)
そういうことしないと自らMetroを否定することになるよ.

Macみたいなガラパゴスと違ってWindowsはサードパーティあってこそなんだから.
自社囲い込みは自殺行為.

2012年7月25日水曜日

【Windows Metro プログラミング】ページ遷移で例外落ち(ヌルポ)

Windows Metro Styleのプログラミングを勉強していて
激しく躓いたところが一点あったので情報共有.
ちなみに環境はWindows8RPとVisualStudio Professional2012RC.
というかWPF勉強済みなら常識なのかもしれないけれど.
初めてのWPFなので勘弁して下さい.

今Metro Styleアプリの勉強で数少ない情報源である
Microsoft公式のデベロッパーセンター
そこのサンプルで勉強をしていたのだけど,
パート3 ブログリーダーを作成する
http://msdn.microsoft.com/ja-jp/library/windows/apps/br211380.aspx
ここで躓いた.

具体的には
ページとナビゲーションの追加
にあるページ遷移なんだけど,
ページ遷移は

this.Frame.Navigate(typeof(SplitPage), e.ClickedItem);
でできるそうな.
ふむふむなーる
と思いながらタイピング,言われたとおりに実行を行い,
ページ遷移させようとすると
LayoutAwarePage.csという自動生成コードにある
onNavigatedFromメソッド中の
frameState[_pageKey] = pageState; ここから
ArgumentNullExceptionという例外が帰ってくる.
どうやら配列のキー_pageKeyがnullらしい.
どこがおかしいのかとそのページをさんざっぱら読みまくっても答えは落ちてなかった.
ググってみるとMSDNのフォーラムで同様の質問があった.
http://social.msdn.microsoft.com/Forums/en/winappswithcsharp/thread/a2611a92-4d2e-4186-9118-cde94346c756
なんかCP版まではうまく動いてたのにRP版でページ切り替えができなくなったとか書いてある.

解決法
遷移元のページ(このサンプルだとItemsPage.xaml.cs)
のOnNavigatedToメソッドの一番最初に
base.OnNavigatedTo (e);
を追加してやる.それだけ.
明示的にスーパークラスのメソッドを呼び出さないといけないようだ.
デベロッパーセンターに書いてないぞ…
どうやらスーパークラスであるLayoutAwarePage.csに遷移元を教えておかないと遷移行為自体ができないようになってるらしい.

つまり
ItemsPage.xaml.cs の OnNavigatedToメソッドはこうなる

        protected override async void OnNavigatedTo (NavigationEventArgs e) {
            base.OnNavigatedTo (e);
            FeedDataSource feedDataSource = (FeedDataSource)App.Current.Resources["feedDataSource"];
            if (feedDataSource != null) {
                if (feedDataSource.Feeds.Count == 0) {
                    await feedDataSource.GetFeedsAsync ();
                }
                this.DefaultViewModel["Items"] = feedDataSource.Feeds;
            }
        }

これでItemView_ItemClickメソッドで呼び出している
SplitPageへ遷移することができるようになった.
遷移で失敗しているからこのItemView_ItemClickメソッドに何かが足りないのかと思っていた…

レイアウト済みページを追加した場合に起こりうるので注意.

どうでもいいけどC#のスーパークラス呼び出しってbaseなんだね.
superじゃないんだ.Javaに毒されすぎかな.

2012年7月8日日曜日

次世代GK妄想

と思う

なるほど,GK-3は確かに使いやすい.
GKシリーズ最新のピックアップである.

だが,今考えると目的の割に回路が古過ぎやしないか.
回路はピックアップ⇒バッファー(OPアンプ)⇒アウトプット
回路がアナログであるが故に多大な不便を感じる部分がある.

無線化できねえ

GK-3の発売が2004年2月らしい.
もう8年GK-3で戦っているようだ.
もはや技術が流行に対してアウトオブデートである.

バンドマンじゃないから言うのもためらわれるが
ふにゃふにゃした公式ケーブルしかろくに手に入らないんだから
これを現場で使うのは厳しいと思う.
ケーブルに縛られるし断線が怖い.

アウトプットが全ての音楽の世界とはいえ,
構成要因がディジタルである以上ムーアの法則が成り立つわけで
8年も進化しないのはどうかと思う.
無線化技術なんて今安いだろ.

サイズにしろ802.11nのUSBドングルだって今や小指の先サイズ.
天下のRolandさんがちょっと発揮すれば実装できるはず.

ただ,問題は後方互換.
あ.俺のGR-55は使えなくなるのねとか
そういうやつ.

うまいことアダプタを作って後方互換に対応できればいいけど,
できなくても俺は問題ですらないと思う.
付け替えたらいいだけだもの.
次世代GK.Rolandルールに従うなら4をとばしてGK-5かな
今みたいにアナログ出力じゃなくて後方互換を切ってディジタルでもいいと思うんだ.
んで,デフォルトはワイヤードだけどオプションでワイヤレスユニットに対応できるようになっていいと思うんだ.

こーんなことを作業しながら思ってた.

GK移植作業のとちゅうですが

ターがぶっ壊れたので

さすがに13pinを空中で配線するのはつらい.
っつーかあの密集した13pinを配線する時点で辛い.
使ってるうちに,ケーブルを抜き差ししているうちに溶接部分が断線してしまう.
というわけで,ギターの修理をしていました.
DIN13ピンと舟形ジャックの処理を
http://noizy-radio.blogspot.jp/2012/04/blog-post.html
こんな風にしていたんだけど
舟形ジャックからコネクタが微妙にずれるわけ.

これじゃいかんということで完全固定の道へ奔走.
具体的には使ったものはセメダインスーパーX2とホットボンド.

舟形ジャックとDINコネクタの接触面にセメダイン塗布して接着.
セメダインの定着には時間が掛かるから仮固定兼務でホットボンド.
2日も置いてると手では動かないぐらい固定できた.

それから,断線対策として
まず13ピン全てをハンダ付けしなおし.
乱視には辛い作業である(´・ω・`)
半田鏝の鏝先ほそいやつが欲しい.

それから,半田後の処理.
これまでは絶縁テープを巻いてたんだけど
あんまり意味が無さそうなので別の方法を考える.

本当は熱収縮チューブで固定したかったんだけど
手元にある熱収縮チューブが複数本まとめる用のやつで
1本だとスカスカで意味を成さないのでこれは諦め.
結果,ホットボンドを垂れ流した.
なんかやってはいけないことをした感が半端無いのだが
トラブルが起こった場合に修復することができなさそうな気もしなくもないのだが
まぁそれでも今は問題ないようなのでよしとしてみる.

これで今は安定期に入った.
問題というとピックアップ部分が両面テープで貼ってるせいで浮いてくる.
螺子で固定はしたくないのだよ.

本当は別のことを書きたくて↑は前置きのつもりだったんだけど
意外に長くなってしまったので分けよう.
一旦ポスト

2012年6月28日木曜日

スタックボリュームポットの改造

ギターの時にもやったけどね.
今なかなかまとまった時間が取れなくて細々とした作業しかできない.
あとでギター含めてちゃんとしたまとめができたらいいなぁ.

今日の作業はこれだけ.
このスタックボリュームA500kΩとB50kΩ.
モノによって構造が違うと思うけど
分解する.
こいつらも千石2で買ってきた.
ボリュームのくせにいい値段するよね.ギター用ってなんでこんなに高いんだろう.

こいつらの分解方法は底面のツメと黒いパーツを外す.
ツメも黒いパーツもラジオペンチだけで外せるよ.
むしろ他の工具使うと難しくなる.

んで, 2段になってる底のほうをそれぞれ入れ替えて
ツメと黒いパーツを戻しておしまい.

2012年6月26日火曜日

次の獲物はこいつだ(・∀・)

の獲物

前回のESP REINDEERギターシンセ化から2ヶ月.
次の獲物はこいつだ(・∀・)

Ibnez SR3000
こいつをベースシンセ化するよ!
ということでGK-3Bを買って来た.
んで仮でマウントしてみた.
見ての通り,こいつもボディが小さくてGKをマウントする場所がない!

しかも今回は早々にディバイデッドピックアップをネジ止めしてしまった.
もうやるしかない!

ということで今回もSR3000にGK-3Bを内蔵していくことになった.
ちなみにコントロールキャビティに基盤が入るかどうかは確認していない.
入らなかったらマジ詰み.

GK-3BはGK-3と違ってブリッジから5cmまで離れて設置できるらしい.
ちなみにGK-3は2cm.
今回試しにつけてみたら一番近い1弦でなんと5cmちょいオーバー.
まぁやるしかないて.

このSR3000さんはIbanezのmade in Japanモデル.
当時はまだSRスルーネックベースがない時代だったかな.
初期タイプだからピックアップがバルトリーニじゃなかった.
写真を見て分かると思うけどリアピックアップはハムに変えてる.
フロント部分にはフェンス.
不可逆改造という暴虐の限りを尽くしたベース.
のつもりが,まだ電気系統はピックアップ変更以外いじってなかったので
今回大幅に手が入ることになる.

何しろ少なくともアクティブサーキットにおさらばしないと
このディバイデッドピックアップ基盤が入らない.


気系統をどうするか

とりあえず軽く完成図を考えておかないとね.
こんなかんじで.
アクティブサーキットは取っ払う.
どうせ音はベーアンで作るから使わないし.
そしたら穴が2つ空く.ギターの時と違って2つも!余裕!
その空いた穴にスイッチを2つ入れる.
ギターの時とは違ってスイッチも2つ.

1つはギターの時と同じ用法でパッチチェンジ用のスイッチ.
もう1つはアウトプットセレクト.
ノーマルピックアップをフォンジャックに流すかシンセ基盤に流すか切り替える.
前者は(ON)-OFF-(ON)の2回路スイッチが必要.
後者はON-ONの1回路スイッチ.

で,ボリュームはギターの時と同様にA500kΩとB50kΩのスタックボリュームを改造して
A500kとB50kの混合スタックを作り上げる.

バランサーはそのままバランサーとして使う.

この構成だとノーマルピックアップもGR55のエフェクトを使えるようになる.
ギターの時はノーマルピックアップはフォンに流すだけだったから使えなかったのよ.
スイッチを仕込む場所がなくて諦めた.

GRの機能をフルで使えるからシンセベース×2,ベースシミュ,ノーマルピックアップの
ベース4重奏が実現できる!


ずやること

一番最初は地味な作業から.

ギターの時もやった舟形ジャックの穴拡張.
舟形ジャックは千石2で280円だったかな.

かなり時間がかかる作業だけど地道にやっていくよ.
ほいでは.

↑2時間くらいで終了した.

2012年6月19日火曜日

MIDIIO on VC++ つづき

環境が二転三転しています.
当初はWindows 7(64bit) + VisualC++2010でやっていましたが
なんと今はWindows Vista(32bit) + VisualC++2008でやっています.
本当はWindows XP(32bit)上でプログラミングしたかったのですが,
どうしてもVisualC++のプロジェクトが作成できない.
そんなこんなでサブ機でプログラミングしています.

環境は変わりましたが,前回の設定を変更する必要はありません.

今回は音が出るところまで確認しました( ´∀`)
つまり,そこまで行けばあとはプログラミング次第です.

やっていきましょう( ・`ω・´)★


MIDIIO VC用Wrapperのダウンロード

どうやらC++/CLI上ではぴゅあーなCで書かれたMIDIIOライブラリだけで叩くのはきついようです.
というわけで素敵なお方がC++用Wrapperを作成して下さっているので
ありがたく使わせていただきましょう.
http://www.geocities.jp/yuusui_housuu/openmidiproject/midiiolibcpp/index.html
ここからダウンロードします.とりあえずアップデートが一番新しいのでいいと思います.

そして前回と同じようにヘッダーファイルはVCのincludeディレクトリに放り込みましょう.
ダウンロードしたファイルを解凍し,中に入っているMIDIIO_cpp.hを
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include
ここでしたね.


ファイルの配置・修正

そのMIDIIO_cpp.hは一点だけ修正します.
#include "../MIDIIOLib0.8/MIDIIO.h"
これを
#include <MIDIIO.h>
にします.
VisualC++が見ているincludeディレクトリ内にMIDIIO.hを前回入れているからこれで済むのです.

次に同じく解凍した中に入っているMIDIIO_cpp.cpp
これをプロジェクトのソースファイル・ディレクトリに追加します.
ダウンロード元のサイトにある画像のようにすれば大丈夫です.

このMIDIIO_cpp.cppも修正します.

①インクルード元を変更
さっきのヘッダファイルと同様に
#include "MIDIIO_cpp.h"

#include <MIDIIO_cpp.h>
に変更します.
上の手順でincludeディレクトリにヘッダファイルを追加したからです.

②デバッグ用とか知らんし
#ifdef _DEBUG
        #pragma comment(lib, "../MIDIIOLib0.8/Debug/MIDIIOd.lib");
#else
        #pragma comment(lib, "../MIDIIOLib0.8/Release/MIDIIO.lib");
#endif
このifdef文を大胆に
#pragma comment(lib, "MIDIIO.lib");
これだけにしちゃいます.
前回,MIDIIO.libをSysWOW64(もしくはSystem32)に置いています.
なのでVC++はこれだけでライブラリを参照できます.

③プリコンパイル済みヘッダは使用しません
#include "stdafx.h"
この一文を消しましょう.
ついでに,このままではエラーだらけになるので,

プロジェクトのプロパティから
「構成プロパティ」> 「C/C++」>「プリコンパイル済み…」
と選択し,
「プリコンパイル済みヘッダーの作成/使用」を
プリコンパイル済みヘッダーを使用しない
に変更します.

以上で今しがたダウンロードしたファイルの編集は終了です.


ストプログラム実装

さきほどのMIDIIO C++ Wrapperのサイトにある
サンプルプログラムを動かしてみましょう.

今回はWindow FORMプロジェクトなので
main関数はとりあえず一旦触りません.

前回同様testFunc関数内に記述していきます.
前回作ったtestFunc関数の中身は全部消しちゃいましょう.
そこに
2.MIDI出力を実現する
のmain関数内の処理をコピペします.

それから,ヘッダファイルのインクルードも忘れずに.
#include "..\MIDIIOLib0.8_cpp0.2\MIDIIO_cpp.h"
こいつだけは 
#include <MIDIIO_cpp.h>
こうなります.

そして,main関数内の適当な場所でtestFunc関数を呼んであげましょう.
 
音が出ましたか?
これでMIDI出力サンプルが動いたはずです.
 
あとは適当に実装を重ねていきましょう.
それでは〜 

2012年6月14日木曜日

MIDIIO on VC++2010Express

今VisualC++でMIDIを扱おうとしています.

っていうか久々でしたね.

自分のための備忘録です.
他の人は役に立つかなー?

そこでいろいろ調べていたらMIDIIOっていうモノがありました.
MIDIIOってのはMIDI信号の入出力用ライブラリなのですよ.
こんな便利なものがあるなんて!
これで勝つる.
と思ってはいたんだけど実際に組もうとすると
リンクエラーが出まくったのだよ.

そもそも僕はLinuxの組み込みばっかりやってたから
VC++なんてほとんど使ったことない.
VC#は昔にDirectXプログラミングやってた.
なので知識がVC++単体で組めるレベルまでしかないのです.
外部ライブラリのインポート?やりかたわからん…

ということで手順.
VC++をバリバリに使ってる人からしたら
当然なレヴェルの出来事です(・ω・)

1.ダウンロードしなきゃ始まらない
MIDIIOはフリーなのです.
素晴らしい.
これで勝つる.
http://openmidiproject.sourceforge.jp/MIDIIOLibrary.html
ここから一番新しいモノを落としてくる.
今現在だとV.0.8かな.

MIDIIOの公式ガイドブックというサイトもあります.
http://www.oifii.org/ns-org/nsd/ar/cp/midi_sf-jp_Sekaiju2/MIDIIO/docs/MIDIIO.html

前提なのですが,このエントリはそのV0.8とVC++2010Expressを使って
ビルドが通ったぜ!ウェーイ
VC++2008Expressも同様に試しています(以下,赤字は後日追記)
っていうところまでしか確認してません.
音が出せない環境で今書いているので
素晴らしいことに動作確認していません.
確認しました ビルドが通るだけで鳴りません

で,ダウンロードしてきたMIDIIOLib0.8.zipを適当なところで展開.
我々が使うのは
・MIDIIOLib0.8\MIDIIO.h
・MIDIIOLib0.8\Release\MIDIIO.dll
・MIDIIOLib0.8\Release\MIDIIO.lib
の3ファイルです.

2.各ファイルを適切な場所に置く
その3ファイルをVC++の管理下に置きます.

VC++を開いて適当なプロジェクトを作ってみて
画面左の「ソリューションエクスプローラ」でプロジェクト名を右クリックして
「プロパティ」を選んで
「構成プロパティ」>「VC++ディレクトリ」
VC++2008では
ツール>オプション>プロジェクトおよびソリューション>VC++ディレクトリ

を見てみたことがあるのなら分かると思うのですが,
ライブラリやヘッダファイルを置く場所というのは決まっています.
VC++は特定のディレクトリにあるライブラリやヘッダファイルを見ているのです.
もちろんVC++が参照するディレクトリを追加することもできるのですが,
参照ファイルが増えるに連れ参照ディレクトリを増やすなどということは普通はしません.

なので,VC++が最初から見ている場所にMIDIIOのファイルを置いていきます.

ちなみにいまの環境はWindows7 64bitでやっています.
前提としてVC++がインストールされているディレクトリを
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC
とします.
VC++2008なら
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC
ですね
Express Editionではインストール先選べなかったと思うので
多分このあたりにインストールされてるはずです.

まずはMIDIIO.h
これは
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include
ここに移してください.

次にMIDIIO.lib
これは
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib
ここ

最後にMIDIIO.dll
こいつは
C:\Windows\System32
ここと
C:\Windows\SysWOW64
ここ
多分OSが64bit版なら後者だけでいいと思います.
32bit版なら前者(後者はないと思うふ)
まぁ両方入れておけばいいでしょう(・ω・)

これで下準備が終わりました.

この章の2文目に書いた「構成プロパティ」>「VC++ディレクトリ」を見てみてください.
さっきやったことで
「実行ディレクトリ」にDLLを,
「インクルードディレクトリ」にヘッダを,
「ライブラリディレクトリ」にライブラリを保存したことがわかります.

3.テストプログラムを実行するビルドを通す

MIDIIO 公式ガイドブックのVC++から使うサンプルプログラムを実行します.
http://www.oifii.org/ns-org/nsd/ar/cp/midi_sf-jp_Sekaiju2/MIDIIO/docs/MIDIIO.html#APPENDIX_A

まずはVC++を開き,今後のためも考えてWindowsフォームアプリケーションのプロジェクトを作りましょう.
ここではプロジェクト名をtestとします.
testプロジェクトができたら左のソリューションエクスプローラの
「ソースファイル」>「test.cpp」をいじっていきます.

すでにmain関数が出来ているはずなのでとりあえずそいつは放置
適当な関数名int testFuncとでもして作成します.
testFunc関数内にサンプルプログラムのmain関数をまるっとコピペ.
インクルードするヘッダファイルの部分もまるっとコピペ.
でもそのままではエラーだらけです.

まずは
'MIDIOut_OpenW' : 1 番目の引数を 'const char [32]' から 'const wchar_t *' に変換できません。
というエラーが出るはずなので

MIDIOut* pMIDIOut = MIDIOut_Open ("Microsoft GS Wavetable SW Synth");
この行を

const wchar_t * wchar = L"Microsoft GS Wavetable SW Synth";
MIDIOut* pMIDIOut = MIDIOut_Open (wchar);
こう修正する.


次に
ijw/native モジュールが検出されました。pure モジュールとリンクできません。
とかいうエラーがでます.(ピュア)
元々.NETで使うことを前提としてないライブラリだからでしょうか.

ツールバーの「プロジェクト」>「プロパティ」
(or ソリューションエクスプローラのtestの上で右クリック,「プロパティ」を選択)
「構成プロパティ」>「全般」の
「共通言語ランタイムサポート」が「純粋 MSIL 共通言語ランタイム サポート (/clr:pure)」になっているのを
「共通言語ランタイム サポート (/clr)」に変更する
このエラーはこれで終わり


最後に
未解決のトークン **** が関数 **** で参照されました。

未解決の外部シンボル **** が関数 **** で参照されました。
外部参照  * が未解決です。
というエラーがどっさり出るはずです.

ヘッダファイルをインクルードしてる後に
#pragma comment(lib, "MIDIIO.LIB")
を加えてやるとこのエラーも終了.

これでビルドが通るはずです.

でもたとえmain関数内でこのtestFunc関数を呼び出しても
音はなりませんでした.
今回は第一章で書いたとおり
ビルドが通るまでなのでここまでです.

2012年6月12日火曜日

呪いのビデオに関する考察

Twitterに貞子がどーのっていうTLがあったから
妄想が発展しすぎたのでまとめてみた.



呪いのビデオって今もらっても再生できる機械がないよね

ぶあついブラウン管はまだしも,薄型液晶から出てくる姿はちょっと横から写メってみたい

テレビの前に押しピンばらまいてたらどういう反応するんだろう

ノートPCで再生して出てくる直前にたたんでみたい

っていうか11"のノートPCで再生してこの画面サイズから出てこれるのか??

呪いのDVDならリッピングしてピンクなタイトル付けてP2P放流したい

やっぱりコンポジット接続した機器から出てくる貞子とHDMI接続した機器から出てくる貞子とではHDMIのほうが綺麗なのかしら?

コンポーネントでRだけ挿したら真っ赤な貞子が出てきてシャア専用

高層ビルの窓にテレビを設置して呪いのビデオ再生したらそのまま落ちていくのかしら? いわゆる出落ち

ひょっとして画面サイズで出てくる貞子のサイズって変わってくるの?7"だと手のりサイズ 50"だとハルクサイズ

そもそも表示装置に接続せずに呪いのビデオ再生したらどうなるのかしら?

プラズマテレビだと電気属性に仕上がります

コンポジットをそのまま分配して再生すると貞子が増殖します その代わり1体1体がより暗くなります

貞子がもし二酸化炭素を吐くんだったら呪いのビデオとVHSデッキを火星に送ってエンドレス再生しておけばCO2による温室効果でテラフォーミングまでできる

貞子にもし人間と同じ程度の質量があるのならVHSを回転させる程度の電力で50kg弱の質量(アミノ酸で構成)を生成できる これは物理学に光明が差す

貞子にもし人間と同じ程度の質量があるのならテレビの前にカタパルトを設置,貞子が生成されたら射出.これを繰り返すだけでローコストなロケットランチャーが実現します.

ビデオラインをGND直結したら貞子はどこへ行かれるのだろう

ビデオラインにOPアンプによる反転増幅回路を組むと貞子が左右逆になるのかな

DLNA配信するとWiFiに乗って宙を飛ぶ貞子が!

2画面表示だときっと悲しむよね…


どうやら貞子というのはエネルギー問題に終止符を打てそうな技術のようです

2012年4月26日木曜日

Android WidgetでonUpdateが呼ばれない

@ITのAndroidで動く携帯Javaアプリ作成入門第10回など
何箇所かでサンプルを見ながらコピーコーディングしてたんだけど
一部のサンプルウィジェットが動作しない.
コーディングが悪いのかと思い,サンプルファイルをインポートしてエミュに送っても
やはり動作しない.

どういうことだ.

と思ってたら
原因が判明.
@ITの例でいくと
AppWidgetExamples\res\xml
slide_show.xmlにある
android:updatePeriodMillis="10000"
こいつ.
updatePeriodMillisってのは
ミリ秒単位で指定した間隔毎にonUpdateメソッドを呼ぶ
という時限更新用の設定なんだけど
Android SDK1.6以降では最小値が1800000となっている.
すなわち30分.
もちろん値に0を指定した場合は時限更新ナシにできる.
が,1~1800000に設定した場合は自動的に30分になってしまう.

Android SDK1.6以降ということなので
実質的にupdatePeriodMillisで30分以下は設定不可能.
updatePeriodMillisは使うな,AlarmManagerを使えということらしい.

updatePeriodMillisの残された使い所としては
3時間ごとに画像を変更するとか
1時間ごとにRSSを自動取得するとか
30分ごとに人工無脳が適当な言葉を話すとか
そういう長周期で眺めるウィジェットとかになりそう.

2012年4月24日火曜日

修復

ンダ付け修復

なんか接触悪かったから再度開けてみて
見てみたら一本線が浮いてたからハンダ付けしなおし.

さすがに13本密集してるからなぁ.

というわけで更に13本全てに布テープ巻いて絶縁.
そうしてこういう状態に.

これから蓋をしていく.
まずはスポンジをひく.
もちろん絶縁用.
コンビニで買ってきた台所用のスポンジを薄く切った.

基盤の上には黒いスポンジを置くよ.
これはGK-3に付属してた奴.

そして
バックパネルを留める.
ちょっとジャックプレートつける位置下すぎた.
写真下側のネジが干渉してる.

表側は
こうなった.
二連ボリュームにはそれ用のノブをつけた.
ボリュームは上がノーマルピックアップ用,下がGK用.
真ん中のスイッチはそのままノーマルピックアップのリア/フロント切り替え.
下のスイッチはギターシンセのパッチチェンジ用.

苦労の甲斐あって全て動作するよ!
なんかGK用のボリュームが9時〜10時くらいのところで一瞬マックスになる
意味不明な不具合もあったりするけど…

次はベースにGK-3Bつけたいなぁ( ´∀`)
でもうちのベースさんはもっとつけるの困難だろうな.
ピックアップとブリッジの間があいてないから.
そういうわけで〜

2012年4月21日土曜日

ギターハンガー

なるネタ

やぁ(・∀・)
やることを終えて今は録りためたアニメを消化しようと頑張っています.
MXでやってたダブルオーがいきなり2期だったのでちょっとがっかり.
沙慈はちょっと自重したほうがいいと思う.

そんななか,昨日届いていたモノを今日受け取りましたよ.


ターハンガー

皆様はギターをどうやって保管していますか?
まぅさんちはこんな感じでした.


warwickのギタースタンドです.


それを今回アップデートしました!




縦に吊るしましたよ.
warwick→ハーキュレス


これで縦に積めるようになりました(・∀・)
予想以上に面積とる…
でも取り出しやすいようになったし,
ネックへの負担が軽減されるようになりました!

ちなみにMarshallのベーアンにかけている奴

こいつですよ.
これはどう転んでも無理.
さすがにヘッドレスはハーキュレスには対応しませんねぇ.

まぁこれは本物のSTEINBERGERではないのでオモチャなのです.
とてつもなく弾きづらいということを教えてくれました.

これはそこらへんにたてかけておくことになるようです.

吊るしたほうが保管にはいいので複数Gt,Ba持ってる方は検討してみては.
オヤスミナサイ(・∀・)

完成させた(やや不安)

きたよ

やっとできた.
昨日言ってたのは確かだった.
ちゃんとシンセの音は出ていた.
あとはパッチチェンジ.

パターン切ってたからその先にあった
表面実装抵抗に導線を直付け.

なんか今回でハンダ付け性能がトランザムした気がしてきた.
これまではユニバーサル基板にもろくに付けられなかったんだけど
だんだん上達してきた気がするよ.
んでこんな感じに.
後ろのクマがぐでーってなってるのは気にしたら負けな( ・ω・)

本当にキャビティ内がギリギリだから
いつ断線するかわからない状況なんだけど.

ギリギリというか無理矢理詰め込んだ感じ.

背面側はこんな感じ.
どすか(・∀・)
これで今回のまぅさんの地獄の工作は終了.
本当GK-KIT-GT3が市販されてたらなぁって思う.
基盤が無駄に大きいんだよ!




パッチチェンジもできるようになった.
音量もコントロールできる.
当然1弦から6弦まで出力される.
これで今回の組み込みは終了だね(・∀・)
本当に プロの人に頼めばよかった…
まぁエンジニーアとして上達できたからいいか.

あとでまとめると思う.
(・∀・)(・∀・)

2012年4月20日金曜日

回路デバッグ(´・ω・`)

日の作業

どうやら昨日言ってた「後日に仕込んだネタ」は今日届いていたようで.
まぁ受け取れなかったんだけどね.

今日は回路デバッグをしていたのだよ(´・ω・`)
まずは2連ポットから.
2連の上の方をノーマルピックアップのボリュームに充てたはずなのに
下を回したら変わったので
上下逆にハンダ付けしていたようでござる.
(ちゃんとテスターで確認してからハンダ付けしろよな)
そこは上下逆にするだけなのでかんたん.

もう1つ.
VGの音は出るのにシンセ音がでない問題.
これはボリューム周りの問題だと判断.
基盤見てみたらここもパターンが切れてた.

なので,パターンが切れてた穴は諦めて
その先につながっているところにハンダ付け.
うまい具合にテスト用?か裏表通し?のための半田がのってたので
そこにハンダ付けしたんよ(・∀・)


それから一番のネックっぽかった13pinコネクタ.
これは一旦全部半田外して付け直し.




音は確認してなくてGR-33のチューナーだけで確認をしたんだけど
どうやら音は出てるっぽい.

あとは今日チェックしてないパッチチェンジスイッチ.
これを明日やって終わりかなぁ?
終わってくれたらめでたしだね(・∀・)

パッチチェンジってサブだと考えると
実質もう使えるようになってるはずだけどね.

うっしがんばるぞ(・∀・)

2012年4月19日木曜日

D3200きましたよ

D3200きたああああ

NIKONから新しいデジタル一眼レフカメラD3200が発表されましたよ.
かねてから4/19に発表されるという噂のあったD3200ですが
噂通りに発表されました.

某掲示板では昨日のうちに某Bカメラからと思われる画像がリークされていましたが
その通りのものが出てきました.


タログスペック

イメージセンサ
そりゃ詳細はニコン様のページを見たほうが早いですが
初心者的に目に付く変更点を挙げていきます.

なんといっても大きいのがイメージセンサ.
D3100の14.2MPから大幅アップの24.2MP.
イメージセンサがお下がりとかではなく新規になっているんですね.

高画素化されたので出力サイズがLで6016*4000という巨大なものに.
D3200のサイズMがD3100のサイズLとほぼ同じ.

高画素=正義 というわけではありませんが,これは大きな変更です.
高画素病初心者には惹かれるものがあるのかもしれません.

連写枚数
なんと連写枚数が130%に!
D3100が秒間3枚だったのがD3200では4枚/秒になっています.
パシャパシャしてみたい人にはいいですね.
動物やスポーツを撮るわけではないまぅさん的には全くどうでもなんですが.

常用ISO感度
D3100から1段階アップで6400まで.
高画素化で高感度化に成功したのでしょうか.
夜景を撮ることも多いのでこれは良い感じに上がっています.

背面液晶
って肩液晶がないから背面液晶のみなんですが.
サイズはD3100と変わらず,だけどドットピッチが上がりました.
D3100では3型TFT液晶,約23万ドットだったのが
D3200では3型TFT液晶,約92万ドットに変更されています.
撮影プレビューがより詳細に見れるようになり,
いざ現像するときに
「よくみたらピントずれてんじゃねーか!撮影しなおしておけばよかった!」
っていうことが抑えられるかもしれません.
ただ,直接のライバルになるキヤノンのKISS Xシリーズでも搭載されている
バリアングル液晶(動かせる液晶部)は搭載されていません.
でも後述しますがバリアングル液晶が不要になるような機能がオプションで搭載されています.

大きさ・重さ
大きさは横幅が1mmだけ増えています.
縦と高さは変わらず.
重さはD3100からそのまま.
進歩しているのに大きさ重さ据え置きというのは正しい判断だと思います.
その代わりに実装を諦めた機能もあったでしょうが,
D3X00はビギナー・ライトユーザー向け.
気軽に持ち運んでもらって一眼レフの楽しさを覚えてもらう機種なんですね.
でもちょっと驚きました.

色は
色はD3100同様ベーシックな黒とガンメタな赤.
ただしD3200では初期ラインナップで赤が入っています.
D3100では追加カラーだったんですよ.
この赤.パナとかキヤノンとかでも出していますが
この形状に合わないような…
なんか初期の携帯電話を見ているかのような感じがします.

外部マイク端子追加
個人的にはこれが大きいです.
内蔵マイクももちろんあります.
だからD3200だけ持って出て録画/録音することもできますが
より綺麗な音で録りたい場合には外部マイクを繋ぐことができます.
D3100にはありませんでした.まぅさん所持のD5000にもありません.
バンドの録画をするときにはミキサーからライン直で録音することが可能になっています.
うらやましい.


では…

その某掲示板で言われていた噂に
D3200はペンタプリズムが搭載される
っていうのがありましたがコレはガセでした.
ペンタミラーのままでしたね.


の他機能


今回,D3200と同時にWU-1aというものも発表されました.
これはD3200にWiFi機能をつけるオプションです.
このWU-1aを接続することでAndroidスマートフォンにその場で画像を転送することができます.
家に帰るまでmixiやTwitterにアップロードするのを待つ必要がなくなりました.
ノートPCを持ってカフェに駆け込む必要もなくなりました.
撮ったらすぐにスマートフォンで一眼レフの画像をアップロードできるのです.

もうひとつ.このWU-1aを使うことでできる機能があります.
スマートフォンからのリモート撮影です.
スマートフォンのカメラで撮影するような感じでD3200で撮影できます.
使い方にもよりますが,これがあればバリアングル液晶はなくても大丈夫ですね.


今のところD3200単体(レンズなし)での最安値
76,300円になっています.
D3100の初値が64,800円になっていたようなのでやや高いですね.
そんなD3100も今は最安値が35,000円を割り込んでいるので
ビギナーはD3100を狙うのもありかもしれません.

とりあえず…
D7100の発表はよ!

ううう

たばってました

いろいろと理由はあるんですが
一番の理由は一発で音が出なかったこと
完璧にくじけてました.
かといって開腹状態で放置するのも可哀想なので
そろそろ修理してやるです!

という感じで実はまだ完成していないのです.

それから全然進んでないので回顧録的な感じで.


作確認

動作を確認したときから挫折が始まりました.
まずGR-55とケーブルで繋いだ時に基盤直付LEDが点灯するかどうか
…これはちゃんと点灯した.
どうやら通電はしているようだ.

音を確認しようとアンプに繋ぐ…
ノイズの嵐.
なんじゃこれ.
弦はまだ張ってないけどもう一本ギターをくっつけてそっちの弦を鳴らしても音が鳴らない.
はいアウト(´・ω・`)

ついでに他のコントロールも試してみるけど
ボリューム⇒反応なし
パッチチェンジ⇒反応なし

全て接続確認 決定.

うわぁぁぁ
そりゃパターン切ったらこうなるわな.
次回のことも考えてちゃんと半田吸い取り器は買っておこう.
吸い取り線だけじゃダメだ.


置を経て

その間にいろいろとあったのですよ.
プライベートだろうがビジネスだろうが.
いろいろとリセットボタンを踏んでみましたさ.
おかげでようやくモチベーションが回復してきたので
昨日くらいから回路デバッグに着手.

めんどくさくて使わなかったテスターも発掘.


を張ってみた

弦を張ってみた.
音が出ないハズなのに何故か出るパッチがある…
どういうことだろうと設定を見てみたら
VGの設定をしているパッチのみ音が出ている.
シンセの音はでていないけどギターシミュは出ている.

ディバイデッドピックアップも一応出力しているみたいだ.

何故だろうと出力切り替えスイッチを切り替えてみたら
一瞬だけ音がでるタイミングがあった.
まったくいじっていない回路のはずなのにどうしてだろうか.

もう1つ.
ノーマルピックアップのフォン側はちゃんと音が出るかな?と思い
ジャックに接続.
ちゃんと出る.
ピックアップ切り替えもOK.
ボリュームは…
あれ?下がらない
と思い,ギターシンセ用のボリュームを下げると下がった…

泥沼決定.


ちょっとしたネタを後日に仕込んでいるので
それまでに方を付けたいところであるのだよ(`・ω・´)


明日からは
・13pinを全て半田付けし直す
・ボリュームポットの再接続
です(´・ω・`)


係ないけど

明日はNikonが発表会を開くようで.
D3200なんだろうけど一応楽しみ.
D7100はよ
去年の11月くらいから買い換えようとしてるのに
タイの洪水の影響でD7000の在庫も悪いし
買い換えられなかった.
18-300は700g以上という噂なのであんまり.
まぅさん所持のタムb008でいいや.

2012年4月2日月曜日

裏面は

面も漸進…

表面はね,あと2連ポットにノブつけて
弦張れば終わりだよね.

でも裏面ほっておいたら
裏面がずるいーって泣き叫ぶから裏面も進んでみたよ.


イン基盤切断

最初に已む無しって言ってたアレだね.
ぶった切ってやった(*´ω`*)

斬るところはギター用フォンジャックがついていたところ.
ここらへんは全部アース行きだから気にせず切ってしまえ!
※出音は確認してないので結果はどうか知りません
切り方はこれまで通りプラスチックカッターで削る なんだけど
プラスチックではないから結構硬い.
時間はかかるけど急がずゆっくりと
決して走らず 急いで歩いてきて そして早く僕らを 助けて
削って削って

いい具合まで削れたら折る!
下手すると基盤が死ぬ(ヽ'ω`)

まぁパターン切ってしまったっぽいひとに言われたくはないよね




まぁまだ完成じゃないんだけど
こんなかんじでドスカ(*´ω`*)

メイン基盤入ってないように見えるけど
一応ギリギリ入るよ.

っていうかマジ
ギリギリ

これでアウトだったらどうするんだって
どうしようもないよね.

とりあえずこのまま埋めるつもり.


作業

・バックパネルの穴あけ
・回路デバッグ

もう大詰めだね(*´ω`*)
一発で音出るといいね!

…絶対無理だけど

リアピックアップエスカッション制作

実に前進 …漸進

ちゃんと進んでいきますよ(・∀・)
まずはリアピックアップのエスカッションから.

実はGR-55というかGK-3にはいろんなギターにマウントできるように
いろいろーなアダプタがついているんよ.
ただ,まぅさんちのギターさんはそもそもの前提でお話しした通り
リアピックアップとフロイドとの隙間が殆ど無くて
ディバイデッドピックアップを入れれる状態にはなかったのだよ(ヽ'ω`)

http://noizy-radio.blogspot.jp/2012/03/gk-3.html
このへん参照

カアイソウ(ヽ'ω`)

まぁ先ずはフロイドを削るわけにはいかんので
リアピックアップエスカッションを削ることになった.


アピックアップエスカッション改造

リアピックアップエスカッションだとしてもオリジナルを保ちたいので
改造用のエスカッションをこれまたS石2号館2階で買ってきた.
あそこはギター用パーツがいろいろあるね.

バックパネル作成時同様にプラスチックカッターで削りまくったら
こんな感じに.
できればディバイデッドピックアップまで伸ばしたかったんだけど
ネジ穴の限界で多少スペースができてしまった.

エスカッションをぶったぎってもフロイドとリアピックアップとの間ぎりぎりに
ディバイデッドピックアップが配置されたんだってのがわかるよね(´・ω・`)

で,ディバイデッドピックアップのケーブルがどういうふうにでてるかというと
こんなかんじ.

これはドリルをつかったんじゃなくて,
棒ヤスリセットの丸いやつを使った.
こんなん使うかよwとか思ってたんだけどめっちゃ使ったわ.
しかも径ぴったし.

今のところ表面はこんな感じ.
とりあえずは暫定的にディバイデッドピックアップは両面テープで貼りつけてるよ.

だんだん完成形は見えてきたかな?
続く!