2016/04/30

ナニを得たいのか?・・・

・・・ふと そう云う疑問が頭をよぎった。


って、PSO2運営のハナシね。
■ 結構イマサラなんだが
そもそもとして、同じサービスに接続する Vita や PS4 は 仕方が無く 且つ、Windowsからでも
複数マシン(ないしVMでも)と 別のアカウントがナイ限り、それが出来なくても まだ理解に難くない。

しかし、せめて es は 同時利用出来ないと、もしかしたら運営自身、自ら首を絞めているだけなのではナイだろうか?
ツマり、PSO2サービスの同時利用に関する現在の仕様についてだ。 ■ 確かに、

2016/04/25

Microsoft SilverLightって・・・

・・・CyberFox上で、使われてもいないのに メインメモリから 200MB近くリソース持って行く事あるのだが(´ヘ`;)
どうやら広告の一部で呼び出すタイプのモノがあるようだ・・・ イマドキ使うかなSilverLight(-_-;)
で、あまりにウザ過ぎたのでアンインストールしたら、かなり軽快に。
元々は、
おきつね鯖(WindowsServer2008R2)から Microsoft製品だけでライブ配信できないのか?
と云うテーマの実験で
おきつね鯖のIIS7.5 に LiveSmoothStreamingサービスを追加、
配信実行機材に、ExpressionEncoder4、視聴試験機材にSilverLight
と云う 基本構成を行った名残り。 だが、ExpressionEncoder4 自体は かなり前に提供が打ち切られており、試用版では とても実用に耐えなかった。 この実験で追加した一連の機能は、そのまま停止させて放置していたのだが、そろそろアンインストールしてしまうかな。
・・・因みに 今現在 その用途には、
nginx を RTMP鯖 として追加した上で、IIS7.5 の仮想フォルダとしてマウントさせ、非常に手間の無い連携を実現。
おきつねサイト上で、ライブ配信を視聴する実験サイトとして構成を完了している。

2016/04/24

無事・・・

・・・手元に SD14が帰ってきた。
本日0934のコトだ。

程なく開封し、パワーグリップ PG-21を、過去ログのように固定、17-70mmの標準ズーム玉を憑け 定点で試写。
動作は極めて快調だ、まぁ修理上がりだし当然とも云えるがw ・・・ミラー周りが変わると やっぱり音が変わるのだなぁ。

毎度の事だが、接眼レンズもクリーニングされてて助かる、傷つき易いので 滅多に掃除出来ないのが難点ではあるからね・・・
ファームが初期化されていて英語表示になったままだったが、どの道必要にな設定を行う必要はあるだろうから手間に差はナイ。
■ しかし今回の件では、
◆ 輸送に関して、色々問題が多いのが良く判った。
そもそも日数的には充分及第点であるのに、なまじ中途半端なWebサービス起因で嫌気される結果となっているのは、
佐川急便のナンとも勿体無い残念な点だろう、明らかに印象として損をしているとしか云いようが無い。

と云うか、最寄営業所についてしまえば、ヤマトも佐川も差が無い事実を踏まえると、
佐川の中継センターの無駄の多さを疑わざるを得ないだろう。

そもそも、昨日の0747に中継センターに到着していたとして、
追跡サイトで表示していたように、本当に営業所へ輸送を開始していたのだろうか???
◆ で、コレが、

2016/04/23

二度と・・・

・・・急ぎの荷物は佐川に回さないようにしないと時間の無駄が笑えないな。
■ 今日の朝、
残念な荷物追跡サービスにより、なまじ近郊の中継センターから近隣の営業所へ配送中と判ってしまった事で、
勘違いして到着を延々待ってしまう醜態を曝してしまったワケだ。
■ しかし、
ヤる気がないなら もうWebサイトでの荷物追跡システムは 早々に畳むべきだろう。

アレは 更新間隔が大き過ぎる上、表示構成が雑で とても実用に耐えないゴミだ、
実験用途としても考え物な水準にしかなってない。

イマドキなら、小学生が学習で ActiveServerPageサイトを構成したとしても、もっとマシに仕上げるだろうな。

それに、根本の出来の格が違うヤマトのそれと比較されて酷評されるくらいなら、
無いほうが企業としては むしろ利益になるだろう。
■ そもそも、
土地勘あるほうが尚更勘違いするシロモノって、使い物になるワケがナイ・・・

まぁ あのような出来の悪いサイトを構成してサービス展開されると、
ネットワークまで TVの二の舞になりかねないから、正直勘弁して欲しい。

雑なモノを提供し続ける媒体など見限られるのだよ、例外なくね。
■ 今日は
待ちはしたモノの、結局荷物は届くどころか 近隣の営業所にも着いてないしなぁ・・・ 

被災地への救援物資かナニかと間違われて、誤配されてたりしてなければいいが(;´ヘ`)

この辺の・・・

・・・佐川急便って拠点構成が悪いのな(´ヘ`;)


まぁ 関東でも拠点作りでヤマトに劣っていたのは確かだが、全国的にこう云う状態なのかな?
結局、末端のドライバの努力だけで首の皮が繋がっているって状況の可能性が高いな。


■ 荷物追跡してみる・・・

組み合わせに工夫が・・・

・・・必要みたいだね。


■ SIGMAに修理依頼したSD14、
修理自体は20日に終えてたようだ。修理代金は手続きの時間的にその翌日扱いとなってしまったが送金、
21日には会津若松の工場から発送されたが、今現在届いてない。

まだ3日と経っていないので文句を云うのは違っているのも事実だが、差があり過ぎるのが悩ましい。
■ 何が問題か?

なんか情けなくてね・・・

・・・日本の自称報道関係者の自覚の無さと、視聴者の低俗化がね(´ヘ`;)


