堕天使の煉獄

Gallery
Comic
Story
Production
Work
Link

2025-02

27

07:31:48

富豪的に行くべき?

先日のビューを回転とかさせると、ジェスチャー時のアナウンス表示まで回転してしまってGraphicsViewに描いたら駄目じゃんの件。

最初はビューの回転をGraphicsSceneの方でアイテムを回転する方向に書き換えようと思ったのですが、そうか……Sceneの方で回転やらなかったのはアニメgifなどの動画形式がScene内のGraphicsItem(の派生クラス)の回転だとコストが高すぎる。
フレーム毎に毎度拡大縮小回転かける感じになってしまうので。
んで回転に関してはGraphicsViewに任せることにしたんだっけか。
じゃあこの案、没~。

Mainwindowに移すか?
と思ったけど、GraphicsViewのマウスイベントと競合する感じでなんかうまくイベントが受け取れない……。
描画も更新のタイミングが駄目なのかうまく描画されず。
コレも駄目っぽい。

んー、なんかビューの変更に影響しない描画方法ってのやっぱあったような気がするんだよなぁ。

ってことで調べてみたのだけども。

GraphicsViewの描画部分QPainter* pで

p->resetTransform();

を追加するだけでおkでした。

これでビューの回転やらリセットした状態で描画出来るようになったので、普通に描けるように。

やっぱあったね……。
随分遠回り。

んで、そこまで来た所で、ああコレ前に使ったじゃん……ってなったり。

むかーしに作ったwiz風3Dダンジョンのマップ作成ツールで、座標系をwizと同じく、左下を0,0の原点にしてy軸は上方向が+になるようにsetScale(1,-1)で垂直方向に反転したかんじのビューに設定して。

んでそこにツールチップ的なの描画する際に、そのままだと文字とかまで反転しちゃう~ってので、その時にもresetTransformやってたわと……。

一度昔に解決した問題でまた悩むとかとっても無駄な時間を……w


気を取り直して、カタログ表示部分を作り始める。

表示周りの外堀をガリガリ組みはじめたのだけども。
仮に表示部分のサイズを決めるところで、どうしようかなと。

問題は、サムネイルの画像サイズをどうするかというところで。

画面の解像度によって(いまは4Kとかもあるしね)サムネイルのサイズも変えたい感じもあるぽ。
画像サイズとメモリ使用量や読み込み速度、描画スピード辺りはトレードオフなのだけども、結構好みの部分もあるしで。

んで、当初の予定だと、パスから適当なファイル名生成して、フォルダ一つに1つキャッシュファイル作成して~て感じだったんだけども。

サムネ画像のサイズ変更のたびにキャッシュ全部作り直しだし、そもそもそんなにキャッシュ要るかな? という根本的なところから見直したほうがいいような感じもしてたりで。


んで、他のツールはどうなってるんだろ?
ってことでsusieは現物ないのでわからない。
でもおぼろげな記憶だと、サムネ画像のサイズは固定だったかな?
Thumbs.dbとか標準的なフォーマット踏襲してる感じだったし。

マンガミーヤを見てみると、

サムネイル表示(1画面)
サムネイル表示(8列)
サムネイル表示(カスタム)
表紙サムネイル

の三種類あって。

サムネイル設定のとこ覗いてみると、縮小に使うフィルタ選択はいいとして。

保存設定てのがあって、保存しないのと画像フォーマット指定して保存するオプションがある。

カスタムサムネイルのところを見てみると
[行x列]=[8x9]: バッファサイズ=1800x2528
予想メモリ使用量: 13.65[MB]

というヒントが表示されたり。
サムネイルサイズ指定に対してどんぐらいメモリ喰うのか指標をだしてくれるんだね。

幅が200高さが300に設定されてる状態なんだけど
バッファサイズが1800x2528てのは??

8*9だと計算合わないな。
そして一枚の大きいサイズの画像をバッファとして用意してる感じなのか。
なんかdirectXのテクスチャサイズの制限てきなアレ?
そんで描画の高速化も考えられてる感じっぽいですね。ドローコール減らす的な。
まあこのへんは最適化の話な感じなのでQtだとあんま関係ないかな。
Qtにほとんど丸投げ部分なので。

んで、リストの枚数が多い場合、画面サイズもといバッファサイズ超えたらもう一個分取得する感じなのかな。
大量にリストあるとき、画面スクロールした後で非同期読み込みしてるけど、スクロールもどしても再読込しないのでその都度バッファの開放はしてないっぽいですね。


なるほど、サムネファイル作らないで、メモリ上に置くだけで、保存はしない。
その方向のがいい感じですね。
その方式だとサムネのサイズも設定で変えても問題ないし。

そもそも、そんなカタログ機能って頻繁に使わない……くない? 個人的にはあんまり使ってないです。

たまーに大量の画像の中からあの画像何処だっけ?
って探す時にサムネ表示して見つけるために使うぐらいだったりで。

タスクマネージャでメモリの増減も見てみたけど、サムネ作ったあとも別のフォルダとか別の書庫に移動しない限りは作成したサムネはメモリ上に持ってるみたいですね。
で、別の場所に移動したら開放って感じで。

ふむう。

全部メモリに読み込んでキャッシュは保存しない方向で作る感じにしようかな。


オンメモリでも、キャッシュファイルに書き出す時でも同じなのですが、考えるべき点は、大量のリストの場合どうするかですね。

せいぜい数十~数百程度ならいいんですけど、数千~数万とかになると、一気に読んだり、全部保存したり大変ですしね。
そういうところまで一応考えて設計しないと駄目な部分なんだけど。

まあとりあえず組んでみてから考えるかw

実際に作ってみて、メモリどのくらい喰って、どのタイミングで開放するべきとかは現物見ながら考えよう。


なにげにまだデバッグモードだけどもメモリ消費量どうなってるかなと見てみたら、実行時画像ロード済みで20MBちょいぐらい。
拡大するともりもり使用量増えていく感じ。

綺麗に拡大縮小するために元画像を実際に拡大したpixmap持ってるからなぁ。
でもまあ特にムダに大きいってこともない感じぽ。

サムネ用の小さいサイズとはいえ、QImageの容量はどんなもんなんだろうね。
QImageじゃなくて小さいjpgとか生成してそれをバイナリで持つとかのが小さく出来そうだけどどうなんでしょね。
所詮サムネなので、画像が判別できればいいわけで。
そこまで画質にこだわらなくてもいいわけだし。
低画質にも限度はあるけどその限度は個人の感覚によるところではあるんだけども。

でも今の時代、数百MB程度ならメモリ喰っても普通なとこあるし、富豪的に作るほうがいいんだろうなぁ。

とりあえず、「完璧を目指すよりまずは終わらせろ」だよね。


それよりも、デバッグビルドしたらCPU100%にがつーんと毎回逝ってることに愕然としたw

おもにclang関係が重いんだろうけど、ビルド負荷重すぎだろと。

わりと最新のCPUでもそんなんなるとかいう記事どっかで見た気もするな。
ガッツリCPUパワー占有する感じみたいね。

clangのなんかいろんなプラグインとか取り込んで、便利になった部分もあるけど、かなり重くなったよなQtの開発環境。

以前の古いPCだと、clangbackend.exeとかいうプロセスがメモリもCPUも爆食いしてハングが頻発して使い物にならなくてclangのプラグイン切ってたけど。

しかしもう2月も終わりか。
ちょっと開発ものんびりしすぎかな。

もちっと気ぃ入れてさっさと終わらせないとな。

プロゴルファー猿 全153話とか見てる場合じゃないぞ(ぉ

2025-02

25

07:45:16

なんか……うーん

前回つけたボタンリスト。
あれから色々試してると……小さすぎて使いづらいなコレ。
となってきたりw


画像ビューワなので画像の表示を邪魔しないようにっていう意識が強すぎたのかもしれない。
ということで

o_020.jpg

サイドバーな感じにしてみたり。
マウスを左端に持ってくと表示される感じのオーバーレイボタンリスト。

見た目的&機能的にはウィンドウの左右の端に次のファイルと前のファイルのボタンがある感じが良い感じなんだけども、次のファイルと前のファイルの「送り」部分はウィンドウサイズ変わっても位置を変えたくないんだよなぁ。

両端にすると、左側のボタンはいいんだけど、右側のボタンは位置が変わりまくるので使い勝手悪い感じで。

この二種のボタンは性質上、マウスのポンタの場所を変えずにその場でポチポチ進めたり戻したりしたいわけで。

ウィンドウサイズ可変で右と下が変化するので、やっぱ動かない左上起点が位置としては鉄板なんだよなぁ。


左端に縦並びで次のファイルと前のファイルの2つだけで、ウィンドウサイズの大きさに合わせて二分割表示なんての試してみたんだけども。

これもウィンドウサイズ変わると下にある方のボタンの位置が変わるのであんまりよろしくない。

サイズ固定にすると、なんか左上にボタン2つってのも見栄えがイマイチ。
とりあえず他の機能のボタンで埋めてみるか?

ってことで上の画像な感じに。

ボタンの中はアイコンとかにしたほうが見栄えはいいんだろうけど、まだ色々と考え中なので、今はとりあえず仮で文字入れてる感じだす。

んーでも……なんか邪魔だなぁと……(ぉ
見た目に煩い感。

あと、縮小しまくるとボタンがどんどん圧縮されて潰れてくのも……
ある程度以上ウィンドウサイズ小さくなったら非表示にするとか要るかなぁ。
でもそれだと結局、マウスだけでリストの送りができなくなるのも……
一応右クリックメニューからも出来るっちゃ出来るんだけど、本末転倒感。
あちらが立てばこちらが立たず~


も一つの方向性として

o_021.jpg

とりあえず4方向だけのスワイプを実装してみる。
いまはとりあえず仮りで、どっち方向にスワイプしたのか表示してるけど、実際に運用する場合は「次のファイル」とかの機能の文字列を表示する感じで。

んで、左ボタンのドラッグはウィンドウサイズより画像サイズが大きい時に表示位置を移動する機能がデフォになってるので使えない。

ってことで、マウスの右ボタンによるスワイプにしてみたり。
スワイプ有効時は右クリックメニューを抑制な感じで。

んーまあ、マウスオンリーでぺぺいと次のファイル~とかやりたい&画面にボタンとかうるさくない。
ってな感じの要件は満たしているんだけど。

んー単純にPCでマウスジェスチャーあんま使わないから慣れの所為かなぁ。
なんかしっくりこないなぁ……。

起点から無効マージン少し取って、縦横ある程度の範囲内に終点有ったら~ていうめっちゃ簡易実装なのですが、まあ機能的には十分なんだけど。
複雑なジェスチャー機能つけても、そこまで設定するべき機能自体が無いしw

普通は移動位置を点でリストに記録して~とかやるんですかね。
一応firefoxではアドオンでジェスチャーの入れてるんですけど、結構複雑なジェスチャーの設定とかあって、こんなん自前で実装しようと思ったらけっこう大変だな……と。

一応Qtにもジェスチャー用のクラスあるみたいなんですけど、デフォだとタッチデバイス専用? っぽいですねコレ。
マウスには対応してないっぽい。
試しに入れてみたけど、マウスだとジェスチャーイベント自体発生してくれないぽ。
なんか独自拡張すればマウスにも対応できるっぽいみたいな記事もでてきたんだけど、もともとそこまで本格的なジェスチャー機能ほしいわけでもないしなーって感じで見送りに。


あと凡ミスで、ジェスチャー機能をQGraphicsView内に追加したんだけど、90度回転とかしたら、ドラッグ位置の線とか文字表示まで90度回転しちゃってワラタw

QGraphicsView内に追加したんじゃ駄目じゃんコレw
ちょっと考えれば分かることだったのにな。
凡ミス~。


むう~
「マウスのポンタの場所を変えずにその場でポチポチ進めたり戻したりしたいわけで」

てとやっぱ、suseiみたく、別窓で小さいウィンドウだしてそこで……ってパターンもやっぱ再考すべきかなぁ。

あと、別窓で小さいウィンドウの場合にも問題になるんだけど、画面最大化のフルスクリーンモードんとき、別窓だと表示されなくなっちゃうよねっていう。

そんでもって、前回の小さいボタンだと、全画面表示の場合画面の左上の端っこって、マウスのポインタそこまで毎度動かすのタルい……ともなったんですよね。

フルスクリーンだと、最下部もしくは、右下起点辺りにボタン群があると使い勝手いい気がする。個人的には。

フルスクリーンモードのことも考えると、ボタンの位置とか一筋縄ではいかないなぁ。
UIのデザインて難しいね。

2025-02

23

05:02:48

モノがないパターン

今日もニコニコPG中。

o_019.jpg

サブウィンドウでリストのツリービュー表示と、マウスをタイトルバー付近に持ってくと表示されるオーバーレイボタンなんかを実装。

右クリックメニューだと、次のファイルに移動するために毎度メニュー開くのタルいよね……てことで、そもそも項目作ってなくて。

現状キーボードのキーで出来る感じだけど、やっぱマウスのみでも次のファイルとかの移動手段は何か欲しいなと思って。

んで、元ネタツールのsusieだと、なんか小さいボタンが連なった小さいウィンドウでてたよねってことで、当初はそういうの作ろうと思ってたんだけども。

でも、正直画像ビューワで画像以外のもので画面が煩くなるの嫌だなーと。
画像ビューワと言いながら、ボタンいっぱいあるツールバー消せないビューワとかあるけどアレ無理w

んでもって、そのボタンツールバーみたいなの作るのは簡単だけど、ウィンドウに吸着させたりとか、並びが縦と横パターンとか、susieではいろんな設定あった記憶あるんだけど……設定作るのめんどくせぇっ! とか思ったり。

あと、このビューワ、表示モードが

・画面に収まる範囲でできるだけ大きく表示(ウィンドウサイズは自動&固定サイズ)
・縦サイズ固定でアスペクト比維持して横サイズ可変(ウィンドウサイズは手動で変更可)
・横サイズ固定でアスペクト比維持して縦サイズ可変(ウィンドウサイズは手動で変更可)

の三パターン……全画面モード入れたら4パターンか。

あるんだけども、基本的にはどれも画像の右と下方向に伸長する感じで。
なので、画像表示画面に付属する形でなんかボタン的なのつけるとしても、動かないのは左上なので場所的にはそこ一択なんですよね。

むしろそこ一択なら、どの位置につけるとかいう設定も要らないしそれでいいかなと。
ということで、マウスを上部に持ってきたら表示されるオーバーレイボタンを表示する方向に落ち着いたり。

んー、機能ボタンだけ分離した小さいウィンドウ出すのも有りかもだけど、やっぱあんま画面がゴチャつくのも好みじゃないんだよなぁ。

そして、susieのボタン連なってるアレ。
susieの現物をもう入れてないのでどんな項目あるのかわからんのですよねw

ちょっと前に、とあるツール作ったときも、あまりに古いツールなのでvc++6.0のランタイム要るとかで、そんなんいれるの嫌やねん。って感じで自作した感じだったんだけども。
そもそもランタイム入れるの嫌=現状動かせないってことで、現物を確認出来ない状態でおんなじようなツール作るのって結構シンドいな……ってなったんですよね。

ツールの使い方説明してるサイトの画像とかの少ない情報と記憶だけを頼りに作ったなぁw
今回も例に漏れず……てかsusieプラグインのサイトがちょっと残ってるだけで、susie自体を解説したサイトはもうほとんど残ってないですね……。


あと別の方向として、マウスジェスチャーで……てのも考えたんだけども。
複雑なのじゃなくて簡易的にドラッグで4方向の4コマンドぐらいだけなら実装簡単そうだし。
と思ったんだけど、ウィンドウサイズより画像が大きい場合、ドラッグで表示範囲スクロールになってるから駄目じゃん……ってなったりw

やっぱ画像ビューワなので、画像をメインに表示したいのでスクロールバーは邪魔だよねってことで、表示範囲スクロールは必要だしな……となってマウスジェスチャーは見送りに。



そんな感じで、あとはカタログ表示作ったら完成かな。

んで、susieのボタンリストの内訳とかないかなーとググってた時に出てきた記事で、susieのカタログ表示って、フォルダ内にサムネイルのキャッシュファイル作る方式だったのね。

んまあ、フォルダ毎に置いたほうが便利なのはわかるけど、今ではちょっと困ったことになること多そうですね。
ネットワークドライブ経由だったり、SSDとHDDのドライブで速度差考えると、キャッシュはSSDに置きたい~とか、SSDの寿命減るから遅くでもHDDでいいとか、いろんな考え方あるし。
該当フォルダ内に勝手に作るのは勘弁な(コング調)な感じですかね。
時代とともに環境も変わるので、随分昔に更新止まってるツールだとその辺でやっぱ問題でちゃいますね。
あとフォルダ毎にサムネファイルあると邪魔だしね。移動とか整理する時とか。

んでこれも現物無いので確認できないのですが、Thumbs.dbとかwinの標準なやつを作る感じだったのかな。
独自規格?
どうだったかさっぱり思い出せん。そもそももうwin7に移行した辺りからsusie使わなくなった感じだし。


んー、キャッシュの持ち方どうするのがベターなんだろね。

キャッシュ保存用の場所用意して(設定で場所指定可)、フォルダパス毎にキャッシュファイル作成な感じかなぁ。

キャッシュファイルは、ファイル名とサイズと最終更新日時とサムネ画像データの開始アドレスとサイズとかの入ったヘッダ部と、あとはサムネ画像データのセットとかでいいのかな。

Thumbs.dbのフォーマットググってみたけど、まあ大体そんな感じっぽいですね。

サムネ画像なんて小さい画像なので圧縮とかしても意味ないし、普通にシンプルなフォーマットになりそうなので、そんなむずかしいとこはないっぽい。

とりあえず終わりが見えてきたな。


パッと作れると思ったファイルリストのツリービュー表示ウィンドウが、以外に面倒っていうか、いろいろと忘れてて手間取っちゃったせいで時間喰ったけど。

デフォのQFileSystemModelだとソートをサポートしてないのでQSortFilterProxyModel使って色々とやるんだけども。

この辺利用する感じのツール作ったの随分昔のことで、該当パスのcurrentIndex拾ってくるだけでも一苦労w

QSortFilterProxyModel使うと、QSortFilterProxyModelからmatch(...)で取ってきたindexはmapToSourceでQSortFilterProxyModel→QFileSystemModelにindexを置き換えないといけない辺りとか完全に忘れてる感じで。

この辺の仕組みを思い出すところから始める感じで。
んでも一度動いちゃえばほとんど触ることもない部分なので、またすぐ忘れちゃうんだよな(ぉ


ふひ~。

2025-02

20

06:17:13

また雪降ってるお

一回寒いの来て、これでもうそんな寒くならない? 
と思ってたらまた雪~

まだまだ寒い~


そんな最中、相変わらずPGガリゴリ。

susieの代替ツール。
終りが見えてきたと思ってたんだけど、なんか縮小が汚くね?
ってなって。

あー。

書庫内の画像をなんやかんやするツール作った時のプレビュー画面でもそうだったんだけどQGraphicsView/Sceneて、高品質設定してもなんか勝手にプラットフォーム依存だかで綺麗に拡大縮小してくれないんですよね。
いまだにこの辺改善はしてない感じかぁ。

で、以前はどうしてたかと言うと、Scene内の画像自体を自力で縮小

pixmap.scaled(width, height, Qt::KeepAspectRatio, Qt::SmoothTransformation)

する感じにすると、普通に綺麗に縮小できるようになるんですけどね……。
そんなんしないで済むためのQGraphicsView/Sceneなんじゃないのかと小一時間……。

で、今までViewの方で拡大縮小回転反転処理してたのを、Sceneの方に……回転と反転はviewのままでいいか。画像自体に変更は無いわけだし。

そこではたと困ってしまう。

gifやらwebpやらのアニメ画像の方どうしようと。
こっちは動画なので、毎フレーム描画の毎に拡大縮小するのもどうなのよ? と。

……QGraphicsItemの派生で動画ファイルを入れるアイテムを用意してるのだけども、QGraphicsItemのscale()を使うと、単純にViewからこれが呼ばれてるくさいので、アニメ画像の方はscale()で対応することでなんとかなりそう。
でもこっち使うとviewで拡大縮小と同じ結果=縮小が汚いんだけども、速度面では速かったりするぽ。
QGraphicsViewは基本速度重視なのかねぇ。
オプションでクオリティ重視とか欲しいなぁ。(一応あるんだけど現状そのオプションは無視される仕様ぽ)

むー。

QGraphicsView/Sceneの仕組み的にはとてもコードもシンプルに書けていい感じなのになぁ。

拡大率によって可変する画像サイズにウィンドウサイズを追随させる処理なんかでは、QGraphicsViewから最終的な画像サイズ受け取ってそれを適用するだけで良かったのに、自前でやる方は拡大縮小後のサイズとか拡大率とかも用意して、横向きに回転した場合は幅と高さを入れ替えたり~などなど……
viewのなかで色々とやってくれてた部分を自前で書かなきゃならなくなったり。
ほぼQGraphicsView/Sceneまわり全部書き直し&コード量も増えるし複雑になるしその分バグも出るしで。

結局この辺組み直すので1日終わっちゃったですよ。
めんどくさー。

せっかく終わり見えてきたのに、2歩ぐらい下がってまた戻ってきた感じ~。

o_018.jpg

で、ようやく表示部分はだいたい終わって各種機能やら設定やらをグリグリと。
コンテキストメニューの項目がもりもり増えてゆくぅ。

あとはカタログ表示と、次のファイルとか前のファイル、上のフォルダ、サブフォルダに移動とかのファイルリスト周りぐらいかな。

あー全画面モードなんてのもあったな。

個人的にはあんまり使わない機能なんですけども。
でもたまに使うかもな感じなので、実装はする予定なんですけど、全画面モード中フラグとか用意してちまちま処理かくのタルいなぁ。

上記の通り、表示まわりかなりごちゃごちゃした感じになっちゃったので。
全画面モードもQGraphicsView/Sceneの真っ当な組み方だと楽に組めたのになぁ。
画像ビューワで画質が悪いとか致命的すぎるのでしょうがないぽ。


そいや開いた場所の履歴やらブックマーク周りなんかを組んでた時。
わりと参考用画像フォルダみたいなのにネットで集めた画像とかぶっこんでたりするので、ブックマーク機能とかは欲しいなと思うわけです。

で、そのブックマークの編集画面なんかを作ってた時の話。

登録されたブックマークの追加や削除、ソートや並び替えなんかを出来るダイアログを作ってたのですが。
保存して閉じるボタンを設置して~

「保存してほじる」

ぶぴっ

ただのtypoなのですが、めっさ不意打ちで、久々にモニタにコーヒーぶちまけちまったw

ていうか、なんでそういうタイミングに合わせたように飲み物口に含んでるんですかね。


そんな感じでじりじりとコーディングし続ける日々。気がついたら大型アプデ待ちのぐーまお旧版をやりだしたりもするよ(ぉ
コルダンも待ち遠しいよ~。

まあ小一時間程度気分転換というか、寝る直前にちょっとやってるぐらいですけど。
しょぼしょぼと目を開けてるのが辛くなってきたところで湯たんぽにお湯いれて寝るのがここ最近のお休み前のルーティーンぽ。
PCのケースファン買い替えたり、長年使ってたオーディオインターフェースが寿命で大往生して買い替えたりしたり。

で、ケースファン周りでbiosの設定画面とか見ること多かったのですが。

やっぱり電源周りにそういう設定ないっぽいよなウチのPCのbiosには……。

何がといえば、スリープ死のことです。
このPCは長時間スリープすると100%復帰しないで死にます。



スリープ死の原因として上がるのは、winの設定以外の部分では

・ディスプレイのドライバ周り
・USBの周辺機器
・biosの電源周りの設定

辺りだったりするのですが。

とりあえずウチのbiosにはスリープ時や復帰時に関係しそうな項目はまったくないぽ。

で、ディスプレイのドライバは結構前になんかの理由があってかアプデしたけど、特に変わらなかった(相変わらず死んだ)

USBの周辺機器は……

ゲームパッド繋いでると駄目とかいう記事も見かけて外してみたけど変わらず。
オーディオインターフェースのUW500も電源落としたり線抜いたりした状態でも変わらず。

ディスプレイのドライバ周りは、HDMIに繋いでると死ぬとか、逆に別の端子に繋いでるとスリープから復帰しなくなったとかいう記事もあったりして、結局相性問題による「おま環」て感じで明確な問題点がわからない感じで。

そんな感じでもうずっと、PCは電源入れっぱで運用してたんだけども。


色々と周辺機器刷新したし、あれから何度もwinのアプデも重ねてるし……。

試してみる?

と思い立つ。
やっぱスリープ出来ないのは不便なんですよね。
寝てる間もファンの音してるし。
ファンの寿命来たのもこの運用法の所為なとこあるし。

で、その辺の状況変わってないのかなと、ぐぐってみたらば。

時間指定して「モニタの電源を切る」の設定をオフにしたら復帰するようになった。

という記事が。
この情報は初見ぽ。

ええー。
たしかに、スリープ死の時って、なんかOS自体は復帰してる感じあるんですよね。
でもモニタが一切応答しない。
電源ON/OFFしても線を抜き差ししても。

スリープ中に時間経ったから電源オフのまま、二度と復帰しない感じになるとかアホすぎん?

とりあえず、時間でモニタの電源オフ設定を切ってスリープしてみる。

数時間後……スリープ復帰したっ!


えーこんなんでぇ??

いやでも時間でモニタの電源落ちないのは不便だぞ。
とくにこの時期は、ちょっと休憩ってお布団はいってヌクるとそのまま爆睡ての多い季節なので。

まあ今どきのモニタは焼き付いたりとかしないので、実害は電気代と夜中だと部屋が真っ暗にならないぐらいですけど。

でもまあ……なぁ。

とりあえず次の日、モニタの電源オフ設定を有効にした状態でスリープしてみる。

問題の原因は確認しておかないとね。



……スリープ復帰したっ!!


んんーwinアップデートで何らかの問題(バグ?)が解決したのだろうか?


win11でもスリープ死はするらしいので、win7では問題なかったのにwin10以降からずっと解決しない問題があり続けてたのは間違いないっぽいのですが。


んまあ、とりあえずスリープ出来るようになりました(なんだが腑に落ちない)

なんだかなぁ。




近況。
susieの代替ツール80%ぐらい完成。
あとは細々とした設定と設定画面(これが実は一番めんどくさい)作るのと、テストで別のプロジェクトで作ってあった別スレッドで順次表示な感じのカタログ表示機能を組み込んだら完成ぽ。

とっとと終わらせて次行きたいでつ。

でもこの時期ほんと、ちょっと休憩ってお布団はいるとそのまま寝ちゃったりして作業効率めっさ悪いんですよね……。

2025-02

13

00:26:54

さぶい

数日前の寒波&大雪のあと、ちょっと暖かくなったような気がしたんだけど、またぶり返したようにさっぶい。

去年はなんだかんだでそこまで寒い日なかったのか、一度も使うことのなかったダイソーで買った(300円だったかな? たぶん)湯たんぽがここ数日大活躍中。

ついつい冷え切ったお布団入ってすぐだと脇の側とかに置きたくなるんだけど、低温やけどとか怖いので足元に持ってくんだけども。

じんわりと温もりが足元から来るのを待つのがもどかしいw
でもやっぱ熱源あるだけで、お布団のなかの温もり違うなぁ。


そんな感じで、起きてるときはコタツでヌクヌクしながらPG中。


QOL上がる感じのツールをペチペチと作っている感じなのですが。


Rapture(おにぎり)っていう画面キャプチャソフトが便利なんだけども、ちょいちょいあの機能あればな~とかあって、似たようなの作ってみるかって感じでつくりはじめたものの。

Raptureの機能を細かく見てたら、あら、設定で実はできたのねって機能がポロポロと。
5%区切りとかの細かい表示倍率設定、デフォだとctrl+ホイールでできたんだね……。
ctrl無しでホイールのみで拡大率変えられるように設定変更。

元のホイールのみの動作はウィンドウの透過率だったんだけども、誤動作でよく透過率変更してたな……w

そして、拡大縮小が汚い! と言ってたんだけども、あるぇ? そんな全然汚くないぞ??

設定で「ズームを綺麗に」っていうチェックがあるのは知ってたし、チェックしてても汚かった記憶あるんだけどなぁ??

と思ったら、ああなるほどと。
このツール結構昔から愛用してるのですが、前のPC、win7んときはペンタブが遅延するとかでエアロ切ってたんですよね。

そんでこのツールも拡大縮小にハードウェア使えなくて汚かった……んじゃないかなと。

なのでいまのwin10だと普通に綺麗に出来るというオチっぽいw
先入観って恐ろしいw

なんか特に不満なくなっちゃったな……。
てことで、キャプチャツール作るのは止めることに。

でもまあ、Qtの仕様で最前面化する時に画面チラつくんだけど、ちらつかない方法(WinApi使う)とか試せたし。

キャプチャ周りとか、マルチモニタ用の設定とか、画面いっぱいのウィンドウとかの表示切替などなど、色々と知識は追加されたし無駄ではなかったぽ。

あとはRaptureでキャプチャすると、キャプチャされた範囲内で一番範囲占めてるやつのウィンドウタイトルを取得してるっぽいんだけど、それってどうやってるんだ??

とおもって調べてみたら、単純にキャプチャ範囲の中心位置の座標にあるウィンドウを取得してそこのウィンドウタイトルを取得してるっていう動作になってたり。

そうだよな……一番占めてる範囲のウィンドウを~ってすんげぇ処理めんどくさそうだぞコレ……って思ったんだよw



次にsusieの代替の画像ビューワ。
今とりあえず使ってるソフトは、avif非対応だったり、アニメwebpにも非対応だったり、アニメgifもなんかえらく重たい&回転すると止まる? とかちょいちょい不具合あって、とりあえずのつなぎで入れてる感じだったりで。
あと設定周りもなーんかそうじゃないっていう動作の物が多かったりするんですよね。


なのでこれも自分好みの作っちゃおうって感じで。

んでも、基本的に画像のロードとか表示の速度面なんかみてると、デバッグモードで動かしてる段階でも今作ってるやつのが軽快だったりして、Qtのライブラリは優秀なんだなぁとか思ったり。

だいたいメインの表示部分と機能の実働部分は出来てて、あとは設定周りと、susieっぽくカタログ表示とかそういうの追加したりしたら完成かな。
別スレッドで非同期にカタログ表示てのは結構前にテストコードで作ったことあるのでそれはめ込むだけだし。

んでもsusieプラグインも対応してるんだけど、susieのアーカイブは対応してないんですよね。
使うかなぁてのがあって。
昔はエロゲの画像抽出なんかでお世話になってたりもしたんだけどもw

そういう過去の遺産的なのて、もう使うことなさそうなんだよなぁ。
ていうのもその界隈、2000年代初頭ぐらいまでに使われていた感じで、基本32bit向けなんですよね。

なのでもうアーカイブ機能使う機会なさそうなんですよね。
今作ってるのは当然64bitアプリなので。

Qtの画像読み込みはかなり優秀で、わりと他のツールでは読めなかった画像ファイルとかも読めたりすることも多いんですよね。

なので、現状avif対応のためにsusieプラグイン使えるようにしてるって感じですね。
webpは結構早かったけど、avifはQtで標準サポートされる日くるんやろか。

webpはわりとどこでも見るようになったけど、avifはまだまだごくたまに見かけるってぐらいなので、このまま消えていくような気がしないでもないw

書庫ファイル対応なんかは……マンガミーヤの代替ツール作ったらそっちでって感じにして、こっちのは画像ビューワとして軽めの作りのままにしておこうかなとか。


とりあえず今後の予定を箇条書きしてみる。


 susieの代替画像ビューワ
 書庫ファイル内の画像をなんやかんやするツールのver2
 マンガミーヤの代替ソフト
 レコポンの代替ソフト


がとりあえず今後作っていきたいツール。

書庫ファイル内の画像を~とマンガミーヤの代替ツールはほぼ中身変わらなかったりする。
どっちも書庫内の画像ファイルのリスト取得して前者はプレビューとして表示して、後者の方表示するの自体が目的のツールになるわけだし。
大部分中身は被ってるので。

そんで書庫ファイル内の画像を~の方はすでに作って運用してる物の改良版を作ろうって感じなので、大部分は組み直しなので先は見えてる……逆にみえてる作業量の多さになかなか手が出せないでいる感じだっやりもする……。

レコポンの代替ソフトは以前からそのうち作りたいなぁと思ってる感じで。
ちょくちょくテストコードなんか書いてたりしてたりで。
midi周りの処理なんかはもうすでにノウハウあるのですが。
譜面表示とか、トラックビューをあれはQGraphicsView/Sceneでやるべきなのかな。リストウィジットとの組み合わせ?
いっそGuitar Proみたく、テーブルウィジットで1マス1小節みたいなのがシンプル?
とか、どこをどういうwidgetで構成して作るのかとかそういう部分がいまだにふにゃふにゃで固まってない感じで。
そもそも特化型でそれ専用に作る部分おおくて過去の経験からの流用部分があんまないんですよね。
いまだに先は長そう……ってかんじw


とりあえずマンガミーヤの代替まで作ったら、次はダンジョンRPGツクール的なのつくってwizっぽいゲーム作るのも早くやりたい感じだったり。

お絵描きもやりたいし。

まあ、ひとつづつ、一歩々々進めていくしかないな。
とにかく前進あるのみ。

2025-02

06

01:52:35

silent night

先日、PCのケースファンが一個逝ったのですが、逝ったのはケース上部に2つ付いてるやつの片方だったのだけども。

なんか逝く直前、結構な轟音と振動あった所為なのか、2つとも同じ製品みたいなので取り付けられたのも同時期? なので仲良く寿命だったのか、もう一個の方もなんか音が大きくなってきてる気がしてて。

マグネットで引っ付いてるタイプの防埃フィルタ除けてみると、ふぃぃぃぃぃんとそこそこ甲高い異音が。

あ、これも近いうちに完全に逝くな。

って感じで。

あとはオーディオインターフェースのUW500も逝ったので(こっちは完全に寿命ぽ)どっちも代替をアマゾンでポチったのが今日到着。

なにげにオーディオインターフェースはM-Track Duoていう5kぐらいの安物をとりあえずって感じで買ったのだけど。
背面のオーディオ出力の端子が普通の赤白のピンプラグでなく、6.35mmのタイプのRLだったので、RCA(オス) ⇔ モノラルフォン(オス)っていうコードもついでにポチったのですが。

M-Track Duoとケースファンは今日で、ケーブルの方は7日到着予定って書かれてたんだけど、なんでかケーブルも今日届いたり。
ケーブルの方は日本郵便でポストに投函だったけど。

まあ、早く届いて困るってことはないのでいいけどw


で。

ケースファンの箱開てみたらなんか接続プラグの形状が違う……。
なんか小さい。

前のは結構ゴツめのだったのに、買ったやつはめっちゃ小さい。

んんん? ケースファンでそんな形状がいくつもある??

普通に3ピンと4ピンの二種があるってぐらいしか見てないんだけど。

ケース開た状態でちょっぴり途方に暮れるw

でもまあ、MBに挿せばいいのか。
ってことで、今付いてるのは複数接続出来る延長コードっぽいので、根本は何処についてんだ?
と見てみると……んん?
なんか電源に繋がってるぞ??

調べてみたら、電源から直接繋ぐタイプのファンてのがあるのかぁ。
その代わりファンの回転制御はできないと。
別途ファンコンをつけるとか色々方法はあるらしいけど。

bios画面で見た最速設定になってるってのは、単になんにも繋がってないデフォルト設定状態だったっぽい?

どうりでなんかいじっても最高速のままで、ファンコン無いタイプのファンなのかなーと思ってたですよ。
4ピンなのに回転数変えられないじゃんてなってたけど、そりゃ電源直でついてたんならそこの画面からはなんにも弄れんわなw

いまググってみたら、ファン用電源変換ケーブルてのが出てきて、電源ユニットの4pin(大)コネクタてのが確かにいままでのファンについてたやつだわ。

MBに直接刺すのは4pin(小)のタイプなのね。

ほへー。
自作PCとかやったこと無いから、こんなん全然知らないことばっかりだよ。


じゃあ、MBに直接指すか……ファン用のコネクタ何処?

MBの基盤の文字小さすぎて見えねぇぇぇぇぇ!!

老眼鏡+ペンライトで照らしながら探す。

んー上部ケースファンのすぐ下にcpuファンてのが1,2と2つ並んでるんだけども。
ピンはおんなじ4pinだしここにつけちゃまずいんかな……。
そのままだとCPUの温度で回転数変わる感じになっちゃうけど、設定いじればMBの温度参照とかに出来るみたいだけど……。

うーん?

……あ、ファン用コネクタ発見。
一番下の方、左の方にFAN2、3が固まってあって、ちょっと離れた右の方にFAN4が。
……でもFAN1は何処にもないんだけど??

とりあえずFAN4のほうが近いかな。
と思ったら

ファンについてるコードの長さが足りねぇぇぇぇぇ!!

めっちゃギリ届くんだけど、途中にあるメモリに結構当たっちゃう感じで、それはなんかヤだなぁ……。

ファンの取り付け位置をちょっとずらしたら他のパーツに干渉しないでつけられるようにはなったけど、それでも結構ギリ。
ほんのちょっとだけマージンある程度の不安な感じぽ。


あと、配線まわり調べてたら、なんかケースの前面の下の方になんかファンが付いてる。

んん?
位置的にHDD冷却用なのかな??

このPCはストレージが2層式で下部に収納タイプのケースで。
そこの最下部にファンが一個ついてたんだけども。
えらく埃が積もってるんだけど、なんか変な埃のつき方してるな。

そもそもこのケース、前面部分は蓋がされてて、上部と下部に格子状の吸入口? がちょろっとだけ付いてる感じなんですけども。
前面に3~4個ぐらいケースファンつける用のフレームみたいのもあるんですが、ここにつけても上と下にちょっと吸入口あるだけじゃ意味なくね?
その吸入口に防塵フィルタつけるような仕組みもなさそうだし。
どういう設計思想??


でもこんな所にファンついてたんだな。
結構下の方に埋まってて気づかなかったよ。

てことは、未だに見つけられてなかったFAN1のコネクタに繋がってるのかな?

と、ファンに付いてるケーブルをちょいと引っ張ってみたらば……。

スルリんとコネクタが出てきたよ。


何処にも繋がってねぇぇぇぇぇぇ!!!!??

www

なんのために付いてるんだこのファンw

そうか……なんか埃のつき方妙だなと思ったら、ただ単に積もってただけなのかw

というか吸気も排気も関係ないとこなので、ウチに来る前からすでにホコリまみれのまま忘れ去れれてた感じ??

とりあえず取り外してみたんだけども、ファン自体に性能書いてあって、最大でも1000rpmとそんなに強い感じのファンではないっぽい。あと12cmサイズで。

今回買ったのは14cmのサイズで、最大が1500rpmのタイプ。

今回ケースファン買い替えるにあたって色々調べたんだけども、「ケース内は正圧になるようにしましょう」と書かれてて。

なるほど、吸入<排出になると負圧となって、ケースのいろんな隙間からも空気が入る=埃も入る。

逆に吸入>排出の正圧にすれは、ケースの隙間から空気は出ていくので吸気部分以外からは埃は入らないと。
考え方はクリーンルームなんかとおんなじなのね。

で、改めてPC見てみると、背面の排気のファンがもともとついてないんですよね。
今までは上部に2つ吸入のファンが付いてるだけだったりで。
まあ正圧にはなってるんだろうけど、排気がまったくなかったのね。

ほぼ一年ぐらい全く掃除してなかったんだけども。
ケースファンのところの防塵フィルタと、さらに百均で買った目の細かいメッシュの小物入れを乗っけてさらに埃よけ追加したりして運用してたんだけど、ケースの中はほんのちょっぴりうっすら埃ある程度しか埃入ってないっぽいし問題は無い様にも思える。

スロット差込部に何もカバーついてなくてフルオープンだし、自然排気オンリーな感じになってたっぽいんだけども、まあ一応正圧にはなってたんかな。ガバガバなんだけども。
でも排気がないのでエアフローもクソもない感じなのでわ?

とか、なんかよくわからない構成になってるなこのPC。
まあそれで排熱に問題出てないのだから別にいいっちゃいいんだけどさ。


んーとりあえず吸気の上部ファンは14cmのちょっと大きめのファンで回転数も1500まで回るので吸気は十分かな。
で、使われてなかったこの12cmで最大1000rpmのファンを背面の排気用に取り付けて見るのがいいんじゃないかなと。

吸入>排気にはなるし、エアフローも一応流れはできてるっぽいし。

ただ、相変わらずHDDと、MBの右下の方についてるSSDは全然冷えない感じなのがちょっと気になるけど。
上部ファンは最初は位置的にMBの右上部分に取り付けたかったんですけど、ケーブルが短すぎて届かせるために中央あたりに取り付けることになって。
なのでエアフローの流れ的にSSDの位置が外れた位置になっちゃったんですよね。

で、背面に排気用ファンを取り付け、FAN2のコネクタに接続。
こっちは位置が近いので楽々届く感じ。

んーFAN1は一体何処にあるのかは結局謎w

CPUファンがFAN1っていう位置づけという感じなのかなぁ??


で、PC起動してみたらば。
起動直後のフル回転だと、上部ファンめっちゃ煩い。

そのあとbios画面で見てみたら、上部も背面も300rpmぐらいで回ってて恐ろしく静か。

MBの温度で回転数上がる設定になってるけど、まあこのままでいいかな?
でも吸気>排気にちゃんとなるように、上部ファンはもうちょっと回転数上げたほうがいいのかな。

設定でsilentになってるのをStandardに変えてみる。
したら600rpmまで上がる。
でも全然静か。

調べてた時にみたけど、やっぱ1000rpmを超えたあたりから煩くなり始めるらしい。

んー以前のファンは電源直=ファンコン無し=フル回転だけども、まあファンの音はするけどまあこんなもんかな? ぐらいの音量だったので、こっちも最大でも1000rpmぐらいのファンだったのかなぁ?

こっちのファンはメーカーロゴ以外何一つ書いてないやつだったので、詳細は不明ですが。

てか詳細と、回転の向きと空気の流れの向きぐらいは必須で書いといてほしいですね。
そういう使う人への配慮が足りないメーカーさんは嫌いですw

今回買ったのはちゃんと風向きの方向の矢印が側面に書かれてたし。
回転数も電圧電流も表記されてたし。


んで。

なんか。

静かすぎて落ち着かねぇぇぇぇ!!!!

ってなってます今w

ちょっと耳を澄ましてみると、ああ、なんとなく微かにファンの音聞こえるかな?

と思ったらら、コタツのヒーターの音でしたw

コタツの音なんて今まで気になったこともなかったのに、静かすぎて初めて意識した感じにw

ここ数日かなりファンの音が大きくなって来てたので、落差が大きすぎる所為なんだろうけど。

まあしばらくしたら慣れるかなw

とりあえず静かにもなったし、今のところ冬なので冷却足りてるのかとかの判断よくわからないのでアレなのですが。
夏あたりで問題あるようならファン用の延長&タコ足配線買って、もう一個ファン増やすとかしましょうかね。

ていうかしばらくのあいだsilentモードで動かしてたけど、この時期だからなのか、なんも問題なかったんですよね。
むしろファンレスで動かしても動作自体には問題でない程度の発熱しかないんじゃないかこのPC。

去年の夏頃、なんとなくやりたくなったFF12やってたときはめっちゃ熱くなってて冷却足りなくなってたけど。
まあそんな発熱気になる高負荷のものって他に普段やらないからなぁ。

ミンサガはえらく低負荷だったなそいえば。

というわけで、ファン問題は一応解決ぽ。


つにでにこの辺調べてた時に出てきたライフハックで、百均で売ってるご家庭のキッチンの換気扇用の換気扇フィルターをケースファンの防塵フィルタとして使うってのがあって。

このPCうちに来た時、上部から吸気ガンガンするかんじなのかーホコリ対策もっとしたほうがいいな……ってことで、ダイソーでなんか使えそうな布とかないかなーって探したんですよね当時。
結局は網目の細かいメッシュの小物入れポーチ? みたいなのを買ったんですけど。
普通にファンの上の元からあったマグネット貼り付けタイプの防塵フィルタの上に、なかに不織布のウエットティッシュ広げたヤツ入れたポーチを置いとくだけって運用にしてたのですが。

それでも十分埃フィルタとしては機能してたんですけど、やっぱどうにも不格好さはあって何かもうちょっと良い方法ないかなぁとは思ってたんですよね。

したら、今回色々見てたらその買ったやつと多分おんなじヤツを分解してメッシュ部分だけ取り出してプラ板加工してメッシュ部分を固定して防塵フィルター自作してる記事とかも出てきたりしてちょっとおもしろかった。


んで、換気扇フィルターとは全く盲点だったなぁ。
ってことで早速買ってくる。
ううむ。
換気扇フィルターという用途からして換気扇の前につける=通気性は保証されてるわけで。
まさに適材じゃないかと。
マグネットタイプの防塵フィルタのサイズよりも各辺1.5cmぐらい大きめに切り出してマグネットの下に織り込む。
それだけだとちょっと掃除のたびにめんどくさくなりそうなんだけど、瞬着とか両面テープとかはなぁ……。

なんかこの、マグネットタイプの防塵フィルタ、結構いいお値段するみたいなんですよね。
そんで、サイズも合うの探すのも大変そうだしで。

なので、こっちを破損とか汚したりとかしたくないなぁってのもあって。

結局、昔なにかの用途でこれまたダイソーで買った、紙製のクリップで適当に止めることに。

まあ多少不格好だけど、前のよりはスマートになったかな。

掃除も楽そうだし(めっさ重要な点)



次にM-Track Duo。

今どきっぽくインスコ用CDとかなくて、ネットからドライバダウンロード。
ドライバ無しでもとりあえず標準のUSBオーディオドライバでも動くみたいですけど。
ダウンロードしたやつじゃないとasioドライバとしては機能しないとかなんとか。

付属ソフトのDAWとかは、いまはまあ要らないかな。
使う当てないし。

で、接続~。

なんかレビューみてたら、ボリュームのつまみが1~9まではほとんど音がしなくて9~10の間でしか音量調節が効かないとか(でもこれはマイクの入力の音量の話っぽい?)
ノイズがーとか音質はまあ値段相応。

とかちょっと不安なレビューもあったんだけども。
まあ5kならいいかーって感じで。

……ボリューム3ぐらいですでに爆音なんですけどw

耳の健康のために2.5ぐらいで止めてる感じです。

音質については……ここ最近までの、PCのヘッドフォン端子に差したのに比べればやっぱ雲泥の差かなぁ。

5k程度でこの音質なら全然問題ないですね。

ヘッドフォンも長時間のつけ心地優先でオープンエアタイプなので、音質の良し悪しはそんな判断できる感じではないけどw


PCのヘッドフォン端子はやっぱ駄目ですねとつくづく。
あとちょいちょい「ブツっ」てノイズ走るんですよねPCのヘッドフォン端子。
どしてもMBのノイズ拾っちゃう感じなんですかね。


あとはいま冬なのでわかんないんですけど、発熱とかどうなのかなぁ、と。

uw500はかなり熱でたので、水満たした500mlペットボトルを上部に置いて冷却してたしw

でも電源別だったからなぁ。
しかも20年ぐらいまえの機材だし。

今どきのだと内部の機構とかもっといいものができてる感じなのかな。
USBのバスパワーだけで動いてるし。
ボリュームが最大10まであるのに3ぐらいで爆音になるぐらい出力デカいし。

なので大丈夫そうな気もするのですが、熱の問題とか出ちゃうと、基本24時間つなぎっぱなので、電源on/off機能無いのもちょっと気になる所。

まあこの辺も追々様子見していく感じで。

とりあえず現時点では特に不満はないですね。


……ただまあ、たまーにヘッドフォンじゃなくてスピーカーで音流したい気分のときもあったりするので(真夏とか特に)一応卓上の小さいスピーカもあって。
そこに接続用に今回ケーブルも買ったのですけども。

とりあえず音出し確認はしたんですけど、この卓上スピーカ。
たしか1500円ぐらい? もうちょっと安かったかな?
の安物なんですけども、買った当初からちょっと音量つまみの接触不良があって。
片方しか音が出ない&爆音になる症状でてて。
この製品のレビューにもこの症状訴える人多くて。

単純に構造的な問題みたいですね。
ボリュームのつまみと配線が繋がってる部分も動いちゃって、もう片方のスピーカの配線と短絡したりしちゃうらしい。

そんで、中身の配線修理しようと思うと、接着剤でガッチリついてるらしくてぶっ壊さないで分解するのはかなり困難な作りらしいw

使用頻度が低いので、何度もつまみをいじってたら正常になるタイミングあるのでだましだまし使ってる感じなんですけども。
最近その正常になる頻度が下がってきてるんですよね……。

ただ、使用頻度が低いのでもうちょといいの買うかってと、そこまではいいかなぁって感じだったりで。

もっと大昔に買ったPCについてたスピーカもあるのですが、こっちは電源をコンセントに繋がなきゃいけないのと、ウーファーとツイーターのセットの構成で、ウファーユニットから分岐してツイーターにって感じで、めっちゃコードがいっぱいグネグネついてんですよね。
基本的にはPCデスクなんかで、足元にウファーおいて、卓上にツイーターな感じ想定しててすんごい長いコードがぐねぐねとw
コードは机の後ろに隠れてるから気にならないから良いでしょな感じぽ。


でもいまうちの環境はコタツのうえにモニタ置いてる感じなんですよね。
その後ろにコードグネグネとかいやんです。

ちな安物のスピーカの方はusb電源で、卓上にほかのusbで給電するタイプの様に卓上にUSBタップあるので、そこにつけるだけで。
あとはオーディオ端子つくだけでコード類が煩雑にならないってところがメリットで。

音質よりも利便性優先な感じなんですよね。

そもそも基本はヘッドフォンばっかで、ほんとにたまにしか使わないってのもあるしで。


でも、大昔のアナログのテープとかたまに聴きたいなってときもあるので、ミニコンポとかも欲しいかなーなんて思ったりもするんですけどね。
でも今どきカセットデッキ付きとか無いよねぇw

今ググってみたけど、結構「中古」っていう選択肢のほうが多いですね。
そしてそこそこ良いお値段w

一個14,080円てのあったけど。

んでもそこまで使うかなぁてのがやっぱりなw
買ったら買ったで場所取るしねぇ。

CDなんかもほとんど仕舞っちゃって触る機会もないし。
ラジオなんかも相変わらず収集だけは続けてる伊集院さんの深夜のバカ力以外は聞く気もないし。

そうなると、外部入力でスピーカーだけ使う用途がメインにしかならなそうなんですよね。

そうなると、スピーカだけ買って、カセットデッキだけ個別でいいかなーと。
ただカセットデッキ、結構前に調べたことあったんですけど、結構ステレオ非対応でモノラルのみの機種多かったんですよね。

でも今見てみたら、結構5k程度でusb接続ありのタイプちょこちょこ出てきてるな。
でもよくわからない謎のメーカーだったり、レビューみるにこりゃ駄目だっての多いけどw
乾電池駆動が多いのも気になったし。

重い腰を持ち上げるような感じにはならない感じぽw


そんな感じで、壊れた機材の刷新終了~。

2025-02

03

23:24:06

遊びすぎだな……

LatelyLoreっていうフリゲやってたら1月終わってたよ(ぉ

去年にver2を最後までやって。
そのあとver3てのが来てて、でもしばらく細かい更新が続いてて、更新が落ち着いたところでやり始めたんだけどもいろいろと追加されてるなぁ。

で、結局130時間超え……あそびすぎぃw


ちょっと正気にもどっていろいろと作業再開。

その前に、PCの上部に付いてるケースファンが一個、こないだ逝ったのですが。

逝ったのは2つ付いてるうちの一個だったのですが、とりあえず一個外して見たところ冬ってのもあってか温度気にするほどでもなかったので特に問題なく……したらなんか残ってた方もなんかちょっと異音がしだしてるんですけどぉ……。


両方とも同時期に寿命迎えたのかね。
逝った一個目、最後は轟音と振動すごかったので(家の表になんか長く車停まっててうるせーな……と勘違いしてたぐらい)、振動でやられちゃったのかしらん。


そんでオーディオインターフェースのUW500も死んじゃったので、送料まとめてしまえるのでケースファンとオーディオインターフェースを買っちゃおうかなと。


ケースファンは前のは120mmのが2個だったんだけども一個でもなんか十分冷却性能足りてるくさい感じだけど、夏になったらどうだろうかなーてのもあるんだけど、このPCケース、140mmもつけられるみたいなので、140mm1基にしてみようかなと。

というのも、もとから付いてたやつはコネクタがオスメス両方ついてて何個もマウントできる感じのだったんだけど、アマゾンでみてるとそうなってるの全然無いっぽくて。

ファン2つつけようと思うとマザボに刺すところから二股になってるケーブルも必要っぽい?
pwmとかいうファンの回転数可変するやつなんかだと、タコ足でつなぐとみんなおんなじ回転数になるみたいなので、同じ場所につけるのならタコ足配線にしたほうがいいっぽいんだけど。

あとはファン逝ったときにbiosの設定もちょっとみてたんだけど、もともとファンの速度は最高速度固定の設定になってたんだけども。
このPC貰い受けたときにその設定ってことは、じつは冷却性能いっぱいいっぱいだったりするん? 単に冷えるだけ冷やそうぜって感じ? よくわからんw

で、とりあえず一個でもサイズ大きい140mmなら冷却性能的にもまだマシかなーというのと、ケースファンなんて買うのはじめてなので良し悪しとかわからんので、いきなり2個買うのものなぁってのもあって。お試しでとりあえず一個買ってみる感じで。
1kぐらいの安いのなので、どうなんでんしょね。


んでオーディオインターフェースの方は、とりあえず5kぐらいの安いのでいいかなと。
今のところ本格的に音楽制作とか出来る状況でもないし、つなぎな感じでいいかなと。

やっぱPC本体に付いてるヘッドフォンジャックだと、なにか音を出すとなり始めに「ブツっ」っていうノイズ入るし、音質もそこまで酷くはないけどやっぱちょっと物足りないかなというのもあって。


しかし、結構昔の常識からすると結構変わってるなぁと。

最近ではファンタム電源対応でもusbのバスパワーのみで電源別とかじゃないのね。
なんとなく電源別のが良い様な気がしてたんだけど、安いモデルだとバスパワーのみってのが多いぽ。

スマホとかノートPC向けで取り回し重視っぽい感じ?

ウチだと24時間ずっと繋げっぱなしなので発熱とかどうなのかなーとか、耐久性とか気になっちゃうけどどうなんでしょね。
まあ5kなら1~2年も持ったら御の字かな。

M-Track Duoってヤツなんですけど。
まあ音質は値段相応らしいですけどw

んでもM-Track Soloっていう、ちょびっとだけ安いモデルもあるのだけども。
M-Track Duoの方はアウトプットのツマミがマスターとヘッドフォンで別になってるのがいいなーと。

あとなんでかsoloの方はヘッドフォンの入力端子がミニプラグなんですよね。
背面のオーディオ出力はRCAピンプラグ(赤と白のアレ)で。

Duoの方はヘッドフォンの入力端子が6.3mm標準ジャックなので、こっちのほうがいいかなーと。
ミニプラグだと差込口の安定性とか、コードに負荷かかりやすくて断線怖いし。

と思ったら、Duoのほう、背面のオーディオ出力が6.35mmのタイプのになってるし……

たまに卓上のミニスピーカーで音出したい時もあるので、以前はUW500のRCAピンプラグから線つないでたんだけども、6.35mm*2のなんて無いぞ……。
ってことで800円ぐらいのRCA(オス) ⇔ モノラルフォン(オス)っていうコードを買うことに。

ヘッドフォンが6.3mm標準ジャックなのはいいけど、なんで背面まで変えちゃったのかコレ。
安価でもともと音質にそんな期待してない価格帯なので、普通にRCAピンプラグでいいのにぃ……。

まあ、今後なにかで使うかもしれないし、まあいいか。


そんな感じで壊れた機材の代替買ったりとか、環境整備的なこと初めたついでに、今後の予定にも関わることだけど、ツール周り見直してみたり。

ランチャーソフトのCLaunchの設定ちょっと見直していろいろ変えてみたりとか。

普段よく使ってるツールのver上がってないかなとか調べて見たりして。
キャプチャソフトのRaptureはもう更新なさげかなぁ。
したらなにげによくある、「コレだけ入れておけフリーソフト」的なサイトにぶち当たって。

Raptureはじめ、Flexible RenamerとかMeryとかわりかし使ってるよってのが多かったりしてw

でもコレ系はなかったなと。
Cliborっていうクリップボードの履歴残るやつ。

pgとかでコピペした後でちょっと前にコピペした文字列が欲しいって時ちょいちょいあったりするし。

ということで導入。

んんー基本的な部分は便利なんだけど、あんま使いそうもない機能も多いかな。
履歴出るだけで十分w

あと配色変えれるんだけど、色設定テキストで一括で設定できるんだけどもその設定の色コードがなぜかARGBじゃなくてABGRな並びになってて、なんで設定した色が変なんだってしばらく悩んだよ……。

Direct3D9とかでABGR並びとかあったっけか。
でもあんま一般的でない並びだよね。
なんでこんな設定方法になってるんだか……。


で、Raptureは大変便利に使ってるツールなのですが、泣き所が一つ。
拡大縮小が汚い&数段階(25%、50%刻み)しか無い。

割と画像検索とかで出てきた画像を参考にして作画したりなんて時にもよく使うんですけど、ペイントソフト上に最前面表示で表示する都合上、あんまサイズがデカすぎても画面占領して困るわけで。

そんで、縮小して全体像見たり、一部拡大して細部を確認したりとかで、高画質かつ数%刻みの拡大縮小機能があればなぁと思うこと多くて。

あとは画像の保存周りの設定ももうちょっといろいろあるとなと。


なぜか冬コミの原稿やってる時期に毎度MSさんはアップデートぶち込んでくるんですよね。
大量にRaptureでキャプチャした参考画像が開きっぱなしで、再起動とかやりたくないんですよね。
で、寝て起きたら勝手に強制リブートされてて全部飛んでてファッキンってのが去年……じゃなくて一昨年か。あったんですよね。
まあsai2の保存してない数時間分の作業も吹っ飛んだけど。
保存しないのが悪いと言われりゃそれまでだけど、疲れ果ててちょっと横に……そのまま爆睡、はっと起きたら再起動されてたって落ちで……。
ファッキンMS。

で、キャプチャした画像もデフォでどっかに履歴残ってたりとかしてて欲しいなとか。(一応キャプチャ画像を指定フォルダに書き出す設定あるにはあるけど、unicode周りでフォルダ指定がなんかバグってるっぽい?)
一括ファイルに書き出すとか、いろいろとアレコレ機能欲しいなってことで、じゃあ自分で作るしか無いかなという感じぽ。


もう一つ、susieの代替的なビューワソフトも作りたいなと。

これも参考画像集めたフォルダの中身を順に表示とかしつつ、表示サイズを自由に変えたりとか最前面にしたりとか。

なかなか絵の資料として表示しながら~っていう用途で使おうと思うとなかなかコレってのがなかったりして。
結局これも自作するかなという感じで、作りかけてるのがすでにあったりするのですが。


なぜ作りかけかと言うと、いろいろと方向性に悩んでる所為で。

アプリ本体は二重起動禁止にして、子ウィンドウで追加していくパターンと、画像一枚ごとに独立して起動するタイプどっちのがいいのかなぁとか。

前者は一括で閉じたり保存したりがやりやすい。でも管理が煩雑。
後者は取り回しはシンプルでいいんだけども、タスクバーにタブが溢れる、設定ファイルの扱いに難あり。

などなど、メリット・デメリットそれぞれある感じで。

そこに、基本的には表示した後の処理(拡大縮小、最前面表示…etc)って、キャプチャソフト作ったとして、キャプチャした後はその部分ほとんどおんなじなんですよね。

なので、画像ビューワにキャプチャ機能も持たせちゃう?
いやでも画像ビューワは今開いてる画像ファイルとおんなじ場所の画像ファイルのリストとか取得してなんやかんやする作りなので、キャプチャした画像の場合は……。


……キャプチャ履歴保存するフォルダのリストにすればいいのか!


なにげに、書いてる途中までは考えまとめながら書いてた感じで、概ね結論としては、やっぱキャプチャソフトとビューワソフトで分けて作るべきかなぁ……。
キャプチャしたときとファイルから開いたときで処理分けるのめんどくさいし……。
なんて考えてたのですけど、キャプチャ履歴保存を巻き込めばそのまま行ける感じになりそうだな……。

そうなると、画像毎に個別起動のがやっぱいい感じかなぁ。

ただ、キャプチャ履歴って、結構動画の1シーンなんかだったりすると、うまくキャプチャ出来るまでなんども繰り返したり、必要ない失敗画像も大量に出ちゃうんですよね。
単純にキャプチャしただけじゃなく明示的に保存(一時保存的な感じ)で~とかなんかいろいろと融通効かせる感じにしたいかな。

なんか色々と見えてきたかも。
やっぱこうやって文字で書いたりしてると考え纏まってくるですね。


んでもこのめんどくさい部分って、結構windowsの問題が絡んでる部分おおくてですね。
開発は基本Qtでやるのですが、winプラットフォーム固有の操作だと対応してない機能あって、結局winApi使って泥臭くやるしかないとなると、結構うんざりするんですよね。
そういうのもう触りたくなくてQtやってるのにねw

例えば二重起動禁止とか同名ツールのプロセス名から検索して一括で閉じるとかそういう処理。

あと作りかけのプロジェクト久しぶりに開いてみたのだけども、そいやコレどうすんだ? と悩んで詰まってた所で停まっちゃってたんだっけってのを思い出したり。

ウィンドウの最前面表示の部分なんですけど。
Qtで提供されてる方法としては

setWindowFlags(windowFlags() | Qt::WindowStaysOnTopHint);

とかやるんですけども。

この方法だと、最前面化はできるんですが、なぜか一旦ウィンドウを閉じちゃうんですよね。
なのでこの後show()しないといけないんですけど、一旦閉じてまた表示するのでちらつくんですよね。

そのへんのソフトで最前面化on/offしても画面ちらついたりなんかしないわけですよ。
なのでちらつかないで最前面化切り替えする方法ないんかいな……。

って所で止まってたりで。

んで今回調べてみたら一応あっさり解決したのですが。

::SetWindowPos( hWindow, HWND_TOPMOST, 0, 0, 0, 0, (SWP_NOMOVE|SWP_NOSIZE|SWP_SHOWWINDOW) );

結局winApi使わないと無理っぽいw

なんでも最前面化する場合、内部的には親ウィンドウ(最上位はデスクトップ?)に登録し直す処理をやってるみたいで。

そこでQtの場合はsetWindowFlagsで再登録の際に内部でsetParentてのが呼ばれて再登録みたいな処理をやってるらしい。
で、その中にウィンドウを閉じる処理が書かれてて。
setWindowFlags使うとウィンドウ消えるのはそれがデフォルト処理と言わんばかりに強制でどうにもならない仕様らしい。
Qtはクロスプラットフォームなので、win以外でそうしないと都合が悪いプラットフォームとかあるからそうなってるのかもしれない?

とにかく、setWindowFlags使ったらどうやったって画面がチラつくのは避けられないっぽいですね。

で、win固有の処理としてWinApiからやれば問題なくちらつかないで最前面化のon/off切り替えが出来るように。

うむう……こういうwin固有の問題やめてほすぃ……。


そんな感じでしばらくはツール周り色々と作っていく感じで。
そこへんの充実が、お絵描き環境の向上にもつながる感じなので。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
遊びすぎだな……
04
05
06
silent night
07
08
09
10
11
[建国記念の日]
12
13
さぶい
14
15
16
17
18
いつのまにか出来るように
19
20
また雪降ってるお
21
22
23
モノがないパターン
[天皇誕生日]
24
[振替]
25
なんか……うーん
26
27
富豪的に行くべき?
28
total:2117235 t:67 y:1106
■記事タイトル■

■年度別リスト■
2025年 2025年12月(0)
2025年11月(0)
2025年10月(0)
2025年09月(0)
2025年08月(0)
2025年07月(0)
2025年06月(0)
2025年05月(0)
2025年04月(1)
2025年03月(3)
2025年02月(8)
2025年01月(3)
2024年 2024年12月(1)
2024年11月(2)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年 2023年12月(3)
2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年 2022年12月(4)
2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年 2021年12月(8)
2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年 2020年12月(3)
2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年 2019年12月(1)
2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年 2018年12月(1)
2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年 2017年12月(2)
2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年 2016年12月(7)
2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年 2015年12月(7)
2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年 2014年12月(12)
2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年 2013年12月(15)
2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)

■レス履歴■

2023-09-26 14:59:38 - 久慈光樹

2023-09-26 14:29:10 - 織田霧さくら

2023-09-26 13:10:45 - 久慈光樹

2023-03-20 05:30:16 - 織田霧さくら

2023-03-15 20:42:58 - まうる

2022-12-26 19:14:57 - 織田霧さくら

2022-12-25 02:28:36 - まうる@まるるん

2022-09-30 04:29:01 - 織田霧さくら

2022-09-23 19:01:29 - まるるん

2022-06-16 21:06:34 - 山本


■ファイル抽出■

■ワード検索■

堕天使の煉獄

https://rengoku.sakura.ne.jp
管理人

織田霧さくら(oda-x)

E-mail (■を@に)

oda-x■rengoku.sakura.ne.jp

堕天使の煉獄バナー 堕天使の煉獄バナー