/ ,' 3

https://twitter.com/gorlemkun

2019/05/11 コード楽器完成したもののうまくつかえず、コード楽器ギター版計画

ちょっと眠いので手短に

---

コード楽器は完成して、期待通りに動いてるんだけど微妙・・・。ピアノの一般的なボイシングで並べてみると音の余計な動きが気になって伴奏として聞けないレベルのクオリティになってしまった。ちょっとテコ入れが必要そう。考えられるのは2つ。

- 転回形を駆使して音の上下の動きを穏やかにする
こういう感じ。

f:id:gorlem:20190512032850p:plain

いやーでもこの方法はちゃんとした伴奏なのかどうか裏がとれてなくて、これでいいのかあんまり自信がない。ちょっとMIDIデータを漁ったりして調べてみようと思う。とりあえずの策としてはまあまあ。

- ギターのボイシングで行く
わりと簡単にできて、それなりに成果が出そう感。
弦をつまびいたとき特有の発音のずれはシミュレートしたい気もするけど、最初は妥協でもいいかも

どっちもそれなりに効きそうな気はするので、試してみたい。が、下記のやつのほうが現状欲しいので、コード楽器を現状の状態で公開だけして、下記の開発にあたっちゃうかも。

---

コード楽器のギター版をつくりたいと考えている。INSTRUMENT1というギターまがいの楽器を持っていて、それのコード弾き機能をMaxの力でもうちょっと柔軟にする計画だ。
今の機能だと、1曲あたり全部で13個のコードしかアサインできないし、アサインできるコードの種類も結構貧弱なので、それを拡張したいと思っている。

といっても、やれることはMIDI OUTを受けて出したいMIDIの信号に変換することぐらいなので、まだまだPoCが必要な状態なんだけど、行けそうな道筋は立ちつつあるので、試してみたいと思う。

なんでこんなにこっちに乗り気かと言うと、弾き語りの楽しさに目覚めてしまったのと、出せる音はギターのほうが演奏の制約上本物っぽくしやすいからという理由。いやあ弾き語りはすごい楽しいので、正直こっちを早く実現したいっす。

というわけで、個人開発物はいつ開発終了判断するかわからないので、いつでも開発終了できるようにマイルストーン置いておくことはやっぱ大事ですねとおもいました

---

owari

2019/05/10 Twelve-Factor Appよい、Chromeのパフォーマンス計測の至れり尽くせり感、コード楽器リファクタ、作業前のアニメ視聴が危ない

結構さぼったのであんまネタがない。

---

Twelve-Factor App、昨日の読んだけど、今日また読んで評価がうなぎのぼり。アプリケーション新規開発のときにすごい役立つ気がしている。定期的に見返したいシリーズだわこれ。
全部のプラクティスに沿った形で次の新規開発するアプリは作っていきたいなあと思わせてくれた。
一読するだけだとおーなるほど!みたいな感想しかなかったので、ちゃんと意見が持ててない状態なのでまだ内容への言及はうまくできないっす。

---

https://qiita.com/y_fujieda/items/a0a69151cf7307039f74
これ見てChromeに感動を覚えた。どんだけ至れり尽くせりなんだ。パフォーマンス計測本当に困らないな・・・。サーバーだとなんだかんだ用意するものがあるのでわりとめんどいんだけど、Chromeの整備され具合がとにかくうらやましいという感想だらけっす。
フロントそこまでゴリゴリチューニングすることは無い気がするが、どういう入り口から入ればいいかはよくわかりました。

---

コード楽器リファクタした。コード定義yamlの記法をわかりやすくいじって、重複して存在するオブジェクトを一つにまとめて、Maxの配線をちょっと整理して、、などなどをやった。まだまだ整理したい部分がある。
これ際限なくやっちゃいそうだけど、Maxパッチの質を上げるものなら時間をかけるようにしている。
ここで我慢せずになおしておくと、次作るときにはより洗練した状態のMaxパッチづくりをもう少しすばやくできそうな気がするので。
あと、コード定義yamlのテンプレートのロジックを考えた。こちらの機能もそれほど時間かからずいけると思われる。
残リファクタ、テンプレート機能、サンプル曲用コード定義ファイルが用意できたら、いったん公開記事を書いて、次のアプリケーションに着手しようと思う。この土日でいけるかなー。そろそろ飽きてきたのでさっさと終わらせたい。