って、twiでグチってたら長くなり過ぎたので纏めて診るコトに。

Microsoftから・・・

・・・珍しくナニかメールが届いていたのだが。

OneDrive に関する変更 - Microsoft [ 20160423 090700 ]
OneDrive の、今後の変更についてお知らせします。
2016 年 07 月 27 日に、OneDrive に付いてくるストレージ容量を 15 GB から 5 GB に変更いたします。
また、15 GB のカメラ ロール特典も終了となります。詳細については、FAQ をご覧ください。
おきつねさまは利用最小限だったから影響皆無だが、コレ、ガッツリ使ってたヒト大変だね(;^ω^) そもそも アップロード時間とUIの高頻度な改変に付きあわされるのが面倒で おきつね鯖を設置したと云う経緯もある。 OneDrive も GoogleDrive も、サイトのパーツを僅かに置くくらいにしか使ってない。 ワイヤレスネットワークが拡充すれば、スマホやタブレットでさえ簡易Webサーバとして利用される日も遠くないだろう昨今。 大手のストレージは 信頼性が高くても 無償だったとしても多用する気にはならないな。

2016/04/22

またPSO2は・・・

・・・ヤらかしか。


DirectX9使ってる時点で 既に難儀なわけだが、アレだけ複雑になったプログラムを
今時32bitビルドでしか提供していないのだ、お察しである。


と云うか、
未だに 64bitビルドの必要性が無い とかブラフるバカが多くて困る。
確かにWindows10アプリケーションを プロセッサが32bitの低スペタブレット向けまで視野に入れ
全プラットフォーム対応ビルドするともなれば仕方がない面はあるだろう。

だが、今時タブレットどころか ヘタすればスマホのプロセッサも64bitだ、32bitでアプリケーションをビルドする理由がない。
そもそも "32bitでいい" なんて云ってるヤツは 短時間しかアプリケーションを稼動させない連中だ。
しかし現実には、一寸複雑なプログラムとなっているだけで、
小一時間以上連続稼動させる場合、変数で扱えるビット数の影響が顕著に出始める。

2016/04/21

本日・・・

・・・アークス業はお休み。


風邪引いた・・・ 身内が外から菌貰ってきたらしい(^_^;)
今朝PSOオチる直前から急に具合悪くなってたんだよね・・・


それでは また後日(^_^)

2016/04/20

ORACLE JAVA 更新報告・・・

■ UpdateLog・・・
<<< 20160420 134621 >>>
報告を受け確認。
・Java 8 Update 77 (64bit) → 8 Update 91 (64bit)
Java Runtime Environment Version 8 Update 91 -
  ORACLE Java Downloads for All Operating Systems [ 20160419 US ] - 54.99MB
・・・だが、やはり Mozillaプラグインチェックには表示されていない。 ><<< 20160324 190619 >>> 公式サイトにて確認。 ・Java 8 Update 73 (64bit) → 8 Update 77 (64bit)
Java Runtime Environment Version 8 Update 77 -
  ORACLE Java Downloads for All Operating Systems [ 20160323 US ] - 54.93MB
・・・しかし、今のトコロ Mozillaプラグインチェックには表示されない。 <<< 20160206 093300 >>> 自動更新通知にて確認。 ・Java 8 Update 71 (64bit) → 8 Update 73 (64bit)
Java Runtime Environment Version 8 Update 73 -
  ORACLE Java Downloads for All Operating Systems [ 20160205 US ] - 54.45MB

<<< 20160121 224843 >>> 久々に自動更新の通知が表示された、mozillaのプラグインチェックでは この時点で まだ出てない。 ・Java 8 Update 66 (64bit) → 8 Update 71 (64bit) ・Java 8 Update 65 (64bit) → Uninstall
Java Runtime Environment Version 8 Update 71 -
  ORACLE Java Downloads for All Operating Systems [ 20160120 US ] - 54.16MB

▼ 更新後
<<< 20151119 143011 >>> mozillaのプラグインチェックにより確認、更新を敢行。 ・Java Update 65 (64bit) ver. 8.0.650.17 (23.1MB) は 据え置き。 ・Java Update 65 (64bit) ver. 8.0.660.18 (101MB) が 追加される。 ・Java SE Development Kit ver. 7.0.55 (218MB) → 変更ナシ。
・Java Runtime Environment Version 8 Update 66 - 
  ORACLE Java Downloads for All Operating Systems [ 20151116 US ] - 54.38MB

▼ 更新後
<<< 20151021 120152 >>> 珍しく 更新報告が mozillaのプラグインチェックより早く出た。今回は久々に自動更新が使えた感。 ver. 8.0.60 → 8.0.65
・Java Runtime Environment Version 8 Update 65 - 
  ORACLE Java Downloads for All Operating Systems [ 20151020 US ] - 54.29MB
