よく･･･

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


■ その頃の

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


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

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


■ ぶっちゃけ あの政権が

デジイチに･･･

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


■ そもそも、

◆ フィルムのカメラのカテゴリーであった

一眼レフレックスカメラ、通称 "一眼レフ" が原型となりデジタル化されたのが デジタル一眼レフ 通称で "デジイチ" だ。
まぁ 今更感もあるが、シロウト向けの解説だと思って貰えばいい。

★ 本題の結論から述べると、

一眼レフ から継承された構造である ミラーとペンタプリズムを用いた光学ファインダだからこそ価値があるのが デジイチだ。
その物理の光学構造を以って目視のフォーカシングが出来ないなら一眼のデジカメなど要らない。
･･･この点に集約されている。

◆ そして、

フィルムを基準に考えるなら、光学的に得た映像を そのままで記録出来るのが最善だ。
しかし、多くのデジカメは、受像素子の特性起因で 色情報を演算で誤魔化してるだけの残念なモノばかりだ。

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

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

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

･･･記録保存と復元も出来ないようなら、そろそろ捨て時カモな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カモ知れないね･･･

ソレについては 別途ログに纏めてみた。

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でもある、ハードが合わなかったと諦めるべきだろう。

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

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


■ 結果

◆ Before - 先日の様子。


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

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

とりのくせに･･･

･･･撃破不能とは(´ﾍ｀；)
フランカさん、ラッ●ピー肉COまだDeathか?

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

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


■ 内容

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

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

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


■ 内容

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

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

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

･･･複数項目変更。


■ 内容･･･

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


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

20h呪われた･･･

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


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



<<< UnderConstruction >>>

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 "任意のプロダクツ名称\任意のスケジュール名称"
デスクトップにレイアウトするよう インストールアーカイブを構成すれば良いだろう。

★ この方法なら、

ドコにアプリケーションをレイアウトしても、
スケジューラの値さえ正しければ、デスクトップショートカットの内容は固定で良いのも利点だ。

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

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


■ 内容としては･･･

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

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

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

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

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

IIyama ProLite T2451MTS･･･

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


■ この製品は、

枠上部左右に隠された赤外線カメラによる操作検出を行う、銀行などのATMで御馴染みの方式を用いたタッチパネルディスプレイだ。
特性上、微細な操作には向かないが、WindowsのUI操作程度でなら 困るコトは殆ど無い。


おきつねインフラで 2枚ほど利用しているタッチパネルディスプレイだが･･･


★ 仕様に難がある事実について、いくつか苦言を呈したい。

以下のような理由で、デスクトップマシンではタッチパネルディスプレイが普及していない。
その事実から目を叛けず、自ら改善するコトを 強く要求するモノである。


■ まずは蛇足から。

ディスプレイ本体の 設定UI構成が残念。

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

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

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

この製品には 上下操作ボタンが１つずつしかない、であれば、ファンクションボタンを介していない
それらの操作は、直接音量を上下させるよう割り当てておくほうが妥当である。

■ 続いて本題。

件のタッチパネルの 電源に関する仕様が 利用に於いて非常に厄介。

端末を起動したまま ディスプレイの電源を完全に落としても、タッチパネル操作は有効になったままとなる･･･
･･･給電を USB側から受けている為、ディスプレイ側では停止させる方法が無いのだ。
端末本体側のシステムがシャットダウンされない限り、タッチパネルは有効となる。

Windows側からの 省電力としての画面制御停止時であれば、再開にタッチパネルを用いるケースは考えられる。
しかし、ディスプレイ側で電源を切った状態にも関わらず操作出来てしまうのは、その時点で既に間違いである。

とは云え、マウスやキーボードでも 端末が起動していれば、画面が消えていても操作出来てしまう訳だが、
物理のある それらHIDと異なり、画面全体が操作対象となるタッチパネルディスプレイでは、結構厄介だ。

しかも光学式だから、画面に接触せずとも 衣服などの接近だけで操作判定が入るコトもザラだ･･･
今の製品のスタンスであるなら、ディスプレイの電源を切る操作で タッチパネルも無効にするのが 正しい挙動だと断言する。