---

作業前のアニメの視聴は危険って何いってんだという感じだけど、帰宅して、アニメみて、あ、続き気になる〜つっって続きぼーっと見まくってはい1時間溶けました。みたいなことにさっきなったのでアニメは危険だと思う。
寝る前に見るようにしようかなー。それはそれで睡眠時間を削ってしまう危険性が。こうしてアニメを見る機会がどんどん無くなっていく・・・。
いまのところ確実に観るのは体調悪いとき、疲れたとき、飛行機に乗るとき、実家に帰宅したときくらい。
別にそれほど観たいアニメがあるわけではないんだけど、新しいネタのインプットが無いとなんとなく不安になってしまう。でも見始めたらハマるのでたぶん深層心理的には見たいんだと思う。
付き合い方の答えが出ない。

---

おしまい

2019/05/09 ゆるふわTypeScript、The Twelve-Factor App、MongoDB、コード楽器のベース分離、FLのステップ入力、脳死絵、Google I/O

TypeScriptいいっすね。ゆるふわに書いても動く。もちろん型付きなんだけど。RubyでそれやるとぼろぼろでRSpecの記述量がやばいことになっていつも萎えるんだけど、TypeScriptはシュッと動いてくれるんで、ッッ動いた・・・!みたいな感動を味わえる。今日わりとちゃんと型定義してみてTypeScriptくんへの印象がとてもよくなりました。

---

The Twelve-Factor Appよんでる。あれすごい分量ある本的なドキュメントだと勝手に思ってたけど、12章それぞれが1画面に収まる分量しかないこと、そして日本語化されてることに今更気づいた。さらっと読めるわりにはすごい価値ある感じで、新規開発のときにチラチラ見ると有用だとおもいました。何のドキュメントか説明しにくいけど、Webアプリケーション開発の汎用的なベストプラクティス集みたいな感じです。

---

7つのデータベース7つの世界を読んでて、それのMongoDBの章をよんでる。ドキュメントDBがなんなのか、というかGoogleのDataStoreとFireStoreがなんなのかをよく知りたかったのでそっくりそうなMongoDBがどんなんなのかを見ているというかんじ。いやしかしどうなんだ?MongoDBから見ちゃったから合ってるかよくわからない。DataStoreとFireStoreのドキュメントも基礎がわかるまで程度のつまみ食いはなるはやでやろうと思う。。
なんでそいつらが気になるかというと、クライアントだけでアプリ開発完結できちゃうケースというのが無視できないくらい出てきてるっぽいので、どれほどのもんか気になったというのがきっかけ。あわよくば使ってクライアント開発デビューしたい。

---

コード楽器、あんまり進捗が無いんだけど、コードとベース音の定義分離作業だけやった。
まだ公開まで、というかドッグフーディングまでやらなきゃいけない作業がちょろちょろあって、それをつぶしている・・まだやることがある。

---

コード楽器+ステップ入力がイケてるというひらめきを得たので、FL Studioで試したら、想像通りの挙動をしてくれた。1小節単位とかでバリバリコード進行を入力できるようになったのですばらしい。
求める理想の快適さにはちょっと遠い部分があるので、ショートカットキーをググっている・・が、なかなか出ない。これは長い戦いになりそう。
あ、あったわ。ここの左上。
http://anotherlife.matrix.jp/wp-content/uploads/downloads/2011/08/FL-_Studio_shortcut.pdf
あんまり期待できないみたいですね :innocent:

---