ただ、漸く 8.0.51(64bit)が アンインストールされた・・・ どの版まで消しても支障ないのかが判り辛いし、 そろそろ ver.番号付きフォルダ名で 複数ver.放置するのは 責任を持ってヤメて欲しい気がする。 <<< 20150904 094717 >>> 就寝前の更新確認でやっと気付いた・・・ 結構な頻度でアプデ確認してたんだが・・・(´ヘ`;)
・Java Runtime Environment Version 8 Update 60 - 
  ORACLE Java Downloads for All Operating Systems [ 20150818 US ] - 53.9MB
<<< 20150715 084000 >>> なんとなく予感はあったw
・Java Runtime Environment Version 8 Update 51 - 
  ORACLE Java Downloads for All Operating Systems [ 20150714 US ]
<<< 20150715 083132 >>> CreateLog・・・    
■ 注)
・64bit版ブラウザを利用している場合は、Windows Offline (64-bit) を選択してダウンロードし、インストールして下さい。

2016/04/16

よく・・・

・・・阪神淡路の被災者寄りコメントとして 社民バッシングがあるが、


■ その頃の
官邸のネットワークインフラや、有事の偵察用途としての自衛隊の装備や体制って知ってて云ってるヤツ殆どいないよね?

トンちゃんなんて 大分県からの おのぼりさんなジジぃだぜ?
情弱常套、引き継ぎたての政府機関インフラすら掌握してなかっただろう。

縦しんば 把握し、ガッツリ使いこなしていたと仮定しても、
自民体制時代からの規則起因で、結果に差が無かった現実もあるのだがねぇ?
■ ぶっちゃけ あの政権が

2016/04/13

デジイチに・・・

・・・求められているモノとは。


■ そもそも、
◆ フィルムのカメラのカテゴリーであった
一眼レフレックスカメラ、通称 "一眼レフ" が原型となりデジタル化されたのが デジタル一眼レフ 通称で "デジイチ" だ。
まぁ 今更感もあるが、シロウト向けの解説だと思って貰えばいい。 ★ 本題の結論から述べると、
一眼レフ から継承された構造である ミラーとペンタプリズムを用いた光学ファインダだからこそ価値があるのが デジイチだ。
その物理の光学構造を以って目視のフォーカシングが出来ないなら一眼のデジカメなど要らない。
・・・この点に集約されている。 ◆ そして、
フィルムを基準に考えるなら、光学的に得た映像を そのままで記録出来るのが最善だ。
しかし、多くのデジカメは、受像素子の特性起因で 色情報を演算で誤魔化してるだけの残念なモノばかりだ。

こだわりがある向きなら、とてもフィルムから乗り換える気になる様なモノでは無い。
そんなモノは フラッグシップモデルだったとしても、タダでも不要だ と断ざざるを得ない。

偽物の色情報しか得られないデジカメなど要らない と云っているのだ。

ウィンドウポジションの・・・

・・・記録保存と復元も出来ないようなら、そろそろ捨て時カモなPSO2


Windowsアプリケーションを構築するにあたり、そうした利便性提供の面で注力するのは 基本中の基本なんだが、
その程度のコトすら出来てない連中が提供してるモノとか、どんなウィルス混在してるか判ったモノでは無いって域。

去年末の更新から、スクリーンショットのドライブへの書き込みすら Windowsのシステムから拒否されてるみたいだし、
思ってる以上に ホンキでヤヴァいのカモな・・・ 

ま、時代遅れのDirectX9稼動のアプリケーションなんて、DirectX12オシな Win10のシェアがガッツリ増してしまえば
Microsoftのヤツらのコト、大義名分アリとばかりに 大手を振って切り捨てるだろう、Googleを模倣してな。

少なくとも、最新鋭開発環境であるVisualStudio2015から Windows7関連の多くのライブラリが排除され、
着々と切り捨て準備が進んでいる事を伺わせているくらいだ、XP世代のDirectX9系が 同じ憂き目に遭う日も遠くないぞ。

その煽りを確実に喰らう空気だよな、PSO2運営って。

サスガのAmazonと云えど・・・

・・・在庫があっても 翌日お急ぎ便指定で 翌日に届けるのはムリらしい。


■ モノは ブロア と 高圧洗浄機
用途と その使用予定の状況を入念に確認し、使用頻度や性能に見合う価格か 身内と充分な検討を行うコト 6h・・・ 
日立工機 ブロア FRB40SA日立工機 高圧洗浄機 FAW105(S)
  この2点を 注文したのは 1800廻った頃だった。
■ 注文時にしつこく・・・
翌日お急ぎ便(Amazonプレミアム)のお試しが表示されるので、身内の承諾を得て そのサービスを試用して診た。
さて、月曜日の1800過ぎの注文、果たして翌日火曜日中に届くのか?w
■ その結果は明暗が分かれた
ブロアのほうは火曜日日中に届いた、しかし高圧洗浄機はダメだった。
確認してみると、両方とも 福岡AFC支店からの発送である・・・

あれぇ?? てっきり発送地域が違うと思ってたのだが、確認して驚く・・・(;^ω^)

もしかして配送ドライバー 荷が 2つあるのに気付いてなかっただけか? 高圧洗浄機のほうがブツは大きいのになぁw
本当に そうだとしたら、Amazonも 要らぬトコロで顧客満足度的な評価を落としかねない可能性があるコトになるね。

Amazonの利用頻度が高くなく 且つ、おためし程度でコレやられたら、
実際使い続けるか躊躇する性急な向きも少なく無さそうだがなぁ・・・

トクに地方だと利用の層も高齢化してる点考えたら、結構無視出来ないポイントになるカモね。
ま、明日届いたら 実際ドウnanoか、確認してみるかなw

このタイミングでか・・・

・・・身内がAmazonで注文した品が届いたので レビュー向けのブツ撮りの最中に(´ヘ`;)


■ 痛恨のSD14ミラー駆動系破損。
◆ まぁ、購入程無い保証期間中にも
7079ショット目で 同じ箇所が壊れて修理に出したが、それから もう 8year近く経ってるし、コンなモノかなぁ・・・
当時のログはコチラ
  って、撮影頻度で云うと、プロに比べれば無いに等しいのだよ。   確定であるのは 寝起きの定点撮影 合計でも 8から12枚程度を毎日と、   たまに静物撮影を行うくらい。
