疼いて泣いた あの日の記憶を
君はひとり眺めていたね
後ろ髪引っ張ってたって
仕方ないだろう、綺麗だけど
想いを畳んだ 思い出になった
きらきら刻んでいた
僕の鼓動 届かないまま
分かっていたんだ 君の声に
「また笑おう」って言うだけ
泣いているよ また まだ
買いだめの天然水切れそうだなあ
洗濯物もそろそろ限界だなあ
いい加減 窓くらい開けようかなあ
ちょっとくらい涙も乾くだろう
ローソクの灯はまだ点いてんだなあ
思い切り吹いて消したんだけどなあ
こうやって感傷に浸ってんのは
別に君のためじゃない …なら、誰のためだろう
想いを畳んだ 思い出になった
いつしか僕の見ていた
あの景色は変わっていたんだな
分かっていたんだ 君の声に
「もう笑えない」って言い訳
想いを畳んだ 思い出になった
ゆらゆら灯っていた
ローソクは消せやしないけど
想っていたんだ 君のことを
「また笑おう」って誓っては泣いてた
あの日々の僕を愛せるかな まだ まだ
一昨日に TRIALのSmartOD買ってはじめてのスタジオだったんだけど、
JCがめちゃくちゃいい音鳴らしてくれましたね…SmartODやば…
いや正直ちょっと不安になってたんよ。
店でJCで鳴らしたときはいい音だったし、だからこそ買ったんだけど
おうち帰って、GE200でヘッドホンで聞いてみると「なんかちゃうな・・・」ってなってたんよ
SmartODは完全に「アンプを気持ちよくする機械」らしく、GE200だと音がヨイショされないのが原因っぽい？
むむむ・・・まあしかし最高の音だったので・・・スタジオでもっと弾く機会増やしたいなあ
フジゲンのj-classicのテレキャス（JTL6M CAR）を使っています。
買った当時（今年の2月くらい）はジャキジャキきもち～って感じだったんだけど、ギター熱もあがってきて、実家でほぼ眠っていた10年前に買ったエドワーズのレスポSP（E-LS-90LTの白）を持ち出して、今は２本を気ままに弾いている
…せいで、テレキャスのトレブリーさがめちゃくちゃ分かるようになった（幸か不幸か・・・）
最近、benimaruさんのエフェクター紹介動画をよく見てて、この人もテレキャス使ってるのですが、めちゃくちゃ音がいい……。いやそりゃそもそも価格帯がちがうだろうし、その差が出てるんだろうとは思うんだけども（あと音作りの練度も）。どうしたらあんないい音がテレキャスから出るんだろ？確かにちょっとハイ寄りなんだけど、でもキンキンしてなくていいんよね…。
ほんで、benimaruさんの動画見たり、レスポSPのP90の甘いトーンに染まったりしていくうちに、「テレキャスのセンターの音ええやん」ってなってきた。前までは「なんやこの抜けの悪いこもった音は！！？！」とか思ってたんだけど、やさしくていいね、尖ってたわスマン
なんですが、フロントPUの音が小さいので、フロントPUの高さ上げてみよう～と思ってガツンとあげて、同時にリア側も調整することにしたんだけど
リアがわからん！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
フロントPUは高くすることで割と単純に音も大きくなっていい感じになったんだけど、
リアに関しては、高くすればトレブリーで耳に刺さり、かといって低くすると抜けが悪うて「センターか？これ」みたいな音になってしまうのでとても難しかったです（小並感）
なおまだ調整終わっていないもよう
メモがてら、PUの高さと音の関係：
ピックアップ⇔弦が近い
メリット：音量と高域が出るようになりピッキングニュアンスが出し易くなる
デメリット：音量が上がる分ブーミーな音になりがち、高域がキンキンうるさくなるピックアップ⇔弦が遠い
メリット：高域の角が取れてマイルドな音になりピッキングの粗が目立ち難くなる
デメリット：音量・高域共に落ちて抜けが悪くなる
これ見る限りでは、「キンキンになるほど近すぎず、抜けが悪くならないほど遠すぎず」のスイートスポット探せってことだね
うーん、目当てのパラメータはハイのトレブリーさと抜けの良さなので、6弦側と中央で抜けと音量のいいところをまず見つけて固定してしまって、その中でいい感じにトレブリーになるところを1弦側のネジで調整するのがいいのか…？なるほど（わかってない）
この記事書きはじめのときは「ピックアップ変えたほうがいいんじゃね？！？！」って結論に持っていこうと思っていたんだけど、もう少しやりようがありそうなので、ピックアップの話はまた今度やな
いやでも、たとえば、リアにシングルサイズのハムバッカーつけて、コイルタップ機構で器用貧乏するのかなりよくないですか？
ま、たぶんP90の音が一番好きなんやけどね・・・・
P90の甘いトーンをベースにしつつ、ジャキジャキ感をプラスしたようなそういうサウンドを実現するPUないかな～
（前略）
聞き間違いバッファと同じ意味。理論上、単語空間 Xn には Sn だけの単語が登録できるが、 実際には登録された単語と「近い」音のつづりは今後使われなくなると仮定する。
すなわち、単語は単語空間上において点として存在しているのではなく、いくらかの体積をもった存在としてそこに登録される。
単語長 n の単語の排除体積を v_n とすると、単語空間 Xn の充填率は
v_n * Nn / Sn
となる。単語空間 Xn に新たに単語を登録しようとしたときは、自身の体積と、この充填の様子によって「そもそも登録できるかどうか」がきまる。
単語空間の充填率とは全く関係なしに、つまり、今の単語を登録するのに十分すぎるくらい広い単語空間であったとしても、 必ずそこに登録するとは限らない傾向を表現するパラメータ。
実際的な意味付けはできていないが、大きな単語空間では単語分布が幾何的に減衰していくことから、類推されたパラメータ。
夢をもっていえばエントロピーのようなもの。現実的にいえば、分布の分散と関わるパラメータ。
おそらく、形態論的制約、語形禁則によるドロップアウトも、このクオリティフィルターが担っている（語の質が保証できる確率、ということでクオリティフィルターと名付けている）。
単語空間 Xn に登録できる確率（厳密には、それ以前の単語空間では登録成功しなかった事象のもとでの条件付き確率）は、
単語空間（とその排除体積）的に登録可能であり、かつ、冗長嗜好にも打ち勝ったとき
の確率に等しい。
ふつう音韻的に、単語空間は指数関数的に増大していくので、ある程度の単語長（n=4でも十分）では排除体積はほとんど無視でき、 採用確率は冗長嗜好に打ち勝つ確率となる（ゆえに、分布のテールは幾何分布的になる）
この分布生成法では、具体的な単語空間、音韻体系の設定を行わない。
必要なのは、各単語空間の広さ、単語の排除体積（その言語における単語同士の近さの忌避具合）、クオリティフィルターくらいであり、それ以上の構造を要請しない。
非常に簡単なモデルだが、「その程度の定量的パラメータだけで単語長分布が決定したら面白い」という目論見からはじまったので、さもありなん。
Pythonのデータサイエンス寄りのところを再復習してて、飽きてきたので他の言語やりたくなった。
F#, Rust, Nim.......。あげく一周回ってGOをやろう。からの疑問点。
まずは引用を。
レシーバとしてポインタまたは値のどちらを受け取るかによって、次の違いがあります。レシーバとして値を受け取るメソッドでは、ポインタまたは値で呼び出すことができますが、ポインタを受け取るメソッドでは、ポインタでしか呼び出すことができません。これは後者ではメソッド内でレシーバを変更可能であるためです。(複製された値に加えた変更は破棄されてしまうため。)
とあるんですが、go 1.10.3 現在だとそうじゃないっぽい・・・？
package main import ( "fmt" ) func main() { p := &Grid{5, 2} q := Grid{1, 0} fmt.Println(p, q) p.move(-2, 2) q.move(3, 3) fmt.Println(p, q) } type Grid struct {x, y int} func (p *Grid) move(x, y int) *Grid{ p.x += x p.y += y return p }
結果がこうなる：
&{5 2} {1 0}
&{3 4} {4 3}
予想：
qはGrid構造体のポインタではなく値を束縛してあるので、レシーバにGridのポインタ型（*Grid）を指定しているmoveメソッドが弾かれると予想していた。
実際：
通ったし、ちゃんと破壊的変更されちゃってる。
ええ～～～～～～～～？？？
もしかして、値で渡しても関数定義の型に従ってポインタが渡されるようになってるのか…？余計なお世話では…？
と思いきや、こちら（関数形式）で渡すとちゃんとエラー吐くことが分かりました。
func main() { p := &Grid{5, 2} q := Grid{1, 0} fmt.Println(p, q) p.move(-2, 2) (*Grid).move(q, 3, 3) // ここが変更点 fmt.Println(p, q) }
# command-line-arguments .\main.go:13:14: cannot use q (type Grid) as type *Grid in argument to (*Grid).move
「Gridは*Gridじゃないからダメ！！！！！！」ってキレてくる。さっきは優しかったのに！
というわけで、値で渡してもそのポインタを自動的に渡してくれる…という挙動はレシーバ限定っぽい。
思うに、メソッドチェーンを考えてのことかなと（こなみかん）
やっぱ公式を・・・最高やな！（最高ではない）
この記事を参考にしようと思ったら、今はなんかインストーラないっぽい：
というわけでやったこと：
%USERPROFILE%\.nimble\bin も通せってあったから素直に従うこれでハローワールドしたら「gccがない💢」って怒られたのでもう少し読み進めると
The Nim compiler needs a C compiler in order to compile software. You must install this separately and ensure that it is in your PATH.
HAHAHA このパソコンCコンパイラ入ってなかったんか～い
丁寧にもリンクがあるのでそこからmingWダウンロードして Program filesにぶちこんでbinまでパス通す
"Error: cannot open '[...]main.nim'" って言われる。なんで？
さらにもっと読み進めると、DLL入れて❤ってあったのでダウンロードして、Nimのbinにぶちこむ。「もうすでにそのファイルあるけどええか？」って言われたので上書きする。
もう一度。が、・・・だめ・・・・！！
もしかしてVSCodeが悪いんか？と思って、cmdでやってみたら いけるやないか～～～～～い
Powershellが悪いんやろか…まあとりあえずインスコできた
と思ってたらVSCodeの更新きてたので再起動してもう一度したらいけた。なんかあったんやろか？まあでもいいや
Win 10
これがとても助かりました（神）：
基本上に従ってやればよくて：
JULIA_HOME, JULIA_PKGDIR を環境変数に設定して、JULIA_HOMEをパス通すjuliaで起動。プラス、Jupyter で使いたいならもうちょっとだけ続いて：
Pkg.init() からの Pkg.add("IJulia"), Pkg.build("IJulia")Pkg.add("IJulia") でエラー出たけど、書いてある通り、その次の build すればいけた。