ついさっきまで絵を描いていたのだけど、今色塗りをしていて、とにかく頭を使わない工程なのでなにも疲れないし、無限にコンテンツを消費しながらやれるのでGoogle I/Oみながらだらだらと過ごしてしまった。
絵は線画と影が山場で、それ以外の作業は本当に脳みそが無になってしぬ。1時間で集中力切れるとかいうのは山場の話だったことを忘れていた。線画が終わったので無限に描ける。

Google I/OKeyNoteだけみてる。というか初めてちゃんとGoogle I/OKeyNoteみたかも。意外と作業しながらでも見れるような内容。
カンファレンスの動画、絵を描きながら見るくらいがもしかしてちょうどいいのかもとか思い始めてきている。追うのに時間かかるわりに自分に刺さる情報すくないからいつも処理に困ってたんだけど、これはいい。明日もこれでちゃんと視聴できるのか試してみたい。いまのところできてる。

---

おしまし

Tokyo Rubyist Meetupに参加したよ

これ。

https://trbmeetup.doorkeeper.jp/events/89258

英語のミートアップで、発表も懇親会も英語のやつです。英語の実力テストのために行きました。

苦痛かと思いきや珍しく気を使わず楽しめた!

参加する前まで全部英語なことによる重圧で最後まで参加を迷ってたけど、参加して良かったととても思う。

理由としてでかいのは英語コミュニティ独特?の知らない人を気軽に受け入れる雰囲気。そのおかげで話すことに心理的な抵抗をあんまり抱かなかった。すばらし。

びっくりしたのが9割くらいnot日本人だったことで、なんだここはサンフランシスコか!みたいな気持ちになった。

いやーみなさんとても英語が上手いですね、スピーキング超はやい。でもたまに聴いてるThe bike shedほどには早くはなかったので体感8割くらいは聞き取れた。でもその逃した2割が割と痛くて、その2割で文章の文脈をたまに失ったりするのでまだまだ精度不足だなぁという。それと、8割というのは気を使ってくれて8割という感じで、本気を出されると5割もわかんないと思う。

自分はスピーキングがくっそ遅かったんだけど、話し始めると聞き手のほうがちゃんと傾聴してくれたのでなんとかなった。助かった…。

しかし、自分が言いたいことが上手く表現出来ないタイミングがいくつかあり、そこは単純に練習不足なのでやっていく。

たぶん普段書いてる日記を軽く英訳できるくらいになってくるとかなり戦えそうだと思う。練習しよう。

そして英語の理解に脳のリソースを取られすぎて、相手の会話に疑問を抱くリソースまで持っていかれたので、気軽にリスニング出来るくらいまでリスニング力鍛えられてるともうちょい楽なんだろうなぁ。最近Podcastのリスニングはサボりがちだったので再開しよう。The bike shed聴ければ多分完璧なので諦めずに頑張ってみる。

上記は会話に入れたら、の話だけど、会話に入るのにも結構コツが居る。気づいたときには大体2人ペア、3人ペアが出来てしまっていて、気を抜くとぼっちになる。ので、頑張って話しに行く必要がある。

すでに他の人同士でペアになってしまっていても、どうにか話を聴くために潜り込むみたいな覚悟が必要。と、教えてもらった。これをやるためにも、ある程度のリスニング能力は不可欠だなあという感じ。1on1で会話するときには聞き返せばいいからリスニング能力無くてもいけるけど、複数人の会話だと遠慮が無くなり早くなりがち。ここでついていけるとコミュニケーションの幅がかなり広がると思った。

んまあ英語以前にエンジニアとしてちゃんとやれてないと話についていけないという問題もあるんだけど、それはまた別の話ということにしておく。

非常に英語で疲れたのでこのへんで終了。

2019/05/07 音楽が集中力阻害、集中モードと緩和モード、コード楽器ドッグフーディング、Redditの作曲スレ、絵

In GW, I could sleep as much as possible... but I can not now. I feel so sleepy!!!

いやーねむいですね、明日もきっとねむい。

---