■ これらの欠陥に近い欠点は、


この製品を あくまでディスプレイ単体として 企画設計してしまったからに他ならない。
コレが大きな誤りだ。 タッチパネルディスプレイは、表示機器であると同時に HIDなのだ。

■ 更に、

端末で行う操作は、"WindowsのUIだけとは限らない" と云う事実でさえ、完全に視野外な造りだ。

・ファームウェアでOSDキーボードを内蔵していない。
・タッチパネル回路にマウスエミュレートを組み込んでいない。
これらの要因から、UEFIやBIOSの操作で使えない残念な製品となっている。

現状では マシンのハードウェアメンテナンスに於いて皆目役に立たず、旧来のHID併用を余儀なくされている。
このような構成の製品では、マウスやキーボードを 完全に置き換えるコトは適わナイのだ。

そんな中途半端な物を提供されても、余程物好きな向きくらいしか 財布の紐を緩めるコトはナイだろう。
その時点で、ビジネスとして破綻してしまっているのは間違いがナイ。

この点を この製品の開発陣は完全に失念し続け、後のシリーズも 改善する事無く そのまま市場へ投入し続けている。
かなり神経を疑う行為と云わざるを得まい･･･

■ 因って、この製品シリーズは

ファームウェアの大幅な更新と、専用アプリケーションの提供を行わない限り、残念な意味での"逸品"で終わってしまうだろう。

◆ 具体的には

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

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

・タッチパネルの回路をディスプレイの電源と連動させるのは、物理改修を伴うので割愛するとして、
　代わりに、ディスプレイの停止を検出し Windowsシステムへ値を返させ、その情報を元に
　タッチパネルの有効／無効を制御させる専用Windowsアプリケーションを無償提供。
最低でも この三点が、今後も このシリーズを続けるに充たり 最低限成すべきコトとなる。

◆ 更に踏み込むなら、

ディスプレイの電源を入れたら、OSDで選択設定されたキーを USBキーボードとして端末本体へ送信する。
このくらいは、製品企画当初にサクサクこなしておいて欲しかった域だ。

この程度の 回路 及びファームの改修や Windowsアプリケーションも、自前製品専用として制作するなら暇潰しに出来る程度のモノだ。
その簡易な手間を雑に省いて残念なモノを提供し続けるようなら、売れもしないし 市場から見限られるコトとなるだろう。


★ ＠、そろそろ 低視野角のFullHDパネルってのも ナイと思うが?

タッチパネルで低視野角は論外、ヤる気が少しでもあるなら そろそろ、4k高視野角IPSで出してよ･･･
こんな体たらくでは、品質良くても うっかり人に薦めるコトも出来やしない(´ﾍ｀；)

イマドキFullHDで満足するのなんて、雑い東洋人くらいだからね･･･


どの企業も どの製品も、須く詰めが甘いんだよな･･･ トクに日本の大企業様の製品はね･･･
だから世界市場でｼﾅﾁｮﾝに付け入る隙を与えているのだが、多分当人たちは自覚すらしてナイだろうね┐(´∀｀)┌

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

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


nVIDIA製品のコトは知らないし興味もナイ、ココで取り扱うのはAMD GPUでのハナシ。


って、一般的な設定でのと事案と云うより、プログラムを組む場合の、プライマリディスプレイ取得に関する考証。


■ まず 結論から。

AMD製GPUで マルチディスプレイを構成している場合、仕様上
ディスプレイ番号で [1] を指定しても、プライマリディスプレイを取得出来ない可能性もある。

◆ コレは、

Eyefinity等 拡張性／運用の柔軟性を重視したハード／ドライバ設計に因るモノ。
･･･と云っても欠点ではなく、一般の利用であればむしろ利点でしかない。

ただ、ディスプレイを制御するアプリケーションを組む側から診ると、少しだけ面倒になっていると云うだけ。

■ 御存知の通り、

◆ AMD GPUでは 1カードで 最大6ディスプレイ構成が組める。

[1][2][3]
[4][5][6] ←どのディスプレイでも １つを任意にプライマリとして指定出来る。
グラボ4枚挿しなら 24ディスプレイも可能となっているのだが、
一般での利用では サスガにソレはないと思うので割愛するが･･･(^_^;)