ここ数日は、度重なる模様替えや 身内のググるアカのアイコン向けに花を撮影したりで、結構使用頻度が高かったのも事実とは云え・・・ まぁ たまの出先では 動体に対して相当数の撮影にはなり、 購入から今までで 58347ショット、全く数撮って無いってワケでもナイのはある。 しかし、前回修理からのショット数が 51269・・・ 当時のSD14公式サイトでは ミラーの機構 100000ショット耐久を謳っていたのも 事実としてあるのだが、ソコから話半分と云うのであれば 正しい結果nanoカモ知れない(´ヘ`;)
◆ 結局のトコ・・・
以前と同じ部分のスプリングが お亡くなりなんだろうか?

とは云え、前のトキは ミラーが完全に固まってしまっていたモノだが、今回は 指で触れれば柔軟に動くので 同じ原因とは考え辛い。
むしろ スプリングではなく 駆動側の可能性を考えるべきか。
■ ナンにしても
保証期間はトウの昔に過ぎてるし、修理費用は如何程になるのか、今日日中にでも確認するしかない。

その費用次第によっては、スチル諦めて Vカムに戻るほうが賢明nanoカモ知れないね・・・
ソレについては 別途ログに纏めてみた。

2016/04/12

TouchSwitch・・・

・・・って、タッチパネルの有効/無効を制御出来る便利なフリーアプリケーション。



■ 更新報告
<<< 20160412 034505 >>>
Ver.1.0.0.8e/1.0.1.8eが Windows7で利用出来る(VS2008ビルド)最終版として登場。
おきつね2nd機(Windows7 Ultimate 64bit)/おきつねMU(WindowsVISTA Ultimate 32bit)と
iiyama ProLite T2451MTS の組み合わせでは、それぞれ正しく稼動するコトを確認した。

尚、使用するタッチパネルの仕様にも依存する為、動作を保証するモノではナイ点に注意。

また、アプリケーションの特性上、"リモートデスクトップで利用される側" となるマシンでは、
スタートアップ登録代替として タスクスケジューラへの登録を代行する機能も提供している
[Automatic Status Control / Startup registration] の 項目を有効化するコトは推奨しない。
<<< 20160411 070426 >>>
最新の Ver.1.0.0.9/1.0.1.9から、Windows7は正式に動作対象外となったとのコト。
因って Windows7で利用出来るのは Ver.1.0.0.8/1.0.1.8まで。
■ 前提として、
Android や Windows10 Mobile など、タブレットやスマホならドウかは知らないが、
とりま x64/86稼動な Windowsでは、こうした機能を 既定では提供されていない。

そうした利便性の補完を実装してくれるのが、hoge1hogeさん謹製の TouchSwitch である。
■ この
アプリケーションの概要は、某大手サイトで紹介されているので参考にして欲しい。
また、更新については、Twitterで hoge1hogeさんをフォローしたほうが、リアルタイムで情報を得られるだろう。
■ ・・・ってまぁ、
いつもなら更新をログにしたりするトコロを省くなど、比較的投げ遣りな紹介となってしまっているが、当然理由もある。

まず、本家の更新報告がTwiであり、そちらのほうが確実で ココで改めてログにする必要が無い。

また・・・ むしろコチラが要因として大きいのだが、このログをルーティンで閲覧するであろうメンツでは、誰一人として、
デスクトップ/ノート機を問わず、タッチパネルディスプレイを使っていない点があるw


・・・まぁ Windows7でタッチパネルとか、3Dゲーム走るスペックのマシンで使ってるほうが稀有だろうしね(;^ω^)
■ そもそも
TouchSwitch は Windows 8/8.1/10 向けとして提供されていたモノで、Windows7で動作するのはオマケに近かったワケだが、
デスクトッフ 且つ、Windows7での利用も視野に入れた おきつねさまの機能追加要望に、快く応じてくれた hoge1hogeさんに感謝。

具体的には、ブレの大きい光学式タッチパネル操作のみでも完結出来るよう設定UIが改善され、
ホットキーの動作選択も 1.0.0.8d/1.0.1.8dから増えた。 

これら要素に寄り、ハードの仕様に依存する事無く シーンに応じた動作を期待出来るようになっている。
■ 一応添えておくと・・・
Windows7での利用に於いては、それ以降のWindows向けな機能を用いる設定を有効にしても、期待した動作を得られない可能性が高い。

また、TouchSwitchのウィンドウを長押しジェスチャしても、今のところ
(1.0.0.8d/1.0.1.8d時点で) Windows7では コンテキストメニューは表示されない。
Windows7/VISTAで この操作が機能するモノとして、
VS2008を用いたビルドの最終版となる 1.0.0.8e/1.0.1.8e が別途提供されている。
コレは開発環境であるVS2015から、Microsoft が Windows7 を 見限ったコトに起因しており、TouchSwitch側の問題では無い。
VS2015を用いて Windows7合わせの構成を行うと、最新であるWindows10の 32bit版との機能衝突もあるようで、 今後 Microsoftが、提供する開発環境に対して改善を盛り込んでこない限り、余程の致命的問題を除いて、 Windows7以前向けに限り TouchSwitchの更新は行われない方針とする旨、確認している。 因って、1.0.0.9/1.0.1.9 からの版は、Windows7 を "正式に非対応" として提供されている。
・・・そのような背景もあり、前述の通り TouchSwitch は、Windows8以降をターゲットとしている点、各位 踏まえておく必要がある。 尚、1.0.0.8e/1.0.1.8e で、Windows7が機能として持たない要素に関連しない TouchSwitchの基本機能は、 Windows7(64bit)/VISTA(32bit)で 正しく稼動するコトを おきつね環境にて検証済みである。 だが、全ての環境で稼動するかは不明だ、もし動作しなかった場合は、既にサポート対象外OSでもある、ハードが合わなかったと諦めるべきだろう。

2016/04/10

痛快・おきつねさまのもようがえ・・・

・・・ディスプレイハンドル固定部の強度補完。


■ 結果
◆ Before - 先日の様子。


◆ After - ハンドル取り付け部位木材の幅を30mmから55mmに、固定ネジの数を倍にした。

・長めに設置していた前のモノと重量差が無いよう、必要なだけの長さに変更。
・幅を増やした角材に接触する為、USBハブの固定位置を変更。

2016/04/09

とりのくせに・・・

・・・撃破不能とは(´ヘ`;)
フランカさん、ラッピー肉COまだDeathか?