メンタリストDaiGoシリーズ、勉強法の本みてみてるけど、結構気になる研究紹介がいくつかあったのでメモ。

音楽は基本的に集中力を阻害する効果しかないっぽい。特にボーカル曲は最悪。
いやあ薄々分かってはいた。自分の場合、集中力ほんとに無いときはボーカル曲で思考を止めて作業したりしていて、それは今でもそういう使い方はアリかなと思っている。
でも、集中したいときにも歌詞の無いトランスとかかけてて、それまでよくないとはおもわんかった。テンポ早い曲とか良くないらしいっす。
対して、自然の音はすごいいいらしくて、今日は雨音ノイズを流してみた。うん、確かにいいかもしれない。でも雨音だからなのか、湿気とか寒気みたいなものを仮想的に感じた気がするw 明日はもっと無害な音をチョイスしよう。

集中してるときって、勉強にとってはいい状態だと思うけど、それを続けていると応用力が無くなっていくらしい。これもなんとなくわかる。ちょっと集中して、休憩して、のサイクルをたどるようにしないと、勉強したことについて全然自由に考えたりしないから、そりゃ応用力つきませんわ。という感じな気がする。
自分の得意としてもたぶんそっち寄りなんだろうなと自覚していて、普段から習慣としてやっていかないと、自分はなにも身につけられないタイプなんだなと身にしみて感じている。今回でよりあるべき集中の仕方が明確になったのはプラス。

---

コード楽器をドッグフーディングしている。自分で使ってみている。
使ってみるとまあ、設計のときには予期できてなかった文句がわりと湧いてきて、学びがいくつかあった。

I am using my own software "chord instrument". There are some issue that is unexpected before create.

文句その1。BASS音程の指定の仕方をしくじった。ベースもコードの一部っしょ、みたいなノリでコードの一部にベースの音程も入れる設計にしたんだけど、分数コードで場合分け地獄発生して死ぬな?という見込みが立ってしまったので廃止しようと思う。
分数コードというのは、あるコードのベース音だけ変更するとかいうやつで、こいつをコードの一部として考えてしまうと、一つの種類のコードに大量の分数一族が発生して、コードの種類が膨大なことになってしまうし、コードの名前もすごくつけづらくなる。地獄。なのでやめた。
やめるにはベース音を別で鳴らす追加実装が必要で、今せこせこ直しているところ。

文句その2。コード定義のyamlファイル書くのが超しんどい。めんどい。
最初なので慣れの問題かもしれないけど、1曲分の定義ファイルつくるだけでもしんどい感情が湧いてしまったのでうごーーしんどい!!!という感想で頭がいっぱいになった。
記述量が多いのが原因なんだけど、この問題はデフォルト定義を用意することで解決する気がした。音楽理論に則った基本的な曲は8割くらいは調に沿うコードで構成されてるから、調に沿うコードをデフォルトにして、そのコードの記述を省略できるようにすれば、もしかして記述量8割減った??ヤッタ!!!
という感じで、デフォルト用意する追加実装もやっている。だいぶこれでマシになるのか?なる気はする。

さっさと公開するぜ〜みたいなこと昨日書いた気がするけど、現時点でも結構めんどさが見えてるので、目立つやつは一旦つぶそうと思う。公開はその後。

---

Redditの作曲スレが非常にいい感じだったので残しておく。作曲において学んでよかったことって?みたいな質問で、音楽理論とミキシングという反応が多かった。これはとても頷ける。自分もそう思う。さらに大事なのが、色々教材をリンクしてくれてるということで、ちょっとこれはじっくり見ておこうと思う。リンクされてる教材のほとんどは知らなかったので、結構たのしみ。
https://www.reddit.com/r/FL_Studio/comments/ble6jo/what_was_the_one_thing_you_learned_while/?utm_source=share&utm_medium=ios_app

---