◆ もしEyefinityモード･･･

･･･これらディスプレイ群を１つのデスクトップとして稼動させる設定で利用の場合、

全ディスプレイが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で １つのデスクトップとして使うのがいいか、
非Eyefinityで 複数のデスクトップとディスプレイという扱いの構成での運用がいいか の差だ。

これらの点では、ドライバの改良もあり、ドチラであっても問題になるようなコトは ほぼ無い。

■ だが、

アプリケーション側から プライマリディスプレイを指定する となると話は変わってくる。

前述の通り、Eyefinity状態なら 多数のディスプレイであっても ディスプレイは１つしかない として扱われるから支障は無い。
しかし、通常環境(非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]以降にするのが難しい現実に直面するコトとなるだろう。

昨今では、アプリケーションを稼動させるマシンと ディスプレイの関係は、以前にも増して多様化している点も考慮に入れると、
意外に、描画領域への制御を行うアプリケーションを構成するのが 如何に大変である事か 判って頂けたかと思う。

着せてみた･･･

･･･ただし試着、高くて買えない。



んー、なんかこの娘ですら 少し小さく感じるんだが･･･

今回、胸サイズの最大値 上方修正でもされたのかな?

プロセッサの･･･

･･･冷却ファンを換装し、SpeedFanの設定も整った。


件のファンは SilverStone CPUファン SST-FHP141 ･･･とりまAmazonでレビューしてある。

以前のログで 紹介した 速風 -Hayakaze- (GLOBEFAN GF-1425PWM20) - 親和産業  [ Amazon ] よりも
確実な選択となるとは思うが、残念ながら 多くの薄型ケースではマズ収まらないだろう点が唯一の問題点か。

ATXミドルタワーケース以上で空冷 と云う条件であれば、このチョイスが最適解だな。

OBS Studio 更新報告･･･

･･･まぁ、インストールしてれば自動通知されるのだが、導入／設定手順も含めてココに統合予定。


■ UpdateLog･･･

<<< 20160322 080523 >>>
起動時の更新通知で確認、早速適用。

・OBS Studio - Version 0.13.2 → 0.13.4 - Adobe [ 20160321 US ]



<<< 20160321 035600 >>>
更新来たねぇ(^_^)

OBSも そろそろ更新報告ログ仕立てるカナ･･･


<<< 20160322 080523 >>>
CreateLog･･･
　
　
　
　
　

Windowsでの･･･

･･･仮想ASIOアプリケーションでサポートされるサウンドサンプリングレートの上限は
ガチなプロ向け製品でもナイ限り 24bit 96KHz になってしまうのだなぁ･･･(´ﾍ｀；)

と、使っている VoiceMeeter などの仕様を診て ふと思ったトコロ。

恐らくは、寄付して有料顧客になったとしても、その辺は変わらないだろう･･･


<<< UnderConstruction >>>

イマサラながら･･･

･･･オーディオの設定を 24bit 96kHz にしてみた。


全仮想／物理オーディオ･･･

Windowsのモノは云うに及ばす、仮想ASIOアプリケーションや ネットワークオーディオパッチである
JACK AudioConnectionKit なども、適宜設定を一致させないとならないと云うのは、結構面倒だった･･･

また、ディスプレイ iiyama ProLite T2451MTS の HDMI入力 か、AMD RadeonHD7770側起因か、
その設定をサポートしてなくて、少しの間ドツボにハマってしまった(´ﾍ｀；)

結局 スピーカー出力で接続するコトで対応したが、イマドキDVD程度の分解能(24bit96kHz)に
対応していないとは、中々盲点だったよ･･･(;-_-)

こんな風景に･･･

･･･なるとはなぁ

おきつね鯖に･･･

･･･レイアウトした RTMP鯖としての nginxの状態を参考までに公開。


■ 尚、このTipsは、

サイトの公開準備(ドメイン確保、DDNS設定など)が済んでいる必要はある点に注意。
また、LAN内で DNSサーバ ないし、簡易DNS機能憑きのルータ使用していないと 面倒事が多いが、その点には触れていない。