にゅー・おきつねさまのもようがえ・・・

・・・T2451MTSの後部支脚、2枚分を1枚の左右に取り付けた。


■ 内容
・ディスプレイアーム、ディスプレイ左右にハンドル取り付け。

新・おきつねさまのもようがえ・・・

・・・って、まだ途中。 時間が遅くて、高速カッター使えなくて(;^ω^)


■ 内容
・ディスプレイアーム、ディスプレイ角度調整ハンドル取り付け。

・・・前ログに記述したモノではなく、アームのおかげで不要として取り外され 放置されていたディスプレイの脚を流用。

2016/04/08

また又・おきつねさまのもようがえ・・・

・・・複数項目変更。


■ 内容・・・
・2nd機 ディスプレイ周りの配線を再調整。
・2nd機用キーボードの可動テーブルの支点部位置変更と展開時の支えを追加設置。
・2nd機ディスプレイに固定したUSBテンキーの位置を変更。
・2/1スイッチャに4/1スイッチャを追加、OkitsuneMUのBIOSメンテも可能に。
・給電可能なUSBハブを追加し、HIDに対するUSB電力供給不足を解消、UEFI/BIOSメンテ向け設置を補完。
・1st機 サーモセンサ変更、電源周り配線調整、光学マルチドライブ位置変更。


