デスクトップでLinuxが普及する訳ないと思った時 14
■ このスレッドは過去ログ倉庫に格納されています
>>56
× 録音済みのPCM音源鳴らすだけですやん
○ 録音済みの音をPCM音源で鳴らすだけですやん
PCM音源(ハードウェア)を
録音するとか意味不明ですからw >>56
MIDIデータをMIDI音源を使わずに、PCM音源でならすってことは
それこそMIDI音源がレガシーになった何よりの証拠では? 音源モジュール自体楽器から録音したか合成したてROMに収めたPCM音再生しとるだけでしょ?
波形データがROM上にあるか、RAM上にあるか程度の違いのような・・・?
PC98の高速テキスト画面だけがテキスト画面!みたいな意味のないこだわりにみえるんだけど MIDI音源自体が内部でPCM音源になってる場合はどうなるんだか >>62
混乱してるようだから図式化してあげよう
0. MIDI機器 → MIDI音源 → (MIDI音源内部の)PCM音源
の話であれば、それは別にレガシーでもなんでも無くごく普通の話だが、
そもそもパソコンやOSは全く出てこない。まったく関係ない話。
1. アプリ → (パソコンにつないだハードウェア)MIDI音源 → (ハードウェアMIDI音源内部)PCM音源
2. アプリ → (OS搭載のソフトウェアエミュレート)MIDI音源 → (パソコン搭載のハードウェア)PCM音源
レガシーになったのはこの二つ。驚くべきことに昔はアプリが
MIDI音源に対して音を鳴らしてってMIDIデータを渡してたんだよ。
そういうMIDI音源がパソコンに接続、または搭載されていた。
御存知の通り今はこのように、アプリは直接PCM音源に対してデータを渡している。
3. アプリ →(パソコン搭載のハードウェア)PCM音源
もしくは古いMIDIファイルを再生するためのプレイヤーを使ってる。
4. アプリ(MIDIファイルを読み込んでPCMデータに変換) →(パソコン搭載のハードウェア)PCM音源
3と4ではレガシーなMIDI音源は消えてなくなってる。 レガシーくんが混乱してるのはW95時代に、PC入門者がMIDIファイルを再生した過去を、あれはレガシーだと勝手に決めつけてる事だね。
現代のPC入門者はMIDIファイルで無くPCM録音からのMP3を再生してる。
PC初心者がMIDIファイルを扱わなくなったから、MIDIをレガシーと勘違いしてるだけなんだよな。
しかし昔も今も同じなのが、生楽器以外の音楽制作はMIDI規格から作られたMIDIファイルで行われてる事も知らないらしい。
しかもそれをエミュレートだと勘違いしてる。
MIDIファイルその物に音源は含まれていない。
MIDIファイルで鳴らす音源がPCM音源(笑)
まあFM音源でも良いけどね。
ただ昔はプロレベルでは外部音源を使っているのが多かったが、
今ではパソコンだけでも全部出来るようになった。
この間の東京JAZZではチック・コリアエレクトリックバンドの演奏で、いろいろなMIDI機材が見られた。 レガシー君の書き込みをたどってみたが、どうやら彼が言う「レガシーなMIDI音源」って「俺定義のMIDI音源」だね。
なのにその俺定義については一切触れないから周りが理解できない。
当たり前だが。
自分が何言ってるのかレガシー君当人も判ってないんだろうな。
バカっぽいし。 >>65
> レガシーくんが混乱してるのはW95時代に、PC入門者がMIDIファイルを再生した過去を、あれはレガシーだと勝手に決めつけてる事だね。
いや決めつけるなよw
最初から一貫して「パソコンに搭載されたMIDI音源」がレガシーだと言ってるだろw
あといつもどおり、MIDI音源の「音源」を勝手に抜かすなや。
お前MIDIの話しかしてないじゃないか、MIDI音源の話だ。俺はMIDI音源の話しかしてない。
お前が混乱してるんだわw
>>66
> レガシー君の書き込みをたどってみたが、どうやら彼が言う「レガシーなMIDI音源」って「俺定義のMIDI音源」だね。
であれば一般的な「MIDI音源」の定義をあんたが探してきなさい。
「お前は間違ってる!だが間違ってる理由は一切説明しない!」じゃ
筋が通らんでしょw ここまでのまとめ
犬厨A「俺はPC-98エミュレータでtmidityを使っている!」
犬厨B「俺はSC-8820を今も使っている!」
A&B「MIDIはレガシーじゃない!」
俺「レガシーじゃないのに何で機材を更新してないの?」 >>70
犬厨って 林 檎 と 白 い お 父 さ ん 犬 が大好きなア フォ ン厨の事ですよ。
でもアッポレOSはWindowsと違って恐怖のiesysとA gentBaseに感染しないから、
身に覚えのない誤 認 逮 捕をされないんだお(笑) ディスクリートで組まれたアシッドな音が欲しいからに決まってるだろ。 みんな勘違いしているけど、俺が欲しいのは原音に忠実なクリアーな音ではない。
昔のレコードや真空管アンプにあった心に響くアシッドな音だ。 ここまでのまとめ
窓厨A「俺はエミュレータと言う言葉を間違って使ってしまった」
窓厨B「俺は技術の進歩でDAWが出現した事は知らん」
A&B「コンサート会場で目隠しをしてたからMIDI楽器は全く見えなかった」
俺「レガシーなのに何で今でも世界中のクラシック以外のミュージシャンに使われてるんだろうと思ってワロタ」
ヤマハ「最新のMIDIピアノが発売されるのも知らない情弱なんだろ」
楽器屋「バイオリンがレガシーと言うのと同じ理屈なんだろ」 プロの音楽家はLinuxを使っている。
なんて話もないけどな。 今時はバイオリンで打ち込みできたりしますね
ttp://www.cantinielectricviolins.com/2/earphonic_electr_midi_violin_3825378.html 現代はpc上で動作するソフトウェアmidi音源とかローランドとかコルグやヤマハ辺りが過去の音源とかのエミュで動いていると思ってた。 nihonngonyuuryokugamatomonidekinakunattatoki. nimfupoieuramnfakjsdpepqeipuwyajldjzvdzkfaur ちょっと雑に扱うとシステムの整合性が崩れる
クライアントサイドの業務ソフトがほぼない
知らんうちにファイルシステムが壊れる レガシーくん発狂しててうざいな。
MIDI音源とやらが廃れたことにしたいらしいけど、もとからそんなものは物はないんだから廃れるも何もないのに。 PCオーディオ「Linux最強」は本当か?導入編
そこで今度は仕事用のWindows8を使用し、WinPCで同じ音楽を再生してみることに。
WinPCでのハイレゾ再生、Linuxと比べて少々雑味が増えている印象です。
全体的に輪郭が薄れ、クリアさが今ひとつ削がれた、薄膜が一枚張られた感じは否めません。
もちろん仕事用という事でノーマル状態&プロセス多しというWindowsマシンと比べるのは少々酷かもしれませんが、
LinuxがPCオーディオに有利とされる根拠は十分に感じ取られることができました。 >>77
一時期盛り上がったGM/GS/XG系ハードウェアのものをソフトウェアで現行リリースしているのはローランドのSoundCanvasVAくらいかも オーディオ再生用機材としてみるならPCよりスマホのほうが音がよかったりする。 >>74
ゲームのBGMの演奏用に使っておきながら、そういった用途が滅亡したことを全く認識できないのなwww
ググったらまだ使われてた!レガシーじゃない!www 波形合成を行う音源でもPCMとは限らないから
MIDI音源ってPCM音源の事だろうって言ってるアホは
僕は蕎麦とラーメンの区別がつきませんくらいの馬鹿に見える >>88
楽器や自然界の音をLA音源とFM音源とPCM音源のどれから加工すれば簡単なのか分からないのがレガシーくん(笑) 音源はサンプラーしか存在しないと思ってるのか
さすがにそんな馬鹿が何人も居るとは思えないので同じ奴が一人でわめいてるだけだろうと思いたいが >>90
楽器や自然界の音はPCM音源から、いかにも高次倍音みたいなシンセ特有な音は、一例としてFM音源から作るのが分からないのがレガシーくん。 >>89
おい、レガシー君は俺やで
誰彼構わずレガシー君呼ばわりするのやめろよ
敵は一人だって思い込んでるぞw 音源といえばPCMとFM音源しか知らないのか
矩形派やサイン波を合成してシンセサイズするのがシンセサイザー
PCMやFMはその一実装に過ぎん
無知すぎる >>93
そんなのレガシーくんだって知ってるアナログシンセだぞ。 FM音源が小室で、PCM音源がKポップという認識でOK? 昔のPCではMIDIガーってやりたいなら昔PC板でやれよ。 こりゃあデスクトップでLinuxが普及するわけないわぁ・・・ GNOME派とKDE派の足の引っ張り合いとか見てても「普及するはずない」って思うわ。 >>102
その点、カーネルは分裂せずによく頑張ってるよな。
リーナスがguiとかにも口を出せばdesktopでもワンチャンあったかもしれんな。 尊師がナチ党員だったことがバレて代表降りたような気が。 >>105
Wineの互換性を高めるためには、X-WindowのZ-Orderや矩形以外のWindow、
透明処理などに関して、Windowsに似た動作をするための修正が必要のようだ。 >>107
> Wineの互換性を高めるためには、X-WindowのZ-Orderや矩形以外のWindow、透明処理など
xeyes等で使われているX Window SystemのShape extensionって30年以上前からあるんだけど
ttps://en.wikipedia.org/wiki/Shape_extension >>108
たぶん、"X-Window"は"X window system"とは別物なんでしょ。どうでもいい事だけど。 >>108
あるけど、Windowsの透明や非矩形Windowと相性が悪くて、処理がものすごく遅く
なったり、フラッシュするとシステム描画が全くできなくなって、数分間
ハングアップしたかのように見える現象に悩まされたりすることがある。
なので、どこかで MS Windowsの仕組みに歩み寄りが必要。 >>111
非常に複雑なので、手短に説明するのは難しいが、触りだけ理由を書いておく。
Linuxだと、ピクセルごとに自由にARGBの A = アルファ値 を使って
システム中に浮いているWindowに対しても透明色が扱えるのに対し、Windowsだと
システム中に浮いているWindowに対しての透明色は、SetLayeredWindowAttributes()
とLWA_COLORKEYを使わないといけない。Windowsでも一見、アルファ値を指定でき
そうだが、実際にはWindow全体のアルファ値なので、好きな部分だけを完全に透明
にして、他の部分は、元のままのようにすることは出来ず、全体的に薄くするような
ことしかできない。
それで話が複雑なのが、Windowsの場合は、LWA_COLORKEYに指定した色の部分は、
完全透明になるだけでなく、その部分でマウスをクリックすると、デスクトップや、
デスクトップ上のアイコンにまで伝達されてしまうようになる。つまり、単に
透明なだけではなく「穴あき」状態になる。
一方、Linuxでは、A=0にしたピクセルは完全に透明になるが、穴が開いている訳ではなく、
上記の様なマウスメッセージのデスクトップへの伝達は生じない。
なので、このままだと、Windowsを模倣することは出来ない。そこで、Wineでは、
LinuxではARGBを使わずに、X-Windowの外形を変えるシステムコールを使っている。
ところが、それはピクセル単位ではなく、行単位でランレングスの様な形式で
データが与えられる。そして、これが頻繁に図形を変えるととても遅い。
Linuxでのこの仕組みは起動時に一度だけWindowの外形を変える目的で使われる
ためである。一方、WindowsのLWA_COLORKEYを使ったやり方は、ピクセル単位で
画像を変更してもとても高速に処理できる。
これで、ある種のねじれ現象が起きてしまう。説明が長くなるが、お互いに悪い部分同士
の性質が出てしまって、Wineでのエミュレーションはとてつもなく重たくなってしまっている。 >>112
> Linuxだと、ピクセルごとに自由にARGBの A = アルファ値 を使って
いいえ
> 一方、Linuxでは、A=0にしたピクセルは完全に透明になるが、穴が開いている訳ではなく、
> 上記の様なマウスメッセージのデスクトップへの伝達は生じない。
いいえ
技術的にめちゃくちゃ >>113
徹底的な実験調査に基づくものです。
そういうデタラメな反論はよしてください。 今気づいたが
> 一方、Linuxでは、A=0にしたピクセルは完全に透明になるが、穴が開いている訳ではなく、
> 上記の様なマウスメッセージのデスクトップへの伝達は生じない。
>>108でリンクを貼った
ttps://en.wikipedia.org/wiki/Shape_extension
に
For example, if a window is shaped with a hole in the middle, not only the hole shows what is below
the window, but a click in the hole is considered to be a click in what is below the window.
後ろに伝達するってはっきり書いてあるじゃん
レスするならちゃんと読んでね あ、>>111-112が何をいっているかわかった気がする
これ、X Rendering Extension(XRender)の話だよね?
ttps://en.wikipedia.org/wiki/X_Rendering_Extension
Keith Packardが20年ぐらい前に作った半透明Windowや透過Windowなど
gtkやQT等の現X環境でメインで使われているのがX Rendering Extension
半透明でなく穴あきのWindowを実現するXの拡張は>>108で言ったように
Keith Packardが30年ぐらい前作ったShape Extensionで、透過ウィンドウや
3Dアクセラレーションがなかった頃からある拡張 >>115
Linuxでも、マウスがデスクトップを「触れる」ような本当に穴を開ける
方法も存在していることは存在している。そしてそれはWindowの真ん中
でも穴は開くし、いくつでも穴は開くので解く形の制限は無い。
しかし、そうするためのシステムコールは、横一行ごとに
ランレングスタイプで指定する。穴が空いている場所と空いて無い場所の
変化点までの長さを次々に最後まで指定するようなイメージ。
それを縦のどドット数分だけ繰り返す。
この方法でも速度面以外では、Windowsと余り変わらないことが出来る。
一方、厄介なことに、Windowsでは、ARGB値を使っての「完全なる透明化法」が、
子ウィンドウに対しては使えるが、デスクトップに浮いているような
TopLevelWindow では使えないので、LWA_COLORKEY が必要となる。
そして、LWA_COLORKEY 法を使うと本当に穴が空いてしまう。
それをLinuxで模倣するためには、上記に書いたように、ランレングス的な
方法で情報を与えなくてはならない。
Windowsで、「完全透明」の TopLevelWindow をアニメーションしたいと思ったら、
上記の方法で高速に行える。本当にアニメ長の絵を秒間60枚でも描こうと思えば描ける。
これは当然、LWA_COLORKEYを使うことになる。
一方、Linuxでは、ARGB法を使えば同様に、TopLevelWindowで、全く同様のことを
高速に行える。
ところが、Wineの場合は、上記のWindowsアプリをエミュレート実行するためには、
LWA_COLORKEYを模倣しなくてはならない。そして、それは、実際に穴を開けてしまうので、
Linuxのせっかく高速なARGB法が使えない。そこで、上記のランレングス法を使わざるをえない。 >>117
ところが、このランレングス法は、アプリを最初に起動した直後に一度だけ行うことを想定している
らしいことと、ランレングス法を使っていることで、透明色のON/OFFが非常に激しく変動すると
ランレングスデータが大きくなってしまうことも有って、ものすごく時間が掛かる。
ものすごくといっても、1/60秒に比べて遅い程度。しかし、やっかいなことに、これが
X-Windowのコマンド・バッファ(?)に「蓄積されてしまう」。
で、Windowsの場合、このように描画が遅い場合は、Invalidate() 系の関数が自動的に処理の
頻度を遅らせてくれたりするようになっているので問題にならないが、Wineは、それが上手く
模倣できていない。調べてみると、もう忘れてしまったが、X-Windowのコマンドバッファが
たまっているか、空いているかを調査する関数が正しい値を返さなかったり、また、
処理のフラッシュが沢山の種類があるが、どれも、本当の意味でフラッシュしてくれなかったり
することで、結果的にエミュレートが出来ないことになっていることが分かった。
思い出してきたが、「Xのコマンドをフラッシュして処理が終わるまで帰ってくるな」
という意味の関数を呼び出しても、実際には、Xの描画が終わって無いのにすぐに帰ってきたりする。
実は、このことと絡んで、WM_TIMERもちゃんとエミュレートできていない。WM_TIMERも、
Windowsでは優先順位の最も低いメッセージの一つで、画面処理が遅いような場合は、
システムが適当に間引いてくれることで、異常な処理の遅さを回避できているのだが、
Wineではそれが模倣できていない。この理由も今述べたようなことが複合的に重なって、
での仕組みを使っても模倣できない事態になっていた。 >>118
「Xのコマンドが実行完了するまで戻ってくるな」
の意味のシステムコールはあるにはある。これをFとしよう。
Linuxで先から述べている「ランレングス法を使った外形変更」のXコマンド、
をRとしよう。
Fは、Rについては処理が終わって無くても、すぐに帰ってきてしまう。
だから、せっかくFを実行してもRはまだ終わって無い状態になっている。
もし、Fが、Rの処理が終わるまで待ってくれていたなら、問題は余り無い。
単に描画が本家Windowsより遅い程度で済む。
ところが、現実には、処理が終わって無いのに、アプリ本体が次から次へと
アニメーションのために、画面の書き換えAPIを呼び出す。
本家では、先に述べた Invalideteや、WM_TIMERの仕組みが、自動的に
それを抑制してくれているのでもんだ無い。
ところが、Linuxの場合だと、Xコマンドがまだまだ大量に残っている状態で、
アプリ側が次から次へとXコマンドを発行するようなことが繰り返される。
この結果、Linuxのデスクトップシステム全体が全く人間のマウス操作に反応できない
ような状態が何分も続くようなことがおきてしまう。
ハングアップしたのかと思って、念のためアプリをなんとか停止させた後に、
数分待っていると、正常な状態に戻る。
事情を知らない人にはハングアップに見えるので、ある意味では「脆弱性」とも言えるかもしれない。 >>117
> しかし、そうするためのシステムコールは、横一行ごとにランレングスタイプで指定する。
Xの拡張APIだからライブラリコール(経由でのプロセス間通信)であってシステムコールではないし、
指定の仕方も横一行ごとにランレングスタイプではない
ttps://www.x.org/releases/X11R7.7/doc/xextproto/shape.html
それにWineで問題があったとしてもWineのXドライバwinex11.drv.soの実装上の問題であって
XやLinuxの問題ではない
そもそもWineで問題が起きる矩形でないWindowを持つWindowsアプリって何? 今wine-4.19のdlls/winex11.drv/以下の#ifdef HAVE_LIBXSHAPEの箇所と
xrender.cを見てみたけど、>>117-119は何の話なんだか全くわからない
一体何を調べて>>117-119を書いたの? >>121
すまんが、俺は高IQだから、一般プログラマには理解できない可能性がある。 >>122
iqとプログラミング能力に関係があるのか? >>123
一般的にIQが高い人ほど抽象化能力が高い
プログラミングの世界で抽象化って言えば
オブジェクト指向
抽象化できるとコード量が減って
バグも減る
だから関係が無いこともない
流れ読んでないから適当だけど > 一般的にIQが高い人ほど抽象化能力が高い
なら、まずそれの証明からだ
その後の話は、それが証明できてからだ >>125
え
IQテストって
なんか、間違い探しとか
共通項から答えを導きだすとか
そんなのばっかじゃん 脳科学的にはIQが高い人は脳の神経回路がシンプルらしいよ
思考プロセスを抽象化することで効率的な思考ができるのだろうね >>128
同性愛者のIQは高い傾向にあるらしいよ >>129
IQ低いからってスネンなよ
受験勉強だって傾向と対策とか
やって、問題の傾向みて訓練するでしょ?
IQテストだって同じなんだよ
IQテストの内容が抽象化指向の傾向がある
って
分かってれば
それの対策で訓練すれば高IQになれる
つまり
知能テストつったって無意識に出来る天才か
必死に訓練した努力家か
見極める手段はありません
どっちにしても
IQテストの内容が抽象化能力を問う
問題ばっかりなんだから
IQテストの成績が良ければ
抽象化能力が高いってことになる 言いたいことを短くまとめられないで
長文ダラダラ書いちゃうような高IQではなぁ >>135
そうだね
結論だけかいたら、ワケわかんない反論されるし
アホみたいに噛み砕いて解説してやっても
話が長いって文句言われるし
バカは論破できないって良くいったもんだ 俺はこのスレに2回(129,130)しか書き込んでない(このレスが3回目)者だけど
お前に反論したつもりはないよ、なんか勘違いして長文返してきたから気持ち悪くて放置してた
むしろ俺は加勢してやったつもりだったので感謝してほしいっすね 犬厨って 林 檎 と 白 い お 父 さ ん 犬 が大好きなア フォ ン厨の事ですよ。
でもアッポレOSはWindowsと違って恐怖のiesysとA gentBaseに感染しないから、
身に覚えのない誤 認 逮 捕をされないんだお(笑) キュートも良いんだけど、もう少しモダンにならないものかな。
あと日本語何とかしてほしい。 >>143
こんなウンコスレ
好きにしたらいいよ
どうせ
ウンコスレだし 戌厨自身が「こんな板」とか言っちゃってるのを見た時 犬厨って 林 檎 と 白 い お 父 さ ん 犬 が大好きなア フォ ン厨の事ですよ。
でもアッポレOSはWindowsと違って恐怖のiesysとA gentBaseに感染しないから、
身に覚えのない誤 認 逮 捕をされないんだお(笑) >>1
グロ針自演がLinux信者だと知ったときだ。 RMS尊師の画像貼ったらグロ画像呼ばわりされたとき この手のスレッドへの書き込みが途絶えたとき
普及する必要はないスレとWindowsやめてスレにだけ同じ連中がひたすら書き込んでるんだよなぁ……
普及する必要は無いと強がりつつ、WIndowsからの移行を強く訴える……なんかすごく……惨めだよね彼ら…… あー。両方に書き込んでいるけど必要な奴には十分普及したし、不要な奴には普及する必要ないと思ってるよ。 なるほどねー。惨めって辺りを主張したいって事ね。俺も同感だよ。 ■ このスレッドは過去ログ倉庫に格納されています