ソースの表示以前のリビジョンバックリンク全て展開する／折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × MIDI音源が受け付ける初期化メッセージと挙動 サクラ質問の板で、各MIDI音源モジュールが受け付けるシステムセットアップメッセージと挙動の素晴らしいまとめを発見。 非常に有益な情報で消えた時のダメージが（個人的に）計り知れないので、保存もかねて転載させて頂きます。 No.4912/各音源が受け付ける初期化コマンド ■投稿者/ ねお -(2004/02/11(Wed) 14:24:52) □ U R L/ http://textso.under.jp/ ねおです。 交流板で話題になっているので質問してみます。 「あなたが使っている音源は、どの初期化コマンド(GM、GM2、GS、XG)を受け付けますか？」 ●音源名 ●受け付ける初期化コマンドと、受け付けたときの動作 （受け付けた、ってことをあなたがどうやって判断したか） よろしくおねがいします。 No.4913/ねおの場合(SC-88、SC-8850) ■投稿者/ ねお -(2004/02/11(Wed) 14:30:43) □ U R L/ http://textso.under.jp/ ●音源名 SC-88VL(SC-88から音色作成用パネルを省いた廉価版) ●受け付ける初期化コマンドと、受け付けたときの動作 ・GMリセット → GSバリエーション音色が使えなくなる ・GSリセット → 本来の動作 ・SC-88モードセット → MODE-1とMODE-2が切り替わります（MODE-2だとポート1と2で別のエフェクトが使える） ----------------------------------------------- ●音源名 SC-8850 ●受け付ける初期化コマンドと、受け付けたときの動作 ・GMリセット → GSバリエーション音色が使えなくなってピアノになります ・GM2リセット → 使ったことはありませんが説明書に書いてあるので ・GSリセット → 本来の動作 ・XGリセット → ピアノ曲を再生してみたらXGっぽい音色(以前借りてたMU1000みたいな音色)に変わりました ※SC-88モードセットについては不明。ご存じの方教えてください No.4920/((（n;‘Д‘))ηの場合 ■投稿者/ ((（n;‘Д‘))η -(2004/02/12(Thu) 02:08:01) 88モードセットの解釈はそれで大体あっています。要するに、SC-55相当の音源を 仮想的に2台に見せかけるモードです。 確かSC-8850ではMODE2は非対応になったんでしたっけ？ Roland SC-55, SC-55mkII ●受け付ける初期化コマンドと、受け付けたときの動作 ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる ・GSリセット → 本来の動作 ・SC-88モードセット → 認識しない ・XGリセット → 認識しない Roland SC-88Pro ●受け付ける初期化コマンドと、受け付けたときの動作 ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる ・GSリセット → 本来の動作 ・SC-88モードセット → モード1/2の切り替え ・XGリセット → ドラム音色配列がXG互換に(通常音色はBANK0のみになる？未確認) YAMAHA MU50/80/90/100/100B/100Bs/100R/128/500/1000/1000EX/2000EX YAMAHA S-YXG50系、DS-XG系、AC-XG系 ●受け付ける初期化コマンドと、受け付けたときの動作 ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる ・GSリセット → TG300Bモードに切り替わる(MU1000EX/2000EXからはGSモードと名称変更) ・SC-88モードセット → 認識しない ・XGリセット → 本来の動作 TG300BモードはGSモードと同等です。SC-88以降のディレイやMFXには対応しません。 TG300Bの音色数は基本的にSC-55相当です。 しかし、後期に販売されたMUは音色数が微妙に増えています。 実際にどの音色が追加されたかまでは調べていません。自分でマニュアル見てください。 (尤もTG300Bモードは互換性の為に用意されているので、このモードで曲を作る意味合いは全くありません) NS5R/NX5R ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる ・GSリセット → 音色配列がGSと互換性の高い物に変わる、エクスクルーシブはSC-55相当の物を一部受け付ける ・SC-88モードセット → 認識しない ・XGリセット → 音色配列がXGと互換性の高い物に変わる、エクスクルーシブはXGの物を一部受け付ける(バリエーションエフェクト非対応) Roland SD-20/80/90 ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる ・GM2リセット → General MIDI Level2で規定された命令しか受け付けなくなる ・GSリセット → 音色配列がGSと互換性の高い物に変わる、エクスクルーシブはSC-55相当の物を受け付ける ・SC-88モードセット → 認識しない ・XGリセット → 音色配列がXG Liteと互換性のある物に変わる、エクスクルーシブはXG Liteの物を一部受け付ける？(バリエーションエフェクト非対応) 既存と異なる構成のvdevをプールに追加しても特に問題はないらしい ZFSで既存プールにストレージを追加する場合、既存のvdevと同じ構成のvdevとするのが基本である。具体的に言うと、HDD 3台のRAID-ZプールにHDDを追加するには、HDD 3台を追加しなければならない。HDD 4台を追加しようとしても「mismatched replication level: pool uses 3-way raidz and new vdev uses 4-way raidz」と怒られてしまう。実際のログはこんな感じ。 $ zpool status pool: ztank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM ztank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors # zpool add ztank raidz da3 da4 da5 da6 invalid vdev specification use '-f' to override the following errors: mismatched replication level: pool uses 3-way raidz and new vdev uses 4-way raidz だがしかし、ログにもある通り-fオプションを付けると、異なる構成のvdevでも難なく追加出来てしまう。 # zpool add -f ztank raidz da3 da4 da5 da6 # zpool status pool: ztank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM ztank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 errors: No known data errors この通り。 forceオプションが必要な事からも分かるように、これは非推奨のプール構成である。かといって、何か問題があるかというと実は然程問題ないらしい。vdevの使われ方に偏りが出たり性能が落ちる可能性はあるものの、危険だったり有害だったりはしないそうだ。まぁ、本当に危険だったら、この操作そのものが許されてないよね。 ZFSの仕組み上、プールの特性は構成する各vdevの最も低い特性の影響を受けるので、vdevの特性は揃えておくのが望ましい事から「非推奨」となっているようだ。名前の通りvdevを仮想的な1台の物理ストレージに置き換えて考えると分かりやすいかなと。 ゆえに上記プール例では速度がHDD 3台のraidz1-0に引っ張られる事になる。また、物理HDDが全て同じ容量だとすると、raidz1-1の方が大きいので容量の消費も偏る事になるが、raidz1-0とraidz1-1はストライピングであることから総容量は全て使われる（ハズ）。ミラー構成時の容量にだけ気をつけとけば、そんなに神経質になることもないのかも。少なくとも家庭用NAS用途なら殆ど問題にならない気がする。速度面ではネットワークが最大のボトルネックだしね…。 よくよく考えると、うちのサーバはHDD×3でRAID-Zの所に空き容量低下でHDD×3を追加したもんだから、vdev間の偏りたるや相当なもの。zpool iostatで見てもストライピングというより最早JBOD状態で、こんなのでもちゃんと動いてるんだからvdevの構成違いなんて誤差みたいなものでしょう、きっと。 参考サイト ZFSのmirror/raidzの容量を増やす方法 - 富士山は世界遺産 ZFS mismatched repli levels | The FreeBSD Forums Mismatched Replication Levels - Oracle Solaris ZFS Administration Guide C#のCreateDocumentTypeがタイムアウトする時の簡易対策 C#のXmlDocumentでHTMLを生成しようと、W3CのDTDを指定してXmlDocument.CreateDocumentType()するとタイムアウトやHTTPステータスコード500で例外を吐くことがある。こちとらvalidなHTMLを生成しようと真面目に指定してんのに、この仕打である(´・ω・｀)。みんなW3Cを見に行って慢性的な高負荷状態になってるのが原因らしいが、まぁ当然そうなりますわな…。 コードにすると↓な感じ。 XmlDocument doc = new XmlDocument(); XmlDocumentType docType = doc.CreateDocumentType( "HTML", "-//W3C//DTD HTML 4.01 Frameset//EN", "https://www.w3.org/TR/html401/frameset.dtd", null); /* ここでエラー */ XmlResolverでローカルキャッシュしたDTDをマッピングするのが正攻法らしいのだが、ぶっちゃけ面倒。というか、調べても良くわからんかったのでパスｗ（分かったら追記する…多分） とりあえずエラーを回避するだけなら、CreateDocumentType実行前にXmlDocument.ResolverをnullにしてやればOKっぽい。コードにするまでもないが一応書いておく。 XmlDocument doc = new XmlDocument(); doc.Resolver = null; // 追加 XmlDocumentType docType = doc.CreateDocumentType( "HTML", "-//W3C//DTD HTML 4.01 Frameset//EN", "https://www.w3.org/TR/html401/frameset.dtd", null); /* エラーにならない */ ・・・と、ここまで書いて思ったが、これで回避できるって事は自前実装したXMLリゾルバでDTD返してやればいいだけなんじゃね？ 2016-04-13追記 といわけでローカルのDTDを使うリゾルバを作った。 P4で「Client 'foo' can only be used from host 'bar'」と言われた時の対処方法 Perforceのワークスペースは基本的にマシンと紐付いているため、複数マシン間で使い回すことができない。 普通は使い回しはしないので問題はないのだが、故障などでマシンを交換した時にちょっと面倒なことになる。利用可能なワークスペース一覧に表示されず、たとえ無理やり選択しても「Client 'WORKSPACE' can only be used from host 'OLD-HOSTNAME'」と怒られて使えないのだ。 ちなみに新旧マシンのホスト名を一緒にしておけば問題は起きず、まぁ新マシンで新たにワークスペースを作ってしまうのが正攻法なんだろうけど、巨大なデポだと再取得するのも嫌じゃん？ そんな時はp4 clientコマンドでワークスペースが持っているホスト名を変更すれば良い。手順は下記の通り。 p4コマンドが使える状態にする。 p4 client を実行。 ワークスペースの情報がテキストエディタで表示されるので、Host: OLD-HOSTNAME となっているところを Host: 新マシンのホスト名 に変更して保存。 テキストエディタを終了すると、Client WORKSPACE saved.と表示されワークスペース情報が更新される。 念のためp4 infoで「Client host:」が書き換わってるか確認。 以上で新マシンから既存のワークスペースが使えるようになるハズ。 C#のジェネリックで特殊化っぽいことをする 新年明けましておめでとうございます（遅。開設14年目となるクソゲ～製作所を本年もよろしくお願い致します。 Cのテンプレートには特殊化という、特定の型パラメータの時にテンプレートの実体を別に定義する機能がある。だが、C#版テンプレートとも言えるジェネリックでは、なんということでしょう、特殊化が使えないではありませんか！それをどうにかしてジェネリック特殊化っぽい事をしてみたっていうお話。 こんなコードがあったとする。 <code csharp> public class Node { // 子ノード public List<Node> Children; // 特定の子ノードを取得 public List<T> FindChildren<T>() : where Node { List<T> list = new List<T>(); Type type = typeof(T); foreach (Node e in Children) { if (type == e.GetType()) { list.Add(e); } list.AddRange(e.FindChildren<T>()); } return list; } } public class DocumentNode : Node {} public class PageNode : Node {} public class TitleNode : Node { public string Title; public TitleNode(string title) { Title = title; } } public class SectionNode : Node { public TitleNode Title; } static void Main() { DocumentNode doc = new DocumentNode(); PageNode page = new PageNode(); doc.Children.Add(page); SectionNode section1 = new SectionNode(); section1.Title = new TitleNode("はじめに"); page.Children.Add(section1); SectionNode section2 = new SectionNode(); section2.Title = new TitleNode("つぎに") page.Children.Add(section2); // 全セクションを取得 List<SectionNode> allSections = doc.FindChildren<SectionNode>(); //正しく取得できる // 全タイトルを取得 List<TitleNode> allTitles = doc.FindChildren<TitleNode>(); //★正しく取得できない!! ... } </code> <code> ◆データ構造 [DocumentNode] -Children -[PageNode] -Children -[SectionNode] -Title -Children -[SectionNode] -Title -Children </code> 文章を模したデータ構造を作り、''FindChildren''メソッドで型をパラメータに子ノードを取得しているが、 ''doc.FindChildren<SectionNode>()''は正しい挙動をするものの、''doc.FindChildren<TitleNode>()''の方は空のリストが帰ってくる。''FindChildren()''は''Node.Children''しか見てないので、独立したメンバ''SectionNode.Title''が入るはずはなく当然の挙動である。 こんな時、C++なら特殊化で''FindChildren<TitleNode>''専用の処理が書け同一のインタフェースを提供できるのだが、前述の通りジェネリックは特殊化が使えないの。C#的には''FindChildTitleNodes()''的な別メソッドで提供するのが正しいのかもしれないが、やっぱり統一感に欠けて美しくない（そもそもこんな糞いデータ構造にすんなって話だが例ってことで許してね。） で、知恵を振り絞って''FindChildren''を以下のようにした。 <code csharp> public List<T> FindChildren<T>() : where Node { List<T> list = new List<T>(); Type type = typeof(T); if (type == typeof(TitleNode)) // (1) { List<T> titles = new List<T>(); // (2)-a var sections = FindChildrenInternal<SectionNode>(); section.ForEach(e => { titles.Add(e.Title as T); }); // (3) return titles; // (2)-b } return FindChildrenInternal<T>(); } List<T> FindChildrenInternal<T>() : where Node { List<T> list = new List<T>(); Type type = typeof(T); foreach (Node e in Children) { if (type == e.GetType()) { list.Add(e); } list.AddRange(e.FindChildren<T>()); } return list; } </code> 元の''FindChildren()''を''FindChildrenInternal()''とし、''FindChildren()''には型パラメータ''T''に応じた処理を書くようにした。C++でコンパイラが自動で行ってくれる特殊化による処理の振り分けを、実行時に手動で行うような感じかしら。原理上、実行時コストは増えるが、この程度なら大した影響はないだろう。JIT様もあることだし。 型が増えると''if''と特殊化処理の嵐になるが、型ごとに処理デリゲートを作って''Type''とデリゲート辞書でも作ればすっきりするので大した問題ではない。そもそも、そんな状況は最早「特殊化」の本質から外れてるので設計から見直すべきだろう。 このコードのミソは(1)～(3)の部分。 (1)で処理すべき''T''の型が明確になったものの、(2)-aで''List<T>''としているのはコンパイルを通すため。''List<TitleNode>''でも良さそうに見えるが、''T == TitleNode''になるとは限らないので(2)-bで型不一致エラーになる。''List<TitleNode>''とした場合に''T = SectionNode''で呼び出した時にどうなるかを考えれば、すぐにおかしさに気づいて頂けるかなと。 (3)も一見''titles.Add(e.Title)''で良さそうだが、これまた''TitleNode''が必ずしも''T''に変換可能とは限らないのでCS1503エラーとなる。よって、ちょっとアホくさいが''TitleNode''を自身の型''T''にキャストしてやらなければならない。 メソッドの引数に型パラメータを持てる場面では、[[https://arbel.net/2007/11/22/c-partial-specialization-with-extension-methods/ 拡張メソッドを使った特殊化もどき]]が使える模様。 リフレクションは楽しいなー。Cにも軽量な型情報システムがあればいいのになぁ…。 < Newer Posts 1 2 ... 39 40 41 42 43 44 45 ... 83 84 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo