JVC HA-FD01SP

 以前JVC HA-FX850を購入したのもあって、イヤホンの相性的には最近はJVCの方があっているような気がして、新しく買ったWalkman(WN-A55)向けに用意してみた。
 その前に SONY WI-1000Xを用意してみたものの、Walkmanのイコライザ設定をbluetooth接続時に引き継いでくれず、スマホで設定を弄らないといけないというのが(持っているスマホが古くて、設定アプリが使えないという…orz)問題で結局使う以前の話になってしまった。

 この製品の売り口上は「透明感のある伸びやかな音質」、「クリアで伸びのあるサウンドを実現するフルステンレスボディを採用。高い強度を持つステンレスにより、音の雑味を排除。高い質感とソリッドなサウンドを表現するとともに、伸びのある高域と輪郭のある低域を実現します。」ということで、基本的に音をクリアに聞けるのが売りです。

 得意なのは中高音。音をスッキリ聞かせるタイプのイヤホンで、ウォームな響きを売りにしているHA-FX850とは対極な感じ。
 別にFD01が響きを疎かにしているというわけではなくて、響かせ方がじわっと余韻に浸らせるよりもスッキリ聞かせる感じ。「ヌケがいい。」という表現になるのかしら。
 音像が割とクッキリ聞こえる。FX850はどこか角の落ちた音像になって、パート毎に音を区別して聞く感じではないが、FD01は比較して区別が付けやすい。
 FX850は音場に拡がりを感じさせる鳴り方だったが、それに比較すると音場は薄い。頭の中でなる感じが強い。パッと見には開放口が見当たらないので、その辺りの都合があるかもしれないが、そのぶん音漏れが少なそうな作り。
 たぶん、FD01は音がクリアに聞こえるぶん感覚的に拡がりを感じにくいのだと思う。ただ音像がハッキリしているせいなのか、頭の内側に向かって奥行き感を感じる。(FX850は、むしろ周りに拡がったような印象)

 また、このイヤホンはハイレゾ(Hi-Res)仕様で周波数帯が特に高音の方に少し広く取られている(8Hz-52kHz)ということだが、正直周波数の影響がどういう違いを生むのか自分には判らなかった。
 
 
ファーストインプレッション:

 鳴り方が素直。クリアな音という通り、特に中高音が聞きやすくて、ポップスや電子音楽向きな感じ。
 高音が出るという性格付けっぽいが、特に音が耳に刺さる感じがない。
 音量絞り気味だと、低音がどうしても弱く感じる。

 それと、(パッケージから出したばかりもあるかもしれないが)凄くソリッド感の強い音。
 ケーブルが豪華。FX850の貧弱なものと比較すると、凄く高級感があって、いかにもシールドされてる感がある。逆に、ちょっとゴツイとも言える。
 本体も重い感じ。FX850も重いけど、ボディがステンレスなぶんこっちの方が重そう。(カタログスペックで1.5倍ほど重い。FX850も重いと言われていたので、これはなかなか重量級っぽい)

 あとFX850の頃とは違って、シュア掛けしやすいような作りになっていた。(自分としては、特にこだわりがある所ではないが、設計的に掛けやすくなったのは評価ポイントかも。)
 本体重量もあるので、もしかするとシュア掛けで耳の上からケーブルで下げる感じにしないと本体を安定させにくい場合もあるのかもしれない。
 

悪いところ:

 どうしてもFX850と比較してしまうが、低音の線が細い、というか薄め。
 Walkman WN-A55の場合、イコライザで低音域を持ち上げつつ、別機能で拡がり感を追加したりしない場合、音源によってはひょろっとした音に聞こえてしまう。自分は低音厨ではないのだが、低音厨には辛そうだなと思った。
 主にロック系の重低音がキモの音楽に合わせづらいのかも。(意外やオーケストラなんかは自然に聞ける。ただ太鼓系メインだとどうだか判らない。)

 
 ともかく、FX850とは対極。というのが現在の印象。
 どっちがいい悪いではなく、気分に応じて変えればいい感じの性格の違いだと思った。

 ちなみに、Walkman(WN-A55)に合わせるなら間違いなくHA-FD01が自分の耳にはフィットした。
 価格は、新品購入価格3.6万だった。(SPでなければ、2.8万ほど)
 音を考えると普通の値段かと思う。今回自分はクリアに鳴るイヤホンを求めていたので「フィットしている。」と感じたが、低音に明らかな弱点を感じるので、それを受け入れられない場合はかなり高く感じるかもしれない。
 購入する場合は、音質調整機能が充実しているプレーヤとセットで使う事も考えていた方がいいかもしれない。

 付属のノズルが複数あり、交換すると鳴り方が変化するそうなので、もしかするとノズル交換で低音の状況は好転するかも。
 ただ、低音が増せば他は埋もれる傾向は否めないので、結局は取捨選択する事にはなると思われる。
 暫くは、標準のノズルで楽しむつもり。

その後

 どうしてもWalkman(WN-A55)の音に納得がいかなくて、結局NW-WM1Aを購入した…
 素直に音源の音が出るというだけで、それなりにお金が必要。ということを痛感してしまった。

 お陰で、音質調整なしで納得いく再生音に変わった。
 幾ら良いイヤホンを買っても、元の音が気に入らないのではどうしようもない。ということらしい。

 悩むくらいなら高いのを買え。みたいな格言もあるらしいが、正しくそんな事例だった…

その後のその後

 FD01よりもFX1100の方が、音が繊細な感じに聞こえる気がする…
 FD01は現在ノズルをりん青銅に変えているけど、比較した印象では繊細な響きを感じない。

 単に、イヤーチップがまだフィットしている状態にないのか、ドンシャリ系のFXの方が好みってことなのか…判断つかず…モヤモヤは続く。

[PySide] Maya、Windowsスタンドアロンの記述

少し記述に違いがあったり、モジュールとか環境の違いも出るので、メモが必要な感じ。

極端に古い環境を考えても仕方ないけど、そもそも自分も結構古い環境なので、現行との違いとか忘れてしまうのもある…

2014/2016/2018で考えてみたい。

PySide/PySide2

PySide1: 2014, 2016
PySide2: 2018(※2017から、PySideのバージョンが変わってる)

shiboken

2015/2016辺りでMixin記述が出来るようになったので、2016, 2018はshiboken不要。
2014の場合はshiboken入れるなり、MayaのWindowハンドルを取得するなりして、PySide側のWindowにParentの設定が必要。

QApplicationのinstance生成

これは、スタンドアロンとMayaの場合で実装が異なる。
スタンドアロンの場合は、よくあるexampleのようにインスタンスを生成すればいい。

Mayaの場合は、既にインスタンスが作られた状態から動かすので、必要に応じてinstanceメソッドでインスタンスを取得する。

でも既にイベントループとか動いているので、app.exec_()しなくてもウィンドウ作成&表示で動き始める。
必要なら呼べば大丈夫な感じ(そういえば、これはOKなのか?)ていうか、要らない。

[Maya] ノードの変更を検出してツールの値を更新

 掲題の通り、Maya向けにアトリビュート編集をするUIをPySideで作っている時に、MayaでもPySideのUIどちらからも値の変更ができるようにする処理を書いていて、何故かMayaがCrashする現象を起こしてしまって何故だーと思っていたら、単にシグナルのブロックが不完全だった…というお話。

 やってるつもりでもポカしている部分はあるもので、油断は禁物。という話になってしまった。

ノードの変更を検出

 これは、先に書いた記事(ノードの変更を検出する)を参照すれば基本的なことは分かると思う。
 指定のノードに変更が掛かると、コールバック関数が呼ばれる。
 コールバック関数内でなんの変更が掛かったか判定して、必要に応じて対応をする。単に値の変更を捕まえるなら、MNodeMessage.kAttributeSetをチェックすればいい。

 問題なのは、MayaとPySide2つの変更に対応する場合にどう書くか。

 基本的にコアな部分は、この2通り。

 ・Maya(getAttr)⇒PySide(set)
 ・PySide(get)⇒Maya(setAttr)

 イベントのトリガーは、基本2つ。
 (※Mayaのタイムライン移動にも対応とか諸々対応すると増えるが、とりあえず値変更に限定した場合)

 ・Maya : ノードの変更を検出
 ・PySide: widgetの変更イベント

 動作としては、以下の通り。

 ・Mayaトリガー
  ノードの変更コールバック処理で、
  Mayaの対象ノードをgetAttr、PySideのwidgetにsetする。

 ・PySideトリガー
  PySideのwidgetの値更新イベント処理で、
  PySideの値をget、Mayaの対象ノードにsetAttrする。

シグナルの抑止

 これだけで書くと、冒頭に書いたCrashの件のような問題が起こる。
 単純に、Mayaトリガーの変更を実装。PySideトリガーの変更を実装。
 …というように進めてみるとふと気づくのが、「変更イベントが循環する」という問題。

 PySideでGUIのプログラムで凝ったものを書き始めると途端に出てくる障壁のような問題なのだが、これを制御しようとし始めると「シグナル」の機構を理解しておく必要が出てくる。
 その機構の利用方法の1つが、blockSignalsというメソッドの機能。

 このメソッドを呼ぶと「シグナルの抑止動作」を制御してくれる。
 単に止めるのではなく、止めるか止めないかを設定できるので、必要に応じて一時的に止めてその隙に変更を掛ける。ということができるようになる。

 これを然るべき位置に設定しておけば、(無限ループに嵌って)Crashすることなく意図通り動いてくれるようになる。

循環しない形

 先ほどの処理の話で言うと、循環が起こると例えば以下のような状況が発生する。

 ・Mayaトリガー
  ⇒PySideのwidgetに値をset
  ・PySideトリガー
   ⇒Mayaのノードに値をsetAttr
   ・Mayaトリガー
    ⇒PySideのwidgetに値をset
    ・PySideトリガー
     ⇒Mayaのノードに値をsetAttr
     :
     :

 このように、シグナルを止めなければ循環してしまう。
 なので形としては、以下のようにしなければならない。

 ・Mayaトリガー
  ⇒flg=blockSignal(True)
   PySideのwidgetに値をset
   blockSignal(flg)

 ・PySideトリガー
  ⇒flg=blockSignal(True)
   Mayaのノードに値をsetAttr
   blockSignal(flg)

 PySideトリガーの場合、Maya側のトリガー(ノードの変更通知)をどこで抑止するかにもよるが、blockSignalsメソッドを利用するにはシグナルの機構を自前で用意する必要がある点に注意。
 Pythonは基本マルチスレッド動作ではないので、(並列処理が絡まなければ)単にフラグ管理でも動くだろうし、ちゃんとシグナルを使って記述するもよし、である。

 それからblockSignalsメソッドを使う場合は、flg=blockSignal(True) してから blockSignal(flg)で終わらせるのが基本的なお作法。
 これは、blockSignalsが“入れ子”になってしまう場合を想定した書き方になる。

 途中のメソッド内が、blockSignal(False) で終わらせるとおかしなことになってしまうので、注意したい。

QTreeViewの項目追加, 項目へのWidget追加

試したこと、めも。
viewにwidget反映させる部分とか良い方法ないんかな…あとsenderメソッドも、この場合に利かないのは何故なのか判らなくて、スッキリしない。

参考:
 https://gist.github.com/skriticos/5415869
 http://hareoff.blogspot.com/2013/03/pyqtqtreeviewwidget.html

self.sender() で発信元が見えない場合

 自分は、self.ui=loader(path)でui読み込んだ後、gui.ui.show() とかやっていたが、これではsender()で発信元を受け取れなかった。
 仕組み的に、ちゃんとQMainWindowにQDialogとか読み込んで配置するには、正しい場所にuiを配置しないとダメだった…ということです。

関連:シグナルの発信元を取得する

ノードの変更を検出する

調べたら意外と最近追加されてたので、めも。

マニピュレータで移動している間、任意のスクリプトを実行するスクリプトのサンプルはありますか(@AUTODESK KNOWLEDGE NETWORK)

インスタンスの破棄について

 基本的には、2通り。
 ・「del instance」の形で明示的に開放する
 ・関数などのブロックから出ることで暗黙的に開放する

[Windows] キーボードのCapsLockキー入力をCtrlキー入力に変換

掲題の通り。
仕事場で英字キーボードを使っているが、左Ctrlキーは日本語キーボードのCapsLockキーの位置にある。
配置関係的にCapsLockと位置が上下逆転しているので、英字配列を使う人はよくキー入れ替えをする。

MS提供の設定変更ツールというのを見たので、メモしておく。

これを使ってみると、Ctrlの入力がCapsLockでも出来るようになった。(左Ctrlキー入力は、元のまま。)
CapsLock入力が消えたけど、そもそもそのキーを使うことがほぼないので、これで良いか…って感じ。

もしCapsLockを必要に感じたら、今度は入れ替えツールを探してみようかな。

logging.configの使い方

覚書。

起動時に、カレントディレクトリを.pyファイルの場所に設定している。
同ディレクトリに.confファイルを配置しているので、これを読み込んでロギング設定を反映する。

設定内容は後述。

設定的には、consoleHandler, fileHandler2つを用意していて、個別に出力レベルを設定中。
ファイルには詳細にログを落としたいが、表示的には黙らせたい…という感じの設定。
※warningやerrorは表示してくれるので、黙らせたい要素のコントロール方法の参考に。

シグナルの発信元を取得する

覚書。

QListview等利用時のmodelの更新

覚書。