動画見てないけど、横押しっぱなしとかで出来るって事かも？＞＜
テラリアのトロッコデジタル回路とかみたいに操作無しではできないよね・・・？＞＜
動画見てないけど、横押しっぱなしとかで出来るって事かも？＞＜
テラリアのトロッコデジタル回路とかみたいに操作無しではできないよね・・・？＞＜
スーパーマリオメーカーはチューリング完全 | スラド サイエンス https://science.srad.jp/story/19/07/16/1317217/
・・・・・・＞＜
気象庁 | 週間天気予報： 埼玉県 https://www.jma.go.jp/jp/week/317.html
インクリメントは、Delphiメインに使ってた時は、Pascal系のなにかの読み物の「インクリメントは正しくない！！！ hoge:=hoge+1; の方がいい！」みたいな記述を理由を忘れたまま覚えてて「そうなのかも＞＜（駄目な信者）」って感じだったけど、
時が流れ、CIL(MSIL)を弄って遊んでた時には「スタックマシンにこそ高速化の為にインクリメント命令つける方がよくない？＞＜；」になった＞＜（じゃないとループ書く時とかにものすごく処理増える＞＜；） 同じスタックマシンなVMでもJavaVMにはインクリメント命令あるっぽい＞＜
「書き方によって速度が変わる」べきでは無いのであれば、プロパティでもメソッドでもメソッドのなんか名前の付け方がどう（？）でも変わるべきではないんだから、つまり「プロパティは軽くなければならない（？）けどメソッドは重くてもいい」みたいに考えることもおかしくない・・・？＞＜
賢くないからこその戒めであり枷かも＞＜
「（メンテめんどくさい；； こんな目先しか考えなてない仕様にするんじゃなかった；； 次に何か作る時はちゃんと作ろう；；）」って＞＜
内向きと外への約束ってきっぱり分けて考えていれば自然にそうなるはず＞＜
動的型付け環境が「そんなもの好む人が本当にいるなんて信じられない！！！＞＜」って思うのも、「外への約束がそんな曖昧でいいの！？＞＜； ていうか何も約束してないじゃん！？＞＜；」って所かも＞＜
将来を見越してというか、「公開してしまった約束は死ぬまで守れ！！！！！＞＜＃ 」ってオレンジが普段いろんな話題で言いまくってることそのまんまかも＞＜
約束を死ぬまで守るために隠蔽して、あとでなにかあってもエミュレートして互換性を保てるようにする＞＜
互換性を保てなくなったら「私は目先のことしか考えていませんでした」って札を下げて土下座して謝る＞＜
このアカウントは、notestockで公開設定になっていません。
後からアクセス制限をかけることが絶対にないと確信・断言できるメンバ変数なら外出ししてもいいと思うけど、ライブラリでそういうのってなかなかないのではと思う
まあ、どこまで将来を見越して設計できるかの勝負みたいなところはあるけど
https://mstdn.maud.io/@orumin/102455097216663974
私は15年前に自我がなかったのでよく知らないけど、構文の一貫性とか、後から値のセットで validation を付けたくなった場合などのことを考えると、その可能性のあるものは最初から関数の getter / setter を用意しておくべきだろうという立場
そう，昔 Java で論争されてたときも，validation とかのために，あとカプセル化の観点から setter/getter は全てのメンバに付けるべきでメンバは全て private でやれという話があって，これに対して，絶対 setter/getter を付けるべきとかじゃなくて，フィールド外出しでいいやつは setter/getter つける必要ないし，setter/getter が本当に必要なときにはもうちょっと気の利いた命名できる場合がほとんどでしょ，という反論があって，私は後者の立場だった
ていうか、プロパティでは無い単なる習慣でしかないgetter setterって、存在意義謎だし、プロパティが無かった事がオレンジがストレスすぎてJavaを本格的には使えなかった2大理由のひとつ＞＜
（もうひとつの理由は演算子のオーバーロードが無くてBigIntegerみたいなのが愉快な事になってしまうこと＞＜）
Delphi / C# 方式プロパティが好きな人、呼ばれる側が賢くあってほしいみたいな発想があるのかもしれない＞＜（サンプル数1）
オレンジの場合で、（Delphi / C# での）プロパティが返すものを予め準備するか否かはケースバイケースで、例えば最初に呼ばれた時に用意して、次回からはキャッシュしたやつを返す、再計算が必要な時にも用意したり用意しなかったりする
みたいに、呼ばれる側が自動でいい感じにいろいろしたい時は、むしろプロパティじゃなきゃ気持ち悪い＞＜
手動でそういうの制御できるようにもしたい時には設定用のプロパティを作ったり、明示的に準備させるメソッドを用意したりする＞＜
オレンジ的には隠蔽するんだから、重いかもしれない可能性も含めて隠蔽される（隠蔽されてしまうけどそういうもの）みたいな考えだった＞＜
そういうのを含めてストレージの隠蔽をするために getter, setter を定義するのでしょう。じゃなかったらフィールド外出しでいい
もちろん、その処理自体は O(1) であることが期待されるし、そうでない構造をバックに持つべきではないですが
Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと
C# の文脈だと
public string this[string key] {
return this.dict[key];
}
が存在するので別名を付けたくないモチベーションはある
平均tじゃなく最大値、最小値だってそうだよね＞＜
「そういうの一切プロパティにするな」ってそれプロパティ畑（？）の人っぽくない＞＜（プロパティー畑（？）であるDelphiが好きな人です＞＜）
例えば平均値を返すプロパティは存在していいのかみたいな話・・・？＞＜（「呼ばれてから平均を調べる可能性があるならプロパティにして欲しくない」みたいな話かも？＞＜）
そういう話じゃなく、実際の処理が重いかどうか、場合によっては予め返すものを用意してるか否かがみたいなのが不安なのが問題って話じゃないの・・・？＞＜
さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで，基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども
100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ？
メソッドでも軽いか重いかわかんないけどメソッドは重い覚悟をする（？）みたいな感じ？＞＜； プロパティも同様に考えればよくない・・・？＞＜
プロパティだと中味の処理が軽いか重いか、何らかの結果をキャッシュしたりしてるかしてないか、そういうのが不安というか、「プロパティの方が軽いことを期待しちゃう」みたいな意味かも・・・？＞＜
代入式が使えるプロパティより、 GetHoge, SetHoge メソッドの形式を推すのは、どちらにしてもメソッド呼び出しだからです。メソッドの契約は名前だけ（言い過ぎ）であって、内部の実装はなんでもいい、例えば通常の変数へのアクセスより、その getter のほうが 100 倍遅い可能性だってあるわけで、それをばんばか使われるわけには行かない。そういう意味で、メソッド形式であるべきで、呼び出した結果は、呼び出し元がしばらく持っておけと思うわけです。
GetHoge, SetHoge 方式だと、プロパティ方式よりもコンパイラがバグを見つけにくいかも？＞＜
プロパティ自体はあんまり好きじゃなくて、 GetHoge, SetHoge のほうが好きなんですけどね。メソッド呼び出し感があるので。それはそれとして自動実装プロパティは、 public メンバーとしてあるべき契約のあり方（つまり getter, setter。値を記録するストレージを隠蔽する）でフィールドを公開できるという点でうまい
getter, setter が必要か、わからないから必要なのであって、そういう意味で自動実装プロパティというのは正解
たとえば
*foo(a, b) += 1;
のような式は += がないと一時変数を用意することになってしまうので、そこはさすがに
++どころか+=すらないPascalさんが・・・＞＜
（Delphiの場合はInc()でインクリメント＞＜ http://docs.embarcadero.com/products/rad_studio/radstudio2007/RS2007_helpupdates/HUpdate4/JA/html/delphivclwin32/System_Inc@.html ）
たとえば Rust でも ++ 演算子がなくて += 1 を使えみたいなデザインだったり、条件演算子がなくて if の値を使えという感じだったりして、あまり本質的でない拡張を言語機能から除外するというのはアリなのかなと最近は思っている
いまさら気づいたけど、単に32bit floatに変換だとDACも32bitじゃないとオーディオデバイスのドライバ内（？）で丸め誤差が出ちゃうけど、24bit-int on 32bit-floatに変換するようにすれば、一般的な24bit DACでも出口まで16bit精度を保てる・・・？＞＜（ソフトウェアは作れるけど検証できる機材持って無い・・・＞＜）
ハードウェア作るの大変そうだけど＞＜；（計測機材でさえほとんど24bitっぽいのに＞＜；）
MSが公式で64bit float入力対応DACを出したらさらにおもしろそう＞＜
WindowsのWASAPIというかWindowsCoreAudio、どうせなら内部64bitモードにも対応したら世の中のオーディオマニアをぎゃふんと言わせられそうだけど、やらないのかな？＞＜
（でも、その意味が理解できてぎゃふんといえるような人はそもそもオカルトに近いオーディオマニアにはならない説＞＜；）
そういえば、前に書いた「16bitの音源をWASAPI共有モードで32bit floatに変換して再生する事で、WASAPI共有でもビットパーフェクトと理屈の上で同じ精度で再生できるプレイヤー＞＜」って、かなり前にエンジン部分は完成してるんだけど、GUI作るのがめんどくなって放置されてる＞＜；（ファイル選択すら無くてdrag and dropだよ！＞＜；）
このアカウントは、notestockで公開設定になっていません。
”のが特徴＞＜”というか当然内部floatで作るのが制度を考えたらむしろ当たり前だと思ってたんだけど、わりとそうでもないことに気づいてわりとびっくり＞＜（音関連のプログラマって、整数精度派（？）がかなり多いっぽさ＞＜）
オレンジが今作ってるオーディオ編集（？）ソフトウェアは内部が32bit float固定で、整数精度にしない事により高精度にするのが特徴＞＜
クリップボード対応機能つけたときに気づいたけど、クリップボード越しに32bit floatなwavを受け付けてくれる無料のオーディオソフトウェアってわりと少ない・・・＞＜
21世紀に出口がラダーDACで音量調節はアナログボリュームのみみたいな奇抜な環境なら別だけど＞＜ そんな機材持ってる変人なんてごく少数でしょ＞＜
あと、（世の中の主流である）1bit DACも、32bit floatで解釈できるようにも作れるんだから、DACも32bit floatにすれば（精度が！！！ってうるさい人を考慮するならさらに内部64bit float化するとか）、音量変えても、元の精度を壊さずに、
理屈の上では16bit intのデータをディザかけずに32bit floatに単純変換して送り込んであげれば、16bit DACでビットパーフェクト再生（）してるのと同じ事になる＞＜
@hadsn うん＞＜ ていうか32bit floatでも仮数部24bitあるんだから、ちゃんと整数精度にしたい！って人であれば16bitのデータなら元の精度のまま表現できるかも＞＜
（で、そうじゃない人でも精度が下がるだけで波形はそれほど壊れない＞＜（（リミッタなしでは）機材が壊れるほどに極端なデータとかにしたら別だけど、それでさえも再生時に対処できる＞＜（精度はすごくあれだろうけど）））
@orange_in_space なるほど、演算時の内部表現で "十分に長い" 浮動小数点を使えって話ですか。ちょっと勘違いしてました
ものすごく当たり前だけど、オーディオシステムが16bitで、演奏する楽曲データも16bitであれば、音量調節したら16bitの精度は出ない＞＜
24bitの環境であれば壊さずに8bit精度で音量調整できる＞＜
元のデータを復元できるか否か？＞＜で言うなら、32bit floatでも16bit intのデータを音量調節後にも16bit精度で復元できる＞＜（みたいな感じなので（馬鹿でも扱えるように）floatにしようよって言てる＞＜）
最初から最後まで「floatにするな！」っていうと、大部分のDAWとか使えなくなっちゃう＞＜
それは、ミックスダウンしない前提だから「丸め誤差が実数になってしまう！」ってなるけど、整数精度でミックスダウンなり音量調節すれば、当然ながらその整数の制度で丸め誤差が出るよ？＞＜
で、一般にプロ向けのオーディオソフトウェアって内部32bit or 64bitのfloatで扱っていて、一方でプロ向けハードウェアというかDAC/ADC等は24bitのが多いので・・・あれかも＞＜（？）
@orange_in_space 他にも演算時に丸め誤差とかも発生しちゃうから、適切な深度の整数で扱うのが妥当だと思うんですね
でも、それはそうだけど、16bit intのデータを単純に最小単位（？）を明かさずに32bit floatで指数部も使って（ディザなしに）表現しても、十分な長さ（と表現？）があれば、16bitのデータに復元できるんだから別によくない・・・？＞＜（もちろん最初から32bit float精度のデータはその通りだけど＞＜；）
@orange_in_space 整数だと1ビットの分解能は常に固定だけど、浮動小数点だと表現すべき数が大きくなるにつれて分解能が下がるじゃない。仮数部の桁数は固定なんだから
@hadsn つまり量子化方向に精度がリニアじゃないじゃんって意味かも・・・？＞＜
それは言われてみればたしかにそうかも・・・＞＜
@hadsn リニアPCMの定義がよくわからないかも・・・＞＜（32bit floatだろうが2bit int 辺りだろうがリニアPCMはリニアPCMだと思うんだけど・・・＞＜（DSDも単語の元の意味からするとリニアPCM？＞＜；））
音楽は整数精度で扱うのはやめようの会を作りたい＞＜；（そのくらい酷すぎる＞＜）
アニメのオープニング版（？）をなぜかニコ動で聞けたけど、それもかなり崩壊してるし、なんでそんなもの投げ返さなかったのか・・・＞＜
（アニメのオープニング版は専用でミックスダウンする事もあるって、実際にアニソン作ったことある人（編曲者の人（ネトゲで仲良くなった＞＜））に聞いた事ある＞＜）
犯人この人・・・？＞＜
藤田淳平 - Wikipedia https://ja.wikipedia.org/wiki/%E8%97%A4%E7%94%B0%E6%B7%B3%E5%B9%B3
電波状況が悪いFMラジオよりも、昔なつかしAMステレオラジオ放送っぽさを感じてある意味懐かしい＞＜；
ていうか。これ聴いてNOと言えなかった関係者全員音楽業界去るべきレベルでしょ＞＜； なんで途中で誰も止めなかったの？＞＜；
こんなの「出来ました！」「じゃあ聴いてみよう＞＜」って再生した瞬間にぶん殴るレベルでしょ＞＜
クリッピングしまくりのCD買って滝涙を流したこと何回かあるけど、それだってこんなレベルのなんて無かったかも＞＜； 盛り上がる所とかバスドラム重なる所とかでザラザラになりまくりで「；；」って程度かも＞＜
でも、このCOSMIC LOVEって曲そういうレベルじゃないじゃん？＞＜； 山奥で微かに届く電波でFMラジオでも聞いてるのか？＞＜；ってレベルじゃん！？＞＜；
すごいね！！！＞＜； 想像以上だね！＞＜； なんでこんなもの売っていいと思ったんだろう！？＞＜；
ていうかこれミックスダウンした人、音について1時間でも（30分でも？＞＜（5分でも？＞＜；））勉強したことあるんだろうか？＞＜； 小学校の理科からやり直すべきレベルじゃん？＞＜；
これ通しで聴くとやっぱ意図的なエフェクトじゃなく、なんでこれをCDにつめて売っていいと思った？＞＜；ってレベルに壊れてるだけっぽさが・・・・＞＜；
https://open.spotify.com/track/4QOjxaCeta3aLLSX6emoB1?si=MxXrSw37Rv-VellhiVrchA
音がトレモロっぽくなってるエフェクト（？）の長さ11～13Hzくらい？＞＜
これ、エフェクトならエフェクトだけど、その周波数の音が馬鹿デカいせいでクリッピング起こしてもこんな感じの音になるかも＞＜
（仮に意図的にもしこの音にするためにクリッピングでこうしたのであれば、すぐにクビにすべきレベル＞＜）
COSMIC LOVEって曲、出だしから変な音だけど、意図的にこうした音なのかクリッピングしてこうなったのかさっぱりわからない音＞＜；（聞くだけでは＞＜）
このアカウントは、notestockで公開設定になっていません。
ミックスダウンに自信が無いのであれば、完成品はCDの16bit 44.1kHzで出さずに、32bit float（周波数は好きにして）で出して、それをmp3圧縮したらいいかもね！＞＜（ちゃんとエンゴードすればmp3は整数精度では無く0dBFS越えを許容する規格なので、クリッピングだけはしない＞＜）
海苔波形は許す＞＜（というか別にいい＞＜ 音楽的表現の範囲なので＞＜）
クリッピングさせたら死ね＞＜（物騒）
このアカウントは、notestockで公開設定になっていません。
圧縮音源のデジタルループバックでも「元音源がクリッピングしてます！」ってわかりやすすぎる波形＞＜；（astrogationって曲＞＜）
Spotify起動したら、「水樹奈々がSpotifyに」みたいな広告が出て「ついに伝説の最悪音質クリッピングしまくりバカ音源が聞ける！？＞＜；」
って思ったんだけどこれの事かも？＞＜（まだ聞いてない＞＜）
https://open.spotify.com/album/5scAa9AvRlYRD37a1ScuYl?si=wbXNmGrBSIut8etvbgna_w
ブレーキの負担と荷重移動考えたら結果論として（？）正しいテクニックっぽさが＞＜
（オレンジの脳内自動車シミュレーターの考え的には・・・＞＜（主にこの本がソース＞＜ https://www.amazon.co.jp/dp/4876871507））
生演奏派（？）の人はこういうの「バックコーラスがすごく上手い人を何人か呼んで後ろで歌わせればいいじゃん？」ってなるかも？＞＜
それじゃ駄目なんだよとここまでこだわるのが録音の芸術＞＜
音楽には生演奏だけじゃなく『録音の芸術（オレンジの言葉＞＜）』というものもあるんだよって話題としてこれおもしろいから聴いて＞＜
https://mstdn.nere9.help/@orange_in_space/102242313712968949
エスティマのCM
Toyota Estima 20th Anniversary (トヨタエスティマ20周年) Japanese Commercial - YouTube https://www.youtube.com/watch?v=TKXlJWa8S4s
これの曲＞＜
後ろで「あ～」ってずっとコーラス入ってる＞＜ この音、10ccのI'm not in love
【自動車CM】 NISSAN SKYLINE (R34・後期・30秒)／日産スカイライン - YouTube https://www.youtube.com/watch?v=IS2bRJZaVcs
この曲の録音手法（当時どうやってたのか気づけたの！？＞＜；）をリスペクト（？）する感じで「あ～」をたくさん多重録音して作ったって、作った人が言ってた＞＜
話がさらに脱線するけど、オレンジが本格的なジャズが嫌いだったのも「やっぱ生演奏こそ」派の人＆「真空管アンプの温かみが・・・」みたいな人のジャズ率が高くて嫌いだったのもある＞＜
（そういう人は今でもリスペクトしてないけど、ジャズミュージシャンをリスペクトするようになったのは、ロスアンゼルスの伝説的スタジオミュージシャンの方々の多くがジャズ畑出身と知ったから＞＜）
テレ東的、お年寄りターゲット「日本の歌」番組の境目がおもしろいかも＞＜＞＜
みたいな感じといえば言いたい事がより伝わる？＞＜；
このアカウントは、notestockで公開設定になっていません。
出だしを愛のコリーダに差し替えてもおもしろそう＞＜（お年寄りなら気づかなそう＞＜）
おじいさんが北酒場を聴きながら「やっぱ日本の曲ってこうだよね。ポップスとかあんなちゃらちゃらしたもの聴けないね」なんて言ってたらおもしろいじゃん？＞＜；
悪戯でサビにハッスルリフ入れたくなるじゃん？＞＜；
演歌は基本的に「これこそが日本の歌！ ポップスなんてちゃらちゃらしたのは日本の音楽じゃないね」みたいな風潮は嫌いなので嫌ってるというかそういう風潮を馬鹿にしてるけど、それぞれの元ネタ辿るのは楽しい＞＜（それはそう言う風潮馬鹿にしてるからもあるけど＞＜；）
オレンジも「パクリだ！＞＜」とか騒ぎたいわけじゃなく、元ネタが明かされればおもしろいのにというのがある＞＜
（どう分けるのか説明するの難しいけど、パクリはパクリで「悪質な盗作でしょこれ！？＞＜＃ 」って感じのはキレる＞＜（レディーガガがカイリーミノーグの曲をパクったのとか＞＜））
音楽はどれがどうみたいなのよりも融合が楽しいみたいなのがあるからなあ(だからこそ木の根っこを見る楽しみはあるかもしれない)
このアカウントは、notestockで公開設定になっていません。
飲み屋さんで北酒場が流れて、ディスコ世代のおじさんおばさん（もう60歳前後？＞＜）がお酒飲みながら通常のアレンジだと思って聴いてて、サビが突然ハッスルリフ（？）になってたら、ディスコで踊ってた人だけお酒吹きそう＞＜＞＜＞＜
北酒場にハッスルリフ（？）を入れるとか＞＜；（2分42秒から＞＜）
The Stylistics - Can't Give You anything but My Love
https://youtu.be/sPi4L-9rc8M?t=162
北酒場って、ディスコ畑の人が本格的にヴァンマッコイ風リミックスしたら、ディスコ好きな人には「ヴァンマッコイだ！！！＞＜；」ってなる一方で、お年寄りが聴いたらどう違うのかわからないんじゃないのかなって気がする＞＜；
ムード歌謡、あれも曲調で分類しようとすると大きいくくりはディスコミュージックと言えてしまう気はする
ムード歌謡も、起源で言うと歌謡曲の起源につながるけど、各楽曲の元ネタをたどるとおもしろいのかもしれないってこの前ちょうど思った＞＜（通販の『音楽のある風景』のCM見たときに＞＜；）
まあ実際これはそうみたいなところあるな 北朝鮮の軍歌とかは今風のポップな感じだったりするし、いわゆる歌詞は演歌で曲調は流行りのポップスみたいになるだろうし、恐らく曲の分類としては歌詞によって揺らぐところがあるのかもしれない？(ムード歌謡とかはムーディーな曲調というよりも歌詞のムーディーさがより重視されそう)
たぶん、会津磐梯山のオケを1980年代の演歌の編曲の人に作らせたら、ヒップホップ？＞＜（？＞＜；）
民謡の場合はそうかも＞＜（古いので＞＜；）
演歌の場合は「ちょっと民謡風にする事で日本古来の曲と思わせて、一方でその時の流行のジャンル（明るい曲の場合だいたいディスコ系）を取り込んだインチキ伝統曲」（とげとげしい表現＞＜；）なので、民謡成分より流行り成分が強い傾向がある楽曲は「元ネタのジャンルそのまんまじゃん！？＞＜；」にはなると思う＞＜
まあこれはどれにでも言えると思うんだけど特定の曲をどのジャンルに分類するかっていうのって結構難しい(文化的に?)気がする もちろん今から見たら要素を兼ね供えていてディスコミュージックと言えてもその時代にそれが言えたかみたいな
割とポップスの時代になってからの音頭がおおいから民謡とかの流れで出すのはアレかもしれないけど、歌謡曲・民謡というかもう新しいのと古いのの融合みたいな感じになっちゃってるな
北酒場とか、なんであれがディスコミュージックじゃなく演歌（歌謡曲？＞＜）なのか、わけがわからない＞＜（ヴァンマッコイ風じゃん？＞＜；）
ていうか1960年代以降の音頭（＆演歌等）だと、ソウルミュージックの影響を多大に受けちゃってるから、別の意味で「それはそう＞＜」みたいな感じが＞＜
公式試聴動画あった＞＜
ヤバ歌謡3 NONSTOP DJ MIX 音頭編～Mixed by DJフクタケ - YouTube https://www.youtube.com/watch?v=S5Wa3zoWAMc
ヤバ歌謡３ NONSTOP DJ MIX –音頭編 - Mixed by DJフクタケ ユニバーサル https://www.amazon.co.jp/dp/B00XIIJJAS
民謡がヤバいという話、前にも出していてヤバ歌謡というCDがあることもpostしていた
これに直接関係はないけど「ヤバ歌謡」というCDシリーズがあって、そこで歌謡民謡音頭など色々なヤバい音楽が収録されているんですがおすすめです
wikipediaによると、ソーラン節の「ハイ！ハイ！」はYes!Yes!です＞＜
このアカウントは、notestockで公開設定になっていません。
前に調べたけど、種類がかなり少ないらしい＞＜（ていうか日本が極端に多いらしい）
なので、英語で汎用的な表現にしようとすると、「はーどっこい」も「エンヤコラ」もほとんどheave hoに訳すしかないらしい・・・＞＜（あやふや）
ドッコイショ的なワードを合いの手みたいに(合いの手としてでなくても)使うのは昔からあっちにもありそうだけどどうなんだろう
「はーどっこい」って英語でなんて言うの？＞＜；って
heave hoらしい＞＜
合いの手が海外にあんまり無いのかもって所からこの辺興味持ったからこその突然の思いつきだった気がする＞＜
これ、ジャパニーズなパーカッションをTR-909とTR-727に置き換えてBPM上げればだいたいヒップホップ（？）じゃん？＞＜
会津磐梯山 （福島民謡） - YouTube https://www.youtube.com/watch?v=8bRH72OIS4A
直後のツイートにこれが貼ってあった＞＜
トースティング - Wikipedia https://ja.m.wikipedia.org/wiki/%E3%83%88%E3%83%BC%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0
（その直後に歩くサメ見て話題がサメにとられたらしい・・・＞＜；）
https://twitter.com/orange_in_space/status/375859702170542081
”突然謎に思ったけど、どうして「おら東京さ行ぐだ」はヒップホップなのに、民謡「会津磐梯山」はヒップホップじゃないの・・・？＞＜”
このアカウントは、notestockで公開設定になっていません。
これ、の問題"(ある)"の面って、オレンジがあんまりフォロー返ししてない最大の理由でもある＞＜
その人の『好き』に「嫌い！＞＜」と言ってもある程度だいじょうぶそうな人じゃないと、その人を気にして「嫌い！＞＜」と言えない話題ができてしまう＞＜
https://mstdn.nere9.help/@orange_in_space/102453504194733541
オレンジは会話を目にするのが嫌いな話題ってたぶんあんまり無いかも＞＜
目にするだけでブチキレるようなものはあるけど、それは嫌いなものの話題であって、嫌いとその理由を言ってdisっていいのであれば問題ない＞＜(ある)
どんな話題でもその話題が嫌いな人がいるので話題気にするの無意味かも的なこと前に書いた気がするけど見つからない＞＜