その他、ディスプレイアームにディスプレイ角調整ハンドルを作って取り付けたが、
重さが予想以上に増してしまって断念・・・ モノは軽く仕上がったのだがなぁ(´ヘ`;)

2016/04/07

20h呪われた・・・

・・・JACK Audio Connection Kit の サポート/インストールスクリプトの仕上がりに難を感じて精査を始めたのが運の尽き・・・(-_-;)


とりま、スクリプト本体にいくつかのケアレスミスがあり、iniファイルも調整を要した。
それだけで済めば6h程度の作業だったのだが・・・



<<< UnderConstruction >>>


2016/04/06

PSO2yomiの・・・

・・・セットアップスクリプトを、前ログの内容を踏まえて構成してみた・・・ 但し、実験の一環である。

コマンドラインで・・・

・・・Windowsの[タスクスケジューラ]にタスクを登録するTipsは、GUIを用いる場合同様に多い。
■ しかし、
コマンドラインのみで
指定したアプリケーションの起動をキーに、
スケジュールを開始し、指定時間だけ遅延させて 指定プログラムを実行させる。
と云った定義を行うケースで、適合する内容は皆無に近かった。
■ ソコで、
ここでは 試行した例で ざっくり紹介するコトに。
◆ トリガー後、5min遅延して開始。 Schtasks /create /f /it /sc onevent /rl highest /tn "PSO2yomiD5" /tr "'C:\Program Files (Free)\StreamingSet\PSO2yomi\PSO2yomi.exe'" /ec Application /mo *[System[Provider[@Name='pso2.exe']]] /delay 0005:00 ◆ 遅延指定ナシ。 Schtasks /create /f /it /sc onevent /rl highest /tn "PSO2yomi" /tr "'C:\Program Files (Free)\StreamingSet\PSO2yomi\PSO2yomi.exe'" /ec Application /mo *[System[Provider[@Name='pso2.exe']]]
pso2.exe が 起動されたら、5min後に PSO2yomiを開始する と云うスケジュールを登録する為の指定を模索した結果だ。 タスクスケジューラへの登録は、概ねこれで完結出来ている。 しかし、pso2.exeが "起動をイベントとして返さない" 為、予定していた用途としては動作しなかったが・・・
◆ Schtasksコマンドへの パラメータを詳細を解説すると・・・
/create - タスク作成。

/f - 既存エラーを返さず強制上書き。

/it - ユーザーがログオンしている場合のみ実行。

/sc onevent - トリガーで[イベント]を選択。

/rl highest - 最上位の特権でタスクを実行。

/tn "PSO2yomiD5" - スケジュールの名前。
  "AnyFolderName\PSO2yomiD5" のような形式で 階層化指定も可能。

/tr "'C:\Program Files (Free)\StreamingSet\PSO2yomi\PSO2yomi.exe'"
  実行させたいアプリケーションのフルパスを指定する。

/ec Application - トリガー[イベント時]-[基本]-[ログ]-[アプリケーション]を選択した状態に。

/mo *[System[Provider[@Name='pso2.exe']]]
  @Name=に続く 'pso2.exe' の部分で、スケジュールのトリガーとなるアプリケーションの
  プロセス名を指定。

  ココに指定したアプリケーションからの 起動イベントが検出されたら、スケジュールを開始する。

/delay 0005:00 - この記述で 5min・・・ 同様の書式で、スケジュールがトリガーされてから、
         [実行を指定されているアプリケーションを開始するまでの時間] を指定。 
         /delayは省略可能で、その場合はトリガー後、即実行扱いとなる。
コンなカンジ。 このような記述で、 [タスクスケジューラ]に 登録されるスケジュールの設定画面のうち、[全般] [トリガー] [操作] 各タブは 設定制御出来る。 だが、[条件] と [設定] については、数多あるTipsサイトの情報を併読したとしても定義不能な項目もあり、該当パラメーターを調査中。
■ 尚・・・
上述の通り、この方法で登録したスケジュールは多くのアプリケーションで機能しない。

◆ 原因は、
殆どの一般アプリケーションは、Windowsに対して "イベントを返さない" 構造であるコトに尽きる。

そもそも、/sc onevent 指定、"トリガーとして[イベント]を利用する" 登録でのキモは、

任意に指定したアプリケーションが
イベントを返す・・・ イベントログに対して "起動などを報告する(書き込む)" かどうかである。

因って、
イベントログに該当する変化のナイ殆どのアプリケーションでは、ソレを検出して動作する /sc onevent を用いても、
トリガーとして機能するコトはナイ と云うワケだ。
★ しかし、このタイプのタスクスケジューラへ登録は、UACナシでの起動を実現したい場合には有用である。
schtasks.exeは、スケジュール登録だけを行うコマンドではナイ、登録済みスケジュールを実行させる用途でも用いる。

以下のような内容でショートカットを作成すると、
schtasks /Run /TN PSO2yomi
クリックするだけで スケジュールが 前述のコマンドラインから設定した通り [最高権限]で実行される。 これでUACの確認画面は出ない。
しかし、一瞬プロンプトが表示されてしまう・・・ schtasksを実行している画面だ。

これをショートカットからの起動で非表示にしたい場合は、
ショートカットのプロパティで [実行時の大きさ] で [最小化] を 選択しておくと良い。
◆ 当然VBScriptからの利用でも、
・・・UAC非表示で実行可能だ。
Dim My, ShApp
Set My = WScript
With My
    Set ShApp = .CreateObject("Shell.Application")
End With

Const schtasks = "C:\Windows\System32\schtasks.exe"

ShApp.ShellExecute schtasks, "/Run /TN PSO2yomi", "", "", 0

Set ShApp = Nothing
My.Quit
このように .ShellExecute の 最終引数で 0 [ウィンドウ非表示]を指定しているのだが、 コレは schtasks.exe の実行を非表示にするモノであり、その後に起動されるアプリケーションは、 元々のウィンドウ状態で起動すると云うのが、この用法でのポイントだろう。
◆ 但し、
schtasks.exe /Run を用いた場合は、"トリガーで起動していない" 為、
トリガー後に対する遅延起動指定である /delay で設定された待機は実施されない点に注意が必要だ。

従って、対象のアプリケーション起動まで 任意の待機時間を設定したいのであれば、
Dim My, ShApp
Set My = WScript
With My
    Set ShApp = .CreateObject("Shell.Application")
End With

Const schtasks = "C:\Windows\System32\schtasks.exe"

My.Sleep 300000 ' 5min
ShApp.ShellExecute schtasks, "/Run /TN PSO2yomi", "", "", 0

Set ShApp = Nothing
My.Quit
VBScriptで sleep を事前に配置するなどして、対処するしかない。
■ もし、
◆ フリーアプリケーションを提供されていて、UAC起因でお困りなら、以下のように、
.batファイル (.ShellExecuteでなら パラメータで カレントディレクトリを別途指定して) に、
Schtasks /create /f /it /sc onevent /rl highest /tn "任意のプロダクツ名称\任意のスケジュール名称" /tr "'%~d0%~p0任意のアプリケーションのファイル名'" /ec Application /mo *[System[Provider[@Name='dummy.exe']]]
%~d0%~p0 は、実行した.batファイルのルートフォルダを著す文字列として扱われる。
・・・ないし、 実行させたいアプリケーションへパラメータを付与したい場合は、
Schtasks /create /f /it /sc onevent /rl highest /tn "任意のプロダクツ名称\任意のスケジュール名称" /tr "'%~d0%~p0任意のアプリケーションのファイル名' アプリケーションへのパラメータ" /ec Application /mo *[System[Provider[@Name='dummy.exe']]]
・・・このようにSchtasksを記述しておいて、
実行したいファイルと同じ場所に設置、
このバッチファイルを実行すると スケジュールが適宜登録される。 ◆ このスケジュールを
・・・起動する 以下のような ショートカットを作成しておき、
schtasks /Run /TN "任意のプロダクツ名称\任意のスケジュール名称"
デスクトップにレイアウトするよう インストールアーカイブを構成すれば良いだろう。
★ この方法なら、
ドコにアプリケーションをレイアウトしても、
スケジューラの値さえ正しければ、デスクトップショートカットの内容は固定で良いのも利点だ。

2016/04/04

続続・おきつねさまのもようがえ・・・

・・・今日も大掛かりに変更。


■ 内容としては・・・
・2nd機 ディスプレイ周りの配線を再調整。
・1st機 ファンコトントローラの上に、余ってた140mmファンを FET冷却用として取り付け。
・1st機 サブディスプレイ設置部、強度確保の為 少し前へずらす。
・電話配線移動
・2nd機用キーボードの可動テーブル設置。
・マウスのみ USBスイッチャで、1st/2nd接続切り替え可能に、UEFIメンテ向け。
コンなカンジ。

2016/04/03

続・おきつねさまのもようがえ・・・

・・・1st機の2ndディスプレイの設置を改善。

おきつねさまのもようがえ・・・

・・・一見すると、先日ツイートした状態との違いが判らないカモw

IIyama ProLite T2451MTS・・・

・・・この製品に続く、光学式タッチパネルシリーズも含む ハードウェア構成についての考証。


■ この製品は、
枠上部左右に隠された赤外線カメラによる操作検出を行う、銀行などのATMで御馴染みの方式を用いたタッチパネルディスプレイだ。
特性上、微細な操作には向かないが、WindowsのUI操作程度でなら 困るコトは殆ど無い。
おきつねインフラで 2枚ほど利用しているタッチパネルディスプレイだが・・・ ★ 仕様に難がある事実について、いくつか苦言を呈したい。
以下のような理由で、デスクトップマシンではタッチパネルディスプレイが普及していない。
その事実から目を叛けず、自ら改善するコトを 強く要求するモノである。
■ まずは蛇足から。
ディスプレイ本体の 設定UI構成が残念。

このディスプレイにはスピーカーが内蔵されていて、その音量調節も設定UIに統合されている。

ただ、この優先順位が悪い・・・

あくまで設定の1つとして音量設定がある為、折角手元で用いるタッチパネルディスプレイであるのに、
一旦音量を操作する画面まで操作を進める手間が 実際の利用では かなり笑えない。

この製品には 上下操作ボタンが1つずつしかない、であれば、ファンクションボタンを介していない
それらの操作は、直接音量を上下させるよう割り当てておくほうが妥当である。
■ 続いて本題。
件のタッチパネルの 電源に関する仕様が 利用に於いて非常に厄介。
端末を起動したまま ディスプレイの電源を完全に落としても、タッチパネル操作は有効になったままとなる・・・
・・・給電を USB側から受けている為、ディスプレイ側では停止させる方法が無いのだ。 端末本体側のシステムがシャットダウンされない限り、タッチパネルは有効となる。 Windows側からの 省電力としての画面制御停止時であれば、再開にタッチパネルを用いるケースは考えられる。 しかし、ディスプレイ側で電源を切った状態にも関わらず操作出来てしまうのは、その時点で既に間違いである。
とは云え、マウスやキーボードでも 端末が起動していれば、画面が消えていても操作出来てしまう訳だが、
物理のある それらHIDと異なり、画面全体が操作対象となるタッチパネルディスプレイでは、結構厄介だ。

しかも光学式だから、画面に接触せずとも 衣服などの接近だけで操作判定が入るコトもザラだ・・・
今の製品のスタンスであるなら、ディスプレイの電源を切る操作で タッチパネルも無効にするのが 正しい挙動だと断言する。
■ これらの欠陥に近い欠点は、
この製品を あくまでディスプレイ単体として 企画設計してしまったからに他ならない。
コレが大きな誤りだ。 タッチパネルディスプレイは、表示機器であると同時に HIDなのだ。
■ 更に、
端末で行う操作は、"WindowsのUIだけとは限らない" と云う事実でさえ、完全に視野外な造りだ。
・ファームウェアでOSDキーボードを内蔵していない。
・タッチパネル回路にマウスエミュレートを組み込んでいない。
これらの要因から、UEFIやBIOSの操作で使えない残念な製品となっている。 現状では マシンのハードウェアメンテナンスに於いて皆目役に立たず、旧来のHID併用を余儀なくされている。 このような構成の製品では、マウスやキーボードを 完全に置き換えるコトは適わナイのだ。
そんな中途半端な物を提供されても、余程物好きな向きくらいしか 財布の紐を緩めるコトはナイだろう。
その時点で、ビジネスとして破綻してしまっているのは間違いがナイ。
この点を この製品の開発陣は完全に失念し続け、後のシリーズも 改善する事無く そのまま市場へ投入し続けている。 かなり神経を疑う行為と云わざるを得まい・・・
■ 因って、この製品シリーズは
ファームウェアの大幅な更新と、専用アプリケーションの提供を行わない限り、残念な意味での"逸品"で終わってしまうだろう。

◆ 具体的には
・OSDに ソフトウェアキーボードを追加、USBキーボードとして稼動可能にする。

・タッチパネルにマウスエミュレート機能を盛る

・タッチパネルの回路をディスプレイの電源と連動させるのは、物理改修を伴うので割愛するとして、
 代わりに、ディスプレイの停止を検出し Windowsシステムへ値を返させ、その情報を元に
 タッチパネルの有効/無効を制御させる専用Windowsアプリケーションを無償提供。
最低でも この三点が、今後も このシリーズを続けるに充たり 最低限成すべきコトとなる。 ◆ 更に踏み込むなら、
ディスプレイの電源を入れたら、OSDで選択設定されたキーを USBキーボードとして端末本体へ送信する。
このくらいは、製品企画当初にサクサクこなしておいて欲しかった域だ。
この程度の 回路 及びファームの改修や Windowsアプリケーションも、自前製品専用として制作するなら暇潰しに出来る程度のモノだ。 その簡易な手間を雑に省いて残念なモノを提供し続けるようなら、売れもしないし 市場から見限られるコトとなるだろう。 ★ @、そろそろ 低視野角のFullHDパネルってのも ナイと思うが?
タッチパネルで低視野角は論外、ヤる気が少しでもあるなら そろそろ、4k高視野角IPSで出してよ・・・
こんな体たらくでは、品質良くても うっかり人に薦めるコトも出来やしない(´ヘ`;)