絵を1時間半くらい進めた。1時間超えたあたりから集中力激減してくので、自分の一日に集中可能なラインってそこぐらいなのかなーと最近思っている。これまで日記を先に書くようにしてたので絵は描けてなかったんだけど、日記を後にすると合計時間はぜか一緒で絵の進捗だけ追加されたみたいな感じになった。なんだこれ。

まあ日記はあんまり予期しない感じで書いてしまうので、それが際限なく時間を食ってしまい、絵の時間まで食ってしまったということと理解しておく。

---

平日、仕事あるし大して書けないと思ってたけど、書けたわ。おしまい

2019/05/06 コード楽器がやっとできた、Binary Search Treeちょっと、これからの世界〜本、歯の詰め物を詰め直した

やーっとコード楽器が完成した。yamlで定義したコードなら指一本で弾けるようになった。せっかくそれ単体で使えるパッチとして成立したので、GitHubに公開して記事書こうかなと思う。

それほど大したことないアプリだし、既存でそういうのはあるって十分に分かっているんだけど、今回はのちの拡張も加味してつくっているというところが大事。

スピード優先するならすぐ次の開発フェーズに移行するべきだろうけど、今回久々の個人開発なので、いつ途切れるか本当にわからない。なので、ちょっとでも成果としてまとまったら、開発速度が落ちても公開することを優先しようかなと思う。そうしておくと、もし開発が止まっても成果は残り続けて色々と都合がいい。

まずはソースコード(というかMaxパッチ?)をGitHubに公開して、記事書いて、その後なんらか1曲伴奏を弾いてみようと思う。実用的な実装をしたつもりなので実演まではいきたい。

しかしずっとコード楽器の実装に集中してしまっていたので、次の計画を忘れてしまった。なんだっけ?

---

Binary Search Treeの続きをほんのちょっとだけやった。練習問題のひとつも解けなかった。
Pythonのコードを場当たり的に書いてしまっていて、あたらんなあ・・・。みたいなことをやっちゃってたんだけど、この姿勢、今となっては良くないと思う。
理想としては多分、このBinary TreeはBST(Binary Search Tree)の条件を満たしているのか?を考えうる場合を書き出した後に、それを条件とするプログラムを書くべきだったんじゃね?とちょっと反省した。なので次からは紙とペン(iPadとPencil)に書き出してからプログラムを書くことにします。

---

落合陽一のこれからの世界〜本、相変わらず面白く読めている。「思考体力」の話が結構ぐさっと来た。

どうしてぐさっと来たかというと、こう、一点を考え抜いて深めていく、みたいな体験をサラリーマン始めてからそんなに出来ていなかった気がとてもするからで、個人開発また始めて、ちょっと戻ってこれたかな。という感じ。

大学居たときのほうがよっぽどあらゆることを考え抜いていた気がしていて、ちょっと楽をしてたなーと反省した。サラリーマンとしてやっている仕事がよくないという可能性もあるけど、それはそれとしてもうちょっと頭使えたよなーみたいな場面が結構思い当たる。ぐぬぬ

それと、世界を相手にするスモールビジネスの話がいくつか出ていて、なるほどー!という感じなんだけど、こういう例が身の回りの見聞きできるところにあるのがひたすらうらやましいなあという。
多分そういうコミュニティに所属してないと聞けないような気がする。そして自分はそういうコミュニティになじめない気がする。ぐぬぬ

あと自分に一見関係ないジャンルでも、そこで起こったことを自分のフィールドに適用すると、問いが立てやすい的な?ことを聞いてなるほどなと思った。なるほどなと思ったけど実践できるかなこれ?現状だと非常にあやしい。

とかなんとか書いてたら読み終わっちゃった。いい本でした。研究の基本姿勢みたいなもんが学べた気がする。

---

ちょっと外れるけど作曲のコミュニティとかそういえばあるのかな?初心者のドローイングコミュニティはこの前Redditで発掘したんだけど、作曲のそういう情報が流れてくるコミュニティはそういえばウォッチしてなかったかも。自分に刺さる情報がもしかしたらあるんでは。