あくまで "Webサイトくらいは公開出来ている" コトが このログの内容を活用する為の最低条件となる。
ツマり、誰にでも判るようなログにはしていない、察しが悪い向きには この内容では解説になっていないだろう。

■ このログの設定サンプルは、

使用しているLANボードのプロパティで、ネットワークアクセスで常用するメインIPアドレスの他に、
RTMP鯖として配信で用いるIPアドレス 192.168.xa.xb を追加設定してあるコトが前提となっている。
xa は メインアドレスと同じに、xb は 未使用の数字を指定する。

また、3つ配信を処理する状態を例としているが、必要の無いユーザーフォルダと application設定は削除していい。


■ フォルダ構成

配布されている nginx_1.7.4_rtmp_1.1.4 のフォルダレイアウ
トでは、WindowsServerで稼動している おきつね鯖の IISとの
連動に不便である為、usersフォルダを追加し、liveフォルダ
を移動、配信ユーザー名に変更してある。

nginxで Webサーバを構成してある場合は サイトフ
ォルダとして usersフォルダが使用されているケース
もあるので、利用環境によっては この構成も一考が
必要になる。

ただ、Windowsであれば WindowsServerでなく
ても、IIS7.x以降を導入でき、Webサイトを立ち上げ
るコトは出来る。 因ってnginxをWebサーバとして
構成する必要はナイだろう。

また、usersフォルダ直下のフォルダ名が配信URLとなる。
ソレを踏まえた上で このフォルダレイアウトを基準に
以下サンプルソース群を参照して欲しい。
ユーザーフォルダ MainUser ExternalUserA ExternalUserB は、任意に名称を変更し、配信のURLとして用いる。
■ nginx.conf

confフォルダ配下に格納されている nginxの基本的な動作を定義する設定が収まるファイル。

以下サンプル中の MainUser ExternalUserA ExternalUserB は、それぞれのユーザーフォルダ名であると同時に、
配信URLとして扱われる。 因って それらを、任意に変更したユーザーフォルダ名に置換するだけで使用が可能となる。

#user nobody; 
worker_processes 4;

error_log logs/error.log crit;

events {
    worker_connections 1024;
}