イマドキFullHDで満足するのなんて、雑い東洋人くらいだからね・・・
どの企業も どの製品も、須く詰めが甘いんだよな・・・ トクに日本の大企業様の製品はね・・・ だから世界市場でシナチョンに付け入る隙を与えているのだが、多分当人たちは自覚すらしてナイだろうね┐(´∀`)┌

2016/04/02

ディスプレイの位置・・・

・・・マルチディスプレイ構成での、プライマリディスプレイの扱いについて。

nVIDIA製品のコトは知らないし興味もナイ、ココで取り扱うのはAMD GPUでのハナシ。
って、一般的な設定でのと事案と云うより、プログラムを組む場合の、プライマリディスプレイ取得に関する考証。 ■ まず 結論から。
AMD製GPUで マルチディスプレイを構成している場合、仕様上
ディスプレイ番号で [1] を指定しても、プライマリディスプレイを取得出来ない可能性もある。

◆ コレは、
Eyefinity等 拡張性/運用の柔軟性を重視したハード/ドライバ設計に因るモノ。
・・・と云っても欠点ではなく、一般の利用であればむしろ利点でしかない。 ただ、ディスプレイを制御するアプリケーションを組む側から診ると、少しだけ面倒になっていると云うだけ。
■ 御存知の通り、
◆ AMD GPUでは 1カードで 最大6ディスプレイ構成が組める。
[1][2][3]
[4][5][6] ←どのディスプレイでも 1つを任意にプライマリとして指定出来る。
グラボ4枚挿しなら 24ディスプレイも可能となっているのだが、 一般での利用では サスガにソレはないと思うので割愛するが・・・(^_^;) ◆ もしEyefinityモード・・・
・・・これらディスプレイ群を1つのデスクトップとして稼動させる設定で利用の場合、

全ディスプレイがFullHDと仮定すると、
[1][2][3]   この構成の場合、[6]がプライマリディスプレイであれば
[4][5][6]   左上の座標は、x=3840 y=1080 となる。
このモードでは、全ディスプレイ分を足した範囲 x=5760 y=2160が、 1つのデスクトップ領域となり、ディスプレイ番号は [1] しか存在しなくなる。
■ しかし、
Eyefinityでの運用は 意外に現実的でないシーンのほうが多い。

と云うのも、Eyefinityの場合、ゲームなどでフルスクリーンモードを使用すると、全てのディスプレイが そのアプリケーションに占有される。
以前のドライバでは、Eyefinityでは CrossFireXが機能しなくなるなどのデメリットもあり、嫌煙される原因となっていた。
現在では、Eyefinity で CrossFireX を併用し、複数のグラボを効率よく稼動させる事が可能になっているので、
全ディスプレイでゲームをプレイしたい向きには、朗報だったと云えるだろう。
それでは おきつねさまのように、ゲームをプライマリでフルスクリーンプレイ、サブでシステムステータス表示 と云った利用は成立しない。 やはり別々のデスクトップで、別のディスプレイとして扱われるほうが都合が良かったりする。
■ 結局のトコロ、
Eyefinityで 1つのデスクトップとして使うのがいいか、
非Eyefinityで 複数のデスクトップとディスプレイという扱いの構成での運用がいいか の差だ。

これらの点では、ドライバの改良もあり、ドチラであっても問題になるようなコトは ほぼ無い。
■ だが、
アプリケーション側から プライマリディスプレイを指定する となると話は変わってくる。

前述の通り、Eyefinity状態なら 多数のディスプレイであっても ディスプレイは1つしかない として扱われるから支障は無い。
しかし、通常環境(非Eyefinity状態)では、複数のディスプレイと 同じ数のデスクトップが存在し、番号が割り振られている。

◆ コレが、以前のシステムなら、
ディスプレイの識別番号1 が プライマリディスプレイだった。
 ・・・コトで、大きな落とし穴となってしまっている。
■ と云うのも、
AMD GPU群では、ディスプレイ番号が 接続端子に応じて、固定で割り振られているからだ。

◆ ツマり、
(アプリケーション側から見える)ディスプレイ識別番号 ≠ ディスプレイ識別順位 
ってコトになり得るのだ、ドライバでのプライマリの指定や、ディスプレイの物理的設置次第でね・・・ ◆ 前提として、
AMD GPUのグラボは HDMI DVI(変換でRGB) DisplayPort の3端子がリファレンスの構成となっている。
◆ それら出力端子のうち
DisplayPortに関しては、対応したディスプレイを所有していない為、不明だが、
HDMIとDVI(RGB)では、番号が振られる優先順位は HDMIが DVIより上であるのは 確認出来ている。

DVIに変換コネクタで繋ぐアナログRGBのディスプレイも DVIと同じ順位となる。 
■ ココからは、
おきつねインフラ固有のハナシとなる。

◆ 具体的には おきつね2nd端末の
▼ ディスプレイ構成
[1] TV [Victor LT-26LC60] - HDMI入力
[2] タッチパネルLCD [iiyama PL T2451MTS] - DVI入力
で、 その物理配置は
[1][2] ← [2] がプライマリディスプレイ。
こうなってる。
・・・もう、お気付きの向きも多いだろう。 そう、プログラム側から [1]をプライマリだと思って指定されていると、 実はサブディスプレイに描画してしまっている と云う結果になる。 ◆ コレが おきつね1st端末なら
▼ ディスプレイ構成は
[1] タッチパネルLCD [iiyama PL T2451MTS] - HDMI入力
[2] LCD [BUFFALO FTD-G741A] - RGB入力
こうなってて、 配置は
[1][2] ← [1] がプライマリディスプレイ。
こう。
つまり、番号が振られる優先順位を踏まえれば、設定と物理レイアウトの関係で、 1st端末で発生しない問題も、2ndでは発生しうる と云うコトだ。 コンピューター用のディスプレイであれば、入力端子も多彩で、レイアウトと接続先を一考すれば、 プライマリディスプレイを画面[1]にするコトは可能だ。 しかし家電である TVに、DVI入力は ほぼ期待出来ないと考える。 多くのケースで、物理的に TVを ディスプレイ[2]以降にするのが難しい現実に直面するコトとなるだろう。
昨今では、アプリケーションを稼動させるマシンと ディスプレイの関係は、以前にも増して多様化している点も考慮に入れると、 意外に、描画領域への制御を行うアプリケーションを構成するのが 如何に大変である事か 判って頂けたかと思う。