専用ハードウェアなデジタルスペアナってどうやってるんだろう？＞＜；
専用ハードウェアなデジタルスペアナってどうやってるんだろう？＞＜；
すごく当たり前だけどわかりやすく強調すると、10秒ごとに届くデータを滑らかに表示しようとすると10秒のレイテンシになっちゃう＞＜；
レイテンシを下げようとすると録音バッファの更新のタイミングでしか表示を更新できないから、結果的に、（簡単にバッファの更新タイミングがFFTのサイズより大きい場合で言うと）各サンプルが一度しかFFT通されない事になっちゃう＞＜； それだとめちゃくちゃ不自然な表示になっちゃう＞＜
スペアナ自分で作ってみてやっとWaveSpectraの録音のリアルタイム表示のレイテンシが長い理由わかった＞＜； 表示を滑らかにしようとすると原理的に不可能なのか・・・＞＜
FFTしたデータ関連のバグだと思って悩んでたのもこれだったっぽい・・・＞＜；
BytesRecordedと言うものに気づかず、録音バッファが埋まったらイベントが起きるんだと勘違いしてた＞＜； https://github.com/naudio/NAudio/blob/master/NAudio/Wave/MmeInterop/WaveInEventArgs.cs
見つけたのさっきのリングバッファのバグじゃなく根本的にNAudioの使い方を間違えてたと言う・・・＞＜；
Array.Copy、全然C# っぽく無いしすごく使いづらい＞＜；
よーするに追加削除とアクセスのどちらに即応性を求めるかという話なのでユースケースによりけりです
なんて名前にすればいいのかわかんなくてExport()にした＞＜；
ん、いや、バッファは定数長だからすべて O(1) か。この説明は間違ってるな(まあ雰囲気で察してください)
前者は push / pop が常に O(1) だけど書き出し時(連続領域の配列としてアクセスしたいとき)に(たぶん)常に O(N) かかります。
後者は push/pop が O(1) にならない(償却できるかは知らん)代わりに、常に O(1) で連続領域の配列に乗ったデータにアクセスできます
あ！＞＜ オレンジが書いたのは、内部的にはズラしてなくて、読む時に、普通に読むんじゃなく連続にした配列を返すようにしてる感じ＞＜（どっちにしてもコピーしたのを使うので、コピーする時に連続に直してる＞＜）
リングバッファ自体は、内部データがバッファ両端を跨いでいても動く(→push / pop が O(1) になる)のがメリットなので、そのメリットを潰さず連続領域にデータを乗せたいなら、
・外部のバッファに書き出す関数を用意する
・少ないずらし頻度で連続領域に乗せる
のどちらかになるかと。
この図は後者の実装です
ExportBuffer()って言うので連続になってるデータ返すようにする方があとの処理軽くなるかもって思った・・・＞＜（どっちにしても読んで弄る時に書くスレッドを長時間ふさがないようにコピーしないと駄目かもって・・・＞＜）
コピーが見えるのはずらし操作かな(連続領域を使いたいからか
リングバッファ、これでいいのかな？＞＜；（ちゃんとテストしてない＞＜；）
https://gist.github.com/orange-in-space/ccdbd35835fc51b7c9d9ba6bce6ee9f9
青森いってみたい場所わりとあるけどお金ない・・・＞＜
1サンプルずつ読み書きしてた・・・＞＜（これじゃ遅すぎる＞＜）
よく考えたら少し前に作ったテープエコー（のようなものを作ろうとしてふざけて作った、変な音を出すもの）ってリングバッファ・・・？＞＜（どうやって作ったのか覚えてない・・・＞＜）
Circular Buffer in .NET
https://social.msdn.microsoft.com/Forums/vstudio/en-US/416a2175-b05d-43b1-b99a-a01c56550dbe/circular-buffer-in-net?forum=netfxbcl
10年前のコレが上位に出てくるあたり、今も標準にはなさそう……(知らんが)
C# で、高速なFIFOなバッファで、固定長の必要な分だけ最新のデータを保持して古いデータはどんどん捨てるってどう作ればいいんだろう？＞＜；（具体的に言うと最新の65536バイト分だけ必要でそれ以外はどんどん捨てたい＞＜；）
「一意見だけど」ってつまり、完全な根拠の説明を省くあるいはそもそもそこまで深くは考えて無くてまだ思考中ですみたいなあれなのかも＞＜（なのかも＞＜）
ていうか「一人の意見でしかない」物のうち、何らかの欠陥を指摘しなければ崩せない構造の物は「一意見だけど」とか「個人的には」が要らなくて、そこまでの論にはなっていない（言い方を変えると話の中に根拠までは入っていない）場合には「個人的には・・・」みたいなのが要る感じっぽい気がしなくもない・・・＞＜
何らかの基準を話したり、何か組み立てられた論があるのでありその構造ごと（？＞＜）話すのであれば、自分が考えるにはってつけなくても良いと思うし、逆にそうじゃないのであれば自分の考えであることをつけないと両者がぐちゃぐちゃに混ざっちゃうかも＞＜
オレンジはちゃんと、オレンジが考えたのかそれとも例えば何らかの基準や通説を説明しているのかで表現を変えてるつもりかも・・・＞＜（完全に出来てる自身は無いけど＞＜；）
あくまでも一人の意見でしかないから、気にしたくなかったら無視してくれって感じの雰囲気づくり
そういえば日本人は英語書くとき何でも "I think 〜" と書きがち、みたいな話をどこかで聞いた(自分もそうだなと思った)
オレンジの場合、「べき」って何かの目標をクリアする為の解決法の時とかにも使うかも＞＜ 「蛇口から水を出したいのであればひねるべきかも＞＜」みたいな・・・＞＜
個人の意見であるという自覚があったとしても「〜べきと考えている」って至るところに書くの冗長だから「〜べき」と書きます(文句があるなら自分の発言全てに「私は〜と考えています」と付けてから言ってほしい)
「～べき」より「～と言われている」にするとまろやかになるのは分かるんだけど、なんか「～ってみんな言ってる」と同じ感じで、どこで？ってツッコミが入ってやっぱり泥沼にも思う。
オンラインでMMLを活用してるメジャーなのってピコカキコくらい？＞＜
ピコカキコ - ニコ百 http://dic.nicovideo.jp/id/513511 #nicopedia
PCの所にきたら、なぜかciv5が起動直後の状態で放置されてた・・・・＞＜（昨日起動してそのまま忘れた？＞＜；）
MMLじゃだめなの・・・？＞＜
Music Macro Language - Wikipedia https://ja.wikipedia.org/wiki/Music_Macro_Language
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
その通りかも＞＜
あと今のままだと改変の問題があれだけど、「鯖にリソースが足りなくなっちゃったので、泣く泣くだけどこれを消します」という情報も配れたらおもしろそうって思ってる＞＜(それをどう信用するかは受けとる側の鯖の設定であれだけど、例えば「だったらそれはより保存の優先度をあげて代わりに消えないようにしておこうか」ってしてもよさそう＞＜)
This account is not set to public on notestock.
で、「発信側の鯖が弱い人の人気が上昇してslashdottedみたいなことになったらどうすんだ？」って問題は、それこそ人気者になっちゃった人には投げ銭してあげられる人が投げ銭してあげればいいんじゃないのかな？＞＜って考えてる＞＜
俳句で例えるならば、一般に、俳句の批評は俳句より長いかもしれないけれど、その俳句を詠んだ人が着想を得るに至った情報は俳句の批評よりは長いかも＞＜
なので俳句の発信のみのリソースしか確保できない人でも参加出来るようにするのが、もっとも誰でも俳句を詠む世界に参加できる選択と言えるかも＞＜(ものすごく当たり前だけど＞＜；)
オレンジ的にはこの点、読むより書くを重視していて、読む側が読み続けられるようにする対象はある程度手動で選別して絞る形でいいと思ってる＞＜(例えばふぁぼったのは保存しておこうみたいな＞＜)
なぜそう考えるかと言うと、一般にある人が書く量よりも読む量の方が圧倒的に情報量が多く、さらに、強く意識して読んだ情報よりも無意識に取得し聞き流す情報の方が圧倒的に多いであろうと考えているから＞＜
それらが重要な情報であるかもしれないのは確かかも＞＜
でも、情報量が自分が書く総量よりも圧倒的に多いという事は、より多くのリソースが必要という事かも＞＜
もし、読む為のサーバーリソースを『全ての情報を保持し続ける』という参加条件にしてしまったら、書いたものを保持し続けるよりも圧倒的な読むものを保持し続ける為のリソースを提供出来る者のみが書く権利を得られる世界になってしまうかも＞＜
これは言い換えるならば「あなたが世の中に一言でも発言したいのであれば、その根拠になった情報をすべて保存している (比喩ではない)図書館を持つ必要がある」というような状況かも＞＜
たとえば「以前受信した投稿を後から投稿を fetch しようとしたが、実は内容が書き変えられていた」などのケースは、書き換えという悪意に弱いし、なんなら発信者サーバ停止という障害にも弱い。
まあ前者はハッシュとかを記憶しておくことはできるけど、それは完全な防衛ではないし……
クラウド分散ストレージが他者のためのリソース提供を義務として他者からのリソース提供に強く依存するシステムで健全に成立するのは、データの所有者と発信者と受信者が同じで、かつ暗号化が施せるからであって、 SNS の投稿データについて同じような仮定は成立しない
各々が「自分が使うために、自分の手の届く範囲だけはしっかり維持する」という(言ってしまえば)自分第一の動機を持っている分散システムの方が、参入障壁は高いかもしれないけど、悪意に強くなると思う
すぺっこ的に弱い鯖がたくさんいて強い鯖にリクエストをとばしまくるつらみなアレにもなりそう
これの文脈については、主張の妥当性には同意するけど、「自分が手を出せない部分に都合の良い期待をできない/したくない」という悲観的な動機のある分散主義者なので、実現してもそれは短期的だろう、そのうち悪意や手抜きから崩壊していくことになってしまうだろう、と思えてしまいます
発信側と受信側、どっちが保持するかは、なるべく両者保持する方がいいけど、弱い鯖が限界が来たら保持を諦められるように、決めずにゆるふわにする方がネットワーク全体としては有利かもって気がするって話です＞＜；
オレンジが長文を書いているうちに話題は次へとどんどん進む・・・・＞＜；
無限に(比喩表現)鯖のリソースを確保出来るなら別だけど、実際には限られた人にしかそんなこと出来ないし、「分散を」「誰もがインスタンスを」というのであれば、より小さくより弱い鯖も参加出来るようにする方がそれをより実現できると思うし＞＜(例えば切手サイズの数千円の計算機でも十分動かせるとか＞＜)
つまり、例えば発信側の鯖が強くて購読側の鯖が極端に弱い時に、無理に購読側に保存し続けようとせずに、出来る限りのみ保持して、無理っぽい部分はまたそのうち発信側にとりに行って「残ってたらいいな・・・」でいいと考えてる＞＜ その方が購読よりも発信によりリソースをさける気がするから＞＜
オレンジはその辺りゆるく考えてて、リソースを多く提供出来る方が長期的に保存されるということを期待する みたいな方式にすれば、(世界)全体ではそれほど大きなリソースを用意せずにすむかも？＞＜みたいに考えてる＞＜
自分の使う部分さえしっかりしていればどうにかなるのが分散システムのいいところなので
なので、ユーザ削除時にリモートの投稿にまで根刮ぎ削除リクエスト飛ばしたり、 DB のお掃除と称して消えたユーザの投稿をローカルから削除しにかかるの、本当にやめてほしいです
静的ページジェネレータを内蔵すればかなりマシになりそう？＞＜ アカウントごとに日毎の発言ページ作るとか＞＜(あと、スリープモードみたいなのがあるといいのにって思ってる＞＜)
分散 SNS において発信元サーバにデータが長く残る必要性は感じていなくて、自分が使っているインスタンスさえ残っていれば過去の投稿は(実装のサポートはともかく原理的には)可能なので、手元の鯖をしっかり維持していきましょうという気持ちです
This account is not set to public on notestock.
ツイッターの会社、キーワード式ブラックリストでどうにか出来ると考えてる時点で おふがお氏とどっこいどっこい＞＜
ツイッターの会社はそもそもまともにデザイン出来る人も、そして当然その検証を出来る人も居ないイメージ＞＜
アメリカって誤爆(故意な誘導に乗っちゃった事例含む)に緩すぎる(ペナルティが軽い)イメージ＞＜(SWAT呼ぶやつとか＞＜)
DMCAのクソリクエストをrejectする仕組みがあればいいんだろうけど、なんともなぁ…
・・・なので、逆にオレンジは嫌ってる物の疑問点普通に公言もする＞＜(ていうかナチュラルにdisってる＞＜)
「エアバスって危ないんでしょ？なんか昔、名古屋空港で落ちたし」って言う人にエアバスの思想の説明するのすごくすごく楽しい＞＜＞＜
教えるのは大変そうだけど、一方でオレンジは自分が好きなものを嫌ってる人の話を聞くの大好き＞＜ 自分が好きなものをに対する別の視点の意見を聞ける大チャンスだし、説明するチャンスでもある＞＜
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
どっちが安全な動作で取り返しがつくか？って視点も大切＞＜(マージする挙動の方式でも「やっぱ元に戻したくなったけど、混ざっちゃってわかんなくなっちゃった」って状況も、もとに戻せるのも大切＞＜)
merge と replace だったら replace の方が人間が実現するには簡単だから、システムとしては merge をしてくれ、という視点の意見もある
Twitter にもかいたんだが，同名のディレクトリを drag & drop したときに merge でも cancel でもなく replace されて嬉しいひととかおるの？？？
安全側の挙動になってない上に説明不足なの、すごくAppleらしい＞＜(逆にMSの7？Vistaからのダイアログの説明の細かさ・・・・＞＜；(あれはあれで・・・＞＜；))
macOS の Finder のこの挙動のせいで音楽ファイルがいくつか消し飛んでキレそう。macOS 一気に嫌いになった >> Macでフォルダを上書きしたら、元のファイルが消失・・・ | ITエンジニアのための『カラダトリセツ』 https://karadatorisetsu.com/overwrite-a-folder-in-the-mac-the-original-file-is-lost/
オレンジは知識の量がどうの言いたいわけじゃなく、知りたいかどうか？の事を言ってる＞＜
いきり云々よりもマウント云々の方がもっとわかりやすいかも＞＜ 対象についてより深く知ろうなんて気がないんだからオタク/マニアその他そんな感じの言葉の範囲の人じゃ無いんでしょ感がある＞＜
ていうか、(言葉の定義論じゃなく(でも定義になっちゃうけど＞＜；))いきりがどうのいってる人々、全然オタクじゃないんじゃないの感がある＞＜
今はなんかこうオタクが「レッテル張りに苦しんでいる」というよりは、オタクがオタクを迫害する世の中になってるっぽい イキリオタクと思われるのを攻撃したり嘲笑ったりして群れてワイワイやってる感じのやつ
「『hogehogeパズル』ってゲームについて調べよう！＞＜ 『hogehogeパズル w...』」
Google「『hogehogeパズル wiki』かな？」
「それだ＞＜」
Google「wikiとはこういうものだよ」
「一番重要なhogehogeパズルって固有名詞削るな！＞＜＃ しかたない『完全一致』・・・＞＜」
Google「『hogehoge パズル w』だね！」
「違うよ！＞＜＃ ていうかhogehogeとパズル分けるな！＞＜＃ 」
みたいになりまくり＞＜＃
ツイッターでキレてかくと文字数足りなくて「どういう事か説文字数」みたいになってジョークっぽくなるけどマストドンだと文字数足りてしまうのでジョークにならない問題がある＞＜；
Googleが事実上、完全一致で検索しないと何にも役に立たなくなってるけど、補完利用して検索して「キーワード勝手に削るな馬鹿＞＜＃ 」ってオプションで完全一致を選ぶと今度は補完前の文字列で検索するから「嫌がらせでわざとやってるのかごるぁ＞＜＃ その仕様の正統性を説明して見ろ＞＜＃」ってキレて堪忍袋が枯渇して危機的状況＞＜