http {

    access_log off;

    # MIME Settings 
    include mime.types;
    types {
        application/x-mpegURL m3u8;
        video/MP2T ts;
    }

    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    # WebServerSettings 
    #server { 
    #    listen 80; 
    #    server_name localhost; 
    #     
    #    location / { 
    #        root html; 
    #        index index.html index.htm; 
    #    } 
    #} 

    # RTMPServerSettings 
    server {

        server_name live.okitsunesama.com;
        listen 8888;

        # Root 
        location / {
            root users;
            index index.html index.htm;
        }

        # RTMP statistics in XML (stat.xsl) Settings 
        location /stat.xsl {
            root users;
        }

        location /stat {
            allow 127.0.0.1;
            allow 192.168.0.0/16;
            allow 172.16.0.0/12;
            allow 10.0.0.0/8;
            deny all;
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        # rtmp control 
        location /control {
            allow 127.0.0.1;
            allow 192.168.0.0/16;
            allow 172.16.0.0/12;
            allow 10.0.0.0/8;
            deny all;
            rtmp_control all;
        }
    }
}

rtmp {
    server {
        listen 1935;

        access_log logs/rtmp_access.log;

        ping 30s;
        ping_timeout 10s;
        #chunk_size 8192; 
        #max_streams 10; 
        drop_idle_publisher 15s;

        # MainUser Settings ▼▼▼▼▼
        application MainUser {
            live on;

            wait_video on;
            #wait_key on; 
            meta copy;
            #idle_streams off; 
            #publish_notify on; 
            
            allow publish 192.168.xa.xb;
            #allow publish 127.0.0.1; 
            #allow publish 192.168.0.0/16; 
            #allow publish 172.16.0.0/12; 
            #allow publish 10.0.0.0/8; 

            #deny publish all; 

            hls on;
            hls_path users/MainUser/ts;
            hls_continuous on;
            hls_playlist_length 18s;
        }
        # ▲▲▲▲▲

        # ExternalUserA Settings ▼▼▼▼▼
        application ExternalUserA {
            live on;

            wait_video on;
            #wait_key on; 
            meta copy;
            #idle_streams off; 
            #publish_notify on; 
            
            allow publish 192.168.xa.xb;
            #allow publish 127.0.0.1; 
            #allow publish 192.168.0.0/16; 
            #allow publish 172.16.0.0/12; 
            #allow publish 10.0.0.0/8; 

            #deny publish all; 

            hls on;
            hls_path users/ExternalUserA/ts;
            hls_continuous on;
            hls_playlist_length 18s;
        }
        # ▲▲▲▲▲

        # ExternalUserB Settings ▼▼▼▼▼
        application ExternalUserB {
            live on;

            wait_video on;
            #wait_key on; 
            meta copy;
            #idle_streams off; 
            #publish_notify on; 
            
            allow publish 192.168.xa.xb;
            #allow publish 127.0.0.1; 
            #allow publish 192.168.0.0/16; 
            #allow publish 172.16.0.0/12; 
            #allow publish 10.0.0.0/8; 

            #deny publish all; 

            hls on;
            hls_path users/ExternalUserB/ts;
            hls_continuous on;
            hls_playlist_length 18s;
        }
        # ▲▲▲▲▲

    }




■ utils.js

･･･各ユーザーフォルダに納まっているファイル。

MainUser と なっている箇所を 任意に変更したユーザーフォルダ名に置換するだけで使用可能。

function GetFlashVersion(){var m,f,o;try{o=navigator.plugins["Shockwave Flash"];if(o[0].enabledPlugin!=null){f=o.description.slice(16)}}catch(p){try{m=new ActiveXObject("ShockwaveFlash.ShockwaveFlash.7");f=m&&m.GetVariable("$version")}catch(n){try{m=new ActiveXObject("ShockwaveFlash.ShockwaveFlash.6");f=m&&m.GetVariable("$version")}catch(l){}}}f=/(\d+)[^\d]+(\d+)[^\d]*(\d*)/.exec(f);return f?[1*f[1],1*f[(f[1]*1>9?2:3)]*1]:[0,0]}
if (GetFlashVersion()[0] == 0 && !navigator.platform.match("Win")) { location.href = "./index_m.html"; }

var arg = (location.search.substring(1) || "").toLowerCase();

function SetDisplay(element, value) {
    document.getElementById(element).style.display = value;
}

function SetOpacity(element, value) {
    element.style.opacity = value;
}

function SetOpacityIE(element, value) {
    element.style.filter = "alpha(opacity=" + (value * 100) + ")";
}

function OnHlsEnabled(text) {
    if (navigator.platform.match("Win")) {
        //SetDisplay("linkMobile", "none"); 
        SetDisplay("linkQR", "inline");
    } else {
        SetDisplay("linkMobile", "inline");
        //SetDisplay("linkQR", "none"); 
    }
}

function OnHlsDisabled(text) {
    SetDisplay("linkMobile", "none");
    SetDisplay("linkQR", "none");
}

function CheckHLS() {
    try {
        var xhr = new XMLHttpRequest();
    } catch (e) {
        return false;
    }
    xhr.open("GET", "./ts/MainUser.m3u8", true);
    xhr.setRequestHeader("Cache-Control", "no-cache");
    xhr.setRequestHeader("If-Modified-Since", "Thu, 01 Jun 1970 00:00:00 GMT");
    xhr.onreadystatechange = function() {
        if (this.readyState === 4 && this.status === 200) {
            OnHlsEnabled(this.responseText);
        } else if (this.readyState === 4 && this.status !== 200) {
            OnHlsDisabled();
        }
    }
    xhr.send(null);
}

function Body_OnLoad(self) {
    if (arg == "window") {
        SetDisplay("bottom", "none");
    } else {
        if (arg == "small") {
            SetDisplay("linkSmall", "none");
            Bottom_SetTimer();
        } else {
            SetDisplay("linkNormal", "none");
            Bottom_SetTimer(30);
        }
    }
    if (typeof document.getElementById("bottom").style.opacity != "string") {
        SetOpacity = SetOpacityIE;
    }
    CheckHLS();
}

function Bottom_OnMouseover(self) {
    SetOpacity(document.getElementById("bottom"), 1.0);
    Bottom_SetTimer();
}

function QR_OnClick(self) {
    self.style.display = "none";
}

var timerBottom = 0;
function Bottom_Hide() {
    if (timerBottom != 0) {
        clearTimeout(timerBottom);
    }
    timerBottom = 0;
    Bottom_Fadeout();
}

function Bottom_SetTimer(duration) {
    if (timerBottom != 0) { clearTimeout(timerBottom) }
    timerBottom = setTimeout(Bottom_Hide, 1000 * (duration || 10));
}

function Bottom_Fadeout() {
    var alphaBottom = 1;
    var timerFade = setInterval(function(){
        if (timerBottom == 0) {
            alphaBottom -= 0.09;
            if (alphaBottom < 0.15) {
                alphaBottom = 0.15;
                clearInterval(timerFade);
            }
            SetOpacity(document.getElementById("bottom"), alphaBottom);
        } else {
            clearInterval(timerFade);
        }
    }, 100);
}

function ShowQRCODE() {
    var container = document.getElementById("QR");
    container.style.display = (container.style.display == "none") ? "block" : "none";
    var uri = location.href.match(/(.*\/).*$/)[1];
    container.innerHTML = '<img src="http://chart.apis.google.com/chart?\chs=150x150&cht=qr&chl=' + escape(uri) + '"/> ' + uri;
}

function SetupPlayer() {
    if (arg) {
        var w, h;
        if (arg == "window") {
            w = "100%"; h = "100%";
            with (document.getElementsByTagName("body")[0].style) {
                margin = 0;
                padding = 0;
            }
            document.getElementById("container").style.height = h;
        } else if (arg == "small") {
            w = "640px"; h = "360px";
        } else {
            w = "864px"; h = "486px";
        }
        document.getElementById("container").style.width = w;
        document.getElementById("player").style.height = h;
    }

    flowplayer("player", "./flowplayer/flowplayer-3.2.18.swf", {
        plugins: { influxis: { url: "./flowplayer/flowplayer.rtmp-3.2.13.swf", netConnectionUrl: 'rtmp://' + location.hostname + '/MainUser/' } }, 
        clip: { url: 'MainUser', live: true, autoPlay: true, scaling: 'fit', provider: 'influxis',
            onMetaData: function() {
                setTimeout(CheckHLS, 20 * 1000);
            },
            onMetaDataChange: function() {
                setTimeout(CheckHLS, 20 * 1000);
            }
        }
    });
}

このサンプルは 参考構成中の users\MainUser にレイアウトする前提として記述されている。

■ index.html

･･･各ユーザーフォルダに納まっている 各配信のWebページを処理するHTMLファイル。

上述 nginx.conf内 [rtmp]-[server] 各[application] で hls を無効にしている場合は機能しない。

因みに、見た目の変更が必要ナイ場合は、配布されたままの状態で使用出来るファイルである。

<html>
    <head>
        <meta charset="utf-8">
        <link rel="stylesheet" href="default.css" type="text/css">
        <!-- link rel="stylesheet" type="text/css" href="任意のCSSファイルが格納されているURL"-->
        <title>ページタイトル</title>
        <script src="./utils.js"></script>
        <script src="./flowplayer/flowplayer-3.2.13.min.js"></script>
    </head>
    <body class="CatalogView" onLoad=Body_OnLoad(this)>
        <div id="container">
            <div id="player" class="iExp" style="background-color:#5588cc;color:#eeeeee;max-width:1500px !important;"></div>
            <script type="text/javascript">SetupPlayer();</script>
        </div>
        <p id="bottom" onMouseover=Bottom_OnMouseover(this)><a id="linkSmall" href="?small">小</a><a id="linkNormal" href="./">中</a><a href="?window">窓</a><a id="linkMobile" href="./index_m.html">モバイル</a><a id="linkQR" href="javascript:ShowQRCODE();">QRコード</a></p>
        <div id="QR" style="display: none;" onClick=QR_OnClick(this)></div>
    </body>
</html>
このサンプルでは配布版に対し、bobyへクラスを割り当て、外部CSSへのアクセスを行う行を準備している。

■ その他重要なポイント

・上記3つ以外のファイルは 配布されているまま 変更する事無く利用出来る。
・nginxフォルダ内の構成は、稼動する上で重要な要素であり、理解していないうちは変更を推奨しない。
・hlsを有効にし、配信ページも機能させ、その装飾を任意に構成したい場合は 各ユーザーフォルダ配下の default.css へ定義を列挙する。

・IISへは、取得したドメインをバインドさせるよう新規Webサイトを追加し、ソコへ仮想フォルダとして nginx配下の各ユーザーフォルダを設置する。



■ ひまストで配信するだけなら ココまでで設定は完了となるのだが･･･

･･･他の配信サイトへも同時配信したい場合は、その分 nginx.confへ 追記事項が増える。

ただ、ひまストと異なり、外部配信サーバからの配信を受け付ける機能の無いサービスが殆どだ。
その場合、nginxを用いたマルチキャストを実行するには、配信データを対象サービスへpushしてやる必要がある。

要は、ひまスト鯖とOBSを直接接続する配信と同じ状態を、他の配信サービスへ 平行して実行するよう
nginxに指定するコトになると思えば判り易いだろう。

■ 具体的には、nginx.conf内 [rtmp]-[server] 各[application] 配下に

#Twitch.tv (Asia: Tokyo, Japan) 
push rtmp://live-tyo.twitch.tv/app/{Twitchから配布されたユーザーキー};
･･の様な形式で追記する。

その他のライブ配信サービスを対象にする場合の書式は、コチラを参考にすると良いだろう。

■ 上述のTwitchを例に抜粋すると、コンなカンジ ▼

        application MainUser {
            live on;

            wait_video on;
            #wait_key on; 
            meta copy;
            #idle_streams off; 
            #publish_notify on; 
            
            allow publish 192.168.xa.xb;
            #allow publish 127.0.0.1; 
            #allow publish 192.168.0.0/16; 
            #allow publish 172.16.0.0/12; 
            #allow publish 10.0.0.0/8; 

            #deny publish all; 

            hls on;
            hls_path users/MainUser/ts;
            hls_continuous on;
            hls_playlist_length 18s;

            #Twitch.tv (Asia: Tokyo, Japan) 
            push rtmp://live-tyo.twitch.tv/app/{witchから配布されたユーザーキー};
        }

複数対象を追記し、多数のサービスへ同時配信させるコトも可能。
但し いずれの場合も、回線のトラフィックは増大する、利用しているISPの規約や性能を考慮すべきだ。

OBSの･･･

･･･利用スタイルを診るに、


OBS + CLR BrowserSource版のほうが 用途として利用し易いライブ配信者も多いのカモ知れない。


■ CLR Browser Source は、

･･･URLを設定し、Webサイト(の一部)をキャプチャする機能だ。

よくある 流れる文字テロップや コメントを吹き出し処理するような 既存の ツールを多用して配信を構成する場合は
コチラの版を利用して、そのコンテンツを取り込むカタチとなるだろう。

■ ココからが本題だが、

･･･試用の結果 １サイト取り込み毎に 取得範囲のサイズを問わず50MB弱使用されるコトを確認した。

そして、取り込むサイトの数だけ 別プロセスが実行され、倍々にメモリを消費する。
まぁ 指定したサイト毎に、ブラウザを見えない形で起動していると考えれば、当然の話ではある。

■ しかし、

･･･この動作によるリソースの浪費は、それだけではナイ。

[BrowserSource] を 何れかの[シーン]の[ソース]として設定されている OBS Studioでは、
その[シーン]や[ソース]を非表示にし、配信コンテンツとしては利用しない状態にしたとしても、
全てバックグラウンドで稼動し続け、OBS Studioを終了するまでスレッドとメモリを占有されるコトとなる。

■ この点から、

もし、マシンのメモリに余地が無い場合、

CLR Browser Source版の利用 ないし、[BrowserSource]の多用は推奨出来ない。
･･･と云うのが 今回のログの結論だ。

OBS Studio の 設定手順･･･

･･･を 数行で表現する試行。


・(まだ作って無ければ)使用するプロファイルを追加。

・[設定]画面で 配信サービス情報などを 旧OBS同様に設定。

各項目に詳細な設定モードが選択出来る点にだけ注意。
また、今のトコロ ひまスト向けには プロファイルのプリセットは用意されていない。
因って 詳細モードでなければ、 ひまスト合わせの細かな設定は出来ない。

・[シーン]を任意に追加。

・[ソース]を任意に追加。

・追加したソースを右クリック。

・表示されたコンテキストメニューから [フィルタ]を開く。

・開いた['～'のためのフィルタ]画面で、空白な左ペイン下の +ボタンを押す。

・表示された一覧から、任意のフィルタ(機能)を選択して追加。
　(取得画面範囲指定なら[クロップ]、透過/半透過/指定色透過させたい場合は[クロマキー])

・追加したフィルタに 任意の設定を施す。

以上。


■ フィルタが･･･

･･･ナンだか判ってないヤツがTipsしてるサイトとかあって、ヘンな勘違いが広がりつつあるので、

警鐘兼ねて このログをアゲた次第。

フィルタで追加出来る機能で、ソースの枠を決めたりと云った指定は、全て サポートしている。

使用者が欲しい機能を、必要なだけ追加して実行させるスタイルに 適宜変更されただけだ。
アプリケーション開発環境でなら御馴染みな構成であり、別段珍しい造りになっているワケではナイ。

OBS Classic で 可能なコトで、今のトコロ OBS Studio で 実現してないのは、OBS Remote の 導入と使用だけだ。

何故か･･･

･･･盛大に毛嫌いされている AMD Gaming Evolved


マトモなマシンなら、常駐されていても全く支障無いモノだが、皆そんなに貧弱な機器でゲームしてるのかねぇ?

AMDのGPUを採用したからと云って、ゲームで使うとは限らない。 

むしろCADや描画アプリケーションを用いた仕事などでの利用なら ゲームでマシンを使用しない向きも多かろう。
それなら サクっとアンインストールすればイイだけのハナシだ。

それ以前の問題として、AMDの統合ドライバインストール時に 表示される説明をしっかり読めば、
raptrツールをインストールしない導入手順 を 間違うハズもナイのだがね?

画面の表示も読まず、残念Tips鵜呑みにするだけのドライバ導入なんてするなら、自作端末とか組まないほうがいいな。

最低限、説明書や画面表示の英語くらい読もうや、みっともないからさ。 最悪 ググれば翻訳出るよね?
分厚い紙切れの辞書を開かないとならない時代でもナイのに、ソレすらしないで文句垂れるのは そろそろ辞めよう。

raptrツールが嫌煙されている理由も、ココに起因していると結論できる。

元々 英語圏相手の国際的ゲームコミュニティである raptr の コミュニケーションツールである。
設定画面を理解するには、設定画面の英語群を理解する必要があり、説明の英文を読めなければならなかった。

今と違い以前は raptr も、Google同様のスタンスで 全く日本語対応などしていなかった。

そりゃそうだよね、文句ばかりで 対話に必要な努力をしない国の人間相手に
UI対応なんてする気も起きなかったとしても、責めるほうが すぢが違う。

学生時代 英語最低評価だった おきつねさまでも、あの程度の英文群なら意味を理解出来ると云うのに、
日本人、ドンだけゆとりになったんだかな･･･┐(´∀｀)┌


p.s.
raptrサイドに唯一苦言を呈する点があるとしたら、閉じるボタンの無いウィンドウを開かないようにする事だ。
肯定的な利用者を減らしたくないなら一考を推奨する、プログラマならバカでも出来るだろ、ソレくらい。

Windows10のOBSのPSO2キャプチャについて人柱

Windows10にしてみたので、そのへんのことについてカキカキ…

ということで、ちょうどWindows10にアップデートしてから1ヶ月ほど経過して、ある程度配信のこととか整えられました。
なので人柱的に記録を残しておこうかと。（内容的にはブログに書くほどの大した物は無いので悪しからず。）