TeraTermのマクロにおけるリンクと状態制御 その3（2021/02/03） [Windows]
なぜ制御が失敗してしまうかいくつか例を挙げてみたいと思います。
waitで待つ文字列の考慮不足1
waitで待つ文字列の考慮不足2
waitのタイムアウト
waitで待つ文字列の考慮不足1
sendln 'show running-config' wait 'Myhost2' ↓ Myhost2# show running-config .... ! hostname Myhost2 !このようにプロンプト以外でホスト名が出力され、マクロとしてはwaitが満たされたため勝手に先へ進んでしまいます。
waitで待つ文字列の考慮不足2
sendln 'show running-config' wait '#' ↓ Myhost2# show running-config .... interface GigabitEthernet0/3 description ### Server ### switchport access vlan 100CISCOの特権モードではプロンプトが#に変わるため、waitで期待する文字列に設定するケースも多いです。ですがこのように#はdescriptionに含めることができるため、マクロとしてはwaitが満たされ勝手に先へ進んでしまいます。
waitのタイムアウト
timeout=5 sendln 'show tech-support' wait '#' sendln 'show logging' wait '#'timeoutが5秒のため、waitは5秒後に指定文字列の受信がなかったと「タイムアウト」され強制的に先へ進んでしまいます。show techなどは出力完了に数分かかるケースもあります。
タグ：TeraTerm
TeraTermのマクロにおけるリンクと状態制御 その2（2021/02/03） [Windows]
前回、ちょっと専門的で難しく書きすぎたようなので、もっと簡単に書くことにします。
TeraTermのマクロ作りで一番難しいのは、「入力と出力の同期を取ってきちんと制御下におくこと」です。同期が取れておらず、暴走している or 潜在的に暴走しているマクロログは以下のようになります。
単純な改行の連続のはずなのに、空行ができてしまう
投入コマンドが復唱されてしまう
次の投入コマンドがログの中に埋もれてしまう
よく見るパターンですね。これら全て制御に失敗していると言えます。基本的に送信のsend系命令と、受信のwait系命令が1対1で対応していればこのようなことは起こらないはずです。
こういった制御不能な状態を無理矢理制御するために、pause命令でウェイトを入れたりしますが、本質的には愚の骨頂であり何の解決にもなっていません。きちんと制御できているマクロは流れるようにログ取得が行われますが、pause命令でウェイトを入れてしまうと頻繁に停止し、ギクシャクとした動きになってしまいます。
一応私の持論として、きちんと制御できているマクロであればpauseによるウェイトはいらないと思っています。
TeraTermのマクロ作りで一番難しいのは、「入力と出力の同期を取ってきちんと制御下におくこと」です。同期が取れておらず、暴走している or 潜在的に暴走しているマクロログは以下のようになります。
単純な改行の連続のはずなのに、空行ができてしまう
Router# Router# Router# Router# Router# Router# Router#
投入コマンドが復唱されてしまう
Router# show ip route
show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
...次の投入コマンドがログの中に埋もれてしまう
Router# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
show interfaces
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
...よく見るパターンですね。これら全て制御に失敗していると言えます。基本的に送信のsend系命令と、受信のwait系命令が1対1で対応していればこのようなことは起こらないはずです。
こういった制御不能な状態を無理矢理制御するために、pause命令でウェイトを入れたりしますが、本質的には愚の骨頂であり何の解決にもなっていません。きちんと制御できているマクロは流れるようにログ取得が行われますが、pause命令でウェイトを入れてしまうと頻繁に停止し、ギクシャクとした動きになってしまいます。
一応私の持論として、きちんと制御できているマクロであればpauseによるウェイトはいらないと思っています。
タグ：TeraTerm
TeraTermのマクロにおけるリンクと状態制御 その1（2021/02/02） [Windows]
TeraTermのマクロでそこそこのマクロを組んでいます。まあこのマクロ仕様、いろいろとクセがありますね。
多くの人が経験するのは、なんと言ってもマクロの暴走でしょうか。プロンプト受付とコマンド発行の対応が取れておらず、超速でコマンドを発行しまくるのはよくあることです。また、telnet/sshコネクションが切れてしまい、showコマンドを発行する際、接続がありませんとエラーが出てしまうケースもよくあります。
制御の甘さをごまかすためにpause命令で数秒のウェイトを入れたり、それでもおかしい場合はさらにウェイトの秒数を増やしたりと、まさにカオスです。
私の持論として、基本的にウェイト（pause）は不要です。コマンド発行のsendと、それに対する応答waitが対応できていれば、暴走することはありません。まあ、大規模なマクロや汎用性の高いマクロを作ろうとすると、どうしてもウェイトによる微調整が必要になってくる部分もありますが…
「自動でtelnet/ssh接続し、ログ取得を行うマクロを作成」する場合のテクニックを一つ紹介します。
意識しないといけないステップ・状態把握は、ざっと以下の3つがあります。
1)ホストへのtelnet/ssh接続とその状態
2)接続ホストとTeraTermマクロのリンク状態
3)ホストの入力受付状態
順に追って説明します。
1の「ホストへのtelnet/ssh接続とその状態」はconnect命令の実行です。telnet接続しているか or ssh接続しているか、です。これを実行しないと何も始まりません。概念的にも分かりやすいですね。ただ、telnetとssh接続には決定的な違いがあります。最初に言っておきますが、sshの方が10倍制御が難しいです。
telnet接続の場合、「Login:」や「Password:」といったプロンプトがホストから返ってくるので、該当文字列をwait命令で待つことで、意図せず2)と3)の制御ができています。「Login:」が返ってきていることは、入力可能であることと同義だからです。
一方、ssh接続は厄介です。制御がうまくいかない人も多いのではないでしょうか。ssh接続の場合、「Login:」や「Password:」といったプロンプトの返答はなく、connect命令でユーザ名とパスワードを直接指定して接続します。その結果、接続・リンクの状態が不明な「中間状態」が発生します。一言で言えば、「処理中」の状態ですね。
当然、完了していない状態でsendコマンドを発行しようとするとエラーとなってしまいます。だからしばしばpause 10などとマクロに書かれ、適当に10秒待って次の処理へ進むという荒っぽいマクロができあがってしまうのです。
これに対しては2)の状態確認を行う必要があり、testlink命令で確認を行います。
testlinkの戻り値によって、
・ssh接続が完了していること
・TeraTermのマクロ制御とリンクしていること
の2つが確認可能です。ssh接続の場合、暗号化処理が重いのか、1秒～4秒程度のランダムなタイムラグが生じることがあり、より制御を難しくしています。
次に3)の管理・確認が必要です。前述の2)の状態確認では、ssh接続がTeraTermのマクロ制御とリンクしていることは分かりますが、「ホストが送信文字列を受け付け可能か？」には関係しません。
つまり、ssh接続直後など受け付け不可状態で送信した文字列（showコマンド等）は無視されるため、期待するプロンプト文字列が返ってこず、wait待ち状態が続く制御不能状態に陥ります。
これもまたpause 10などと乱暴にマクロに書かれ、適当に待ってから次の処理へ進むという荒っぽいマクロが作られる原因になっています。
実は3)の制御処理は結構厄介です。ダミーのsend（空行）を発行し、応答文字列の有無で判断すれば良いという考えるかもしれません。これはシステムにもよりますが、ssh接続直後にログインバナーなどが表示されるケースがあり、さらにそのバナーの中にプロンプト応答文字列として使われる>や#、%などが含まれている場合もあります。がダミーのsend（空行）に対応する反応とは限らないからです。
例）
step1)ssh接続のconnect命令を実行
step2)マクロでsend（空行）を発行 → しかしホスト側は受け付け不可状態のため無視
step3)ホスト側は依然として受け付け不可状態だが、ssh接続後のログインバナーを応答
step4)マクロは応答をsendに対する反応と誤認識し、文字列送信（コマンド発行）可能と判断
とまあ、泥沼ですね。マクロが暴走する原因に思い当たる節があるのではないでしょうか。
あまりに面倒なので適当なウェイトを掛けてで荒療治するというのも、コストを考えれば現実的な解だったりします…
多くの人が経験するのは、なんと言ってもマクロの暴走でしょうか。プロンプト受付とコマンド発行の対応が取れておらず、超速でコマンドを発行しまくるのはよくあることです。また、telnet/sshコネクションが切れてしまい、showコマンドを発行する際、接続がありませんとエラーが出てしまうケースもよくあります。
制御の甘さをごまかすためにpause命令で数秒のウェイトを入れたり、それでもおかしい場合はさらにウェイトの秒数を増やしたりと、まさにカオスです。
私の持論として、基本的にウェイト（pause）は不要です。コマンド発行のsendと、それに対する応答waitが対応できていれば、暴走することはありません。まあ、大規模なマクロや汎用性の高いマクロを作ろうとすると、どうしてもウェイトによる微調整が必要になってくる部分もありますが…
「自動でtelnet/ssh接続し、ログ取得を行うマクロを作成」する場合のテクニックを一つ紹介します。
意識しないといけないステップ・状態把握は、ざっと以下の3つがあります。
1)ホストへのtelnet/ssh接続とその状態
2)接続ホストとTeraTermマクロのリンク状態
3)ホストの入力受付状態
順に追って説明します。
1の「ホストへのtelnet/ssh接続とその状態」はconnect命令の実行です。telnet接続しているか or ssh接続しているか、です。これを実行しないと何も始まりません。概念的にも分かりやすいですね。ただ、telnetとssh接続には決定的な違いがあります。最初に言っておきますが、sshの方が10倍制御が難しいです。
telnet接続の場合、「Login:」や「Password:」といったプロンプトがホストから返ってくるので、該当文字列をwait命令で待つことで、意図せず2)と3)の制御ができています。「Login:」が返ってきていることは、入力可能であることと同義だからです。
一方、ssh接続は厄介です。制御がうまくいかない人も多いのではないでしょうか。ssh接続の場合、「Login:」や「Password:」といったプロンプトの返答はなく、connect命令でユーザ名とパスワードを直接指定して接続します。その結果、接続・リンクの状態が不明な「中間状態」が発生します。一言で言えば、「処理中」の状態ですね。
当然、完了していない状態でsendコマンドを発行しようとするとエラーとなってしまいます。だからしばしばpause 10などとマクロに書かれ、適当に10秒待って次の処理へ進むという荒っぽいマクロができあがってしまうのです。
これに対しては2)の状態確認を行う必要があり、testlink命令で確認を行います。
testlinkの戻り値によって、
・ssh接続が完了していること
・TeraTermのマクロ制御とリンクしていること
の2つが確認可能です。ssh接続の場合、暗号化処理が重いのか、1秒～4秒程度のランダムなタイムラグが生じることがあり、より制御を難しくしています。
次に3)の管理・確認が必要です。前述の2)の状態確認では、ssh接続がTeraTermのマクロ制御とリンクしていることは分かりますが、「ホストが送信文字列を受け付け可能か？」には関係しません。
つまり、ssh接続直後など受け付け不可状態で送信した文字列（showコマンド等）は無視されるため、期待するプロンプト文字列が返ってこず、wait待ち状態が続く制御不能状態に陥ります。
これもまたpause 10などと乱暴にマクロに書かれ、適当に待ってから次の処理へ進むという荒っぽいマクロが作られる原因になっています。
実は3)の制御処理は結構厄介です。ダミーのsend（空行）を発行し、応答文字列の有無で判断すれば良いという考えるかもしれません。これはシステムにもよりますが、ssh接続直後にログインバナーなどが表示されるケースがあり、さらにそのバナーの中にプロンプト応答文字列として使われる>や#、%などが含まれている場合もあります。がダミーのsend（空行）に対応する反応とは限らないからです。
例）
step1)ssh接続のconnect命令を実行
step2)マクロでsend（空行）を発行 → しかしホスト側は受け付け不可状態のため無視
step3)ホスト側は依然として受け付け不可状態だが、ssh接続後のログインバナーを応答
step4)マクロは応答をsendに対する反応と誤認識し、文字列送信（コマンド発行）可能と判断
とまあ、泥沼ですね。マクロが暴走する原因に思い当たる節があるのではないでしょうか。
あまりに面倒なので適当なウェイトを掛けてで荒療治するというのも、コストを考えれば現実的な解だったりします…
タグ：TeraTerm
Windows10でMIDIファイルを再生 その6 （2021/01/21） [Windows]
救世主はloopMIDIというソフトウェアでした。loopMIDIは、Windows MIDIデバイスの作成と、直接連携できないMIDI機器間のデータ通信を"中継"してくれるしてくれる働きがあります。一言で言えば仮想ブリッジデバイスといった感じでしょうか。
https://www.tobias-erichsen.de/software/loopmidi.html
流れとしてはこんな感じです。
1）loopMIDIをインストールする
2）以前紹介したMIDIMapperをインストールする（VirtualMIDISynthはおそらくインストール不要）
3）loopMIDIデバイスを作成する
4）MIDIMapperの出力先をloopMIDIにする
5）twsyng（Timidity++）を起動させ、以下の通りloopMIDIデバイスで入力を待ち受ける（自動で開始するにチェック）
あとはゲームを起動させればOKです。loopMIDIデバイスが正常に機能している場合、最初のスクリーンショットのようにTotal dataのカウンタがどんどん増えていきます。なお、Timidity++（twsyng）は古い2.13.2を使っていますが、問題なく動作しています。
Let's enjoy 高音質MIDI life!
https://www.tobias-erichsen.de/software/loopmidi.html
流れとしてはこんな感じです。
1）loopMIDIをインストールする
2）以前紹介したMIDIMapperをインストールする（VirtualMIDISynthはおそらくインストール不要）
3）loopMIDIデバイスを作成する
4）MIDIMapperの出力先をloopMIDIにする
5）twsyng（Timidity++）を起動させ、以下の通りloopMIDIデバイスで入力を待ち受ける（自動で開始するにチェック）
あとはゲームを起動させればOKです。loopMIDIデバイスが正常に機能している場合、最初のスクリーンショットのようにTotal dataのカウンタがどんどん増えていきます。なお、Timidity++（twsyng）は古い2.13.2を使っていますが、問題なく動作しています。
Let's enjoy 高音質MIDI life!
タグ：Timidity++
Windows10でMIDIファイルを再生 その5 （2021/01/19） [Windows]
もう一つ、私家版 TiMidity++ for Windows Vistaというのもあり、かなりの改変パッチを取り込んでいるようです。これにはWindowsドライバとしてインストールするための.infファイルも提供されています。
早速、ドライバとしてインストールしてみようとすると、「サードパーティのINF にデジタル署名情報が含まれていません。」と表示されてインストールできず、あえなく撃沈しました。
一応、署名のないドライバを無理矢理インストールする方法もあり、以下のWebを参考に試してみました。が、インストール処理は終わってもTimidity++がMIDIデバイスとして登録されることはありませんでした。（インストールに必要な事前設定が足らない可能性もありますが･･･）
https://4thsight.xyz/4958
と言うわけでドライバとして組み込むのは、難しそうです。
ただ、私家版 TiMidity++ for Windows Vistaには種々の改変パッチが取り込まれているため、機能拡張版としても魅力的なバージョンになると思われます。試しにGUSパッチ用のtimidity.cfgを読み込ませてみました。
･･･音が鳴らない
基本的にどんなバージョンでもtimidity.cfgファイルには下位互換性がありますので、音はすぐに鳴ったものです。ただ、これはピクリとも反応しませんでした。内部では鳴っているけど、出力先がおかしくて音が出ないといった感じではなく、内部でも処理できていなさそうな感じです。
数々のパッチを取り込んだ結果、下位互換性すら失ってしまったのでしょうか。
一応、コンフィグファイルの代わりにサウンドフォントを直接指定して自動生成コンフィグで鳴らすという荒技もできるようです。こちらの方法だと、ちゃんと音は鳴りました。（チューニングが甘いので、荒削りの音色になってしまいますが）
早速、ドライバとしてインストールしてみようとすると、「サードパーティのINF にデジタル署名情報が含まれていません。」と表示されてインストールできず、あえなく撃沈しました。
一応、署名のないドライバを無理矢理インストールする方法もあり、以下のWebを参考に試してみました。が、インストール処理は終わってもTimidity++がMIDIデバイスとして登録されることはありませんでした。（インストールに必要な事前設定が足らない可能性もありますが･･･）
https://4thsight.xyz/4958
と言うわけでドライバとして組み込むのは、難しそうです。
ただ、私家版 TiMidity++ for Windows Vistaには種々の改変パッチが取り込まれているため、機能拡張版としても魅力的なバージョンになると思われます。試しにGUSパッチ用のtimidity.cfgを読み込ませてみました。
･･･音が鳴らない
基本的にどんなバージョンでもtimidity.cfgファイルには下位互換性がありますので、音はすぐに鳴ったものです。ただ、これはピクリとも反応しませんでした。内部では鳴っているけど、出力先がおかしくて音が出ないといった感じではなく、内部でも処理できていなさそうな感じです。
数々のパッチを取り込んだ結果、下位互換性すら失ってしまったのでしょうか。
一応、コンフィグファイルの代わりにサウンドフォントを直接指定して自動生成コンフィグで鳴らすという荒技もできるようです。こちらの方法だと、ちゃんと音は鳴りました。（チューニングが甘いので、荒削りの音色になってしまいますが）
タグ：Timidity++
Windows10でMIDIファイルを再生 その4 （2021/01/17） [Windows]
VirtualMIDISynthというソフトウェアがあり、解の一つとして光明をもたらしそうです。
https://coolsoft.altervista.org/en/virtualmidisynth
ついでに、Windows8以降で消失されたMIDIマッパー設定を復活させるMIDIMapperというソフトウェアもありました。同じソフトウェア会社（？）のアウトプットのようです。
https://coolsoft.altervista.org/en/midimapper
VirtualMIDISynthをインストールすると、正規のドライバインストールを伴って「VirtualMIDISynth」というMIDIデバイスが作成されます。これをMIDIMapperで「既定の MIDI デバイス」を「VirtualMIDISynth」変更してあげれば、高音質な音色に切り替わるのではないかと思います。
----------参考----------
MIDIプレイヤー
↓ 既定の MIDI デバイスを指定（MIDIマッパー）
↓
Windows ← MIDIデバイス・MIDI演奏エンジンを登録（要ドライバインストール）
↓
MIDIデバイス・MIDI演奏エンジン出力
--------------------------
ただ、問題点として、MIDIデバイスはVirtualMIDISynthであり、Timidity++で鳴らすものではありません。とはいっても、VirtualMIDISynthではサウンドフォントを使えるようなので、かなりの高音質で演奏されることでしょう。
（Timidity++もサウンドフォントは使えますが、GUSパッチはサウンドフォント形式のデータではないのでVirtualMIDISynthでは読めない）
https://coolsoft.altervista.org/en/virtualmidisynth
ついでに、Windows8以降で消失されたMIDIマッパー設定を復活させるMIDIMapperというソフトウェアもありました。同じソフトウェア会社（？）のアウトプットのようです。
https://coolsoft.altervista.org/en/midimapper
VirtualMIDISynthをインストールすると、正規のドライバインストールを伴って「VirtualMIDISynth」というMIDIデバイスが作成されます。これをMIDIMapperで「既定の MIDI デバイス」を「VirtualMIDISynth」変更してあげれば、高音質な音色に切り替わるのではないかと思います。
----------参考----------
MIDIプレイヤー
↓ 既定の MIDI デバイスを指定（MIDIマッパー）
↓
Windows ← MIDIデバイス・MIDI演奏エンジンを登録（要ドライバインストール）
↓
MIDIデバイス・MIDI演奏エンジン出力
--------------------------
ただ、問題点として、MIDIデバイスはVirtualMIDISynthであり、Timidity++で鳴らすものではありません。とはいっても、VirtualMIDISynthではサウンドフォントを使えるようなので、かなりの高音質で演奏されることでしょう。
（Timidity++もサウンドフォントは使えますが、GUSパッチはサウンドフォント形式のデータではないのでVirtualMIDISynthでは読めない）
タグ：Timidity++
Windows10でMIDIファイルを再生 その3 （2021/01/16） [Windows]
ここでWindows上でMIDIファイルを鳴らす仕組みをおさらいです。私の理解している範囲なので、厳密には異なる部分があるかもしれません。
----------参考----------
MIDIプレイヤー
↓ 既定の MIDI デバイスを指定（MIDIマッパー）※1
↓
Windows ← MIDIデバイス・MIDI演奏エンジンを登録（要ドライバインストール）
↓
MIDIデバイス・MIDI演奏エンジン出力
--------------------------
となり、※1はWindows7ではコントロールパネルから消え、Windows8以降では完全廃止されてしまっています。
フリーソフトの「MIDIせれくたー4.0」というものがあり、既定の MIDI デバイス（MIDIマッパー）を選択することができますが、残念ながらWindows8以降は対応していませんでした。（指定しても変更が有効にならない）
また、MIDIデバイス・MIDI演奏エンジンとして登録できるソフトウェアも、当時は適切にドライバとしてインストールできたと思われますが、Windows10の改変により、2021年1月現在は「サードパーティのINF にデジタル署名情報が含まれていません。」とインストールすらできなくなっています。
私の知っているTimidity++配布場所は以下でした。
■TiMidity++
http://timidity.sourceforge.net/index.html.ja
http://timidity.s11.xrea.com/
■TiMidity++ windows synthesizer(TWSYNTH)
https://ja.osdn.net/projects/twsynth/releases/
しばらく見ないうちに、以下のようなサイトも増えていました。
■TiMidity++ 41版（音質は悪くなっている模様）
https://ja.osdn.net/projects/timidity41/
■私家版 TiMidity++ for Windows Vista
http://www.maroon.dti.ne.jp/yta/win32utl/timiditypp/
----------参考----------
MIDIプレイヤー
↓ 既定の MIDI デバイスを指定（MIDIマッパー）※1
↓
Windows ← MIDIデバイス・MIDI演奏エンジンを登録（要ドライバインストール）
↓
MIDIデバイス・MIDI演奏エンジン出力
--------------------------
となり、※1はWindows7ではコントロールパネルから消え、Windows8以降では完全廃止されてしまっています。
フリーソフトの「MIDIせれくたー4.0」というものがあり、既定の MIDI デバイス（MIDIマッパー）を選択することができますが、残念ながらWindows8以降は対応していませんでした。（指定しても変更が有効にならない）
また、MIDIデバイス・MIDI演奏エンジンとして登録できるソフトウェアも、当時は適切にドライバとしてインストールできたと思われますが、Windows10の改変により、2021年1月現在は「サードパーティのINF にデジタル署名情報が含まれていません。」とインストールすらできなくなっています。
私の知っているTimidity++配布場所は以下でした。
■TiMidity++
http://timidity.sourceforge.net/index.html.ja
http://timidity.s11.xrea.com/
■TiMidity++ windows synthesizer(TWSYNTH)
https://ja.osdn.net/projects/twsynth/releases/
しばらく見ないうちに、以下のようなサイトも増えていました。
■TiMidity++ 41版（音質は悪くなっている模様）
https://ja.osdn.net/projects/timidity41/
■私家版 TiMidity++ for Windows Vista
http://www.maroon.dti.ne.jp/yta/win32utl/timiditypp/
タグ：Timidity++
Windows10でMIDIファイルを再生 その2 （2021/01/14） [Windows]
高音質なWindows MIDIプレーヤーとして、Timidity++というものがあります。高音質な楽器の音色データを用意し、それをソフトウェアでリアルタイム演算させ、MIDIデータを高音質に鳴らすというものです。まあ、このTimidity++も開発が止まって長いものですが。
Timidity++はかつて有志が高音質なデータを配布しており、私も当時の一式は今でも保存してあります。
GUSパッチというかなり有名なパッチです。Timidity++のバイナリ自体は今でも動くので、ちょっと展開して設定ファイルをチューニングしてあげれば、今でも音を鳴らすことができます。
が、ここから大変です。
Timidity++はあくまでMIDIプレーヤーなので、MIDIファイルを読み込ませて鳴らすには問題ありませんが、ゲームのMIDIデータはゲーム内部で再生するので、プレーヤーとしてこのTimidity++を指定できるわけではありません。当然Windows標準の「Microsoft GS Wavetable Synth」で鳴ることになり、ペコペコという薄っぺらい音で鳴るだけなのです。
昔のWindowsであればMIDI出力の設定がコントロールパネルにあったので、まだやりようがあったのですが･･･さあ困った。
Timidity++はかつて有志が高音質なデータを配布しており、私も当時の一式は今でも保存してあります。
GUSパッチというかなり有名なパッチです。Timidity++のバイナリ自体は今でも動くので、ちょっと展開して設定ファイルをチューニングしてあげれば、今でも音を鳴らすことができます。
が、ここから大変です。
Timidity++はあくまでMIDIプレーヤーなので、MIDIファイルを読み込ませて鳴らすには問題ありませんが、ゲームのMIDIデータはゲーム内部で再生するので、プレーヤーとしてこのTimidity++を指定できるわけではありません。当然Windows標準の「Microsoft GS Wavetable Synth」で鳴ることになり、ペコペコという薄っぺらい音で鳴るだけなのです。
昔のWindowsであればMIDI出力の設定がコントロールパネルにあったので、まだやりようがあったのですが･･･さあ困った。
タグ：Timidity++
Windows10でMIDIファイルを再生 その1 （2021/01/12） [Windows]
今さらMIDI？って思うかもしれませんね。MIDIという規格すら知らない人が多いかもしれません。最近は、MP3やAACなど録音した音楽データそのものを圧縮するフォーマットが一般的ですが、昔はコンピュータにそのような処理能力もなく、音楽データはMIDIという楽譜のような形で配布されることが一般的でした。
当然、楽譜ですから楽器（MIDI機器）によって音のニュアンスや音質は異なりますし、演奏はできても、音声を含めることはできません。ただ、圧倒的にデータサイズが小さかったのです。（データ比 1/1000未満）
まあ、昔のゲームはBGMがMIDIデータで提供されていることもありました。標準のFM音源（MIDIよりも音質は劣る）でもBGMは聞けますが、外部MIDI機器を持っている人は、MIDI出力にすることによって、より高音質なBGMを楽しむことができたのです。
うちの年末の大掃除で古いデータが発掘され、昔のゲームのCDイメージがでてきたんですね。（オリジナルの箱やCD-ROMは捨ててしまってあります･･･）
Windows98時代の懐かしいゲームだったので、さすがに動かないだろうと思ってインストールしてみたら･･･動いた。起動した！ Windows下位互換モードとかそういったものは使っていません。これはちょっとビックリです。
DirectX未使用の通常ウィンドウ上に展開されるゲームだから、変な動作制約などがなかったのかもしれません。
で、まさにそのゲームのBGMがMIDIデータであり、一応「Microsoft GS Wavetable Synth」で音は鳴るのですが、音質の薄っぺらいペコペコ音になってしまいます。ちょっとこれでは味気ないですね。
ただWindows10としてMIDIはサポートされていないようで、コントロールパネルの設定項目からも消失してしまっています。
ちょっとWindows10で鳴らしてみたくなりました。
当然、楽譜ですから楽器（MIDI機器）によって音のニュアンスや音質は異なりますし、演奏はできても、音声を含めることはできません。ただ、圧倒的にデータサイズが小さかったのです。（データ比 1/1000未満）
まあ、昔のゲームはBGMがMIDIデータで提供されていることもありました。標準のFM音源（MIDIよりも音質は劣る）でもBGMは聞けますが、外部MIDI機器を持っている人は、MIDI出力にすることによって、より高音質なBGMを楽しむことができたのです。
うちの年末の大掃除で古いデータが発掘され、昔のゲームのCDイメージがでてきたんですね。（オリジナルの箱やCD-ROMは捨ててしまってあります･･･）
Windows98時代の懐かしいゲームだったので、さすがに動かないだろうと思ってインストールしてみたら･･･動いた。起動した！ Windows下位互換モードとかそういったものは使っていません。これはちょっとビックリです。
DirectX未使用の通常ウィンドウ上に展開されるゲームだから、変な動作制約などがなかったのかもしれません。
で、まさにそのゲームのBGMがMIDIデータであり、一応「Microsoft GS Wavetable Synth」で音は鳴るのですが、音質の薄っぺらいペコペコ音になってしまいます。ちょっとこれでは味気ないですね。
ただWindows10としてMIDIはサポートされていないようで、コントロールパネルの設定項目からも消失してしまっています。
ちょっとWindows10で鳴らしてみたくなりました。
タグ：Timidity++
フリーウェア紹介 Windowsリモートアクセス 2020年7月版（2020/07/26） [Windows]
Windowsのリモートアクセスといえば、最も有名なものは「リモートデスクトップ」でしょうか。ただ、私は以下の理由から使っていません。
・Windows Homeエディションは操作対象にできないこと
・リモートログオン（※1）の仕組みであって、遠隔からのリモートオペレーションではないこと
※1）誰かのログオン中にリモートログオンすると、現在のユーザを追い出すことになる
私が欲しいのはリモートオペレーションの仕組みであり、リモートログオンの仕組みではありません。基本的にフリーウェアで実現することになりますが、時代の流れによる変遷があります。そんな私の環境を振り返ってみます。
■UltraVNC時代
昔はリモートオペレーションと言えば、VNCしかなかったように思います。VNCにもいろいろと派生形があり、ナローバンド向けに最適化されたTightVNCなどもありました。基本的にVNCは暗号化に対応しておらず、sshポートフォワードを組み合わせる方法などと併せて紹介されることが多かった印象です。
やがてUltraVNCが登場し、ミラーリングドライバや暗号化プラグインなど高機能をウリにしていたような記憶でした。長らくこれを使っていたような記憶です。
■TrueRemote ＆ Brynhildr時代
VNCはいろいろと不満があったような印象であり、IchiGekiさんのTrueRemoteが登場してからは、TrueRemoteを使うようになったと思います。（このあたり、記憶があまり定かではない）
ほどなくして後継ソフトのBrynhildrが登場し、そちらに切り替えています。Brynhildrはレスポンを含め使い勝手が良く、つい最近まで主力として活用していました。
Brynhildrの良いところは、
・リモート操作のON/OFF（ビュワーモード）をリアルタイムに切り替えられる
・通信量を落とすために、モノクロモードや低FPSを選択できる
・デフォルトで暗号化に対応
ですね。
■TeamViewerの登場
Brynhildrを使い続けていましたが、やがてTeamViewerが登場しました。GUIが使いやすく作り込まれており、何よりポート転送設定などの事前ケアが不要な点が衝撃的でした。Brynhildrとの共存も問題なくできましたので、Brynhildrのアップデート更新によく使っていました。
ただ、Brynhildrを置換することはなく、スーパーサブの位置づけでした。また、ある時点より商用利用の疑いがあると認定され機能制限されてしまい、異議申し立てをするのも面倒だったので使うのをやめました。
■AnyDeskの登場
TeamViewerを青とするなら、こちらは赤です。（GUIの色合いのことです）
TeamViewerとよく似たコンセプトの製品でしたが、当時のソフトウェアの問題なのか私の環境の問題なのか、Windows設定変更におけるUAC権限昇格要求がリモート画面に反映されず、実画面で直接「OK」ボタンを押す必要があったため、当時は使いにくいソフトウェアという印象でした。
■NoMachineの発見
Brynhildrに不満はなかったのですが、リモートに対するマウス操作の分解能の粒度が低く、改善できる代替品を探していたら出てきました。NoMachineはルクセンブルクのソフトウェアで、日本ではあまりメジャーでないようです。
証明書認証など高度なセキュリティに対応している点や、Unix系と統一した設定・インタフェースで構築できる点で、非常に優れたソフトウェアです。
Brynhildrに代わるものとして暫く使い続けていましたが、Windowsにおける問題としては、
・日本語キーボードのキーマップに対応しているものの特定のキーが打てない
・管理用のユーザをローカルユーザとして作成する必要がある（中途半端なWindowsとの融和）
といったところが挙げられます。
さて。今日現在、実はAnyDeskをメインに使っています。最近は親のスマホをリモートサポートする機会が増え、
・HUAWEI P30（親スマホ）なら、AnyDeskのコントロールプラグイン（ad1）でリモート操作できる
・Windows設定変更におけるUAC権限昇格要求がリモート画面に反映されるようになった
ということで、AnyDeskでスマホもWindowsも一元管理できるためです。あまりの便利さに、AnyDeskならお金を払っても良いかと思いましたが、サブスクライブ制で月額1200円程度とかなりお高めだったので諦めました。（もともと個人利用ですが）
今後、AnyDeskがTeamViewerのように商用主義に方針転換しないか少し心配です。
・Windows Homeエディションは操作対象にできないこと
・リモートログオン（※1）の仕組みであって、遠隔からのリモートオペレーションではないこと
※1）誰かのログオン中にリモートログオンすると、現在のユーザを追い出すことになる
私が欲しいのはリモートオペレーションの仕組みであり、リモートログオンの仕組みではありません。基本的にフリーウェアで実現することになりますが、時代の流れによる変遷があります。そんな私の環境を振り返ってみます。
■UltraVNC時代
昔はリモートオペレーションと言えば、VNCしかなかったように思います。VNCにもいろいろと派生形があり、ナローバンド向けに最適化されたTightVNCなどもありました。基本的にVNCは暗号化に対応しておらず、sshポートフォワードを組み合わせる方法などと併せて紹介されることが多かった印象です。
やがてUltraVNCが登場し、ミラーリングドライバや暗号化プラグインなど高機能をウリにしていたような記憶でした。長らくこれを使っていたような記憶です。
■TrueRemote ＆ Brynhildr時代
VNCはいろいろと不満があったような印象であり、IchiGekiさんのTrueRemoteが登場してからは、TrueRemoteを使うようになったと思います。（このあたり、記憶があまり定かではない）
ほどなくして後継ソフトのBrynhildrが登場し、そちらに切り替えています。Brynhildrはレスポンを含め使い勝手が良く、つい最近まで主力として活用していました。
Brynhildrの良いところは、
・リモート操作のON/OFF（ビュワーモード）をリアルタイムに切り替えられる
・通信量を落とすために、モノクロモードや低FPSを選択できる
・デフォルトで暗号化に対応
ですね。
■TeamViewerの登場
Brynhildrを使い続けていましたが、やがてTeamViewerが登場しました。GUIが使いやすく作り込まれており、何よりポート転送設定などの事前ケアが不要な点が衝撃的でした。Brynhildrとの共存も問題なくできましたので、Brynhildrのアップデート更新によく使っていました。
ただ、Brynhildrを置換することはなく、スーパーサブの位置づけでした。また、ある時点より商用利用の疑いがあると認定され機能制限されてしまい、異議申し立てをするのも面倒だったので使うのをやめました。
■AnyDeskの登場
TeamViewerを青とするなら、こちらは赤です。（GUIの色合いのことです）
TeamViewerとよく似たコンセプトの製品でしたが、当時のソフトウェアの問題なのか私の環境の問題なのか、Windows設定変更におけるUAC権限昇格要求がリモート画面に反映されず、実画面で直接「OK」ボタンを押す必要があったため、当時は使いにくいソフトウェアという印象でした。
■NoMachineの発見
Brynhildrに不満はなかったのですが、リモートに対するマウス操作の分解能の粒度が低く、改善できる代替品を探していたら出てきました。NoMachineはルクセンブルクのソフトウェアで、日本ではあまりメジャーでないようです。
証明書認証など高度なセキュリティに対応している点や、Unix系と統一した設定・インタフェースで構築できる点で、非常に優れたソフトウェアです。
Brynhildrに代わるものとして暫く使い続けていましたが、Windowsにおける問題としては、
・日本語キーボードのキーマップに対応しているものの特定のキーが打てない
・管理用のユーザをローカルユーザとして作成する必要がある（中途半端なWindowsとの融和）
といったところが挙げられます。
さて。今日現在、実はAnyDeskをメインに使っています。最近は親のスマホをリモートサポートする機会が増え、
・HUAWEI P30（親スマホ）なら、AnyDeskのコントロールプラグイン（ad1）でリモート操作できる
・Windows設定変更におけるUAC権限昇格要求がリモート画面に反映されるようになった
ということで、AnyDeskでスマホもWindowsも一元管理できるためです。あまりの便利さに、AnyDeskならお金を払っても良いかと思いましたが、サブスクライブ制で月額1200円程度とかなりお高めだったので諦めました。（もともと個人利用ですが）
今後、AnyDeskがTeamViewerのように商用主義に方針転換しないか少し心配です。