チラッと探してみたけどこれとか面白い。自分の曲をアップロードして意見交換したりする場がある。まだ自分はこういう情報を探しに行くフェーズには無いけど、いずれ使う選択肢としてはありかも。
https://www.reddit.com/r/WeAreTheMusicMakers/

---

歯の詰め物を詰め直した。おわり。

2019/05/05 Binary Search Tree、落合陽一の本、コード楽器の実装、歯の詰め物が取れた

今日のLeetCode。Binary Search Treeの概要と、Pre-order, In-order, Out-order, Post-orderがどういうことを示しているのかを学んだ。それだけ。
新しい概念だったので追っかけるのに時間がかかったのと、なぜか英語で学んでしまったのも時間がかかった理由。でも意外とわかるもんではある。Wikipediaの役立ち方がすごい。英語版めっちゃわかりやすい。
このタイプのやつ、毎日ちょろちょろ学んでいく以外に学ぶ方法ないんじゃないんだろうか・・・というのは思う。一気に学ぶとなるとだいぶつらいと思う。なんかこういう性質は英語っぽいな。

---

ホリエモン&落合陽一「働き方」がひじょうに草だったので、落合陽一のこれからの世界をつくる仲間たちへ を読んでみている。
人を驚かせるのにレベルが存在する。という記述にハッとした。本によると

---easy---
- きれい、美しい
- ヤバい、すげえ
- 楽しい、笑える
- なんだかジーンとした
---hard---

という感じらしい。まじか!と同時に確かに!と思った。
きれいとか、美しいとかは確かに丁寧にやりさえすればOKで、絵とかまさにそれ。あんまり経験なかった自分でも最初から誰かに気に入られる絵が書けるのは、絵で驚くハードルがそれほど高くなかったからなのかもしれない。
よりhardな感情を持たせるには?と考えたときに、あー結構これは難しい問題だなと感じてしまった。

そして形式知(明文化されていて誰にも適用可能な知見)ではなく暗黙知を貯めましょう。かー。なるほど。確かに本やGoogle検索した程度の知見はまったくもって無価値と言われれば、確かにそうで、自分で見つけた問題に対する解決策を開発してかないと、今後は価値になっていかないというのは、それはそうだと思った。今やってる個人開発がそういう課題解決につながっている気がするので、それは生活のプライオリティの一番上に置くべきなんだよね多分。やっていくぞ。

---

コード楽器を実装している。コード進行の情報をどうファイルに持たせるか?はもう決まっていて、今日はそれをどうやってルーティングしてMIDI Outまで持っていくか?をゴニョゴニョしていた。全部実装要素みえたので、あと結合するだけ。みたいな状態まで持っていけた。
コードの構成音って、3音だったり4音だったりするんだけど、実装に使っているCycling'74 Maxでそういう可変の値をうまいこと減らしてデータフローを作ってくのが結構難易度高かった。
難易度を高くしてたのはデータ型の扱いがガバガバだったりするところで、例えばunpackオブジェクトに0のargumentを指定するとintegerの値をunpackは期待するんだけど、symbol型の値を入れたときにも0のメッセージを送信してきたりする。いやsymbol来たんだったらメッセージ出さないでよ。あるいはsymbolそのまま吐いてよ。え?そのオプションないの?みたいな。(今回はsprayオブジェクトで代用した)
こういうので結構悩んだけど、なんとかなった気がする。明日には完成させたいなー。
個人的にはもうちょっとすばやく完成するかな?と思って立てた開発テーマだったけど、予想の10倍くらいはかかってるかも・・・。不慣れな技術スタックだから?今後は慣れてきてスピードアップしてくれるんだろうか。

---

歯の詰め物が取れた。やる気全焼失。明日歯医者いきましょう。がーん。なので英語は今日はなし。またあした。

あ、ちょっとだけ英語。歯の詰め物が取れたは、
The filling in my tooth for the treatment came off.
というらしいです。