2024/07/21(日)田村ゆかりさんのライブツアー LOVE ♡ LIVE 2024 *Honey bunny* 7月21日は高崎芸術劇場にお邪魔してきました

はてブ数 2024/07/22 00:02 つーさ


というわけで ゆかり王国観光してきました(初訪問)

ゆかりん単独のライブは初参加。元々、なのは15thリリカルライブで生歌拝聴したのが初、その際特有のPPPH「ゆーーかりんっ ハイっ」を目の当たりに「？！」して、ゆかりん現場どんなんなんだろうと興味をもってから、かれこれ5年？経ってしまいしましたが、最近？奈々クラがゆかりん現場に流れてる雰囲気を感じてて、、比較的近場でチケットが取れるんなら、と、思い立ったが金曜日にローチケで当日引換券を確保して、今回 初訪問を果たせました。

噂になるほどの王国民のパワーそして一体感すごいですね。今回参加した高崎芸術劇場のキャパは2027席らしいですが、この規模の箱だとコールも煽りもアンコールも一発で揃って、一体感臨場感ひとしお。ほとんど予習もなしに凸ってしまいましたが、立って聴く曲(？)は、結構どの曲もサビに振り付けがあって振りコピしてる人も多く、口上も含めて予習していったら、もっとしっかり応援できて、より楽しめたのかなとかは思いました。(群馬の人ー？って問いかけには「少なっ」てリアクションされるくらい、地元からの方は少なめだったようなので、今回参加した現場は比較的練度が高かったのかもではあります

ゆかりんはアイドルでしたね。今回セトリだと半分以上？の曲に、振り付けがあって、歌いながら踊っててすごいですね。当日券なので2階席遠目で表情まで伺うことはかないませんでしたが(遠距離恋愛席というらしい？　オペラグラス持ってくればよかったね)、近くで見たらもっとかわいいんでしょうね(？)

ライブの中身にはあんま触れませんが(というか、何もかもが秒で過ぎ去っていってあんまりおぼえてｎ)、本編・アンコール終わってのお手振りの時間は、ブロックごとというか、ちゃんと時間を切り分けて手を振ってくれていいなと思いました。見切れて見えない席にもステージ反対側の見える位置から手を振ってくれたり。観客の誰かが「せーのっ」って言ったら声を合わせて「ゆかりーん！」と呼びかけましょう だけは予習してたので、そこは乗り遅れずにすんでよかった……

物販が入場後だと知らなくて少しさまよった後、当日券引換で入場できたのは開演30分前くらいで、そこから物販列並ぶと開演間に合わないとのこと。Tシャツもペンラもなく、ユニクロパーカーに徒手空拳での応援になってしまったのはちょっと後ろめたさ残りました*1が、

たのしかったです。

奈々さん現場だとブリッジムービー以外はMC含めて立ちっぱなのが当たり前？だったので、MCは座って聴く、パートによっては楽曲も座って聴くというのは、個人的にはそういったのも異文化で新鮮でした。

*1 : 1列目の人が開幕遅刻して、ゆかりんに「1列目だってわかってたのに なんで遅刻したの？」「物販が……」というやりとりも思い起こされる……ペンラ暗黒騎士のくだりも含め、結構1列目のお客さんいじられますね。じっと見つめてくれたり……。これは王国民の方はたまらないでしょうね。1列目引くために全通したくなりますね

コメント（0件）

2024/06/16(日)LIVE JUNGLE 2024 SAFARI 01,02 (三重県営サンアリーナ)

はてブ数 2024/06/17 20:52 つーさ


いってきました！
なにを歌うか、ツアー初日のわくわく感
期待を裏切らない 激アツなライブでしたね！(こなみかん

今週もお疲れ様でした！

以下セトリのクリティカルなネタバレを含まない程度の感想

続きを読む

コメント（0件）

2024/06/02(日)ぱねりあ OST!

はてブ数 2024/06/02 01:14 音楽::オリジナル作品計算機な日記::ソフト作りつーさ
ふと思い立って ぱねりあ BGM集を蔵出しするなどしていました。
曲を作ったのは約20年前らしいですね、なつかしいですね、やばいですね。

さんくらに上げてもよかったのですが、なんとなく音楽を聴けるページなど作ってみるかと思い立って https://music.tu3.jp/ なるものを作ってみてました。

とりあえず「ぱねりあOST!」と「QoFR OST!」をおいてみてあります。

どっちのアルバムも、収録曲のオリジナル版は、当くーかんでもだいたい聴けますが、今回公開用にちょっとなんか音処理してカットしなおしたりして整えてみたので、ほんのちょっぴりオリジナルともゲーム収録とも別バージョンになっています。びっくりまーくをつけてみました。Highをそこそこ盛ったので環境によっては耳障りかもしれない。

他の曲とかもなんかしらまとめて聴けるようにしときたい感なくもないですが、大体満足してしまったので、、そのうち、やります(ほんとか？)たぶん……やるかなぁ……。

今週もお疲れ様でした。

以下は蛇足(実装した感想)です。

続きを読む

コメント（3件）

2024/05/10(金)自宅鯖りぷれーす

はてブ数 2024/05/10 23:42 サイト運営つーさ
17年前発売のNASから 11年前のノートPCに……

最近(※1年以上前) ノートPCを買い換えたので、
それまで使ってたの*1を自宅鯖その2にしてみることにしました。
QNAP TS-219P+ ASUS TAICHI 21
CPUMarvell 6282 1.6GHz 2C2T→Intel Core i5-3337U 1.8GHz (TB 2.7GHz) 2C4T
メモリ512MB→4GB
ストレージHDD 8TB→SSD 128GB
ディスクとメモリの大幅スペックアップ(？)による応答性能向上*2もさることながら、
ディストロ的にも、ARM系組み込みLinuxから素直な x64 Ubuntu に変わって、apt と唱えたら大体何でもそろうようになった点が、構築が楽でいいですね() *3
SSDは容量に若干の手狭さを感じつつ、かつ、普通に長期常用してた後なので寿命面も些か心許ないですが、まぁ壊れたらまた考える……。

あとは、Webサーバ機能を載せ替えるのにあわせて、前々から思ってたワイルドカードTLS証明書化とか、そのためにDNSとリバプロをCloudflareに移してみたり *4。
JOYSOUND全国GP.xls を夏色仕様にしてみたり*5。
風邪を引いてゴールデンウィークを2日延長してみたり*6。

今週もお疲れ様でした。

*1 : ノート、基本的にリモートデスクトップにしか使わないので10年耐えましたね……

*2 : ブログのページロードが幾ばくか速くなりました

*3 : 物理マシンにLinuxをインストールするの学生時代以来かもしれません

*4 : 当初自前DNSサーバたてて _acme-challenge の NS をそっちに向けて、、とか考えてたのですが、めんどくさくなってしましました()。 Cloudflareさん 無料プランでDNSとキャッシュ付きのリバプロくれるの太っ腹です……転居時に失ったIPv4のリバプロ用に借りたConoHa VPSの割引きっぷ、まだ丸1年以上期間残ってるのちょっともったいない……

*5 : このブログのデザインも長らく変わってないのでちょっとたまにはイメチェンしたいですね。

*6 : 咳の出る風邪が流行っている気がしますね。38.8℃とか出てハイテンションでした。皆様お気をつけください

コメント（0件）

2023/09/30(土)値のビット幅を拡縮するとき

はてブ数 2023/09/30 18:44 つーさ
値のビット幅を拡縮するとき

16bitデータを8bitに落としたり、8bitデータを計算のために32bit表現にしたりすることある思考整理メモ。

unsinged

画像データとかはこっちだな。

落とすときはそのまま右shiftする。

落とすときはそのまま右shiftする。まぁ。普通？

拡張するときは2択？

1つは単純に左シフトする方法。
つまり、u8をu16にするとき、8bit左シフトする＝256を乗ずる。
この方法は最大値は最大値にならない。
u8をu16にするとき、255*256は65535にならず、65280になる。
u8をu24にするとき、255*65536は16777215にならず、16711680になる。

これは、unsigned型は 0 から 1-(1/2**bit数)までを表現でき 1.0を表現できないとする立場(立場？)とも言える。
65535 は 1.0 ではなく 1.0-1/65536 = 0.9999847412109375 である世界の計算。

色の処理をするときはあんまよくない。
たとえば、255の赤が65535の赤にならないので色がくすむ。
もう1つは、元のビット幅の1を繰り返したものを乗ずる方法。
元のビット幅分左シフトしては元の値を足すことを繰り返す方法とも言う。
これは、当該unsigned型の表現可能な最大値(255とか65535とか) が 1.0 である世界。
最大値が最大値として復元される努力をする感じ。

つまり、u8をu16にするとき、 8bitの1 = 0x01 を、上から16bit分繰り返した 0x0101 = 257を乗ずる。(=8左シフトしてから元の値を足す)
u8をu16にするとき、255*257は65535になる。
u8をu24にするとき、255*0x010101(65537)は16777215になる。
こっちは、255の赤を65535の赤にできる。

ビット数が整数倍じゃないとき丸まってしまう。
たとえば、7bitの値を23bitにするとき
7bitの1 0b0000001 を 23bitになるまで繰り返した 0b00000010000001000000100=66052を乗ずると、
127*66052=8388604 で、23bit unsigned の最大値は 8388607にはならない。

こういうケースで最大値がほしいときは、普通に 8388607/127 (= 約66052.0236220) を掛けないといけない。
割り算を嫌うなら、7bit左シフトしてから元の値を足すを4回繰り返して一旦28bit表現にしてから右5bit落として23bit表現にする、をしてもできる。
7bitの1である 0b0000001を4回繰り返した 0b0000001000000100000010000001=2113665を掛けてから、32で割る(5ビット右シフトする)感じ。

signed

音声波形データとかはこっちで表現されよう。

正負で表現可能な段階数が違うので面倒。

落とすとき

正のs16をs8に落とすとき、32767/127 = 約258.00787で割る
負のs16をs8に落とすとき、32768/128 = 約256.00000で割る
正負によって除数が変わる。

はぁ？

そもそもsigned型では 0から+1の距離と 0から-1の距離が異なるのですか？
0から+1と0から-1の距離は一致するが、負の方にだけ表現できる幅が少し広いと考えるべきでは？
なら、より幅の広い負に配慮して、どっちも256で割りましょうか。。

ただし、s16の絶対値を256で割ってs8にしてはダメ。
負について256で割ったあとfloorしないといけない。
0方向丸めしてしまうと、0付近 s16の[-15,+15]の31要素がs8の0になってしまい歪む。
floorすれば、s16の[0,+15]の16要素がs8の0、[-16,-1]の16要素がs8の-1になる。

s16の世界にあった65536種類の値を256個ずつグループにまとめて、256種類の値に射影したいと考えると、
結果的には、unsignedと同じで、落としたいビット数分だけ右シフトするんでよさそう。

拡張するときは？

拡張するときは？
正負によって表現できる幅が違うので、単純に最大値を最大値にマップすることはできない。
とりあえず、素直に拡張したいビット数分左シフトする方法が1つ。
s8をs16にするとき、
+1は+256に、+127は+32512になる。
-1は-256に、-127は-32512に、-128は-32768になる。
最大値に配慮する方法も考えてみてはおく。
「+127が最大」か「-128が最小」か？
「+127が最大」だよ派
ビット拡張先の正の最大値をビット拡張前の最大値で割ったものを係数にする。
s8をs16にするとき、 32767/127≒258.0078740 なので、試しに 258.008 を掛けてみると、
+127が +32767.016 くらいになる
-127が -32767.016 くらいになる
-128は -33025.024 くらいになって、オーバーフローしちゃう(それはそう)。
うーん、元データの性格にもよるけど、-128 なんてなかった(-127と同値として扱う)と割り切るのは、1つのやり方としてはなくはないか？
変換を何度も行った場合の値の保存性は？
「-128が最小」だよ派
拡張先の負の最小値を拡張前の負の最小値で割ったものを係数にする。
これは、 1<<(拡張したいビット数) になるので、先に書いた単純左シフトと同じになる。
「+127が最大」かつ「-128が最小」だよ派
「正のとき 258.0078740 を掛け、負のとき 256.0を掛ける」条件分岐をする。
[0,+2]の距離と [-1,+1]の距離が変わっちゃう。
これは最初に割る話をしたときと同じであんまり筋がよくないと思う。考えない。

あとは、floatと行き来するとき……

signedは負方向に広い。 「-1.0を-32768とする」か「-1.0を-32767とする」かの2択。
上で書いたけど s16の+32767を+1.0、-32768を-1.0など定義してしまうと0を境界に「1の幅」が変わって歪む。
「-1.0を-32768とする」
とき、変換時 32768 を係数に乗算・除算することになる。
デメリットがあって、s16では、-1.0を-32768として表現できるが+1.0を表現できなくなる。
s16で表現できる範囲は、 1/32768 = 0.000030517578125 を用いて、-1.0 から +0.999969482421875 = (1-1/32768) となる。
「-1.0を-32767とする」
とき、変換時 32767で乗算・除算することになる。
こっちは、+32767で1.0を表現できるので一見よさそうだけど、
その一方で-32768は 1+1/32767 (=約-1.000030518509476) になるので、
係数とかに使うときはちょっと気にしといた方がいいのかしら。
また整数型に戻すときはsaturationするだろうし、まぁそんなに気にしなくてもいい気もする。

「-1.0を-32768とする」よりは「-1.0を-32767とする」こっちの方が素直かしらという感覚になるのが不思議。
signed整数型では +1.0 を表現できないんじゃなかったの？
signed整数型を [-1.0, +1.0-ε] の範囲じゃなくて [-1.0-ε, +1.0] として扱おうとしてるってことね。

unsinged のときは、255とか65535とかで掛けたり割ったりすると思うのでそれと一緒ね。

というか、まず、その整数型の最小値と最大値が [-1.0, +1.0-ε] を表すのか、[-1.0-ε, +1.0] を表すのかを考える方がよさそ。
unsignedでも 最小値と最大値が[0, +1.0-ε]なのか[0, +1.0]なのかを考えるのがよさそ。まぁ、unsignedは普通は後者だけど。

😌
コメント（0件）