MIDIシーケンサー誰か作れる？

MIDIシーケンサーの作り方教えてくれー

MFCでMIDIアプリケーションを選択してください。

MDIと勘違いしてたりして（笑）

schemeでMMLモドキなら作った。

できるよ

まずはMIDIポートorRS232CでMIDI楽器を接続して
MIDIの信号をダンプしてみそ。
それからそのダンプを切ったり張ったりしたのを
MIDI楽器に流してみると。
こういうことすればおのずとtodosが見えてくるよん。

専門ですけど。
法人のかたですか？
＞１
メアドのせてもらえればコンタクトとりますよ
WinもMacもOKです

んなわけねーだろ。

aa

aa

>>1
http://www.amazon.co.jp/exec/obidos/ASIN/4894711036/qid%3D1005089030/249-0255043-2396376

＞１
無視かｺﾞﾙｱ！

シーケンサーの試験さー

なに？もう一回言って>13

本当にもう一度聞きたい？

>>11
ってかその本ってもう古くてつかえないのでは？

>まずはMIDIポートorRS232CでMIDI楽器を接続して
>MIDIの信号をダンプしてみそ
ってどうやるんだ？

COMポートなら、CreateFileで

んなことせんでも、SMFの中身はmidiメッセージそのもの。
トラック別に分割してやんないとイカンが。

MIDIバイブルは絶版？
�Tは基礎編 ISBN 4-8456-0267-9
�Uは実用編 ISBN 4-8456-0303-9
MIDIファイルに関しては�Uに載ってる。はず。今手元に無い。

SMFはCマガの'99 11月号に概略とシーケンサの簡単なサンプルが載ってた。

あと、持ってないけど、最近本屋に置いてある”Windowsサウンドプログラム”
　ttp://www.shoeisha.com/book/Detail.asp?bid=1028
が参考になるんじゃない？

>>16
MIDIはWin32APIのマルチメディアAPIで、MidiInOpenとか。

>>18
テンポ情報とかのメタイベントや、可変長データの相対時間など
midiメッセージそのものというほど単純じゃなく、結構面倒だったよ。

ttp://www.infosite.co.jp/~maruyama/misc/smf.html
ttp://www.pluto.dti.ne.jp/~daiki/Midi/Midi.html

　この二つのページで補完しあえば、とりあえずＳＭＦについては
それなりに理解できると
思う。

もっと語ろう
win2000で動くシーケンサーサンプルとかないの？

以下Winで説明します。
まずはＳＭＦのチャンク構造を勉強しましょう。
あとスレッドと高精度マルチメディアタイマとSTL可変長配列を使える
ようにしてMCI(MediaControlInterface)ではなくデバイス制御の低レベルAPI
(midiOutOpenとかmidiOutShortMsgとか）を使えたら一応ＯＫです。
分からないことがあれば聞いてください

シーケンサーの試験さー
とかもう一度言ってみたりするﾃｽﾄ。下はｵﾏｹ。

uint32 ReadDeltaTime(void)
{
　　uint32 n;

　　if ((n = ReadByte()) & 0x80) {
　　　　uint8 c;

　　　　n &= 0x7f;
　　　　do {
　　　　　　n = (n << 7) | ((c = ReadByte()) & 0x7f);
　　　　} while (c & 0x80);
　　}
　　return n;
}

因みに私が使ってるのはこれ。

inline DWORD __fastcall DELTA_DEC(BYTE* buf, DWORD& dwLen)
{
dwLen = 1;
DWORD dwRet = *buf&0x7f;
DWORD tmp;
while (*buf&0x80) {
dwRet <<= 7;
tmp = *(++buf)&0x7f;
dwRet |= tmp;
dwLen++;
}
return dwRet;
}
デルタ時間のエンコードはもう少し複雑...

>>23 >>24
ねえねえ、これって最高 32bit って既定あったんだっけ。
俺不安なんで64bitで計算させてるんだけど。

>>25
私が参照したのはMMAに提出される前のSMFのドラフトですが、

> The largest number which is allowed is 0FFFFFFF
> so that the variable- length representation must fit in 32 bits
> in a routine to write variable-length numbers.

とありました。なにしろ10年以上昔の規格ですから、
こういうみみっちい制限はいかにもって感じ。好きだけど。

ここまでだとシーケンサーというか、
プレイヤーなんじゃない？

再生だけならMidiStream使えば簡単だよ。
同期取れないけど。

シーケンサーでも標準MIDIファイル読み込めないと駄目ジャン
鉄鍋のジャン

普通のMIDIシーケンサーならSMF(標準MIDIファイル)は
読み込めると思うけど...
因みにSMFってフォーマット0/1/2とあるけど 0/1に対応してれば
十分だと思う。間違ってたらゴメンYO

>>27
そうね、シーケンサの話でいくならまず
トラックエディタ
ピアノロールエディタ
イベントエディタ
スコアエディタ
音色セレクタ
読み込み、保存機能等が必要ですね。(もっとか？)
又、１つのデータ(ドキュメント)に対して
複数のエディタ(ビュー)を使うということを考えると
「Observer」デザインパターンも知っておいた方が良いです。

googleでmidiOutOpenでやったらいろいろ出てきた
これってwin2000でも使えるの？
http://ourworld.compuserve.com/homepages/Satsuki_Kojima/winprog.htm

>>32
使えます。当然出力対象デバイスのドライバがインストール
されてないと駄目ですが

内部でMML風味にしとくと使い勝手良いと思う。

こんなのも出てきた
http://puyon.pns.to/old_data/program/midi/index.html

MIDIシーケンサってさ、、、需要あるの？

ASIOは対応してくださいね。

ASIOってなんすか？ ホンダのロボット？

作りたいから，もっと資料くれ

>>36
ここにいるやつらは自分で使いたいんだろう。

mci!

ASIOはMIDIと関係ないだろ、使ったことあるのか？

ASIOはサウンドカード用のドライバ

期待age

一度つくろうとしたけどかなりきついよ。
少なくともプログラミング能力はかなり必要だし、
当然音楽の知識と、さらにＤＴＭの知識が必要。
譜面入力式作ろうとしたら死ぬよ。本当に。
シェアウェアで２０００円出していいってんなら俺が作ろうじゃない。

かつてローランドから出ていたBalladeというソフトがあって、
もう５年もバージョンアップがなされていないのだけど、俺はいまだに使っている。
こいつの機能強化版を作ろうと思っているのだよ。
sysxの送出もできるし、リバーブも使えるやつ。協力者いないか！？

あのステップ入力を一度使ったらもうやめられなくなる。かなり強力だ。
でも多分ＶＢで作られているんだろうな。動作が遅い。

>>45-46
他力本願見え見え。
独力でやりな。もしくは金を作って、頼み込むかだね。

シーケンサー作りたいけどMIDI検定２級（実技アリ）も取りたい俺は
どうすればいいのだろう。

>>45
Ballde最古ー
バジョーンうぷしてほしー

>>46
俺も作るぞ！！
（実は１）

Cakewalkじゃあかんの?>45

昔、MIDIではないがシーケンサをDOSで作ったことある。Win3.1でも
VB2で作った(演奏はCで作ったDLLが担当)。ステップ入力でした。
MIDIシーケンサを作るなら、内部はトラック別に管理するほうが便利
なので、MIDI形式は入出力だけサポートすればいい。Win95以降は
ハード(時間)を自由に操作できない(困難)ので大変そう。

>>45
sysx?リバーブ?
シーケンサとリバーブって何の関係が?

再生は単純にMIDIメッセージをタイミング通りに
送出するだけ。内部的には>>52さんの言う通り、
トラック毎にタイミングとイベントのリストを保持して、
あとはピアノロールなりイベントなり、好きな
ビューで見せれば良いよ。多分。

つーかもうＭＭＬ出力するだけでいいじゃん。

打ち込み易さを追求するならMMLが良いと思う。
自動でフレーズ作ったり。
イベント混合も簡単にできるし。
こういう用途にはLISP系言語が適していると思う。

１０年以内に作ってヤル！気になったらやる・・・

いまどきまだMML使ってるヒトなんているのか？

なんとなくわかってきたので、概要を考えています。
とりあえず、MIDIイベントは全部
イベントオブジェクトで管理して問題ないよね？
その時のデータ構造を
何段かのハッシュにしようと思ってます。
つまり、扱える時間の限界を決めることになるのですが・・・
例えば、最高１時間を扱うと決めておき、
一段目の配列として６０個用意し（１分刻み）
２段目の配列に６０個用意する（１秒刻み）
で、その後ろに双方向リストで並べる。
２段目の配列は使う分だけオブジェクトを作ればいいので
メモリを節約できます。
この方法に何か問題ありますか？
とりあえず，一段目の配列をさらにリストにすれば
無限時間を扱えますが，そこは迷っています。
というか、MIDIの最小時間単位はなんですか？

MIDI インターフェース自体の最小時間単位なんてものはない、
と断った上で。

一般的な MIDI シーケンサの最小時間単位はティック(tick)と呼ばれる
もの（呼び方はシーケンサによって違う場合がある。これ以降に出てくる
用語も同様）。
これは、４分音符一個分の時間をタイムベースと呼ばれる数値で割ったもの。
たとえば、タイムベースが４８０でＢＰＭが１２０なら、１ティックは９６０
分の１秒となる。
逆に言えば､４分音符は４８０ティックの長さ、８分音符は２４０ティックの長さ、
ということになる。
タイムベースの値は、大きいほうが微妙な演奏表現が可能になるんだけど、そうすると
当然重くなる。
なお、タイムベースの値は、２、３、５などの公倍数にするべし。でないと、連音符を
扱うとき困るから。

>>58
「MIDIイベントをイベントオブジェクトで管理する」の意味が
よく分からんですが... CreateEvent?

例えばSMFでいえば
MIDIイベント
メタイベント
システムエクスクルーシブイベント
がありますよね？なので私の場合は
typedef struct {
　int Tick; // Tick累算値
　BYTE cVal[4]; // MIDIイベント
　int iVal; // イベント固有データ
}MEvent, *LPMEvent;
typedef std::vector<MEvent> MEvents;
みたいに１レコードをトラック別に可変長配列で管理してます
あとは、MMタイマのコールバックで経過時間とTick値を計算して
イベント毎の処理(midiOutShortMsgやmidiOutLongMsg)を行います。
この方式だと演奏時の負荷はかなり低い(5%くらい)ですよ

PC-9821のタイマを使う

大体、なんでもパソコンでやろうというのがまちがってる。
音楽は演奏会でやれやヴォケ。氏ね。

ﾅﾆｲｯﾃﾝﾉ？

>62
別に一人自室で弾いててもいいのではないでしょうか？
演奏会となるとなかなか・・・。

>>57
MMLは基本だよ
データをテキストで保存できる利点は計り知れない。

MMLも、もうちょっとちゃんとした規格があれば
互換性が保てると思うんだけどね。

MMLに互換性なんて必要ない。
SMFに落とせば。

MML(Music Macro Language)をXMLベースの
規格にするなんでどうでしょう？
で、XMLパーサーに食わせて演奏／編集を行うとか
※すでにMML(Medical Markup Language)てのが
ありますが

>>68
そんなんじゃ打つやつ居ないだろ

<mml module="GM">
　<track1 tempo="120">cdefgab</track1>
</mml>

こんな感じか？

>>69
そんな感じ。でも良く考えたらあんまり意味
無いような気がしますね

<comment>ＸＭＬ自体意味無いし</comment>

XML採用するぐらいならLISPにする

>>59
なるほどサンクス

>>60
OOのポリモーフィズムです
class EventBase{
unsigned long tick;
virtual char* process();
}
class MIDIEvent : public EventBase{
？？？
}
class SYSXEvent : public EventBase
？？？{
}
みたいな感じです

つまりはどのイベントも、同じ時間単位で処理されるので、
継承クラスで，固有の処理（MIDIOUTに送られるバイト列だけが違うとか・・・）
をオーバーライドします。

>>62
貴様をJ-POPを含む現代音楽すべて鑑賞禁止の刑に処す。

>>65
音楽屋にはまったく利点になってない。
まともに打ち込まれたMIDIデータを見たことあるのか、
それをMMLで表現できると思うかと問い詰めたい。小一時間問い詰めたい。

＃せいぜいPCM８音の世界までだな。

まあ、それは置いとくとしてDTM板なんてのもあるので参考にされよ。
http://pc.2ch.net/dtm/

>>75
ベーマガに投稿できるだろ！！（藁

>>59
MIDI-IFの最小単位って、通信速度が
31.25Kbps(async)ってことを考えると、ポート単位では
出るかもしれませんね。

>>1は実時間ベースで一定時間を確保してからやろうと
してるみたいだけど、普通はそんなことしないと思う。
実時間はテンポと音長が確定済みな再生時にのみ必要で、
データ上では音長だけで良いよ。その辺は>>59さんの通り、
Timebaseを基本にtickを使えば良いよ。
双方向リスト構造でイベントをリンクするのが一番簡単ぽい。
再生時はテンポとTimebaseから最小単位が決まるから、
そのタイミングでタイマ割込みとかでタイミングとれば良し。

MMLは打ち込みはともかく、編集んときに全体を
見渡しにくいから駄目でしょう。
MMLビューも付いてる、てのならアリかもしれないけど。

あと、sysxでなくてsysexが普通だと思ってたんですが。

>>78
折れもＰＣ９８０１でＳ−ＭＰＵ�Uを使ってたとき、それと同じことを考えて、
ドライバを実装しようとしたんですよ。
ところが、ＭＩＤＩインターフェースのクロック制御って、結構いいかげんで。
結局、最小単位時間は確定できなかった。
それに、その後シリアルＭＩＤＩインターフェースってものが出てきたんだけど、
これは要するにＰＣのシリアルポートそのものだから、通信速度は33.6Kbps。
通常のＭＩＤＩとは当然クロックが違う。
というわけで、折れ的な結論として、ＭＩＤＩインターフェースに最小単位時間は
存在しないと。
そういうことです。

イベント間の時間的な関係を表す時に
ティックを使う場合、タイムベースに依存する。
したがって，タイムベースを変更した場合は
全てのイベントのティック数を変更する。
という認識でいいのでしょうか？
だとすれば、アプリケーション側で設定可能な最大のタイムベースを用いて
データ表現し、再生時に計算し直すという方向がいいですね
最大のタイムベースは960くらい？？

Logicが960だからたぶん。

>>80
それくらいでいいと思うよ。それ以上のタイムベースは、もう人間には
認識できないと思われ。
ちなみに、１単位のＭＩＤＩメッセージ（３バイト）を送信するのにかかる
時間は、大体0.7〜0.8msになる。これは１チャネル分のデータを送るときの
話で、１６チャネルのデータを一度に送ると、それにかかる時間は、約12ms。
大体この辺が、ＭＩＤＩが扱える最短の時間間隔といえる。
で、これをＢＰＭを120としてタイムベースに直すと、0.8msの場合で約650。
つまり、現状のＭＩＤＩインターフェースでは、表現できるタイムベースの
上限はそのあたりってこと。
ただし、もっとＢＰＭの値が小さいときは、タイムベースの上限も大きくなる。
まあ、その辺も加味して、960あたりが妥当なんじゃないでしょうか。

Ｐ．Ｓ．
約数も多いしね。

>>79
いや、規格上では31.25Kbpsなハズだから、それが
最短と思われ。まぁ、最近はUSB直結なんかあるから、
MIDIであってMIDIじゃないってのもありますが。
31.25Kbpsにあわせないと、自分の環境以外では再生
できない可能性が。(31.25Kすら再生できない機器もあるけど)
そういえば、98のMPUって割り込みあったなぁ。
あれが正確じゃないってことでしょうか。

>>80
普通、途中でTimebase変えるなんてことはしないです。
最初にTimebase決定したら、後はテンポとtickだけかな。
ただ、読み込み・保存時に変換することはありますけど。
それにTimebaseの上限ってあんまり意味ないと思うんですけど。
まぁ、上限bit数は重要ですが。Timebase自体は16bitあればいいし、
deltaタイムは32bitあればいいんじゃないんでしょうか。

ま〜確かに、シリアルＭＩＤＩなんて規格外もいいところなんですけど、
現に存在するしねえ。
ちなみに、82でカキコした値は、31.25Kbpsで計算したものです。シリアルＭＩＤＩ
だと、もうちょっと短い時間でデータが遅れます。

ちょっと回りくどかったかもしれませんが、要するに折れが言いたかったのは、
現状では、ハードのスペックで最小単位時間を決めるっていう実装は現実的じゃない
ってことです。音楽的にいっても、固定された単位時間というのは扱いづらいですし。

× 遅れます
○ 送れます

鬱です。寝ます。

そんなもん、寝る奴が己の甲斐性で勝手に寝れや。

イベントを多段のハッシュ（最後は双方向リスト）
で管理しようと思っているので、
（内部的な）TimeBaseの上限が扱える曲の長さに影響すると思いますが。
あとイベント間の時間軸も絶対的な扱いにしようと思っているので。

timebaseが決まると、tickが決まりますよね？
timebase=960で、unsinged intだと
だいたい2^20個の４分音符が扱えますね
充分過ぎですね（笑）
という事は、もっと分解能をあげたほうがいいのかも・・・

ところでデルタタイムというのは何でしょうか？
イベント間の時間間隔ですか？

ハッシュハッシュハッシュ　キック and ハッシュ
萌えてー精子がー駆け抜けるー

>>85
現実的じゃないのには同意です。
>>88
うーん、なぜにその方法を推進するのでしょう。利点は?
トラック数分の単純な双方向リストじゃ駄目でしょうか。
それ以前に何故hashなの?それは実時間ベースで段数組むの?
トラック(音楽も)ってのは1本のストリームなわけですから、
データ構造も1本のリストで良い気がしてます。
表示のときとかは確かに、あるべきところにあるほうが
楽なのはわかりますけども。

で、デルタタイムは前のイベントから現在のイベントまでの
差分の時間(シーケンサ上ではtick数)です。
同時に発生するイベントは�冲=0なのです。
Timebase480で��0 NoteOn->��480 NoteOffなら4分音符ですね。

漏れが昔作った奴のソース見たら、最小時間単位は
μ秒になってた。理由は知らん。

＞９１
マイクロソフトが好きだから。

>デルタタイム
なるほど、わかりました

ハッシュにするメリットは、編集時の負荷が少ないと思うからです。
要素をdeleteする場合双方向リストは全くもって問題は無いのですが、
insertの場合、前または後ろから順にたどっていく必要があります。
もちろん、確率的に以前アクセスしたイベントの近くにあるだろうという事で、
そこからたどっていく高速化なんてのもありでしょう。
ただ、イベントが少ないうちはいいのですが、多くなってくると
問題が表面化してくると思いました。
もう一つは、再生しつつ編集するケースで、
その編集結果を、可能な限りリアルタイムで
活かしたい場合、ストリームよりはいくつかのユニットに分けた方が
いいと思いました。
（編集フラグを立て、その間はキャッシュを渡す・・・)
私は実際にやってみた事が無いので，
ハッシュが実際に効果的なのかよくわかりません。

具体的なハッシュの実装方ですが
例えば、３段でそれぞれが１０個の要素を持っているとして
最下段の配列のカバーする範囲が100ticksだとします
すると、100*10*10*10ticks分だけ表示できます
もっと具体化しますと、
上段からクラスA,B,Cとしますと
150tick目のイベントは
A[0].B[0].C[1]->event(50)
となります
また13170tickであれば
A[1].B[3].C[1]->event(70)
となります。（一桁目がAのインデックス、二桁目がBの・・・)
もちろん使われていない部分のクラスはインスタンスかしないので
それ程メモリも消費しません。
でクラスAに
*A next
なメンバをつけると無限長になるのですが
必要なさそうです。
32bitのtickの範囲しか扱わない事にしました。

>>93
なるほど。tick単位で絶対位置をね。

で、リストにインサートするとき、何故に順に
たどる必要があるのかわからないんですが。
インサートなんてインサートしたい位置の前後の
ポインタを自分向けに書き換えるだけですむような。
双方向リストって挿入削除にこそ威力があると思うんですが。

あと、その方法でいくと、それこそ挿入・削除のコストが
すごいかかると思うんですけど。
例えば、150tick目に50tickなイベントを挿入すると、
当然後ろの全てのイベントは他の配列に移動しなきゃ
ならないですよね。削除も同じく前にズラさないとならないし。

お互い何か勘違いしてそうな気配です。(藁

でも、編集フラグってのは要するに編集トランザクションとして
編集がcommitかrollbackされるまでは以前のsnapshotを渡す、
てことだよね。これはこれでアイデアとしては面白い。

なんでhashが出てくるのかわからん。
リストが一番自然な気がするが・・？
トラックのマージとか時間軸列の操作ばっかりだが。

>当然後ろの全てのイベントは他の配列に移動しなきゃ
いえ違います。
ノートイベントは、位置とノートナンバーとゲートタイムを持ちますから。
（ノートオン，ノートオフならなおさら関係ないですね）
つまり，イベントの始点だけを保持すればいいのです。
ちなみに、クラスC以降は双方向リスト（単方向にするかも）です。

>また13170tickであれば
>A[1].B[3].C[1]->event(70)
という状態に
tick13171というイベントを挿入した場合
A[1].B[3].C[1]->event(70)->event(71)
となります。

>インサートしたい位置の前後の ポインタを
インサートしたい位置を探す労力を比較したのです。

>>95
トラックというのをどういう意味で使っているのかわかりません。
たとえ、チャンネルでも
再生時にはマージして再生しますよね？
だから、データ構造的に最初からマージしています。
そして、イベントがチャンネル情報をもっています。
トラックというのを、ある時間帯にあるイベントをグループ化したものであれば
それはユーザーとのやり取りを効率化するものです。
（簡単に複数のイベントを指定できたりする）
だとすれば、単純にそれらのイベントのポインタをリストで保存する
クラスをもう一つ作ればいいだけです。
ハッシュには何ら影響しません。
例えば、そのトラックを全部消去した場合、
そのトラッククラスが含む全てのイベントに対して
while(TrackIterator.hasNext())Hash.delete(TrackIterator.next());
とするだけです
30tickずらした場合
while(TrackIterator.hasNext()){
Event temp=TrackIterator.next();
Hash.delete(temp);
Hash.insert(temp.move(+30));
}
となります

やっぱり勘違いされてますね
配列の要素のインデックスをa,b,cとすると
(つまりA[a].B[b].C[c]->event->event->....となりますが）
(10000*a+1000*b+100*c)〜(10000*a+1000*b+100*c+99)の範囲にある
イベントは全て
A[a].B[b].C[c]が管理します。
というかコード書いてしまうと
class EventManager{
A* a[100];
insert(int eventTick,Event* event){
int point=eventTick/10000;
/*メモリの節約:必要になるまで作らない*/
if (a[point]==NULL)a[point]=new A;
a[point]insert(eventTick%10000,event)
}
};
class A//EventManagerとほぼ同じ
class B//Aと同じ
class C{
Event* next;
insert(int eventTick,Event* event){
Event* ctemp=this->next;
if(!ctemp){
next=event;
return;
}
for(/*なし*/;ctemp->next!=NULL;ctemp=ctemp->next){
//リストの挿入省略//この部分の処理が負担になるなーと
}
};

deleteはハッシュも双方向リストもほとんど同じです

とりあえず，今日は寝ますね
また，来週の土日にでも語りましょう
あ､金曜も休みですね

学校が・・・・

何がやりたいのかｻﾊﾟｰﾘ分からん。

ギャーわけわからん
だけど期待age100!

タイムベース1920のSMFもふつーにありますが

>101
やっぱ（藁、最小時間単位はμ秒？

>つまり，イベントの始点だけを保持すればいいのです。
いや、ですから、挿入とか削除すると、その始点がズレると
思ったんですが。もしかして、ズレない仕様?

>インサートしたい位置を探す労力を比較したのです。
それは「インサート」ではありません。「サーチ」です。
絶対位置のサーチなら当然配列のほうが有利でしょう。
でも普通、インサートしたい位置は探しません。現在のカーソル位置が
インサート位置です。インサートする状況を考えてみてください。
メモ帳で文字入力するとき、毎回検索して文字を挿入してますか?
何を検索するのかもよくわかりませんけど。
未だにhashの意義がよくわかりません。ビューの表示が速くなるくらいで。

それから、MIDIイベントにはチャンネル情報が入ってますけど
ポート情報は無いので注意。16trackしかないなら別だけど。
ちなみにtrackとchannelは別です。trackはシーケンサ上の概念で、
再生時にtrackにアサインされたchannelで出力されます。
(ちなみに、このアサインは一般的に後から変更可能です)

>>101
Tool de Musicでしたっけ。あの辺は当時にしては妙に
分解能高かった気が。

>>102
でも、タイミングの取り方によっては最小単位でカウントするのも
アリですよね。とすると、タイマ割込みの分解能が最小単位かも。

>>93
再生しながら編集なんてするのか？

>思ったんですが。もしかして、ズレない仕様?
メタ？ソースコードは読んでもらってないようで・・・
結局のところ，分割した双方向リストですよ

カーソル位置ってのがよくわかりません。
insertにはサーチする必要があります。
とりあえず、コードを載せます。(C++風です）
//双方向リストの例
class Event{
public:
int time;
Event* next=0;
Event* prev=0;
};
class EventManager{
Event* root=0;
void insert(Event* event){
if(root==0){
root=event;
return;
}else{
Event* temp;
for(temp=root;temp!=0;temp=temp->next;){
if(event->time<temp->time)continue;
//右端と左端の場合の操作は省略
temp->prev->next=event;
event->prev=temp->prev;
event->next=temp;
temp->prev=event;
}
}
};
一番シンプルな双方向リストはこうなります。

文字の場合は、
void insert(Event* insertEvent,Event* prevEvent)
となり、insertEventが挿入するイベント
prevEventで場所を指定しますね
この場合，時間軸なんてものは存在しません。
ピアノロールで、どこかにノートを置いた場合
のことを想像してみてください。
ノートは座標から、ノートナンバーと時間が決定し
時間に基づいてイベントが挿入されます。
trackはシーケンサー上の概念で、ユーザーがイベント群をまとめて
操作できるようにしています。
だから、イベントはトラックに関してはなんの関連（UML用語？）もなく
トラックがイベントに関連をもっています。
トラックclassの例も既に書きましたよ。

そのうちコードをちゃんと書いてアップロードしますね

>>104
大抵のシーケンサーは
再生中に編集可能です。
例えば，外部入力に基づいて
リアルタイムでアレンジするプログラムを作った時
効果大ですね

1の話を理解してるやついるのか？

>>107
具体的にどの部分がわからないのか指摘してもらえれば、
がんばって説明します。
いろいろと参考になる事を教えてもらえるので、
一緒になって考えてくれる人が多いほうがいいです。

>メタ？ソースコードは読んでもらってないようで・・・
ソース読んだ上で、ズレない仕様ですか?と聞いてるんですが。

>ピアノロールで、どこかにノートを置いた場合
どこかにノートを*挿入*した場合のことを想像してみてください。
ノートは座標から、ノートナンバーと時間が決定し
時間に基づいてイベントが*挿入*されます。
ですから、その後ろのイベントは「挿入されたイベントの
長さだけ」後ろにズレると思ったのですが。
EvtA:tick=0 gate=100 NoteOn C4
EvtB:tick=100 gate=100 NoteOn C5
これのまん中に200tickのイベントを*挿入*します。
EvtA:tick=0 gate=100 NoteOn C4
EvtI:tick=100 gate=200 NoteOn C6
EvtB:tick=300(100+200) gate=100 NoteOn C5
てなかんぢでEvtBの始点が200tickズレるのではないかと。
で、このEvtBの「始点」が現在の配列の管理tick長を超えた場合、
他の配列下のリストに移動させなきゃならないのでは?
でないとHashパラメータによる参照がズレちゃいますよね?
それを挿入したイベントから最後のイベントまで延々と
イベントのリスト間移動を繰り返さなければならないのでは?

ソース見たとか見ないは関係ありません。
あなたが何を考えているかが重要です。
とくに、出されるコードは聞いてるポイントと
全然関係ないのばっかり出てくるので。(藁
まぁ、私の聞き方も悪いんだろうけど。

まぁ、ピアノロール云々で想像つきましたよ。
要するに、マウスでぐりぐりっと絶対座標に対して
イベントを「put」するわけですね。「insert」じゃなくて。
だから、リストだと時間をサーチする必要があるわけでしょ?
ピアノロール以外の編集は考慮しなくて、イベントもズレないなら
管理の楽さから言えば悪い方法じゃないかもねん。

>メタ？ソースコードは読んでもらってないようで・・・
ソース読んだ上で、ズレない仕様ですか?と聞いてるんですが。

>ピアノロールで、どこかにノートを置いた場合
どこかにノートを*挿入*した場合のことを想像してみてください。
ノートは座標から、ノートナンバーと時間が決定し
時間に基づいてイベントが*挿入*されます。
ですから、その後ろのイベントは「挿入されたイベントの
長さだけ」後ろにズレると思ったのですが。
EvtA:tick=0 gate=100 NoteOn C4
EvtB:tick=100 gate=100 NoteOn C5
これのまん中に200tickのイベントを*挿入*します。
EvtA:tick=0 gate=100 NoteOn C4
EvtI:tick=100 gate=200 NoteOn C6
EvtB:tick=300(100+200) gate=100 NoteOn C5
てなかんぢでEvtBの始点が200tickズレるのではないかと。
で、このEvtBの「始点」が現在の配列の管理tick長を超えた場合、
他の配列下のリストに移動させなきゃならないのでは?
でないとHashパラメータによる参照がズレちゃいますよね?
それを挿入したイベントから最後のイベントまで延々と
イベントのリスト間移動を繰り返さなければならないのでは?

ソース見たとか見ないは関係ありません。
あなたが何を考えているかが重要です。
とくに、出されるコードは聞いてるポイントと
全然関係ないのばっかり出てくるので。(藁
まぁ、私の聞き方も悪いんだろうけど。

まぁ、ピアノロール云々で想像つきましたよ。
要するに、マウスでぐりぐりっと絶対座標に対して
イベントを「put」するわけですね。「insert」じゃなくて。
だから、リストだと時間をサーチする必要があるわけでしょ?
ピアノロール以外の編集は考慮しなくて、イベントもズレないなら
管理の楽さから言えば悪い方法じゃないかもねん。

てゆうか適当に線形探索したって（略）

>>111
まぁ、表示するときに(略)

どこを勘違いしてるのかわかりました。
79さんの
EvtB:tick=100 gate=100 NoteOn C5
のtick=100というのはデルタタイムですね？
私はtickというのを、ある点（曲の始まりとか、１小節目の頭）
から数えた時間という意味で使いました。

そもそも私が使おうとしているデータ構造は
リスト＋αの形態です
αが何かというと、100tick(違う間隔でもいいです）ごとに
その付近のイベントに対してポインターを張っているという事です。
つまりダミーのイベントが１００tick置きに入っているような物で、
それをハッシュで高速に呼び出す事ができる，ただそれだけです。
そして、ハッシを多段にすることで、ほんの少し（２つ３つポインタをたぐる程度）
の実行速度を捨てる事で、多大なメモリを節約しているだけです。

リストと比較して、
このデータ構造が持つ短所は、コーディングする手間がかかるのと、
使用メモリが多いという事の２点のみです。

念のため書いておくと
tickを小さい順に並べて保存するのがリストの目的ですよね

tickって単位みたいなものだと捕らえてます。
絶対位置の単位でもあれば、gatetimeの単位でもあると。

で、私が繰り返し言ってるのは、イベントを挿入したときに
他のイベントを後ろにズラすのにものすごくコストがかかるんじゃ
ないですか、ということだったんです。
何をしようが一旦生成したイベントの絶対位置はズレない
仕様であれば、それはそれでそういうものとして扱えばいいんですが、
挿入や削除時に、そのシーケンスの後ろにある全てのイベント
がズレるのであれば、全てのポインタを書き換えないと駄目ですよね。
挿入したイベントの分だけ、後ろのイベントの絶対位置がズレるわけですから。
100tickおきで管理なら100tick超えるイベント挿入したら間違いなく、後ろの
イベントをズラさないとなりませんよね。
そこんとこ考えてますか、ということです。
>>1の言う、hashで管理とかメモリ節約だとかは十分わかってますけど。

で、リストはイベントの絶対位置を小さい順に並べるのが目的ですね。

んー、どこで誤解が生じてるんでしょうか・・・

>他のイベントを後ろにズラすのにものすごくコストがかか
そもそも絶対位置がずれるというのはどういう意味なのでしょうか？
絶対位置というのは、すなわち曲が再生されて何秒後に音が鳴るか？
という場合の、「何秒」ですよね？
それは，他のノートが入っても変わりませんよね？

一向に話が進まないな。
>>1
ここではhash抜きで考えてもいいじゃん。
具体的な検索方法なんて後づけで。
ややこしく書きすぎ。
それと「自分用語」を説明抜きで語るのやめて。

とりあえず、tickという単位をやめて「秒」を使いましょう。
この場合「秒」が最小単位となるので
0.5秒のイベントなどは，あってはいけません。
s秒目のイベントを(s)で表し
m分s秒目のイベントを(m:s)で表します
＠を１分（６０秒）毎に置かれるダミーのイベントだとしますと
何もイベントが入っていない状態では
@->@->@->@->@->@->@->@->@・・・・
となっていますね
(30)を入れてみましょう
@->(30)->@->@->@->@->@->@->@->@->@・・・・
もう１個(30)を入れます
@->(30)->(30)->@->@->@->@->@->@・・・・
次は(1:15)
@->(30)->(30)->@->(1:15)->@->@->・・・・
次は(30)
@->(30)->(30)->(30)->@->(1:15)->@->@->・・・・

>それと「自分用語」を説明抜きで語るのやめて
すいません
それって，どれの事でしょうか？
それと，他に題目があれば提案されて結構だと思いますよ


で私は全てをリストでつながず、つまり@へのポインタを切り
+
|->@->(30)->(30)->(30)
|->@->(1:15)
|->@
としています

>挿入や削除時に、そのシーケンスの後ろにある全てのイベント
>がズレるのであれば、全てのポインタを書き換えないと駄目ですよね。
>挿入したイベントの分だけ、後ろのイベントの絶対位置がズレるわけですから。
おまえ打ち込みした事あるのか？
イベントを入力すると必ず曲の長さが変わるシーケンサーでも使ってるのか？（ｗ

>ピアノロール以外の編集は考慮しなくて、イベントもズレないなら
スタッフもピアノロールも変わんないだろ
イベントリストも変わらん
イベントの種類と時間を指定する時に，直接数値を入力するだけ
それとも，他にあるのか？

とりあえず、口先でうだうだ言うんじゃなくて
コードを載せろよ
少なくても俺は１のコードで、１が言おうとしてる事は理解できたぞ
そして、７９が間違っていると思った
リストごとき，書くのに手間はかからんだろ
まあ，俺には７９はリストすらかけないバカに見えるんだが

>イベントを入力すると必ず曲の長さが変わるシーケンサーでも使ってるのか？（ｗ

それはある。
例えば、「ST/GT方式」とか「MBT方式」とかフツーのDTM用語を持ち出せば
上で延々話続けているようなことは一発でケリがつくのだが、
なんでこのスレこんな延々迷走してるかな。

っつーことで、とりあえず>>1よ。
貴殿はMIDIとDTMに関する基礎知識を身に付けることから始めたほうがよい。

見てると、デルタタイムとかトラックとかtickとか一般的な用語すら知らんわ
絶対時間で管理しようなどと非常識な発想をするわで、
よくそれでシーケンサー作る気になるなと、ひたすら呆れるばかりだぞ。
手助けしてやろうにもする気になれん。

で，１２０はレコポでも使ってるわけ？（ｗ
120=79？
カモンミュージックの回し者ですか？
ST/GT方式＝相対時間
MBT方式＝絶対時間
デルタタイム＝イベント間隔
トラック＝イベントをまとめて取り扱うための単位
tick＝最小時間単位
これでいいじゃん
まあ１は用語知っといた方がいいと思うけど、
もう必要な物は全てでてしまった気がする

>絶対時間で管理しようなどと非常識な発想をするわで、
あんた最近のパソコンのスペックわかってないね
使ってるOSはMS-DOSですか？
とりあえず、作曲家なら１曲アップしてくれよな

ちなみに俺が作ったシーケンサーは、
初心者にでも作れるような物だったな
ちなみに作ってから，作る価値が無い事に気づいた

シーケンサについてはもういいから、
次は自動作曲について議論せよ
1)メロを入力してバッキング加える機能と
2)コードを入力してメロディを加える機能
3)1),2)を組み合わせて自動作曲する機能

ポルタメントの無い音源にて、ピッチベンドのみで
これをプログラム的にエミュレートする手法も議論せよ

ST/GT方式結構なソフトがサポートしてるけどな。

>おまえ打ち込みした事あるのか？
>イベントを入力すると必ず曲の長さが変わるシーケンサーでも使ってるのか？（ｗ
はいはい、ありますよ。レコンポーザーつかってましたよ。
基本的にST=0にしないと曲の長さ変わりますな。

>それとも，他にあるのか？
だから、「そういう仕様なら」って言ってるわけですが。
あなたが、その他の方法を知らないとか?

>コードを載せろよ
なんのコード?まさかリスト構造ですか?(藁
リストのほうがいいのでは?以外に提案してないと思いますけど。
>>1はリスト構造についても十分理解して頂いてると思いますが?
今言ってるのは、お互いの提案する構造を使った上での
長所と短所ではないですか?
119がリスト構造のインプリメントを知らないなら載せても
いいですけど、ほんとに知らないの?イメージできないだけ?

絶対時間にしろ、相対時間にしろ、挿入と削除に
多大なコストがかかる構造ではないですか?
始点がズレる挿入と削除ができない仕様なら別ですが。
その辺考慮してますか? と言ってるわけです。

で、1が言う構造とかもかなり前から十分理解してて、
聞きたかったのは、イベント挿入時のズレなんです。
で、ズレないのがようやくわかりました。
120が一番流れをわかってるかも。(藁

>>121
レコポはその打ち込み速度の速さから未だに一部で根強い人気がありますが何か？
DTM板でも定期的にスレ立ってるじゃんよ。
俺はMBT方式のほうが好みだけどな。

>>絶対時間で管理しようなどと非常識な発想をするわで、

ここは誤解されたな。みんながtick tick言ってるにもかかわらず
1が>>58からずっとしつこく分とか秒とかで管理しようとしていることを指している。
曲のテンポ変えたいときどーするんだ一体。

>>122
3)って、メロとコードを入力するってことですか?

作曲の大部分って過去の経験に基づくのではと思ってます。
そういう意味では、例えば適当なSMFとかガンガン突っ込んで
辞書のようなものを生成してから、コード進行とか
あるノートから次のノートへの音長とか音程遷移なんかを
辞書から確率的に選択するなんつーことすると、うまくいかんかなと
思ってみたりしてます。
実際やったことはないんでうまくいくかどうかは知りませんけど。

>>126
それは>>88あたりで時間単位系を1tickにしようと
したのではないでしょうか。
私はそう思ってましたけども。

メロで推測できるコード進行って沢山ある気がするけど、まあ不可能じゃないな。
コード進行からメロ付ける方が大変そう。絶対単調になる。

いつのまにか，話が進んでますね。
ST/GT方式？というのがあるんですね。
私はレコンポーザーとは、無縁の世代なので想像もつきませんでした。
確かに、ST/GT方式はCPU効率もメモリ効率もとてもいいですね。
ただ，ユーザーインターフェースとしてはどうなのでしょうか？
使った事が無いので，想像がつきません。
メリットとかあれば教えてください。

ST/GT方式でなくても、フレーズを挿入したりする機会はあります。
私のシーケンサーでは、トラックを切って
挿入予定のサイズ分だけずらして、新しくそこへトラックを作ります。
この処理も、ST/GT方式のイベントの挿入も、
ハッシュ方式では、後ろにあるイベントを一度取り出して、
イベントの時間を書き直し、もう一度ハッシュに入れなおすという処理
が必要です。そして，この処理は大きな負荷になると思います。
ただ，違いはST/GT方式ではこれが頻繁に起こる一方で、
ピアノロールでは起こる頻度が少ないという事です。
ST/GT方式のUIをサポートするなら、やはり考え直す必要がありそうです。

いいですね，自動作曲
とりあえず，シーケンサー部分だけでも作ってしまおうと思っています。
で、「C++MIDIプログラミング」を少し読みました。
この本には、
３２ビットプログラムのタイマーの精度が悪いため
１６ビットで動くDLLを使うという事をしていますが、
windows2000ではつかえない気がしますし、
１６ビットという事で，悪いイメージを持ってしまいます。
windows2000で正確なタイマーは使えないのでしょうか？

とりあえず、VC++のMSDNにMIDI_MONITORというのがあったので
まずこれを解析する事にします。
これは、MIDIキーボードを演奏すると
送られてきたMIDIイベントを表示するやつみたいで、
実際にひいてみたら、意外と多いなー･･･なんて思いました。

>>130
始点が移動する挿入に要するコストよりも、絶対位置の
取得のほうが重要な場合は確かに有効かもしれません。
ただ絶対位置ってそんなに必要としない気もしてますけど。
編集には表示が必要で、表示のときにイベントの位置って
すでに判明してるはずなので。
ただ、絶対位置にジャンプするようなシークは確かに速そう。

>>131
WindowsNT系ではそもそも正確なタイマは期待できません。
まぁ、タイマは正確なんだろうけどイベント届くのが正確じゃないとか。
リアルタイム系OS以外では無理じゃないのかなぁ。
使ったことないのでよく知りませんが、DirectXとかだと
もちっと良いことあるかもしれません。(ほんとに知りませんけど)

>>132
ほとんどChannel Aftertouchとかじゃないんでしょうか。
もしくはテンポ(名前忘れました)かActiveSenseとか...
確かSY85だとテンポ(名前忘れました)出っ放しです。
タイマが不正確だと他のシーケンサとの同期も難しいかもしれませんね。
いまどきする必要があるのかどうかは不明ですけど。

次の土日は作業できなさそうです。

DirectMusicを使ってもできると思いますが、
なんか使い道が違う気がします。

で、ユーザーインターフェースの件なんですが、
いい事思いつきました。
ST/GT方式では、前のイベントからのデルタタイムを入力しますよね。
そしたら、他のイベントのデルタタイムを書き換えてしまえばいいのです。
（もちろん表示しているデルタタイムは全部計算するだけです）
つまり、任意の入力は他のイベントに影響しないという事です。
これで、ST/GT方式もどきもサポートできそうです。
というか、これではST／GT方式の便利さは失われてしまうのでしょうか？

WINプログミングは初心者なので,
MFCの本を購入しました。
「標準講座MFC6.0」です。
買ってから本をパラパラと見てみたのですが、
これでピアノロールが作れるのか？という疑問が・・・
まあ、まだ全然読んでないのでなんともいえないのですが、
たぶん、VC買ったばかりの人にもお薦めです。
（C++の完全な知識があることが前提ですよ）
これがダメっぽかったら、APIの本（青いやつ）を買うしかないですね。

そういえば、JAVAでも作れるの知ってました？？
本当はJAVAで作るのが楽なんですがね。
やっぱり、クオリティはできるだけ高めたいですからね。

>ほとんどChannel Aftertouchとかじゃないんでしょうか
アフタータッチとかついてないので、ノートイベントだけです。
いいキーボード欲しいですなー。

ポルタメントのエミュレーションは指数的に周波数を増やしていく
だけでいいですよね？
>1)メロを入力してバッキング加える機能と
>2)コードを入力してメロディを加える機能
２の方は、メロディアスな?

>ほとんどChannel Aftertouchとかじゃないんでしょうか
アフタータッチとかついてないので、ノートイベントだけです。
いいキーボード欲しいですなー。

ポルタメントのエミュレーションは指数的に周波数を増やしていく
だけでいいですよね？
>1)メロを入力してバッキング加える機能と
>2)コードを入力してメロディを加える機能
２の方は、メロディアスなフレーズをいかに作るかという
のが問題になりますよね。
１は、コード判定の時点で議論の対象になりますね。
やはり、手をつけるのはコード判定とリズム割り出しですかね？

＞＞１３１
マルチメディアタイマー

http://www.microsoft.com/japan/support/kb/articles/J044/9/17.asp
マルチメディアタイマーは不正確な物になってしまったそうです

今時、レコポだって（笑）

やっぱり自分でGUI作るしかないんですかね・・・
（自分で描画する関数をつくるなりする）

ST/GT方式とMBT方式とは、メリットとデメリットが相補的だし、
表示と内部表現を食い違わせたソフトだって作れるのだから、
あとはプログラマとユーザーがどっちを好むか?の問題にすぎない。

まぁ個人的にはMBT方式をすすめるけど。
ST/GT方式はレコポおよび他のごくごく一部がホソボソとやってるだけで、
それ以外「世界中の」どこででも見かけない。
それだけ注目されるに値しないのだろう。少なくともUserInterfaceとしては。
日本にはその特殊な歴史事情により信者がいるが、それだけ。

「絶対時間」は、こっち畑では知られた用語だが、
一般人に話すと「tickではなく秒の話」をしているとか
「グリニッジ標準時か?」(まぢ)とか誤解されることがあるんで、
一般人を相手にするときは用心が必要。

hashとlistも、それ「だけ」だと限定して考える必要は無かろう。
1つのデータを、hashとlistの両方から参照させたっていいのだから。

ところで、Java1.3以降のMIDIクラスでシーケンサ作った人って居る?
いちおうシーケンサを作れるだけの基礎クラスだけはがっちり作ってある。
ただしその上でどうやって実装を作ったものだか途方にくれるけど。
なんせひとつづつのMIDI MessageからしてObject。メモリ効率わるすぎ。

がいきち発見! メモリの無駄づかい、ここに極まる!!

ttp://member.nifty.ne.jp/guion/SOFT/DAISEQAI.HTM

たしかにGUIを作る手間は省けてるだろうが、
ほかの手間は全部背負いこんでいる。馬鹿。

本人じゃないけど、
>>143
ごめん。どこが馬鹿なのかよくわからない。
他の手間って何のこと?

>>142
まぁ、全部java.lang.Objectにできるから、
コレクションとか使えて便利といえば便利。
しかしnewしまくるのもどうかと思いますけどね。
メモリ効率とかパフォーマンスとかを気にするなら
Java使うなということでは。
だからクライアントでは廃れてサーバサイドなのでしょう。
でもgcで演奏止まりそうな気がしないでもないですが。藁

MBTとST/GTはデータ構造がどうであれ、ビューで変換すれば
良い話ではあります。
ただ、hashとlistの2本立ては無いんじゃないかと。
それこそメモリ効率悪すぎでしょう。

>ところで、Java1.3以降のMIDIクラスでシーケンサ作った人って居る?
JavaPressにサンプルがあったと思いますよ。

>なんせひとつづつのMIDI MessageからしてObject。メモリ効率わるすぎ。
C++でもそうする予定ですが、特に問題ないと思いますよ。
１オブジェクトあたり１０バイト消費しても
１００００＊１０で、たったの100kバイトです。
VMの初期ヒープサイズが４M（でしたっけ？）なので、微々たる物ですね。
処理的には、オブジェクトプーリングもまったく必要ないでしょう。

GCが起きても、実際に体感できるようなタイムラグは発生しないと思いますよ。
というのも、２Dのゲームでおきなかったので。

私の使っているシーケンサーだと、トラック？の移動に多少時間がかかります。
だから、データ構造によってUIに制約がでてしまうと思います。
２本立ては、なによりもコードを書くのがかなり面倒ですね（笑）
よって、今のところ却下という事で・・・

とりあえず、例のサンプルのコードを読んでみたところ
結局は１６ビットのプログラムを使うので、
MaxMidiToolを使う事にしました。
さらにチューニングが必要になった時、解析をしようと思います。

MFCの本も読んだのですが、結局は自分でGUIコンポーネントを作らないと
いけなさそうです。
そういうわけで、SDKプログラミングをもうちょっと勉強した後、
実際に着手しようと思います。

よさげなユーザーインターフェースないですか？

このスレいいねぇ。

昔、PC-9801とQuickC2.0とMasterLibでSMFプレーヤー作ってたなぁ。
標準のタイマーだと粗いから480とかいったタイムベースに対応できなくて、
タイマーのためだけにMasterLibリンクしてつかってた。

頑張ってくれ。関係ないのでsage

LogicAudioみたいなUIきぼんぬ

タイミングの不正確さって言う話は2000とかXPでも16ビットで解決するんですか？

>>148
logicのどこらへんがいいの？
乗り換えを考え中

>標準のタイマーだと粗いから480とかいったタイムベースに対応できなくて

>タイミングの不正確さって言う話は2000とかXPでも16ビットで解決するんですか？

解決しないはずですね。
あーいうのは分解能を「ごまかす」ことで対処すべきものであるはず。

洩れも98とTurboC++で作ったことあるんだけど、分解能というものの「解釈」を
きちんと間違わずにおこなえば、一応たいていのmidiファイル(必殺シリーズはのぞく)
は破綻せず演奏できるものになったよ。

タイマわりこみは4msecくらいに固定して、1回のわりこみで「いくつのtickを」
処理すべきかを計算しといて記憶領域(Timerクラスのinstance)に覚えさせとく。
覚えさせるのは毎回計算するのがあほらしいから。テンポ変更イベントが
きたときだけ計算すればいいのだから。特に昔の機械(80186とか)だと
計算の負荷もばかにならないんで、キャッシュの意味もこめてobjectを使うのは
実際けっこうパフォーマンスに貢献した。

「いくつ」といっても当然ながら答えは整数では駄目で、小数が必要になる。
浮動小数点は(あの環境の98でタイマわりこみ使ったときには)使えないんで、
自前で固定小数点演算をやるようにした。
ただ計算方法を少々間違えていて、正しいプレイヤより常に1%くらいテンポが遅くなってしまった
のが我ながら甘酸っぱい思い出。

ここまできちんとやれば、だいたい演奏できるものが作れるよ。

>logicのどこらへんがいいの？

洩れも知らないが、もしかしてこういう傾向のことを指すの?
http://www.pawfal.org/Software/SSM/
http://www.pawfal.org/Software/SSM/Plugins/essential.html

こういうもの(フリーそふとです)がすでに存在するってのは、
こういうものを「君も作れ」「君にも作れる」という暗黙のエールであるような気がする(^^;

がんばろうぜ!!!!!(かってにもえてるらしい

あ。それからリエントラントの対策は忘れるなよー。

具体的には、わりこんだときに、前回わりこみによる
tick処理がまだ終わってなかったら、「次に処理すべきtick数」カウンタを
増加させるだけでわりこみ処理を抜けるといい。
「借金」しとくわけね。ご利用は計画的に。

ふつーの演奏をさせるだけで慢性的借金状態になるようだったら、
とりあえずわりこみ周期を見なおしてみる。
粗くすればとりあえず軽くなる。

ユーザーによる設定項目として解放するのも手だね。
そうすれば各自が自分の環境に適切なわりこみ周期を設定できる。

ようやく勉強の方も一段落といった感じになりました。
これからコーディングを始めようと思ってます。
windowsでプログラムする事自体初めてなので、
プロトタイプのつもりで特に考えずにコーディングしようと思ってます。
（わかってしまえばwindowsプログラミングは単純そのものですが、
わかるまでは仕様の醜さに怒りを感じる気が・・・）

>151
正確なタイマーを利用するにはDirectMusicを利用する方法と、
16bitコードのDLLを利用する方法があります。
C++MIDIプログラミングという本に、DLLがついてまして
それを利用すると、
タイマーを動かし、デルタタイムを設定したMIDIイベントをキューに入れるだけで
時間どおりに再生してくれるものです。
テンポもテンポイベントをキューに入れるだけで、変更します。
DLLのソースも公開されているので、後々こちらにも手を入れていく予定です。

「ごまかす」っていうのもありですね（笑）
ただ、今使ってるwin2000はプロセス数２５、スレッド数２４４なので
かなり遅延しそうですね。
英語のサイトのソフトシンセはすごそうです。
gnomeだし・・・LINUX?
unix系のタイマーはどうなんですかね。

>C++MIDIプログラミングという本に、DLLがついてまして

あれって再配布ライセンスはどうなってましたっけ?
フリーソフトを作るときや商用ソフトを作るとき、
どれくらい自由に使えましたっけ?
#単なる公開と自由ライセンスとは別物なので。

>プロセス数２５

その状態で音楽ソフトを運用するのって、ちょときつくないですか?
いわゆる「いらないプログラムは終了しましょうよ」状態では?

>unix系のタイマーはどうなんですかね

あんまり優秀なのは、標準では無いはずです。

pcmサウンドだと最終的な出音はサウンドカードの責任なので、
最悪でCPUからカードへの音データの供給が間にあわないときには
プチプチいうかも知れませんが、そんなときでもアナログレコードみたいに
ピッチまでよれてしまうことは、ないでしょうね。

どうしても極めたい人なら、たとえばlinuxだと
リアルタイム機能を(ほかを犠牲にして)改善したRT-Linuxなどの改造版を
使えばいい、ということになるでしょうね。
そこまで凝った既存の事例は知りませんが、やろうと思えばやれるはず。

OSといってもlinuxはどうせライセンスフリーなので、
音楽やるときとそれ以外とで、ふつーのlinuxとRTとを
デュアルブートにしちゃう、という手も有りかと。

というか、音楽ソフトの会社あたりに、そういうの出現しませんかね。
linuxに、自分とこのアプリに都合よい動きをするように自前で改造して、
アプリをosごと売るみたいな。OS本体の部分はGPLに従う義務があるけど、
それ以外の部分は普通の商用ソフトとして(ソース公開せずに)販売できる。
こうすりゃwindows使わなくてもいいからコスト有利という面もあるんだがなあ。

メディアに強いといわれていたSGIとかのマシンとOSが
どんな按排だったのかは、誰か知ってる人、報告よろしく。

>>1
http://pc.2ch.net/test/read.cgi/mobile/1000850447/
http://pc.2ch.net/test/read.cgi/mobile/982293222/
たまたまモバイル板の上のスレを覗いてみたら、WindowsCE用のシーケンサー
（or MIDIデータの作成ソフト）が待ち望まれているようです。
デルタとかいうソフトが既に居るようですが、まだ席が空いてるよといった雰囲気です。

>マルチメディアタイマーは不正確な物になってしまったそうです

>GCが起きても、実際に体感できるようなタイムラグは発生しないと思いますよ。
>というのも、２Dのゲームでおきなかったので。

ｦｲｦｲ

>あれって再配布ライセンスはどうなってましたっけ?
英語で書かれてたのでよく読んでいないのですが、
ぱっと見た感じでは、「copyright　（MAXDLL作った人の名前）」
みたいなのをつければ、使い方はご自由にといった感じだと思います。

>いわゆる「いらないプログラムは終了しましょうよ」状態では?
標準的なwin２０００ではもっと多いと思いますよ。
私のPCは空っぽですから、HDが４Gです（笑）

>アプリをosごと売るみたいな
これは面白いですね。
HDRとかに安いCPUつけて・・・
でも、linux解析するより自分でOS設計した方が楽だったりして。

>>155
windowsCEのプログラムってどうやって開発するんでしょうか？
windowsプログラミングだけでも、かなり情報が足りてない気がするのに・・・
でも、面白そうです。
プロトタイプが完成しましたら、こっちも並行して手をつけてみますかね。
CEの場合どういう入力方法がいいんですかね。

>linux解析するより自分でOS設計した方が楽だったりして。

そうかも知れません。ただ、diskとかmemoryとかの制御を
os書き趣味というわけでもないのにいちいち書くのは
面倒なだけなんで、ありものを使えるほうがいいかなって。
かつてdosが担ってた役割を、今はlinux(や他の安価orフリーな組み込み用のos)が
担うわけですね。

>windowsCEのプログラムってどうやって開発するんでしょうか？

そもそも十分な機能のタイマが有りましたっけ?
あとmidiデバイスも無いよね。

>面倒なだけなんで、ありものを使えるほうがいいかなって。
なるほど。
そういうベンチャー立ち上げを狙ってみますかな・・・
技術がかなーり足りてないですね（笑）
というか、音楽系じゃなくて、もっと別の方面では
そういうベンチャーがありそうですね。
もっとも、日本にはないでしょうけど。
（ソフトウエア関連でのアメリカと日本の技術格差はもはやどうにもならなさそうですね。
大学生の観点から言えば、大学が終わってるところに原因がある気がします。
半導体に関しては日本は優秀なんですがね。）

WinCEの方は
再生プレイヤーがありそうな気がするので・・・
でも、CEって激しく機種依存しそうな予感です。

スレとは関係ないが
半導体はやがて隣国に・・・

PS2が世界中で売れてるので、東芝は安泰なのでは？
NECの技術力もかなりのもんなようで。

マルチメディアタイマーの精度が問題になっているみたいだけど
WinAPIの「timeSetEvent」
使えば低レベル割り込みで正確な時間がわかるんじゃないの？
というかここにMidi再生ルーチンかけば良くない？

バカ言ってったら指摘してくれ。

>162
>>139

>>162
その時計自体がけっこうゆらぐらしいです。
いや、時計はゆらいでいないのかも知れないが、観測不可能(わら)というか。
つまり実際にAPIを使ってみると、ゆらいだタイミングでしか、eventってのが
来てくれないそうです。あてにならん。

win3.1時代は、タイマ割りこみは割りこみそのもの(のラッパー)だったようですが、
win32になってからはタイマ割り込みはスレッドでエミュレートされるようになったそうです。
となると(osが)スレッドを制御&管理する力のよしあしによって見かけの割り込み精度は変化(劣化)するわけで、
実際やってみると、ゆらぐ、と。

本物の低レベル割りこみをかっぱらうようなドライバを書けばいいのかも知れませんね。
もしや著名商用シーケンサは既にそうしてますか?

2chでこれほどまともなスレも珍しい
MIDIシーケンサーに興味はないが

>>164
激しく機種／ＯＳに依存しそうですね。
本気で精度を気にするのなら、ISRで処理することになりますが、
MIDIの転送レートは以下略なので．．．。
結局、DPCでやることになりますが、それでは精度は犠牲になるかと思われ。

所詮1msec単位の世界。しかもOSが確立で割り当てるため正確ではない。
使えん。

>激しく機種／ＯＳに依存しそうですね。

たとえば「Windows上で商用ソフトを作る」なら
それで商売がなりたつのでわないかと。
売れてるwinというプラットフォームの上に載る
仮想プラットフォームを作るようなもの。

他社にもそのプラットフォーム上でソフトを書く権利を認めたら
広がりがでる(かもしれない)。クライアントが存在すれば
プラットフォームの寿命そのものが伸びるし、
改善要求によって鍛えられる。

VSTとかみたいに。

ドライバって結局のところなんですかね？

MIDIアプリーケーション作成におけるタイマに関しては
２つの解決策を以前提示しましたので参考にどうぞ。
どちらの方法も、どちらかと言えばISRを使っている・・・
という言い方しかできないですよね？

ISRもDPCもドライバ関連の用語ですね。

age

age

俺もmmtimerだけでMIDIドライバ書いたけど、
テンポゆらぎを感じた事は無いけど。
そんなに誤差が気になる？
実際どのくらいズレるのさ？
人間の耳で分かる？

ここのスレにいる人で、ゲームに組み込めるような
MIDI演奏ライブラリ作ろうって方いませんか？
スタティックライブラリでループ演奏とフェードアウトくらいの機能が
あるといいんだけど、自分で作れるほど知識ないし・・・。

>>172
>>173

＞MIDI演奏ライブラリ作ろうって方いませんか？
ｵﾚはつくったよ。
timeSetEventで5ms毎に割り込み(擬似的なものになるらしいが)
かけて普通にイベントとシステムイベントこなしていくだけ。
それ使ってmidiプレイヤーとかも作ってみた。

ただテンポの揺らぎは普段はほとんど問題無い(というか分からん)
が、アプリケーションをバックでたくさん動作させると
かなり悲惨なことになった。、ずれまくり。

まぁゲームに使う分にはいいかもしれんけど。

で、質問。
midiOutするのにスレッド作る？(CreateThread)
それともtimeSetEventでいくのか？

どっちがいいの？

>>173
DirectMusicがありますよ。
DirectMusicはスターティックじゃないっぽいですね。

>人間の耳で分かる？
midiデータにもよると思います。
例えば、和音を出す時にギターのエミュレーションをする場合、
それぞれの音を少しずつずらしますよね。
そういう微妙なニュアンスが出せないのだと思います。
ちなみに人間の耳では20msec以上間隔があくと、同時に出てると感じないそうです。
テンポは設定値より遅くなる事は確実ですが
揺らぐのは人間っぽくて逆にいいかもしれませんね。

>>174
midiプレイヤー使ってみたいです。

>>175
DirectXだとマニュアルに「DirectXの何以上が必要です」って取説に書いて
DirectX環境を要求しないといけないから、自前のライブラリで演奏したい
わけなんです（ちなみに画面描画も非DirectXでやってる）。
以前から要求に見合うライブラリを探してはいるんですが、なかなか・・・。

＞要求に見合うライブラリを探してはいるんですが
自分で作ってみろって、midiなにも知らない状態から一週間で作れたよ。
(出来がヘボイからここでは公開しないけど)
まずsmf解析⇒データをSysExとMetaと通常と分けて並べる。(分けなくてもいいけど)
タイムスタンプに沿ってソート(トラックごとに分ければしなくていい)
timeSetEventで設定したコールバックルーチンから呼び
midiOutShortMsg＆midiOutLongMsgを呼ぶ。
↓
終了

まぁ工夫すればすぐにループ機能とかもつけれる。
ネットでmidi規格＆midiプログラミングについて検索してみれ。

で演奏ルーチンは
別スレッドでするべきなのか(CreateThread)、それともtimeSetEventでするべきか
分からん。

漏れ、プログラムもするけど、作曲もするんで、そっちの方からの
アドバイスが必要であればアドバイスします。
異名同音をできるだけ理論的に再現できるシーケンサー作ってください。
ＳＭＦレベルだと保持してないので難しいけどねえ。

>異名同音をできるだけ理論的に再現できる
これってどういう意味なんですか？

コードc e g bをCM7とみなすか
E/Cとみなすか、とか？

>>177
>自分で作ってみろって、midiなにも知らない状態から一週間で作れたよ。
うっ、そうきたか。Σ(￣□￣;
実は自作という考えも全然なかったわけではなく、MIDIプログラミングの書籍は
既に持ってたりする（埃かぶってるけど）
昔、アセンブラでFM音源ドライバもどき程度のものは作ったことあるから
まあなんとかなると思うけどSMF解析あたりがちょっと面倒そうかな・・・。
ということで、ヒマを見つけてこのスレ見返しながら挑戦してみることにします。

>>174
質問見逃してました。
とりあえずtimeSetEvent()で逝ってみようかと思います。

Ｃの音の半音上の音は、Ｃ＃ともＤｂとも表現できる。それが異名同音です。

譜面上でＣ＃になっているのを、Ｄｂに変えて保存しても
再度開くとＣ＃になってるっつーのは、つまりＳＭＦでは
そこまで保存していないということですかいな？

しばらく触ってないから忘れたけど
C3は60だっけ？

SMFではC#もDbも61として保存してて
どっちで表示するかはシーケンサ次第。

シーケンサ独自のファイルでは保存してるシーケンサもある。

詳しくないけど。

異名同音が再現できるとどんなメリットが・・・・

つーか、C#とDbは、本来的には別の音、
周波数も厳密には違うよ
便宜的に同音とみなしているだけ

＞周波数も厳密には違うよ
平均律では同じはず。
つまり現在では同じと考えていいんじゃない。

ﾎﾞｹてたら解説きぼう。

>>187
それは楽器にもよる。たとえば鍵盤楽器だと、C#とDbは同じ鍵盤で弾く
しかないから周波数まで同じになるし、弦楽器なんかだと、演奏者の判断
で違う周波数の音を作ることもある。
また、周波数まで同じ異名同音であっても、音楽的な機能は違う。
ヘ長調の４度音としてのBbと、ロ長調の７度音としてのA#はまったく別物。
（それを行ったら、ハ短調や変ロ長調のBbも別物ってことになるけど）

そんなわけで、作曲をする人間は異名同音を区別して考えているので、
シーケンサでも別物として扱えたほうがうれしいってこった。

>>188
なるほど、ピアノしか頭に無かった。
というか異名同音がシーケンサに必須というのは当然だな。

異名同音はシーケンサより音源側の対応が必要な気が。
シーケンサでは区別してても
MIDIデータとして送る場合はどっちも同じ。
曲ごとに音源を調整するしかない。

音源というよりＭＩＤＩ規格の問題と思われ。

>>190
う〜ん。折れ的にはシーケンサで区別していてくれれば十分なんだよね。
異名同音が区別されていたほういいのは、作曲のときに考えやすいからであって、
演奏時にはまったく同音でもさしつかえない。実際ピアノ曲なんかは全部そうなって
いるわけだし。
>演奏者の判断で違う周波数の音を作ることもある。
といっても、そんなことができるのは世界でも一握りの一流プレイヤーに限られるしね。

譜面上だけでいいならすでに可能だよ。
Logicは可能。
他は知らない。

バロック時代とかだと、鍵盤楽器ですら同名異音をサポートしてた楽器があったらしい。
鍵盤が組み木細工みたいに複雑な構造になってて、よくこんなの弾けるなあ?と思えるような奴。
それが時代が下るにつれて単純化されていったらしく。
で、20世紀頭くらいには平均律などという乱暴なもの(^^;でもいいじゃん、という連中が出てきたとかとか。

midi規格みたいなところででもサポートしてるに越したことはないけど、
それはどっちかってーと、ノートナンバーと実際の音の半音とを対応づけるべきかどうか?を
考えるほうが、実りがあるのではないかと。
どうせ半音以下の微妙な音程は状況やジャンルしだいでニーズが多様なので
すべてのパターンの音に「統一された番号をつける」ことは不可能。
ケースバイケースで番号をふることになろう。
となると、マイクロチューニング(死語?)とかを施すほうの話題になるんじゃないかな。
どのノートナンバーをどの音程に割りあてるか?を、毎回設定するという感じ。

>そんなことができるのは世界でも一握りの一流プレイヤーに限られるし

完璧にあわせるのは達人技だが、その方向にもっていこうとすることは
誰でもやるのではないかと。
たとえば、今弾いてる調の「ミ」は高めになるように弾く努力をすることは多いと思われ。

>演奏者の判断で違う周波数の音を作ることもある。
ギターなんか、コードによって特定の弦を若干強く押さえる（チョーキングかます）ような手法はよく使われるよ。
特に開放弦の音を組み合わせるような場合に。

>>195
違う周波数っていっても、
人間の感覚じゃわからない程度だよ。

とりあえず一つ言える事。
「MIDIでギターは再現不可」（近いトコまで行くけど。）

>>196
感覚ではわかるけど、相当耳が良くないと違いは認識できない
だと思ふ。
基調音ラの周波数も時代と共に変化しているのが面白い。

>>198
一時期どんどん上昇して、やりすぎだってんで戻った経緯があるらしい。

なんか古典調律スレになりかけてるかも(わら
まあそれもよきかな。

>>196
必ずしもわからんってことはない。
半音の差なら判って、それ以下の差なら判らない、とする線引きは特にできなかろう。

というか、「比較」の問題だなあれは。
なにと比較するか、比較基準が身についているか、の問題。
純正に近い調律のドミソに耳が慣れてから平均律のドミソを聞くと
「え?これなに?」と想うよ。まぢで。

(なおミは純正と平均律のズレが大きい。22セントだったかな。つまり半音の1/5もズレてる)

単に平均律しか聞いたことがなかったら鈍感になるというだけ。
(鈍感だと悪いのかどうかは別として)

>>200
同意。
古典調律が簡単に扱えるシーケンサだったら俺も欲しいな。

古典調律について、ちょっと補足しておくと・・・・

>>200 も書いてる純正律という調律法がある。これはひとつの調の主要和音が理想的な
響きになるようにする調律法なんだけど、そのしわ寄せがシのあたりに来てしまい、
残念ながら、メロディーを構成するのは難しい。
また、ひとつの調の和音にのみ着目して調律するので、転調すると響きがめちゃくちゃに
なってしまう。

でも、その和音の響きは捨てがたいので、純正率の良さを活かしながら、メロディー
を構成したり転調したりできる調律法が考え出された。これが古典調律。

１７世紀後半のヴェルクマイスター、１８世紀後半のキルンベルガーなど、いろいろな
流派があるので、これらを簡単に切り替えてるかえるシーケンサは欲しい。

古典調律の詳細については google あたりで検索すれば、いくらでも情報があるでしょう。

>201
基本的な事聞いてすみません。
調律って、シーケンサーで変えるものなの？
調律は音源の方で用意しておくもんじゃないの？

俺はKorgのTriton使ってるけど、Tritonは、音源のパラメータに
調律を持ってるから、Cの純正律のピアノの音、C#の純正律のピアノの音
とかを必要なだけ用意しておけばいいんだけど。

>>202
＞１７世紀後半のヴェルクマイスター、１８世紀後半のキルンベルガーなど、いろいろな
＞流派があるので、これらを簡単に切り替えてるかえるシーケンサは欲しい。
これ、サポートしてる音源って、どのくらいあると思う？

少なくともXGベースの外部音源はサポートしてますが。
自分で各音階毎にセントパラメータを指定できます。
YMFは知らんけど

XVもサポートしてる。

調律の選択はシーケンサの機能ではなく音源側の機能だろう。
実際の音楽に例えるなら、シーケンスデータは楽譜、
音源モジュールは、演奏者+楽器に相当するわけ。
ここで、調律はどこが意識するものかと言えば、後者となる。
クラシックの曲名に、いちいち調性が付いてたのは、そういう
名残であろう。

まぁシーケンサ側でサポートできなくもないけど、PitchBendとかの
メッセージで無理やり周波数を調整する機能を持たせればいいんじゃ
ないのかい? 発音のたんびに(w
異名同音をデータ保存、読み込み時に解決できないのはMIDI規格の
せいだけど、まぁExclusiveMessageとかで調律の情報をいれときゃ
いいと思う。

>>203
もう10年以上前から、YAMAHAのキーボードはほとんどがサポート
していたはずだよ、少なくともDX7II、V50はサポートしていたね。
多分、V2もしてたんじゃないかな。あと当時のFM音源モジュールも。
内部的には単に周波数テーブルを切り替えるだけだからねぇ。

詳しくは音楽系の板に任せるけど、平均律は純粋に数学的に周波数を均等(AHz*2^(note/12))に
割ったもので、平均律で演奏するならC#だろうがDbだろうが同じ周波数の音になる。
ところが、例えば純正律だと、基音に対して、整数比で調律して行くもんだから、
例えばCmajorの純正律とDmajorでは、音の名前は同じでも発音される周波数は異なる。
でも今の様に平均律が台頭したのは、楽曲中に別の調性へ簡単に移行(転調)する事が
できるためと言われている。
そもそも、音階ってのは、西洋音楽では12個あるけど、国や文化によって異なっているものだし、
歴史的にも数は異なっている。たとえば、弦楽器や吹奏楽器を嗜んだ人ならシの音を(H:ハー)と
呼ぶだろう。これは大昔、A〜Gまでの音階を決めた頃にはまだ発見されてなくて、後に、BとCの
間に現在のシが存在する事がわかって、じゃぁGまで決まっているからその次のHを割り当てて、
そのときにあったBはBbとして現在の様になったりしているしね。

>>207
FMとPSG(SSG)あたりはBIOSでは完全平均率以外にも色々と音律持ってたけど
自分で石を叩く場合は一から調律してやらないといけない。
そういえば電卓片手に8オクターブ分の周波数を計算したような記憶があるな。

俺の言ってるのはセント単位で音程を変える機能ではなくて、
＞１７世紀後半のヴェルクマイスター、１８世紀後半のキルンベルガーなど、いろいろな
＞流派があるので、これらを簡単に切り替えてるかえるシーケンサは欲しい。
これらを「簡単に切り替える」機能なんだが…
セント単位で音程を指定出来るというだけなら、「調律の切り替え」はシーケンサの機能ってことになるだろ？
ちがう？

確かトライトンは簡単だった気がする。
まあ、シーケンサーがやるんであれば
その音源用のシステムエクスクルーシブメッセージを
生成すればいいってことか・・・

なんかアホな話題でもりあがってるね！ﾌﾟ

>>210
何を欲しているかいまいちよくわからないけど、音源での調律切り替えは、
単に調律をメニューから選ぶだけだったよ。で、漏れ的にはそれでよいと
考えている。音源側の機能であるべきだと思っているから。
もし、シーケンサーで切り替えるとするなら、音程毎にセント単位で
微調整をするメッセージをしのばせて送信する機能を、そのシーケンサの
ソフト側に持たせて、そのセント情報を、調律名と一緒に管理して、
簡単に切り替えられれば、実現できるんじゃないの？

>>209
F-Numberでしょ(藁)。でBlock情報(Octaveに相当)とあわせて12Bitの
情報になって、8Bitのレジスタの上位、下位別々に設定するんだよね。 > FM,SSG
平均律の場合は、先の式に代入すれば簡単に算出できるよね。
実際にF-Numberに変換する場合には、そのチップの分周比(これはアドレスの
出力だけでいけた記憶が)とそのチップへのクロックから変換できるんだよね。
もうどうでもいい技術情報だな(藁

純正律と、平均律の聞き比べをどうぞ。
純正律を聞いた後平均律を聞くと、ひどく汚い響きなのが分かると思います。
内容はピアノでＣメジャーでＴ−Ｓ−Ｄ−Ｔと弾いているだけ。

↓純正律
http://www.geocities.co.jp/MusicHall-Horn/4154/mp3/just-intonation.mp3

↓平均律
http://www.geocities.co.jp/MusicHall-Horn/4154/mp3/temperament.mp3

忘れていた。上記ＭＰ３は、両方とも１１６ＫＢ。
ついでに、a.mp3, b.mp3, c.mp3というのもあるんで
ヒマな方はどうぞ。

>>215
そうそう。きれいな響きがどこにもないけど、どこでもズレが同じ。
なんか本当に「平均」律って感じだよね。TOYOTA車的(板違いｽﾏｿ)。

どうも、話がだんだんと込み入った方向へ行ってるようなんですが、
結局、自分が言いたかったのは、
http://www.geocities.co.jp/MusicHall-Horn/4154/image/enharmony.gif

↑の赤丸で囲っているＦナチュラルを、正しくＥ＃で表現してほしい、
と、ただそれだけだったんです。

忙しくてなかなか顔を出せずにいました。
純正率、平均率聞いても違いがわからなかったのは
私だけでしょうか(^^;
まあ、私は音楽好きであって、得意ではないんですよ・・・
ところで、音の表記はどこに反映させればよいでしょうか？
せっかくいただいたアドバイスなので、是非取り入れてみたいと思います。

それで、進行状況はというと・・・
全然進んでないです。
というのも、VC++でのユーザーインターフェース作成に挫折仕掛けました（笑）
ようやくわかりかけてきたものの、やはりエグイです。
（本がないのも理由の一つですが）
VC++でユーザーインターフェース作ってる人なんているんでしょうか・・・
それはともかく、速めにプロトタイプを仕上げたいです。

で、質問なんですが
皆さんクラスウィザードって使ってますか？
メッセージを処理するための関数作ったりするのは便利なんですが、
クラスを作るとヘッダに意味不明なコードが・・・

>>219
慣れだよ慣れ。
MDIとSDIどっちを使っているか知らないけど、UI部分は内部のデータ構造とは
分離しているべきだから、Doc側にシーケンスデータを持たせて、操作関係を
Viewに持たせる。これが基本。で、メッセージを処理するクラスでも、独立
したクラスを作れば実装がスッキリするよ。例えば、CMidiViewとか言うクラスの
OnDraw()をオーバロードして、その中に直接コードを書かないで、自作の
クラス、例えばfooの実体をViewのメンバに持たせて、m_foo.OnDraw()とかを
呼び出す様に一枚皮をかぶせてやるのが良い。で、そのクラスの実装はクラス
ウィザードのデフォで作成されたファイルじゃなくて、別途「新規作成」で
cppとhを作ってやる。先の例でいえば、foo.cppとfoo.hみたいに。こうすれば
このファイルを、ClassWizardが勝手に操作される事はないよ。
それから簡単なアプリ作る時は、ClassWizard使えるよ。確かに、一般的でない
メッセージ(WM_USER)とかとかを処理する時は、自分でかかなきゃならなくて、
ClassWizard風に書くにはテクがいるけどね。
んじゃがんばって。

律は、数通りの中から選択できるだけの音源も有るし、
自作できる(自分でデータを与えなければならない)ものもある。
また律の情報がパッチにつく音源もあれば、パッチじゃなくチャンネル
にしかつかない音源(GS音源とか)もある。

律データの自作については、シーケンサというよりは「ライブラリアン」の仕事だろうね。
律編集用の使いやすいGUIを備えていれば尚よし。
それをシーケンサから呼ぶことは有るかもしれない。

お。以前聞いたことのある「五度圏図」という言葉で検索したら、
http://www2.vc-net.ne.jp/~md440/godoken/
っていうズバリのが見つかった。すでにソフト化されてる。
こういうソフトで律を作り、それをシーケンサとリンクできると、幸せと思われ。

糞こまかいことを言えば、ベンドだと、ベンドレンジはともかく、途中のカーブが
GMですら未定義なので、細かい律を表現できない恐れが、かなり有る。

>聞いても違いがわからなかった

すまそ。電子楽器、とくにPCM系、による発音だと、
なぜか違いがうまく聞きとれないことが多いようだ。
生楽器みたいに基本振動に対する余分な成分が少ない音
(シンがあるというか)だとテキメン判るのだが。
ギター(エレキふくむ)とかでもよし。
シンセだと何故かうまくいかない。

>>218
すまそ。

それにしても、なんだろうなあ。この場合、なにが必要なんだろうか?

日本語入力IMEみたいな問題なのかもしれない。
つまり、仮名(ローマ字でも)から漢字に「変換」するのって、
わざわざ脳に浮んだ漢字文を平仮名に変換してキー入力し、
それをふたたびわざわざ漢字変換してるわけじゃん。

で、和音を単なる音符列に置きかえて入力し、それを再び和音だとみなしてほしいわけだ。

だとすれば、IMEの真似で、音(複数)を入力してから、
それを「変換、確定」するという作業が、あってもよさそうなものだ。
あ。音符だけ事前入力しといて再変換、ってのもありね。

一案として、もしお気にめしたら自由に使ってくれぃ。

律の自作については、ベルクマイスターさんだって「自作」したのだから(藁
純正やピタゴラスや平均みたいに物理法則そのまんまの人為性の少ない律もあるが、
それらを人が意図的に合成したベルクマイスターみたいな律もある。

ベルクマイスターってバッハの弟子兼調律スタッフだったんだそうだが、
彼の調律って(電子チューナーがない時代には)結構手間がかかるものだったらしい。
なので、自分の練習とかのときにはバッハは、ベルクマイスター方式よりは響きは劣るが
もっと手軽に合わせられる調律パターンを、「自作」して使っていたらしい。

いろいろ考えられるよね。たとえばベルクマイスターは
調記号が少ない調ほど純正に近い大人しい響き、
多い調ほどピタゴラスに近いきつい響き、になるのだが、
この関係を逆にする(五度圏図を180度回す)だけで、
1つの律を自作したことになる。

>>219
これ言うと優良スレでなくなっちゃいそうでなんなんだけど(^^;、
やっぱり餅は餅屋、ViewはDelあたりで作るのが理想なんだよね。
楽だし、質も良いものを作りやすい。

演奏エンジンや、演奏データの内部データ表現(Model)とかは
C++のほうが良いかも。byte単位とかの細かい処理は、
delの文法で書くと繁雑になりやすいので。

仕事とかで全部VC++でやれと命じられたら漏れも220みたいにする。
あなたが感じてる違和感はきっと、VCが素(wizなし)のコードを書く以外の用途を
不得手としていることの、証拠なんだよ。

＞ViewはDelあたりで作るのが理想なんだよね。
私はC++Builderで作成しました。
難しいのはシーケンスエンジンとドキュメントクラスの関係ですね。
結局オブジェクトコンポジションにしましたが・・・

なんか良スレ化してきたね。

ていあーん。
ピアノロールの、音符に相当する横棒が、
ピッチベンドに連動して上下に「たわむ」ような表示を
できるシーケンサ、きぼーん。

たわむ比率は、ベンドレンジと連動ね。

>>226
内容が一般的じゃないからね。
多少理解している人数人でスレが回れば
まず良スレに見える。

Delphiもダウンロードしてみたのですが、
それなりにいろいろと知らなきゃいけない事が多そうなので。
でも、そのうちDelphiもしっておこうかと思ってます。
Pascalはいいですからね。ObjectPascalになって、ダメになったっていう落ち
はないですよね・・・
VC++は、GUI用のライブラリーが充実していない事が問題だと思います。
まあ、C++の性質上ライブラリー化するのは相当のコストなんでしょうが。
とりあえず、ラップするという方向でやってみます。

>>227
それはなんか見づらくないですか？（笑）
プロトタイプを作ってから考えてみますね。

bc++とdelphiて同じ会社だよね？
bc++も同じようなインターフェースだったような気がするけど
delphiの方がGUI設計しやすいの？
とたずねる自分はSDK派。
（内部しか作らないのよ　汗
つくってもMFCダイアログ）

>>230
Delphi には VCL という GUI コンポーネントライブラリがついてくる。
VB のごとくペタペタはるだけでそこそこいける。

いやBC++と比較してどうかなって思ったから…
似たようなものなら慣れているCが使えるBC++のがいいかなって思ったから。
VBとVCは同じ会社でもぜんぜん違うじゃん。

あ、BCC じゃなくて BCB か。
言語が違うのと、コンパイルが遅めなのと、
ネット上では Delphi 専用コンポーネントがあったりするのと、
くらいじゃないかな。
C++ に慣れていて BCB 持っているなら BCB でいいんじゃない。

Borland C++ Compiler と Borland C++ Builderね。

前者はあくまで普通のC++。
後者はDelphiに有ってC++に無いものを補うために
若干言語仕様を拡張している。
(ただしsupersetなのでANSI C++も問題なく扱える)

DelのメリットとC++のメリットを両方取りたいからC++Bにする、ってのは、
そんなに間違ってない選択肢と思われ。

>delphiの方がGUI設計しやすいの？

ペタペタやれるという意味で、設計もしやすいし、
GUI部品クラスを自作するときも、結構無理なくやれる。

COMコンポーネントがどうのこうのなんて仕掛を経由せず
interface的にネイティブな部品をネイティブなままアプリに貼れる
(しかも開発環境にもinstallできる)ので、VCよりも使い勝手や性能は上かも。

使いやすく作りやすいので、GUI部品に限らず色々なクラスを
「コンポーネント」にしてみたくなる。実際たいていうまくいく。

>ネット上では Delphi 専用コンポーネント

C++BにはDel相当のコンパイラも附属してるので、
特殊なものでなければDel用コンポはC++Bにも取りこめるです。

GUIの作りやすさ
Builder/Delphi>MFC
の関係は昔から変わらないね。
つーか、そろそろスレ違いの話題だって事に気づけ>ALL

了承。ちょっと気になったんで。

>そろそろスレ違い

たしかにそうなんだけど、del/C++Bだとたとえば
「演奏制御コンポーネント」なんてものを作ることにも
十分意味がある、ってのは知っておくとお得。
出来が良いライブラリ作成環境なので、活用できる範囲が広い。

いろいろ調べてみたんですが、
GUIはC++Bの方が、圧倒的に良さそうですね。
ただ、C++BだとCOMとかDLLとかは使えるんでしょうか？
delは未知数です。
とりあえず、今度C++BProちょっと高いんですが買ってみます。
（デルファイもついてくるみたいですね）

いろいろ参考になる意見を聞かせていただいて恐縮なんですが
プロトタイプに関してはVC++で作ります。
せっかくの勉強が水の泡になるのも悔しいですから（ToT)

vectorでダウンロードしたシーケンサーの中に
不正確なタイマーを使ったと思われる物があったのですが、
私のwin2000では使い物になりませんでした。
（スイングしてましたよ（笑））
ユーザーインターフェースの構想はcherryと同じ方向性になりそうです。

DLL作成利用は問題ありません COMの利用も問題ありません。
しかし、COM作成がわは、 VCLスタイルと ATLスタイルの混在になって
ワケワカ状態になり易いので VC++ か Delphiの方が楽だと感じました。

>>238
C++Builderは結構良いですよ。（たまにバグりますが）
私はVCLカスタムコンポーネントとして、
・ピアノロールコンポーネント
・イベントリストコンポーネント
・トラックビューコンポーネント
等作成しましたので、GUI／コンポーネント辺りの質問なら
答えられると思います。

そんな事より聞いてくれよ>>1よ。
今朝、「MIDIシーケンサー誰か作れる？」スレ行ったんです。スレ。
そしたらなんかDel坊がいて待ってるんです。
で、よく聞いたらなんか、Delphiマンセー、とか言ってるんです。
もうね、アホかと。馬鹿かと。
お前な、このスレ、最初っから脱線ぎみなのに、尚更拍車が掛かる様な事言ってんじゃねーよ、ボケが。
信者だよ、信者。
なんかBuilder使いとかもいるし。信者同士でコンポーネント自慢か。おめでてーな。
VCLカスタム、とか言ってるの。もう見てらんない。
（中略）
QYのエミュレータでも作ってみなさいってこった。

持ち歩けないQYなんてクソですよクソ、
それよりSSWは2chなんかに広告だして売れてるんだろうか？

とりあえず走り読みした感想

　ハッシュとか内部構造にこだわりすぎ
　そういう部分は隠蔽出来るようなスタイルを身に付けるべし

レコンポーザの後継シーケンサーを作ってください！是非！
私の要望書を読んでくれたら、オーディオ機能無しでもMSSより
確実に売れます。しかも高い値段でも売れます。

>>244
そんなに言うなら自分で作れ（うぇ

>>244
日収100万円のプログラムスレに似たノリだな(ｗ

>>243
そういう細かい部分の実装(を取捨選択)するという段階まで
開発が進んでいる、あるいはマダだけど今のうちに考えとく、
ということなのだと理解してます。

隠蔽と一口にいっても、hashのように独特のinterfaceを必要とするので
設計段階でそのことを考慮に入れないとならないものも有るので、
常に何から何まで隠蔽できるというわけでもないです。

あと、シーケンサだと、実行速度について結構シビアなことを言わないとならない
にも関らず、そのための公知ノウハウってものがあまり多く蓄積してないので、
こういうスレを立てて、瑣末な部分について(も)色んな人の意見を聞く
ってのは有効と思われ。

>>244
1：要望書を(無料かつ自由に)公開する
2：もしそれが世間の大勢にとっても良い案なら、 いろんな人が実装を作ってくれるだろう
3：そのうちの幾つかはきっとフリーソフトだろう
4：フリーなのから気にいったのをゲットする
5：自分は一銭もかからない。ウマー

特定少数の相手だけと強い絆を築くと、手間がかかるばかりで、上手くいかないことがしばしばある。
不特定多数相手に投げるほうが、保険という意味でも、お得。

ただし、よほど特殊な要望なら、賛同者が少ないだろうから、契約関係のほうが旨くいくけど。
なので、自分の要望がどれくらい一般的か特殊か、を見極めるのが大事。

いやまあ本人がそう思ってるならしょうがないけど

とりあえず
途中出て来たDelphiのコンポーネント指向な手法を試しにやってみたらどう？
という事で

実行速度については、286の１千倍の能力のあるCPUが普通のこの時代
ハードウエア上の制限（途中出てきたタイマーの話しや
　MIDI規格そのものの制限）の方が余程大きいですよ

>286の１千倍の能力

アルゴリズムやデータ構造の選定を誤れば、
「たかが千倍」くらい、あっという間に埋まってしまうよ。
計算時間の「オーダー」の問題ね。
だからその部分の議論は必要。

それに、それ以外にも、どういうデータ構造のほうが
「この問題にとって」美しい持ちかたか?という議論も、ある。

>>249　うーん
MIDIの通信能力から１秒に数１００Byteが限界
もちろん転送だけならもっと高くなるけど、時間精度の面からの話しね。
1時間の演奏だとしてもせいぜい1MByte程度のデータ
普通に2分検索程度のアルゴリズムで十分だと思うけどなあ・・・

というか言いたい事は、そんなことじゃなくて・・・・・
実装を考えつつ設計するのは　単体の製品（マイコンやDSP使う奴ね)なら
コストダウンの為に必要な事だけど、さ

　今作ろうとしてるのはパソコン上のアプリでしょ？
２分検索でも処理時間が不足するなら内部構造だけ変更出来るような
インターフェース面の設計の方が大事だと思うよ。

いや、別にそこ考えるのが楽しいんだって話しなら、そりゃいいんだけどね

>>250
二分木ならば、ね。
あれは単に内部の最適化の問題にすぎないデータ構造だから。

でもハッシュってことは、実装の内部の違いというだけの問題じゃなく、
データの検索の「やりかた」にも絡んでくる問題。
データをどう捉えるかの問題。

だから、「ハッシュなんか要らんだろ」という議論(反論)ならば
意味があるかも知れないが、「ハッシュかどうかなんて考える意味ない」
というのは、変だと思われ。

Hashと、それ以外の奴とだと、外に晒すinterfaceも違ってくるでしょ。
配列(?)の引数が整数以外だったりするじゃん。
それだけ、外から見ても、意味があるんす。

>251
なんかフレームじみてしまうんでもう止めますが

Hashと、それ以外の奴でも、外に晒すinterfaceを同じにするべきだと私は思います

windowsで言えばハンドルみたいなものを渡しておいて
その正体がハッシュだったりポインタだったりという方式って事ね

>>250
>>MIDIの通信能力から１秒に数１００Byteが限界

31250bpsでは？

ちなみに、上の方のは私じゃないです。

>外に晒すinterfaceを同じにするべきだと私は思います
MIDI再生クラス、ユーザーインターフェースとしかやり取りしないので、
それらでインターフェースが決まりますよね。
（汎用データコンテナを作るわけではないのでデータ構造（コンテナ）のパブリックメンバについて
考える必要はないですね）
そういうわけで、この程度のプログラムではそんなに慎重に
なる必要はないという事でいいでしょうか？。
ちなみに私はOO信者なので（笑）、設計周りの心配は不要だと自負しています。
（自信過剰ですね・・・）
もし他に設計段階で考えなきゃいけない部分があれば教えてくださいね。
コーディングしてからでは遅いんで・・・

ところで、私はアルゴリズムとデータ構造がまずあって
それらをアプリケーションとして実現（利用）するために
インターフェース（クラス）設計をするようなものしか
作った事が無いのですが、逆のケースもやはりあるんでしょうか？

それはそうと、
なぜデータ構造の話題が最初にでたかというと、
データ構造をハッシュにしておかないと、再生しつつアレンジする事はできないと
思ったりとしていたもので・・・・
それで、線形リストVSハッシュがあったのですが
私はレコンポーザーなるものを知らなかったので
なぜに線形リスト？と頭をひねっていました。
ハッシュを用いて、レコンポザーのユーザーインターフェースをプログラムすると
曲を作り終わったあと、それを編集する時を考えると悲惨ですね。
ウェーブとの同期再生などを考えるとどうでしょうか？
柔軟なデータ構造にしたはいいけどメモリ効率は？実行効率は？
未だに、多段のハッシュでいいのか不安です。

MAXMIDIはNTでは使えないそうです。
そうなると２０００でも・・・
で、代替手段を確保してきました。
DirectMusicが用意しているタイマーを使います。
詳細はこちらを
http://www.necoware.com/~dearna/dmusic/overview/timing.html
で、指定した時間が過ぎるとセマフォをUP？してくれるみたいで
まあ、なんか便利そうです。
MAXMIDIはWAVとの同期も無理っぽいし、
無駄にバッファしてたり、設計も・・・・と思っていたので
丁度良かったです。
今日はアルコールが入っているので、文章が乱れてますね(^^;
なんせ学校が始まってしまうもんで・・・

MIDI程度のデータ量ならSMFそのままでベタにメモリ上に持って
再生、編集時にコピーしながら処理すれば、それで十分でしょ
12345<-6789
削除も挿入も問題無しでは？

>>254
確かに線形リスト(チェーンリスト)は論外だが多段ハッシュは複雑すぎ。
というかstd::vectorを使わない理由を聞きたい。
可変長配列を知らないとか？

たぶん、イベントをオブジェクト化してとか考え出して、
するとどう管理すればいいか　チェーンだと効率悪いしてな方向に走ってしまったと思うよ

OO使って目的と手段が逆転するパターンじゃないかな


編集は常に編集点でしかやらないんだから >>255 の方法でも十分
　それでランダムアクセスに不満が出たら、固定長のブロック化して、テキストエディタなんか
　でやるギャップ法でいいと思うよ。
　それぞれのブロックは１００％詰めずに７０％程度詰めといて挿入で100%になったら2分割
　てやり方ね。

こんばんは。ちょっとお聞きしたいことがあります。

こちらに集う方々はシーケンサーに対して何かビジョンをお持ちですか？
少なくともこの世に存在する代表的なシーケンサー・DAWたちの特徴と弱点
を把握していますか？それがないとCherryやMSSのように作者のマスター
ベーションになってしまうだけです。
MSSがほぼ個人レベルで作れるなら、SSWクラスも作れるでしょう。
しかし、SSWとLogicはあまりにもユーザーのリクエストに応え過ぎです。
前者はGUIに統一感が無く、後者は操作体系が煩雑極まりないです。
ユーザーサイド（使い手）に立った物作りは大切です。本当に大切です。
でも誰も彼もの要望を聞いていては駄目だと思います。
孤高感のあるMOTU（Digital Performer）は余りにも頑固でユーザー数を
減らしている感がありますが、そこそこの拘りや頑固さも必要だと思います。

私の要望書はオープンです。>>247さんの１〜５に賛同します。
もう暫くしたら公開させて頂きます。

編集にかかる時間が気になるなら、対象データの「コピー」を作って、
そのコピーを編集してから、演奏ルーチンから参照してる元データへのポインタを
コピーのほうに切りかえる、ということをすれば良い。

演奏ルーチンから見れば瞬時(しかもアトミック)にデータを更新できるので、演奏しながら編集する場合でも
問題が生じにくいし、元データを捨てずにおいとけばundoバッファの役割も果たすので一石二鳥。

さいわい今はメモリは潤沢に有るんで、コピー自体の量的な無駄は無視できる。

もう1はアホなので放っておきましょう。

>>253
31250bps がフルに埋まりきってしまう状態で、どうやって時間管理するんだ？

とりあえず、音が鳴り始めるのはいつ頃になりますでしょうか？

>>262
痛いツッコミですね。でも、悔しいので言い訳してみます。
音が鳴る状態というのはどういう状態でしょうか？
単に音を鳴らすだけならとても簡単ですよ。
とりあえず、一番時間がかかったのはWindowsでのプログラミング作法を習得
する事です。
これが7割を占めていると思います。
次にDirectMusicの仕様書が2割、MAXMIDIの仕様書が１割程度です。
シーケンサーなんてたくさんあるので、
いろいろな事を調べた上で作り始めるのがいいと思っていましたので。
それに、私もそんなに暇じゃないので。
あくまで趣味です。

＞編集は常に編集点でしかやらないんだから
それは偏見だと思うのですが。
ピアノロールを作る時にわざわざカーソルを意識したプログラムを書くのは
面倒ですよね？（過去ログも是非読んでみてくださいね）
あと、今後の発展性も見越した柔軟なデータ構造を選択したいと思っています。
>でやるギャップ法でいいと思うよ。
その方法の場合、イベントの時間表現はデルタタイムをつかうのでしょうか？
それとも、絶対時間を使うのでしょうか？
ちょっと理解できないので、詳しく教えて欲しいです。
ポインタをたどる手間が省けるのは・・・
>>std::vector
vectorのアルゴリズムはどのようなものですか？
Javaのベクターと同じですか？
Javaのベクターは便利なので、どうでもいい部分では多用し過ぎてるかも。
>>259
ちょっと勘違いしてるかもしれないです。

263も私です。

>>244
私のビジョンは、「効率的な入力」です。
あるフレーズが思いついた時に、
それを感覚的に入力（編集）できる事が、
イメージを具現化するために最も大切な事だと思っています。
ちなみに、感覚的に入力するというのは
操作方法が感覚的にわかるという事ではなく、
体が覚えているので、感覚的にできるという意味です。
扱うためににはたくさん覚えなくてはならないけれど・・・
といったところです。

具体的な案としては、マウスレスな環境を目指しています。
（もちろん、マウスレスは不可能ですし
トラック編集などはマウスの方がいいですから）
MIDIキーボードを入力インターフェースに採用するかどうか
悩んでいます。
アドバイスがあれば、ぜひお願いします。

ピアノロールであっても、
　一人の人間なんだから同時に２つの時間帯の
　　　　編集が出来るとは思えませんが？


それでも例えばネットワークを通じて同時に編集する場合が
ありえる＝複数の時間帯に同時に編集をかけたい＝よりランダム編集へ
の自由度を増したいなら

Ｂ木スタイルはどうでしょう？
　葉は1K〜16KのブロックサイズとしてベタSMFを細切れに置きます。
　枝は葉の絶対時間と枝又は葉へのポインタを置きます。
検索、挿入削除はＢ木と同じ方式にします＝非常に高速に出来ます

さらに同じブロックサイズなので挿入削除が頻繁に起きてもメモリが
断片化しないおまけもつきますし
サイズについて、ほぼ無制限で、かつサイズにあまり影響されないですし

ただ　枝と葉を区別するＢ木は結構メンドクサイです

だから、もし、ホントにやるなら、削除はバランスさせない方がいいでしょう
　イベントが０になっても放置して悪い訳じゃなし

>>263
急かしたつもりはなかったんだけど、気を悪くしたらごめんね。
単にどのくらいかかるか把握しているのかを知りたかったのです。

と、これだけではなんなので。
>>264
PC-9801で作業しているころ、UNYAというシーケンサを使ってました。
音符の入力はMIDIキーボード+ファンクションキーでした。
MIDIキーボードの鍵盤を押さえると、
リアルタイムにトラックのカーソル位置に和音が表示されます。
この状態では音符データは確定しないので、
何回でも押しなおせます。
で、ファンクションキーを押すと音長が確定する。という感じです。
かなりサクサク打ち込めましたよ。

>>265
ピアノロールでユーザーから得られる入力は
マウスカーソルの位置なんですね。
つまりそれって、絶対時間しか得られないって事なんです。
それとも、マウスの動きをトレースしますか？
例えば、自動作曲機能なんてどうでしょうか？

B木で一番面倒なのは、木を平衡に保つ事ですね。
あと、演奏時のシーケンシャルアクセスでディレイが起こるのは
好ましくない気もしますが・・・
で、一番の勘違いしてるのはB木にしろ、線形リストにしろ、双方向リストにしろ
ハッシュというのは、それらをより高速化するための手法という事です。
絶対時間での場合なんですがね。
私が主に気にしていた事は、MIDIイベントを相対時間で表現するか
絶対時間で表現するかという事や、
トラックをどういう風に表現するか（トラックという概念との親和性）、
さらに新しいトラックのような概念を作るか？
そんな感じの事です。

>枝は葉の絶対時間と枝又は葉へのポインタを置きます
ちょっと用語がおかしくないですか？
それと、べたSMFって何でしょうか？
この辺を勝手に解釈したので、もしかしたら
私は誤解してるかもしれません。

>>262
自分でも作業が進まないのにイラついていました。
でもって、かなりマイクロソフトが嫌いになりました（笑）。
ユーザーインターフェースの構想が固まっていないのは事実です。

MIDIキーボードは買った方が良さそうですね。
といってもMIDIキーボードにもサイズがいろいろあり
全部買い揃えるのはきついので、これまた悩みの種です。
ちなみに、MIDIキーボードというか64鍵と88鍵のシンセを持っているのですが
これはでか過ぎて、PCのキーボードと並べておくのは不可能ですね。
だから対象外にします。
＞リアルタイムにトラックのカーソル位置に和音が表示されます。
和音なんですか？
スケールを決めといて・・・ということでしょうか？
MIDIキーボードを押しておいて、PCのキーボードでデュレーション決定は
もらいかもしれません。

インターフェースもいいのだけれども
目標とするシーケンサはレコーディング対応なんでしょうか。
ライブ対応なんでしょうか？

ずいぶん違ってくると思います。
あとDirectXを使う場合DirectX8になると思いますが
これを使うということは旧来のMIDIイフェクトはMIDIからはずして
オーディオサイドでやる形じゃないでしょうか？

ライブベースの場合遅延を気にする人は多いですけれど
例えばプロの演奏家はステージのはじとはじで相当な時間差があるのに
ちゃんと演奏できます。

音速は300m/s強だから例えばコーラスで右の人と左の人が15ｍ離れていたら
50msの時間差が生じるわけです。
でも全員が完全に同期して演奏してます。

それがなぜか理解できないいといつまでたってもだめだと思います。
プログラミングの前に演奏者に基本を聞いてみてはどうでしょう。

ちなみにMIDI機器かキ-ボードをたたいてWin指定のまっぱで鳴らすようなサンプルはあちこちにあるし
MIDIファイルはMCIでもなるわけですから
なんか一ひねりしたことをする前にとりあえず雑なものを作って
ストレス解消に音を出して見てはどう？

ホイールマウスとかジョイスティックにPitchアサインするとか
クリック、右クリックに同期して演奏するとか
強弱をマウスにするとかすると結構楽しいかもよ。

>268
いや、私は単に、データ構造に今凝る必要はそんなにないでしょうと
外からは、
　●指定時間に移動　●読出　●削除●挿入という４つのインターフェースを用意しておけば
後から変更出来ますよ・・・という事を言いたいだけで、　B木はそんな方法の一つのつもりです


＞B木で一番面倒なのは、木を平衡に保つ事ですね。
　挿入は簡単です。削除が面倒ですね。　でも削除はしないくてもいいと思います。


＞あと、演奏時のシーケンシャルアクセスでディレイが起こるのは
＞好ましくない気もしますが・・・
　　B木のシーケンシャルアクセスはリンクリストと同じ程度で遅くはありません
　　外のハード上にデータを置くとかなら別でしょうけどね。　　メモリ上なら


＞私が主に気にしていた事は、MIDIイベントを相対時間で表現するか
　内部は相対で　インデックスは絶対時間で持てばいいのでは？

　インデックスにも色んな方法があるでしょうけど、こういう挿入削除が頻繁に
　ある場合に、一番簡単で速いのはB木ですよ


枝、葉についてはこの図で
http://www.t3.rim.or.jp/~matsuuch/IMAGE/btree2.gif
　枝を持たない末端のブロックを葉と呼びます

ただし葉には　ベタSMFだけでキーは１個しか置きません。
　　ここでキーは先頭からの絶対時間です
　　ベタSMF　はSMFのヘッダを除いた部分の一部をそのまま並べるという意味で使いました。
　　　このデータを先頭にバイト数とデルタ時間合計　その後にデータを並べる訳です
　　　必要ならデルタ時間合計も置けばよいでしょう
　　結局　「絶対時間、デルタ時間合計、データバイト数、データ」が葉ブロックになります。

そして枝には、デルタ時間と、枝又は葉へのポインタを当然複数持たせるという事です

>>264
>操作方法が感覚的にわかるという事ではなく、
>体が覚えているので、感覚的にできるという意味です。
>扱うためににはたくさん覚えなくてはならないけれど・・・

反論多そうだけど1つ。
悪名高きunixのviエディタみたいな方式は、どう?
まさに「体が覚えればこんなに楽なものはない」の筆頭です。

噂に聞くレコンポーザやUnyaは、ファンクションキーを多用してたそうですね。
あれでは速くなりきれません。それすら使わないviの入力方式は、相当速いです。
いわゆるホームポジションから手が離れる必要が殆んどないですので、
キーボードをいっさい見ずに延々と入力することだって出来ます。
(日本語だと変換でつまずくけど、シーケンサの参考にする分には、心配ないです)

viは、キーボードに「モード」というものを持ちこんだものです。
文字入力モードでなければキーを叩いても文字は入らず、かわりに
1文字(または文字の組みあわせ)が編集コマンドに割りあてられています。
これをコマンドモードと呼びます。コマンドモードではほぼ全部のキーに
命令としての意味がありますし、シフトやコントロールを使うと更に意味は増えますし、
数値と組みあわせて命令を拡張したり、複数命令を組みあわせたり
(カーソル移動コマンドとコピペコマンドを組みあわるとか)します。

これで速度を得ます。慣れるとマヂ速いです。慣れないと散々ですが。

>>268
> ＞リアルタイムにトラックのカーソル位置に和音が表示されます。
> 和音なんですか？
ああ、和音というのは、単に鍵盤を押した分だけ表示される
ということを書きたかったのです。ドを押せばドが表示され、
ドミソを押せばドミソが表示される、という感じです。

レコーディング対応、ライブ対応という単語がよくわかりません。
とりあえず、リアルタイムレコーディングでの入力はメインとしません。
（考えてないからサポートしないというわけではありませんが）

＞あとDirectXを使う場合DirectX8になると思いますが
いえ、タイマーだけです。
それに、私も含めて皆さんは外部音源派だと思いますので・・・
それから、オーディオの同期再生も視野に入れていきたいと思ってます。
オーディオに関しては全然調べてないんですけどね。

＞ライブベースの場合遅延を気にする人は多いですけれど
いいたい事が推測できました。
DTMでシーケンサーという場合、
プレイヤーではなく、エディターという意味なんです。
それに、ライブでPC使ってフリーズされても困りますよね。
キーボードマガジンにて、あるアーティストいわく2台用意するなんて事が
載ってましたが・・・私は専用のデバイスを買った方がいいと思います。
それに、ライブでMIDIで演奏させるってのもね・・・
それで、先の質問ですが答えは「レコーディング対応」という言葉で
的を得る事ができるのではないかと思っています。
でも、レコーディングって録音するって意味じゃないですか？
とりあえず、作曲用に最適化するつもりです。

>音速は300m/s強だから例えばコーラスで右の人と左の人が15ｍ離れていたら
そうですが。
15メートルでどれくらい音が減衰するか理解されてますでしょうか？
50msecがどの程度の時間間隔か、ストップウォッチで測ってみてはどうでしょうか？
きっと桁が足りないと思いますが。

>でも全員が完全に同期して演奏してます。
リズム感という事をいいたいんだと思いますが
試しに一人で演奏してそれを録音してみて、メトロノームと比較してください。
その揺らぎがいい、なんて本に書いてあったりもします。
バンド（集団）では、その種類によってリズムのとりかた（同期の仕方）
が違いますよね。
指揮者なんてポジションもありまして・・・
とりあえず、よくあるMIDIのタイムベースは
着メロのタイムベースの10倍だったりします。
精度というのが、表現力にも影響を与えるという事だと思います。
これが、私は一番重要かと・・・
まー、実際は他のデバイスとの同期が重要になってくるのかな（笑）

>それがなぜか理解できないいといつまでたってもだめだと思います。
自分で考えて理解しなきゃわからない事だとは思いませんが。
それとも私は何か勘違いしてますか？

>ストレス解消に音を出して見てはどう？
忙しくてなかなか時間が作れなくて。
というか、あまりそのプログラムには魅力を感じなかったりして・・・

>いや、私は単に、データ構造に今凝る必要はそんなにないでしょうと
確かに、プロトタイプを作る事が先決かもしれませんね。
本番に耐えられるプロトタイプを作ろうと欲を出してました（笑）

>後から変更出来ますよ・・・という事を言いたいだけで、　B木はそんな方法の一つのつもりです
ハイ、そこらへんも大丈夫です。
>B木のシーケンシャルアクセスはリンクリストと同じ程度で遅くはありません
まあ、ノード数にもよりますが
前順序(preorder)でアクセスした場合、
ルートの、左側の木の一番右の深いところから、ルートの右のノードまでの
距離が結構あったりしませんか？
距離は木の深さになります。
でも、GHzなCPUにとってはこんなのは一瞬なのかもしれません。

それで、私には挿入時にどういうアルゴリズムでバランスさせるのが
効果的なのかいまいちわからないのですが
もし、時間があれば教えてください。

ちなみに265さんは、やっぱり勘違いなさってると思いますよ。
私はハッシュと言っていますが、
巧妙なハッシュ関数なんてもんは必要ありません。
265さんの言っているB木のノードを
絶対時間の小さい順に配列に入れるだけですよ。
それをN段で構成すると、n分木になりますよね？
Node *left,*right;
を
Node **pointer=new Node*[2];
としてみてください。

>>272
まさにそういう感じを目指してます。
私はviを使う機会はそんなになく（リモートログインする時くらい？）
emacsをそれなりに使ってました。
なので、windowsを使っている最中ても、
ctrl-x,sでセーブしたつもりになってる事がよくあったりしますよね（笑）

コマンドのアイディアをいろいろと考えてます。
モードの概念も参考になりそうです。
左手でMIDIキーボード、右手でPCキーボードというのが
今私の中では有力です。
ノートを入力する場合は、
PCキーボードの移動コマンドがアサインされたキーでカーソルを合わせ、
PCキーボードでノートイベントを置くコマンドがアサインされたキーを押す。
といった感じです。
アサインできるコマンドは、ベロシティー２０ゲートタイム２０のノートを置くとか
ノートのベロシティーを３０下げるとか・・・
アサインコマンドは、インタープリターを実装して
ユーザーがプログラムできるようにしようかとも考えています。
それから編集時は、MIDIキーボードに手をおく必要が無いので、
左手側のキーへのコマンドのアサインもかなり活躍できると思います。
（カーソルの移動は2種類必要ですね。）
MIDIキーボードに余計なボタンがついてれば、さらに
たくさんコマンドをアサインできますよね。
それから、左手でのキーボードの演奏が上達するんじゃないかと
期待してたりもするんです（笑）
ついに、アイディアをばらしてしまいました。
viなんて言うから････
インタープリターを作るとすると、初言語設計です。
どおせやるなら、アレンジプログラムが作りたくなるくらいのものを
作ろうかと思っています。
Java信者なので、たぶんJavaに似てそうな・・・・
多分物好きな私は、2つ以上の言語を作るはずです。
手続き型と、関数型ですね。
とりあえず、この辺は野望という事で・・・

>ああ、和音というのは、単に鍵盤を押した分だけ表示される
了解です。
実は、和音入力もサポートしようと思っていまして。
今のところは、＋p5音プットコマンドみたいな感じがいいかと・・・
先に実装があるなら、参考にしたいなーと思ったのです。

訂正です。
>PCキーボードの移動コマンドがアサインされたキーでカーソルを合わせ、
>PCキーボードでノートイベントを置くコマンドがアサインされたキーを押す。

PCキーボードの移動コマンドがアサインされたキーでカーソルを合わせ、
MIDIキーボードでノートナンバーを指定して
PCキーボードでノートイベントを置くコマンドがアサインされたキーを押す。

確かに勘違いする用語ですね　ハッシュ・・・他にその使い方をしてる人はいないかも

n分木にするなら、B木でないと挿入削除に弱いですよ
B木でも時間挿入はどっちにしろ遅いですけどね

B木をアクセスする時はスタック（又は仮想スタック）を使い
ます。シーケンシャルアクセスでも同じです。一番悪いケースはルート迄
戻る局面ですが、それでも葉迄の距離の２倍です。
枝には１００〜1000のキーを配置するでしょうから、せいぜい数段です。
パソコンCPUが1/1000の1MでもMidiシーケンシャル処理には遅くは無いでしょう


B木のアルゴリズムは教科書もあり、Webでも探せば見つかります。
　挿入でバランスを取るのは、単に一杯になれば２分割するというだけですよ

削除でバランスを取るのが難しいのですが、MIDI編集では削除しないという方針でいいでしょう
普通編集では追加する事が殆どですし、メモリ上の作業用であり永続的ではありませんからね

>>278
＞n分木にするなら、B木でないと挿入削除に弱いですよ
といってるのに、
＞削除でバランスを取るのが難しいのですが
とはこれいかに？
スレ違いスマソ。

それと、最初から削除しない方針でやるぐらいなら、
ギャップバッファ+ブロック使った方が速い。削除も簡単だし。
まあテキストエディタと同じ理論でしょ。

265は過去ログ読んでないんじゃないか？
コードもウプされてるぞ。
枝にキーを配置するんかい（ｗ

ああ、
n分木は普通、基本的にノードをn埋める場合に使う用語だと思ってたからです
　その場合、挿入時のコストは大きいです。

　削除でバランス取るのが難しいくはなくて、初めてだとメンドクサイだけです
　既にB木書いるなら問題ないけど、書いてないなら後回しにしたら程度の意味です
　というのはB木の解説に行くと、当然削除もバランスする方法が説明されてますからね
　これは大変な作業だと勘違いされてはいけませんから

>>280 ギャップバッファ＋ブロックは私も薦めたのですが　却下されたもので
　・・・検索が早くないとダメなんだそうです
　削除時にバランスしないB木はギャップバッファ法と同じ程度のコード量ですから

>>281 枝にキーですが、キーは先頭からの時間を置くと書いたつもりでした
　　つまりキー＝１さんの言うハッシュ？　ですね

>確かに勘違いする用語ですね　ハッシュ・・・他にその使い方をしてる人はいないかも
さらに勘違いさせてしまったようです。
>巧妙なハッシュ関数なんてもんは必要ありません。
この部分は、「ハッシュ関数が巧妙な物ではありません」
と書くべきでした。
外部ハッシュでかつハッシュ関数を複数組み合わせて使ったものです。
あまりわかってもらってないようですね。
ハッシュ関数を複数組み合わせると、n分木なるところまではOKですか？
（nはハッシュ関数の返しうる値の数で決まります）
ちなみに、ギャップバッファはキーを線形リストで並べた物とほぼ等しいです。

私の知っている平衡探索木はAVL木しかないんですが、
>挿入でバランスを取るのは、単に一杯になれば２分割するというだけですよ
という意味がいまいちよくわかりません。
2色木（赤黒木）や、B*木のアルゴリズムは本で読んだこと無いんですよね。
まあ、手作業でデータを入力しているうちは、関係ないですけど
ファイルを読み込んだ場合や、トラックを時間シフトさせた場合に
結構効いてくるのではないかと・・・

ついでに
>n分木にするなら、B木でないと挿入削除に弱いですよ
ハッシュの場合キーは全てあらかじめ用意しているので、
キーの挿入削除は関係ないですよ。

>B木をアクセスする時はスタック（又は仮想スタック）を使い
木のメリットは再帰的に処理ができる事ですね。
そういうわけで、スタックが大活躍ですね。
といっても、ヒープにスタックを作るわけじゃないですが・・・
ハッシュも木なのでシーケンシャルアクセス再帰で行います。
仮想スタックって言うのは何でしょうか？

>枝には１００〜1000のキーを配置するでしょうから、せいぜい数段です。
この部分の意味がよくわかりません。

一つ聞いていいでしょうか？
曲の最後の方にノートをつける場合、
B木ではどういう風にするのでしょうか？

>>269
>でも全員が完全に同期して演奏してます。

同期してるといっても、それはズレがそれ以上「変化」しないという程度の意味でしょうね。
どんぴしゃ合うことは滅多に無いですね。むしろその珍しい(合っている)状況になると
プレイヤは気分がよく(Player's High)なるわけですが、それはその状態がそれだけ珍しいことの裏返し。
わざわざ悪い環境を参考にしてもしょーがないでしょう。

それに、遠くのプレイヤの音がずれてるのはしかたないけど、
自分の手元で鳴る楽器がそもそもズレているのを許せるプレイヤは、いないでしょう。
たとえば「常に一定」100msだけ遅れて鳴るピアノとかを、まともに弾けると思いますか?
もし弾けたとしても、わざわざそれを好む人が居ると思いますか?
最初からずれてるものを基準にする阿呆はいません。まずドンピシャありき。ずれを語るのはそれから。

あなたが言ってるのは、クラシックとかジャズとか、
リズム(の正確さ)に大雑把なものしか要求されない方面、なのでしょう。
ひかえめに言っても、それはジャンルしだいの問題です。

>例えばプロの演奏家はステージのはじとはじで相当な時間差があるのに

ロックやポップス(乱暴な区分けかな)では、
プレイヤの「そば」にモニタースピーカーを置くことは、普通に行なわれていますが、なにか?
あるいは、ドラムみたいにシビアな正確さを要求されるパートでは、
ヘッドホンやイヤホンすら使われていますが、なにか?

アコースティック楽器で、シビアなタイミングを要求されるジャンルって、
あんまり無いんですよね。それは偶然ではないはずです。

どうもお使いの用語が非常に混乱してさっぱり判らなくなりました
例えば
＞ハッシュ関数を複数組み合わせると、n分木なるところまではOKですか

ハッシュ関数の定義は
●与えられた原文から固定長の疑似乱数を生成する演算手法
ではなく
http://nakajima-www.cs.titech.ac.jp/~rocky/prog2001/datastructnode15.html
●あるキーが与えられた時，それを保存する場所に対応する数値を求める関数

という事を転じて、さらに絶対時間　ポインタの対応表の事ですか？
だから外部ハッシュはリスト構造だからn分木となぞられているのでしょうか？

＞ギャップバッファはキーを線形リストで並べた物とほぼ等しいです
　これも乱暴な話しです。　　その前のブロック化というのが線形リストで管理するのであって
　ギャップバッファは
　エディタ等の編集点にギャップを設けて、挿入、削除を高速にする方法です。
　ようはコピーしながら追加削除する方式の事です

なお、B木のアルゴリズムは検索すればすぐ出ます
http://www.cs.u-gakugei.ac.jp/~miyadera/LECTURE/algo2/5-2.html

＞曲の最後の方にノートをつける場合、
　　最も大きなキーで検索した葉の最終位置に挿入するのでしょう？

>>284　違うんだけどなぁ。
あなたはつまるところクラシックコンサートは阿呆だと言っているわけです。
音楽の演奏というものが理解できてないのですね。

ロックでスピーカーをプレーヤーのそばに置いたらフィードバックしちゃうでしょう。

大体リアルタイム演奏を目指さないのであれば楽譜があるわけだから
MIDIキーボードとPCのキーボードをたたいて何をやりたいのかも不明です。

結局、何のために何をしたいからどういうソフトをつくりたいんでしょうか？
なんか迷路に迷っているようにしか見えません。

どうせヒントを出してもわかんないと思うので撤退

１よ

・他人と話しするには、自分用語じゃだめだぞ
・俺からみたら１は本来なら有益なアドバイスを沢山貰ってるぞ
　　もう少し目を開けて他人の話しを吸収したらどうだ？

そもそも１はアドバイスした奴が皆どんどん険悪なレスになってくの判ってるか？

このスレおはつ

>>286
キーボードを2つ使うのはベロシティとかの微調整と音階入力を手軽にさせようって事じゃないかな。
そういう事ならありがたい。
もっともMIDI-INステップ入力と何か違いがあるのかは判らんですが。

それよりも1よ
前から考えていたんだが、アナログジョィスティックでギターベンド編集できたり、
タブレット叩いてドラムのアナログ入力できたりできるようにしてくれんか。
ありあわせの周辺機器で似非リアルタイム入力。
これでウチにある機材が有効活用できまする(w

265さん
OKです。
たぶん、バランスという言葉の意味が食い違ってます。
今日はちょっと時間が無いので、金曜日の夜にまた書き込みします。

>>286
>>284は私じゃないですよ。
私の意見は>>274にあるので、是非読んでみてください。
あ、ちなみに
>ロックでスピーカーをプレーヤーのそばに置いたらフィードバックしちゃうでしょう。
ハウリングの事だと思うのですが、ロックで使うのは電子楽器です。
なので、ハウリングは起こりません。
もちろんドラムの音をマイクで拾う場合は、ドラムにモニターはつけません。
そういう場合、全リズムをドラマーに合わせます。
が、しかしMIDIを使う場合は、ドラマーはヘッドフォンをつけて、
シーケンサーからクリック音をもらうのが一般的です。
（シーケンサーがドラマーにあわせてくれませんからね）

もう1は書かなくていいよ

エレキギターはハウりません。
これ定説。

>>291
ハウるだろ。つーか、そう言うテクがあるだろ。

286のいう意味は演奏者にフィードバックするという事じゃないの

　パソコンでサウンドの入力->出力デバイスを別にして　ヘッドホンで
自分の声聞きながら歌ってみろよ　もう異常に歌い辛いぞ

つーかさー
モニタースピーカー無しでどうやって演奏しろっつーの？
マイクが無いのにどうしてハウリングするんだ？
カラオケ行った事のないやつが集まったのか？

http://www.people.or.jp/~fussy/argo7-2.htm
まず、バランスという言葉ですが、上記のホームページのAVL木のところ
を見てください。
googleで「2分木、バランス」で調べていただいても結構です。

ハッシュ関数は
あるキーに対して、その保存場所を示す関数という意味です。
絶対時間を入れると、そのイベントを格納すべき場所へのポインタがわたされます。
ハッシュ関数を3種類用意したとします。それぞれ返す値は、j,k,l通りだとしますと、
イベントが格納される場所は、J*k*l個になりますね。
j*k*l個の配列を用意してもいいのですが、
たとえば、1個目のハッシュ関数によってj分割され、さらにk分割され・・・
という見方もできますよね？
つまり、ルートはj個の子を持ち、それはk個の子を持ち・・・
と見れば木になりますよね？
木にするメリットは、メモリが節約できる事です。

>エディタ等の編集点にギャップを設けて、挿入、削除を高速にする方法です。
まあ、確かに乱暴な言い方でした。
私のイメージでは、検索するキーがわかっているので
そのように最適化してある線形リスト・・・といった感じです。

せっかくなので、265さんが一つ作り
私がハッシュで一つ作り、検証してみませんか？
一人で2つ作るのは結構めんどうなので。
実際問題、私が言ってることは全て机上の空論に近いものがあり、
はたして本当にハッシュでいいのかどうかは怪しいです。
あらかじめ、インターフェース(純粋仮想関数だけのclass)を決めておけば
大丈夫ですよね？
おそらく、絶対時間を指定してイベントを入力するのと、
イベントへのポインタを指定して、要素を削除する事の2つでいいと思いますが。
イベントのポインタから時間が取れなきゃどうしようもないので、
イベントは絶対時間を持っているという事になりますね。
テストはMIDIファイルの読み込みや、データをまるごとメモリ上でコピー、
MIDIファイルへの書き出しや、シーケンシャルアクセス、
ランダムなデータの挿入削除、そして複数のイベントの移動
こんなもんでどうでしょうか？

>・他人と話しするには、自分用語じゃだめだぞ
了解です。
参考までに、どれが自分用語なのか教えてください。

>もっともMIDI-INステップ入力と何か違いがあるのかは判らんですが。
ステップ入力の強化版という事で。
でも、ステップにはない良さがあると思います。
机に載るようなMIDIキーボードを持ってないので
ステップ入力はやった事ないんですよ。

ハッシュ関数という用語は、既にハッシュ法で使われており、
　「元の文に対してランダムな値を出力」する関数の意味なので
　たとえ、おっしゃるように断ってあったとしてもイメージが伝わり難いです。

こういう場合は　「指定時間データ変換」と書いた方が誤解を招かないでしょう

　指定時間データ変換用にAVL木を利用すると書かれてあればほぼ正しくイメージが伝わると思います

おっしゃる３段木の方式は、データ長（少なくとも最大）が固定なら良いですが、固定でないなら
段数固定よりも　ブロック長固定が好ましいと思います

検証の方法ですが、私は趣味のコードはDelphiを使います。それでよろしいですか？

メソッドの希望は

EditPointOpen(time):TMidiEditPoint 　新しく編集作業点を確保して

TMidiEditPointのメンバー
Free:　　　　　　　　　　編集作業点をシステムに返す
insert(data:array of byte); イベントを入力する
Delete(size):; 要素を削除する
Read(size);　　 最大size個のバイト列 を読み取る　読めたバイト数をDelphiの動的配列で返す
ReadNext(size); ReadとNextを同時に行う
Next(size); //相対位置　　
Seek(pos); //絶対位置ただし実行は遅い場合あり
TOF:boolean;
EOF:boolean;


全データの処理は
　　with EditPointOpen(0) do try　ファイル書き出し(Read(High(Integer)))　finally free;end;
で出来るものとします
シーケンシャルアクセスは
　　with EditPointOpen(0) do try
　　while not EOF do 処理(Read(1));
　　finally free;end;

ギャップバッファ法で実装する場合は複数の作業編集点を持てませんから
　２番目のEditPointOpen(time)に対しては nilを返して下さい

AVL木で管理するなら複数に対応出来るでしょう

複数のスレッドで呼び出される事は無いとします
　それは外部で処理すべき事としないと無意味に重くなりますから

>>294
＞マイクが無いのにどうしてハウリングするんだ？

ライブでギター演奏したこと無いのか？スピーカ
にピックアップを近づけると干渉してハウるんだよ。
エレキギターとアンプ買って自分の家で試して
みろよ。

＞たとえ、おっしゃるように断ってあったとしてもイメージが伝わり難いです
申し訳ないです。
ハッシュで使う関数＝ハッシュだと思ってました（汗）

>指定時間データ変換用にAVL木を利用すると書かれてあればほぼ正しくイメージが伝わると思います
んーと、これは意味がわかりませんが。
指定時間データ変換は基数で割るというか、適当な数で割ってきり捨てればいいのではと・・・
具体的な例を示せば、各桁の値をハッシュ値として使うとかそんな感じですが。

＞段数固定よりも　ブロック長固定が好ましいと思います
私が思うに、MIDIデータの密集率は限度があるので、
ブロック長固定にする意味はないと思いますが。

>検証の方法ですが、私は趣味のコードはDelphiを使います。それでよろしいですか？
Object Pascalですか・・・・
今回は当初からC++でMIDIシーケンサーを作るという事だったので、
C++で書いてもらえるとうれしいのですが・・・
私がDelphiを使うってのもありなんですが、
それを捨てちゃうのももったいないですからね。
それ以外にも、インターフェースクラスを用意するので、
単純にnewするクラスを切り替えれば、全く同じテストが実行できる
というメリットもあります。
イベントを作る時間は無視する事は不可能ですからね。
ObjectPascalとC++の違いってどのくらいありますかね？

続きです。

>メソッドの希望は
ちょっと待ってください。
基本的に必要なメソッドは、再生時のシーケンシャルアクセスと
ピアノロールでの編集時のMIDIイベントの挿入削除（MIDIファイル読み込み等）、
トラック単位の移動、削除。
シーケンシャルアクセスではイテレーターを介してやるのが
いいと思います。
Iteratorのメンバ関数として、
セットスタートタイム(絶対時間）
セットエンドタイム（絶対時間）
準備（）//スタートタイムに、カーソルを合わせる
hasNext()とnext()があればいいですよね？
これで繰り返し再生も簡単ですね。
多分、番兵としてループイベントなりのダミーのイベントを入れると思います。

ピアノロールの編集では、
クリックされたポイントとノートの高さ、編集中のチャンネルナンバーがきますね。
よって
insert(new NoteEvent(absoluteTime,noteNumber,channelNumber))
となりますね。
だから、こうなりますよね？
insert(MidiEvent* evt)
delete(MidiEvent* evt)
インサートに関してはMIDIイベントオブジェクトへのポインタで行うのがいいと思い
ます。
各イベントは、MidiEventクラスを継承しているという事です。
MidiEventクラスが持つ物は、AbsoluteTimeとChannelですね。
MidiEventの時間を変更するには
一度deleteしてからinsertを行う事で問題ないでしょうか？
ちなみに、TrackはMidiEventへのポインタを線形リストで保持します。
（ソートはしません/してもいいですが）
トラックに対する編集時は、それらのポインタに対して変更をかけます。
編集ポイントなりは、insert時にやってもらえればいいのかな？

オブジェクト指向さえしっかりやってもらえれば、
PascalからC++にトランスレートしてもいいのですが
んー。

>複数のスレッドで呼び出される事は無いとします
OKです。
再生しながら、編曲するという事も実はやりたかったのですが
今回は置いておきます。
とりあえず、再生エンジンとCUIのインターフェースを作っておきます。

>>292
なるほど
スピーカーは電磁波でまくりですからね。

>>301
スピーカの音を弦が拾うんですよ。

1は宇宙人でした

ちゅーか、>>291 は本物の１とは別なような気が
してきた。

なるほど、全てのMIDIイベントをオブジェクトにしたいのですか・・・・
　とするとやっぱり根っこが違う訳ですね


全てをオブジェクトにする為に管理構造の末端はオブジェクトインスタンスになり
　だから編集上の種種の問題点が発生する　それを解決する為に木構造が必要
　という悪循環のように思います

私はデータはMIDIデータについてバイトイメージのまま持つと考えていました。
　計算の容易の為にデルタタイムをパック形式ではなく32bitに変換する程度の
　加工は別にしてです。だから"B木の葉にSMFイメージ"をというふうな表現を
　していた訳です

確かに、MidiEventのデルタタイムを変更するという事は、それ以後の絶対時間
が全てズレる訳です。　ですからこれを編集した場合は全体に影響を与えます。
だから、編集点クラスではなく　データクラスに指令を与える必要がありますね

＞再生しながら、編曲するという事も実はやりたかったのですが
　というか、これをやらなければ、何の為に編集点クラスを別にして、複数の編集
　点をもてるようにするのかと、
　複数のスレッドで呼び出される事が無いとした意味は、別スレッドから呼び出し
　たい場合は、メソッド呼び出しをメッセージ通信を介して処理して下さいという
　意味に取って下さい。

もし複数のスレッドから直接呼出を許可した場合、管理しなければ安全に編集は
出来ませんから内部でセマファ類を使ってスレッド管理をする必要があります。
それよりはメッセージ通信を介した方が通常は全体のスループットは上がりますから

デルタタイムを変更した場合、
　１、その場で以後のデータを全て変更する
　　　普通はコレでいいと思います。時間編集は通常再生中には行いません
　　　それでも行いたいなら

　２、バッファを用意し、バッファ上にテーブルとして一時的に持たせる
　　編集点クラスが全てFreeされた又は明示的な指示で　このバッファから
　　実際の内部データ形式に影響を与える
　　　絶対時間を受け取る内部関数は、内部データ形式にアクセスする時には
　　このバッファ上のテーブルを検索し置き換え処理をする。

あと、編集点クラスにデータチェンジイベントを追加する必要があるでしょう

＞ピアノロールの編集では、
＞クリックされたポイントとノートの高さ、編集中のチャンネルナンバーがきますね。
＞insert(new NoteEvent(absoluteTime,noteNumber,channelNumber))

私はSMFをそのまま持たせる為にこう考えていました
　この場合ノートONとOFFに別けて２度アクセスする事になります

dp:=データクラス.EditPointOpen(AbosluteOn);
try
　dp.insert(cvtSMFChannnel(noteNumber));
　dp.insert(cvtSMFNoteOn(noteNumber));
finally free; end;
dp:=データクラス.EditPointOpen(AbosluteOff);
try
dp.insert(cvtSMFNoteOff(noteNumber));
finally free; end;

この間のデルタタイムは関数内部で処理します

こう設計思想が違うとスリ合わせは難しいものになるように思います

なるほど、そこから違いましたか。
根本的に違うと思われるのは、
私はSMFのようなデルタタイムでイベント間隔を表現するのではなく、
絶対時間で指定します。
デルタタイムを求めるには、前のイベントとの差を求めればいいですね。
デルタタイム（相対時間）で表現するメリットは、
無限長の時間を扱える事と、メモリが節約できる事ですね。
絶対時間のデメリットは、メモリをふんだんに使う事と
有限長の曲しか表現できないところにあります。
しかし、処理が簡単というメリットがあります。
過去にも同じ議論をしたので、過去ログを読んでいただけるとうれしい
のですが・・・

たぶんソースコードを読んでいただいた方が、
私がやりたい事が理解できると思うので、
もしC++が読めるのであれば、ソースをアップしようと思うのですが
どうでしょうか？
pascalにはないと思いますが、object pascalには
動的バインドがあると思われるのですが、
その機能を贅沢に使って作るのですが、
そのあたりがわかっていないと、読むのはきついかと・・・
でもって動的バインドがわからないと、
私の設計思想を理解するのは困難であると思われます。

あ、あとメッセージ通信ってどういう意味ですか？

あと、265さんのアイディアの細かいところも知りたいので、
pascalでいいので、時間がある時にでも
見せてもらっていいですか？

>>292
もちろん291は私じゃないですよ（笑）
相当スピーカーに近づけないとならないですよね？

>>286
>あなたはつまるところクラシックコンサートは阿呆だと言っているわけです。

拡大解釈は困りますな。クラシックの「リズム」は阿呆だと言っただけです。
実際、あの程度の精度で良しとするのは、別の幾つかのジャンルを愛好
してる人々から見れば、噴飯もの。

>ロックでスピーカーをプレーヤーのそばに置いたらフィードバックしちゃうでしょう。

すでに色々反論がでてますが、そういうことです。

ハウリングをおさえる技術は色々存在します。エレキギターが共鳴胴を持たないのも
もともとはハウ防止のためだし、マイクにハウリングキャンセルのための仕掛を持たせるのも
今や珍しくないです。

ちなみにカラオケでカッコつけたつもりでマイクの上の丸い部分を握るひとがいますが、
あれやるとキャンセラがうまく機能しなくなるんで、五月蝿いんでやめてください。
すぐ近くにもう1つマイクを仕込むことで、遠くからくる音と近くのユーザーの口からの音とを
区別する仕組ですので、その2つめのマイクを塞いでしまったら、すべての音を正規の音と認識してしまい
キャンセルしなくなってしまいます。

エレキでは故意にキャンセラの限界を越えた入力をしてハウリングをおこさせる
フィードバック奏法というのもありますが、常に使うものではないですんで、
普段はハウらないに越したことがありません。
で、それを解決する技術は、すでにある、と。

#ほかにも色んな技術がありますよ。イコライザーだってハウ対策に使うし。

>大体リアルタイム演奏を目指さないのであれば楽譜があるわけだから
>MIDIキーボードとPCのキーボードをたたいて何をやりたいのかも不明です。

シーケンサとかで、既に録音(または打ち込み)済みのパートを聞きながら
リアルタイム録音で次のパートを取り足すことって、日常的でしょ?

で、そのとき、既存録音分はレイテンシの分だけ逆に先行して
そのトラックを演奏させれば済むことだけど(というかどうせ分からないんだから
そのままやれば良いだけのこと)、
リアルタイムの分のレイテンシはどうしようもなくて、困るわけです。

だからこそ、「(どうにか)弾けるソフト音源」という言いまわしが、あるんです。

ヘタレな質問ですが、絶対時間って時:分:秒の事? 小節:拍?

>>309
> 拡大解釈は困りますな。クラシックの「リズム」は阿呆だと言っただけです。
> 実際、あの程度の精度で良しとするのは、
デタラメ吐くのはやめた方がいい。

はて?

>> 拡大解釈は困りますな。クラシックの「リズム」は阿呆だと言っただけです。
>デタラメ吐くのはやめた方がいい。

なのだとすると、リズム以外のたとえば和音は崩れたりしない(よって阿呆でない)
のは自明だから、「デタラメ」だという主張の論拠が全く見えないし、

>> 実際、あの程度の精度で良しとするのは、
>デタラメ吐くのはやめた方がいい。

だとすると、実際にそのように演奏されてるのは動かしがたい事実なので、
これもデタラメとする論拠が不明。

デタラメだというデタラメを吐くのはやめた方がいい。

>>308 １さん
やはりあれは１さんではなかったですね。なのでちょっと
混乱してました。おかしな話題でスレを汚してスマソ。
おとなしくします。

＞相当スピーカーに近づけないとならないですよね？
そうです。かなり近づきます（ワラ
大ホール用の大型スピーカだと結構自分の耳に
キます。

>>277
>MIDIキーボードでノートナンバーを指定して
>PCキーボードでノートイベントを置くコマンドがアサインされたキーを押す。

噂に聞くレコポが、そういう順序だったそうですね。
鍵盤で音程入れてから、PCキーで音の長さを入力すると、データが入力されるという。

でもその順序って面倒じゃないかな?と思います。
漏れが知ってるレコポ以外の「すべての」シーケンサ(ハードシーケンサもソフトも)では
順序が逆でした。

まず「あらかじめ」音の長さを入力しておきます。
シーケンサに(正確にいえば、入力カーソルに)、その長さを記憶させておきます。
お絵かきソフトでパレットから色を選択しておくのと、同じですね。

で、つぎに鍵盤を叩いて、音程(とvelocity)を入力します。
正確にいえば、鍵盤を叩いてから「離す」と入力されます。
というのは、多音対策です。複数の音を同じタイミングに入力したいのか、
それとも次のタイミングに入力したいのか、を区別するために、
叩いた複数の音に対応するノートオフが全部出揃ってから、
その複数の音を入力と看倣します。(というタイプのを良く見かけました。
最初のノートオフに反応するというアルゴリズムも有りでしょうが、
そうすると両手で押えきれない多くの音(^^;を入力することが出来なくなります。)

で、鍵盤を離すと、音符が入力されてから、カーソルが
さっき入力しておいた音の長さ分だけ右に進みます。
もちろん、記憶している長さは、再び操作しないかぎり、そのまま変わりません。

これだと、同じ長さの音符が何回も続くかぎり、鍵盤だけをばんばん連打するだけで
入力が進みます。長さを替えたければ入力しなおせばいいだけ。

このほうが便利じゃないですか?

つづき。

この方式は良いんだけど、1つ悩むのが、音長パレットの選択ってのが
打ち込みやってると案外うざったいっていう点。

そこで、選択作業を出来るだけ楽になるようにしたらどうか?と思うんだ。

上の方式の何がうざいかというと、音長パレットにならんでいる音長は
いわば店で買ってきた状態の絵の具と同じ素の状態なので、
切り換えるたびに自分の狙った色の調合を「やりなおす」に等しい手間が
かかってしまうせい、だと思うんだ。

そこで、自分で調合した色も、パレットに置けるようにしよう!

符点なんとか音符とか三連とか、ついでにゲートタイム(デュレーション)も組み合わせた
「カスタム音長」を、作ってパレットに登録し、キーボード(pcや鍵盤の)に割りあてる、
というふうに出来ると、楽になると思うんだ。

>>288
>アナログジョィスティックでギターベンド編集できたり、
>タブレット叩いてドラムのアナログ入力できたりできるようにしてくれんか。

昔、マウスでベンドを出力するプログラムを書いた(それを別計算機のシーケンサに
リアルタイム録音させた)ことがあるが、マウスは駄目だね。
うまく狙った量のベンドを素早くかけられないんで、すごくヘロヘロのベンドになっちゃう。きもい。
ビブラートなんて最悪。

タブレットでベンド、という話なのかと思ったが、そうじゃなくてドラムなのね。
おもしろい案だなあ。ベロシティ入れられないけど(^^;。
横軸に音程(ノートナンバーは御仕着せの順番じゃなくて設定もできるとして)を、
縦軸にベロシティを、割りあてるという手もあろうか。

>>297
そういうコードというかインターフェースの記述に、便利なモデル言語があるYO!
「U言語」。ちなみに「う言語」じゃないYO(藁)
UMLを、テキストだけでさらりと書くためのもの。
ttp://objectclub.esm.co.jp/U-Language/

ところでそのTMidiEditPointだけど、メソッドがある(pascal知らない人が見ると
後ろに括弧がないとメソッドじゃなく変数フィールドと誤解されるかもしれないのが心配)
ということは、TMidiEditPointはクラスだよね。
じゃあ、EditPointOpen(time):TMidiEditPointじゃなくてコンストラクタでも良いんじゃない?

>>300
>ObjectPascalとC++の違いってどのくらいありますかね？

C++から見て大きな違いといえば。

1：Object変数は必ずポインタ。intとかの変数は普通。このへんはjavaと同じ。
2：コンストラクタやクラスメソッド(staticメソッド)をvirtualにできる。
3：2と絡むけど、クラス自体(インスタンスじゃなく)を変数に代入できる。

演算子overloadとかは瑣末なことだから良いんだけど、上記の点は、
言語のアーキテクチャの根本的な違いを意味するので、事前に注意してないと
「こんなこと不可能だよ」と頭かかえることになる。

>>301
>番兵としてループイベントなりのダミーのイベントを入れる

イテレータ的なものを使うならば、番兵は不要だよ。
番兵など入れる(本体データを「よごす」)ようなことをしなくても済むのがイテレータ。
本体データじゃなくてイテレータのほうで、どこまでを一回りだと看倣すかの情報を持てばいい。

>>305
>計算の容易の為にデルタタイムをパック形式ではなく32bitに変換する程度の加工は別にしてです

というか1イベントあたり1構造体かな。objectでもいいけど、参照じゃなく即値の
配列(など、なんでもいいが)として持つほうが、効率が良さそう。
1イベント(1メッセージじゃなく)という言いかたをしたのは、SMFとちがって、
ノートオンとオフのペアは事前にまとめておくのをお薦めするから。
どうせ音符はペアが有って始めて成り立つので、ペアは常に必要になる。
なにか編集やるたびごとにペアを検索するのは無駄だよね。
そんなのはSMFからimport/へexportするときだけでいい。

>複数の編集点をもてる

単に、複数の編集個所の「編集中という状態」を壊したくないときにも、その仕組は重宝しますよ。

>>306
何らかの意味でプレイバッファを持たせると解決だYO!
専用のバッファに転送されたデータ(だけ)を演奏処理に送るという手もあるし、
「編集はかならずコピーをとったほうでやる」というCheckOut方式も有効。

>混乱してました。おかしな話題でスレを汚してスマソ。
いえいえ。いろんな話があったほうが、参加者も増えていいと思ってますから。
なにやらにぎやかになってきましたが。

>>314
おそらくそれはステップ入力の事だと思います。
私がステップ入力を行わない理由は
>これだと、同じ長さの音符が何回も続くかぎり、鍵盤だけをばんばん連打するだけで
>入力が進みます。
これなんです。
私はあるフレーズを作るのに、「打ち込んで、聞いて、再編集」
この作業を何度も繰り返します。
だから、カーソルの移動は不都合なんです。

>そこで、選択作業を出来るだけ楽になるようにしたらどうか?と思うんだ
だから、PCキーボードとMIDIキーボードを組み合わせるわけです。
PCキーボードにアサイン可能なマクロは、インタープリターを実装できれば
かなり汎用的なものになります。
マクロ一つで、いろいろな種類のステップ入力をできるようにするといった
事も可能になると思います。
最初はRubyの文法でJAVA的な言語を作ろうと思っています。
この言語に関してもアドバイスか何かあれば、お願いします。
私、言語作成に関してはド素人なので、最初は軽い話から入っていただけると
うれしいです。

CUIを作るって書きましたが、それがインタープリターになればいいかなと
思っています。

lispがいいよ>318

アナログジョイスティックは私が持ってないから・・・・

>>317
１は私のC++もそうだったりします（笑）
何ゆえJAVA信者でして・・・
３はtypeidがあると思いますが。

>イテレータ的なものを使うならば、番兵は不要だよ。
番兵の意味は、比較を無くすという事で、
コードがきれいに書けたり、演算量が減ったりと・・・
演算量を減らす意味はないかもしれませんが、
これからの事も考えて、なるべく汎用的かつ
高速で動く物を作ろうと心がけています。
ただ、今から考えて見ると、
番兵を入れると複数のイテレーターを作ったときに・・・
だめですね（笑）
素直に比較ですね。

>ノートオンとオフのペアは事前にまとめておくのをお薦めするから。
私はノートオンイベントにノートオフイベントへのポインタを
持たせておく予定ですが、
イベントを統一的に扱えないのが悔しいとこですね。

>何らかの意味でプレイバッファを持たせると解決だYO!
個人的には、ハッシュの最下層に位置するコンテナーを
バッファにしてしまい
再生バッファに入ってるときは、編集禁止フラグでも
立てようかと思っています。
ただ、この辺は曖昧なので作ってみないと・・・

MMSYSTEM関数で少し実験しました。
とりあえず、デバイスの列挙と
入力デバイスでデータを受け取って、
コールバック関数が呼べたので、今日はこれでやめようと思うのですが
midiInAddBufferは何に使うのでしょうか？
最初から充分なバッファーを用意しておけば、
特に必要ないんですかね・・・

MidiStreamは使わないの？

>>322
wavとの同期はどうするの？

>>323
そんな話初耳だが

>>322
ループ機能は？

>>325
リングバッファでも使えば？

>>326
はぁ？

>>327
きみが理解できなかったのは、日頃全く努力していないからだ

>>308
○全デルタタイム絶対時間化は、時間挿入が起きた時に重いと思います
○メッセージ通信は、SendMessageやPostThreadMessage 等を手がかりに調べて下さい
○動的バインドがvirtualメソッドの事であるならDelphiにも当然あります

>>317 1イベントあたり1構造体は否定しないです。
　そこらへんは趣味というかコダワリの部分だと思います

　後半の、複数の編集点を持てる事と、CheckOut方式の両立は不可能ではない
けどメンドクサイ部分かもしれませんね

>>320クラス自体とtypeid は別では？ というかクラス変数はC++に無いから
　BCBなんかではTMetaClassへのポインタとして実装してますよ

>私はノートオンイベントにノートオフイベントへのポインタを
　これをやってしまうとデータ位置の再配置が不可能です。
　私がイベントレベルでオブジェクトにしたくないのは、>>317さんのいう
　プレイバッファ・CheckOutはもちろん、動的な再配置さえ難しくなる為です

＞midiInAddBufferは何に使うのでしょうか？
　ガクッ・・・・・・・

まあ初めてやるなら仕方ないか
MIM_DATA　以外が必要なら MIM_LONGDATAの都度 midiInAddBufferする
http://www.borg.com/~jglatt/tech/lowmidi.htm


結局　１さんは先に何かとにかく作った方がいいと思う
　ここでグタグタ思考実験するよりやってみるコストの方がたぶん低い

＞midiInAddBufferは何に使うのでしょうか？

MIDIデバイスからの信号を受信するのに使います。
使用方法としては、
::midiInPrepareHeader(....);　で前準備を行い、
::midiInAddBuffer(....);　でデバイスにバッファを送信して
::midiInStart(....);　で受信を開始します。

>○メッセージ通信は、SendMessageやPostThreadMessage 等を手がかりに調べて下さい
そういう意味ですか。
了解です。

>クラス自体とtypeid は別では？ というかクラス変数はC++に無いから
クラス変数ってどういう意味でしょうか？
staticなメンバ変数ですか？

midiInAddBufferはシステムエクスクルーシブを受け取るのに使うわけですか。
という事は、ダンプする目的がなければ特に必要なしですね。
では、PrepareHeaderは、どいういう意味があるんでしょうか？
とりあえず、意味もわからず書いてるのですが・・・・
あと、バッファはどれくらい用意すればいいんでしょうか？

>１さんは先に何かとにかく作った方がいいと思う
ですね。
やり始めています。

というか、私のmidiInAddBufferの予想を書いておくと、
システムエクスクルーシブの長さは未定なので、
prepareで用意したバッファに、さらに
addBufferで加えるのかな？、と・・・

システムエクスクルーシブメッセージを受信する
サンプルがあったので予想はしていましたが・・・

>>332
midiIn〜 はMIDIキーボード等、外部デバイスからの受信を行います。
いわゆるリアルタイム入力というやつです。

midiInPrepareHeader()は入力バッファの準備を行うAPIです。
バッファサイズ(MIDIHDR::dwBufferLength)は
4096 もあれば十分でしょう

あの...「Windows95 APIバイブル3」 はお持ちですか？
この辺りのことは上記の本に書いてあります。
人に聞く前に、まず自分で調べましょう

>あの...「Windows95 APIバイブル3」 はお持ちですか？
いえ、持ってません。
本屋でみかけた事もないです。
というか、ただだか１０数個のために8000円ってのは・・・

>人に聞く前に、まず自分で調べましょう
いろいろ調べたんですが、どうしてもわからなかったのです。

>>335
図書館いけよヴァカ

具体的なデータ構造とかはまあ初心者ならトンチンカンでもしょうがないとは思うが
APIの使い方くらいは自分で調べろ

>1
首吊れ

>>333　読むと、自分用語を作り出す背景がなんとなく見えてくる

１よ半分電波の世界に片足突っ込みかけてるぞ

だいたいそういう資料なんて
　たとえ１ページでも参考になる事書いてあるなら「当たり」
　ASCIIなんぞには重しにしかならんクソ本が多すぎるくらいあるからな

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/mmfunc_8otu.asp
に
> The buffer must be prepared by using the midiInPrepareHeader
> function before it is passed to the midiInAddBuffer function.
とありますな。
日本語なら
http://www.microsoft.com/japan/developer/library/default.asp?URL=/japan/developer/library/jpgdipf/_win32_midiinaddbuffer.htm
とか。

APIをどう組み合わせるかとか実践的な使い方とかなら、サンプルや
解説本の出番ですが。

>>340
こんなのがあったんですね。
助かります。
Prepareはシステムエクスクルーシブを受け取らないのであれば
不要なんですね。
ところで、システムエクスクルーシブって
最高どれくらいの長さの物があるんでしょうか？

図書館にそういう系の本って置いてあるんですか？

>>339
あれは誰が読んでもわかると思ったので、省略しただけです。

で、ちょっと質問なんですが
ノートオフメッセージのベロシティーなんですが、
本には、ベロシティー０のノートオンメッセージで発音停止
させるのが一般的であるとかいてあります。
一般的である理由は、ランニングステータスを使う事で
データサイズが小さくなるとの事なのですが・・・。
一方ノートオフのベロシティーですが、
ベロシティーの指定の仕方で音の消え方を指定する事ができるそうです。
家のキーボードで、MIDI入力ポートのデータを調べたところ
ゆっくりキーボードを離すとベロシティーの値は小さく、
急激に話すと値は大きくなります。
私の持っているシーケンサーで、ノートオフのベロシティーを設定する
事はできないのですが、
そもそも、ノートオフのベロシティーを繁栄する音源っていうのが
少ないという事でしょうか？
ノートオフのベロシティーは重要だという方がいたら教えてください。

>>341
＞ところで、システムエクスクルーシブって
＞最高どれくらいの長さの物があるんでしょうか？
あのさ、システムエクスクルーシブの意味わかってる？
もういいから、首吊れ。

>>341
>図書館にそういう系の本って置いてあるんですか？
どこに住んでるんだ？
近辺の最適な図書館を探してやろうか？

>>341(1)

ノートオフのベロシティー要る。

あんま使わんけど、GMのサポートすることは、できるだけ実証しようや…

s/実証/実装/; ?

とりあえず、ノートオフのベロシティーを使うという方向でやりますね。

>>342
未知のエクスクルースブメッセージを受け取るんであれば
既知のエクスクルーシブメッセージの最大長を、バッファとして
用意するのが適当かと思ったので。

>>343
本当に探してくれるんですか？
じゃあ、東京だったらどこですか？

今日はお暇な人が多かったようで、シーケンサーに興味ない人も
カキコがあったようですね。

私はこれからちょっと忙しくなってしまうので
ちょっと間があいてしまいそうですが、
ちょくちょく見るようにはするので、
アドバイス等あればよろしくお願いします。

>>346
東京だったら国会図書館行ってみろ（借りれないがコピー可）
それに町田、世田谷、渋谷など色々デカイところはある。
いずれにしろ何区か知らないが、最寄の区民図書館で予約すれば
他の図書館の蔵書も取り寄せられるぞ。

>>318
>私はあるフレーズを作るのに、「打ち込んで、聞いて、再編集」
>だから、カーソルの移動は不都合なんです。

じゃあ「移動しないモード」もあれば済みます。そういう事できるソフトも実際ありましたし。

というか、それ(だけ)の理由で、ステップ入力方式ぜんぶを捨てるのは、勿体ないです。

あるいは、ステップ入力を「しながら」他の編集も受けつけるような
複合モード(?)を作るという手もありそう。
今しがた入力された音符を、選択して編集できるならば、それで良いわけでしょ?
じゃあそういう風にいじれるソフトを作ればいいだけ。

>マクロ一つで、いろいろな種類のステップ入力をできるようにする

なるほど。それは正しいですね。今みたいに計算機が速いなら、
そういう仕組でも苦痛は少なそう。

マクロでなんでもと言えば Emacsみたいなものですね。
Lispという声もありますね。CakewalkのマクロはLispだと聞きましたが本当でしょうか?

>最初はRubyの文法でJAVA的な言語を作ろうと思っています。

うーん。rubyとjavaを混ぜるメリットって、あんまり無いような。

>番兵を入れると複数のイテレーターを作ったときに・・・
>だめですね（笑）

ええ。そのとおりです。

>API

たしかに図書館とかは便利と思われ。漏れは職場になぜか有ったんでそれですませました。
あとDel1(つまり16bit時代)のMMAPI和訳ヘルプは重宝しました。
なにせCとpascalの両方で解説してるんで、役立つ状況が多くて多くて(藁)

>あのさ、システムエクスクルーシブの意味わかってる？

まあまあ(^^;。いちおうマヂに説明すると、「Exclusive」ってのはここでは
「他社との互換性なんざ気にしない」というような意味です。
音源メーカーが勝手に内容を考えていいわけね。自社でメーカーID登録した分については。
で、勝手にです。つまり理屈の上では「無限の長さ」であっても誰も咎められない(ぷ
#SMFでは28bit長まで。

>GMのサポートすること

あれ? NoteOffのベロってGMでサポートしてたっけ?

>東京だったらどこですか？

便乗質問ですが、図書館の蔵書を検索するwww頁などという都合の良いものは有るでしょうか?

ここなんかどうですか？
全国の公共図書館等の蔵書検索
http://www.inh.co.jp/~yuichiro/opac.html

>Lispという声もありますね。CakewalkのマクロはLispだと聞きましたが本当でしょうか?
ほとんど同じですよね。
私はschemeしか知らないので、LISPとSchemeはほとんど同じだろう
的な気持ちで書いてます。
Calは参考にさせてもらう予定です。

>うーん。rubyとjavaを混ぜるメリットって、あんまり無いような。
いえいえ、混ぜるのではなくて
単純にJAVAの文法でインタープリターに食わせても
パースするのが大変なので・・・
あと、OO度合いはJAVA程度でいいかな、くらいの気持ちですね

>たしかに図書館とかは便利と思われ。
学校にあればいいんですがね。
使うAPIもせいぜい20個程度なので、大丈夫でしょう。

>まあまあ(^^;。いちおうマヂに説明すると、「Exclusive」ってのはここでは
私の文章ってわかりにくいんですかね・・・
まさか、そういう突っ込みがくるとは思ってもみませんでした（笑）
28bitという情報が頂けたので、良かったのですが。

>そういう仕組でも苦痛は少なそう。
まあ、まだ早いのですが
マクロはメモリに持つのと、一回一回ファイルから読むのとどっちがいいですかね。
一回一回読み直すと、更新の手間が省けたりするんですが。
というか、読み込む速度なんて一瞬ですよね・・・
ファイルから読み込むで決定。

もう一度アドバイスを聞きたいのですが、
VC++とC++Builderどっちで開発するのがいいのでしょうか？
VC++初めて触ったのが9月の頭だったので、
C++Builderの使い方を一から覚えても全然痛くないです。

>>350　 あの・・・スクリプトの前にウオークサンプルくらい作ってみては？
　　仕様の広げすぎかと
　　スクリプトにする前にDLLに別けてプラグイン式にする方法を先にしては？


＞VC++とC++Builderどっちで開発するのがいいのでしょうか？
　って、どっちでもいいと思うよ
　MIDI系のDelphiコンポーネントが使えるという面ではBCBだろうけど
　だったらDelphiやった方がいい

>仕様の広げすぎかと
確かに夢語りすぎですすね

間違って、書き込むボタン押してしまいました・・・

で、ウオークサンプルってのはなんでしょうか？
それと
C++よりDelphiの方がいい理由はなんでしょうか？

ああ、ある程度動作出来るものって事ね

Delphiがいい理由は・・・何だろうね、

俺ならDelphiなら今言ってる程度のウォークサンプルなら１日(まあ２４時間だけど）
で作れるという程度の理由かもな

こういうのは頭で設計せずに、ウォークサンプルサクサク作ってみてから再設計す
るのが吉かと

なるほど。ウォークはランより遅いわけですな(^^;

たしかに、簡単な(あるいは部品の)試作をしながら思索(藁)すると
コーディングと思考の双方が弱点を補完しあって進んでいき、良い感じになる。

C++は全体をキッチリ設計 -> コーデング -> デバック ->完成
　というスタイルなら最強。
　タイプ量も少なく、テンプレートも強力
　が、設計が甘かったり、デバックに不慣れだったりすると泥沼

Delphiは言語仕様面ではC++に遅れるが、何といってもコンパイル速度が速い
　だから大きなアプリの作成中でも、ちょっとお試し　がストレスにならない
　試しながら組み立ててゆくスタイル＝個人で作成する場合には
　最高のツールだと思う

　特に MIDI関係ならMIDIやSMFの入出力　ピアノロール表示や、ソフト鍵盤とか
　　色々コンポーネントがソース付で公開されているから、これを利用すれば
　簡単に試作出来る。
　試作の後、問題があれば完全フリーなソースなら改良してもいいし、
　インターフェースを真似て自作改良なんて事も可能

>なるほど。ウォークはランより遅いわけですな(^^;
なるほど

DelphiとC++の比較説明、どうもです。

>こういうのは頭で設計せずに、ウォークサンプルサクサク作ってみてから再設計す
>るのが吉かと
時間があればいいのですが、学校やらバイトやらで忙しくて
なかなかまとまった時間ができなくて・・・・

とりあえず、今度BCBを買ってみます。

それで、前回書き忘れてしまったのですが
>スクリプトにする前にDLLに別けてプラグイン式にする方法を先にしては？
これはどういうメリットがあるのでしょうか？
ちなみに,CakewalkのCALはDLLを呼び出すことができます。
DLLを使った事が無いのですが、COMよりは気軽に使えるのでしょうか？

>>357
Pascal覚えるのが苦にならないなら
BCB買うよりDelphi6 Personalをダウンロードしてくるほうがいい。
コンパイル速度は爆速だし。

COMより手軽かと言われると比較するもんじゃないという気もするが
とりあえず、ずっと手軽
　WinAMPとかのプラグインもDLLだから、試しにWinAMP SDKとか探して
　みればイメージはつかめるだろう

　DLLは　単に関数を別のファイルにおけるというもの
　クラスもDLL化する事は出来るが、コンパイラとの依存性が出るから
　プラグイン用ならCスタイルのインターフェースを介さないといけないぞ


　OO好きならCOMの方が好みじゃないのか？

Pascal覚えるのは苦になります。

>>316
そか、タブレットなら曲線が比較的自由に描けそうだからベンド編集にも使えますね。
タブレットは筆圧があるからドラムベロシティ入力に使えると思って書いたんだどね。

筆圧(絵の分野の道具の事情)は知りませんでした。なるほど。すばらしい。
でもそれ、ドラムのような素早い加圧も、センシングできるんでしょうか?と老婆心。

スレ(板)違いだが以前悩んだのが、ベロセンスつきの電気または電子ドラムを
作れないものか?ということ。センサーを個人レベルでお気楽に作る方法が思いつかなくて頓挫。

いろんな意見があって迷いまくりです。

COMはリファクタリングから程遠いんで・・・（笑）
とりあえず、DLLが呼び出せるメリットは無さそうですね。

タブレットは触った事すらないんで、イメージがつかないです。
タブレットって何に使ってるんですか？
便利な使い方があれば、購入しようかな。

>スレ(板)違いだが以前悩んだのが
全然OKです。
撃力を電気信号に変えるのってどうするんでしょうね。
今度、制御系の人に会ったら聞いてみます。

>>363
　COMはリファクタリングから程遠いかどうかはさておき

DLLは
>マクロ一つで、いろいろな種類のステップ入力をできるようにする
の部分を
DLLを用意すればいろいろな種類のステップ入力をできるようにする
程度に仕様ダウンしたらどうだという事でしょう

>>362
　単純にイヤホンばらしてくっつけて電気信号にして
　大きさが時間幅で表現出来るように変換して読めばいいだけだと思うが？

で、シーケンサーどこまで出来たの？
とか言ってみるﾃｽﾄ

VC++で書いた方がアプリケーションの速度が速い。

×VC++で書いた方がアプリケーションの速度が速い。
○散漫にそのツールを使った場合、VC++がアプリケーションが早く動く場合がある

しかし注意深く書けばどのツールでも当然同じだよ

いや、OSの開発元のMSがコンパイラ付くってんだから、VCの方が早く動くと思う。

>>369
その理屈ならCPUの開発もとのIntelのコンパイラのほうが速いと思うんだが…

実際に同じソースを VC++ とBCBでコンパイルしたら VC++の方が少し小さくて少し速いことは事実だ
　その差は平均して数％
　もっとも悪かった標準入出力で２倍
　倍違うと確かにコンソールアプリはVC++を選びたくなるね

しかし、それだけが全てではないのも確か
　同じ開発時間をかけるなら
　BCB/DelphiだとRADによる開発スタイルで画面回りを手早く片付けて
　アルゴリズムに凝る事が出来る訳で、　トータルでは逆転する事は容易な事

　また、コンポーネント指向を利用して
　各部分を再利用性の非常に高い形式でモジュール化出来るなんて事はVC++には出来ない

>>370
マジでIntelのコンパイラのほうが速いよ

>>372
だいぶスレと話がズレて申し訳ないけど、intel製コンパイラって
どこに行ったら買う事ができるんでしょうか?

>実際に同じソースを VC++ とBCBでコンパイルしたら VC++の方が少し小さくて少し速いことは事実だ
ソースによっては、コンパイルのオプションでだいぶ違う。

>>373
http://www.xlsoft.com/jp/products/vtune/perftool.htm
こんなところとか。

俺Athlonだしなぁ…

windowsサウンドプログラミングを読んでおけば
くだらない煽りを相手にしなくてもすんだのに

なんか最近、自分のプログラムでVC6よりもBCCの方がベンチ結果が良くなる
傾向があるけど・・・
inline展開し過ぎかも。

2chよりも良書で勉強。
人間の基本ですね。

>>378
たしか　BCCだと 条件判断が入るだけでインライン展開から外される？
もしかしてヘッダファイルにコード書いてるとか？

市販シーケンサ使うだけの人間ですが、使うだけの側の考え
とにかく早い編集機能が付いたステップ方式、かその発展型
具体的にはギター入力で、オープンボイシングと言われる楽器の入力が楽
あとどなたか書いてたように音符の長さをカスタマイズ可能

一度自分で作ろうと思ったけどここ見る限り早めに手引いて正解だった（藁
ピアノロールの考え方でレコポみたいにさら〜と編集できちゃうといいね

1さん＆このスレの方々
頑張ってください期待age

ついで自分が使ってるタブレット(WACOM)について
タブレットは、安いのでも筆圧100段階だか検知できる
ヴェロシティカーブと同じようにハード、ソフトみたいな設定も可能

aペン先、bボタン、c消しゴム、dその他
このうち筆圧を検知できるのはaとc
どちらにしてもポンポンペンを打つのは苦痛

マウスでベンドはwinampみたいに中間で遊びがあればいいかも
もしくは重みをつけてやるかホイールかな

久しぶりに現れてみたりして・・・・
コード書いてる時間が無いのが残念なのですが、
アイディアをより具体的にする事は日々行っています。

DLLに関して詳しく解説しているページってないもんでしょうか？
いまいち、DLLを外部から自由に追加する方法が理解できません。

>具体的にはギター入力で、オープンボイシングと言われる楽器の入力が楽
コード入力支援はターゲットに入れてます。
タブレットに関しては、あまり効率よく入力できなさそうなので
今のところはサポートしない方向でいこうと思います。

あ、windowsサウンドプログラミング買って来ました。
まだ、袋の中に入ってますが・・・

個人的な意見ですが、C++MIDIプログラミングは
買う必要ないと思います。

>>383　APIヘルプで
を読めばそれ以上の解説は不要だと思います
LoadLibrary　　して
GetProcAddress　で関数ポインタに代入し　関数ポインタから間接コールするだけです

効率良く知りたいんだと思われ

>>385
>>384が最も効率的と、言うかこれが唯一の手。

windowsサウンドプログラミング。。。
あまり個人的にはお勧めできない。書式が変で読みにくい。
個人的には↓をお勧めしたい。
Windows95 APIバイブル〈3〉ODBC,マルチメディア編
http://www.amazon.co.jp/exec/obidos/ASIN/4881354744/ref=sr_aps_d_1_1/249-2880516-0919508

>>385　だから DLLの入れ物に使ってるって事は
DLLをメモリー上に呼び出す命令が必要で、それが LoadLibrary

その後、必要な関数が実際のメモリ何番地にロードされたからも必要だからそれが GetProcAddress

それとも関数ポインタが判ってない？

厨房祭りアゲ

プロセスの優先度をRealTime_Classにするとよいよ

>>390
他のスレッドが動けなくなりませんか

不安なので上げておきます

タブレットを使うより
http://www.casio.co.jp/emi/lightdrum/ld80.html
こっちの方がいいよ

>>393
そりゃそうでしょ。
本物があるならそれにこした事はないかと。

タブレットやスティックの話は汎用的なアナログデバイスを活用できないかどうかと
いう思想から発生した物だから、良い悪いは関係ない。

ちょっと話しがずれるが

timeSetEvntでやると演奏のずれが気になるって話について
これってひょっとしてストリームMIDIにしたら解決するの？

>>395
するよ

プレイヤーとか簡易シーケンサーならそれでいいと思う。
データの変更が再生中に変更できないだけ。

それにしても、
そのドラム欲しいな･･･

>>397
変更できないのはちょっと違うのでは。
ストリーム(midiOutStreamだったっけ?)出力した物は変更できないけど、
それをする前のデータは変更できるのだから、純粋に遅延時間の問題になるのでは。
timeSetEventなら1ms精度できるけど、MIDIストリームでも1msとか100msの精度に
すれば問題ないかと。

ま、どのみちシーケンサーとしては無理か。

http://www.pearsoned.co.jp/washo/prog/wa_pro10-j.html

上記のMaxMIDIってどうでしょ？

>>399
なぜシーケンサとしては無理なの？
1msで反応すれば十分では？

たぶん、バッファーを用意して
「再生」すると、そのバッファーを全部再生してしまうんだと思う。
（止めるまで）
だから、バッファーとして読み込ませたものを変更する事が
できないってことじゃないかな？

曲をいくつかに分けて、バッファにいれて再生して
再生し終わったら、またバッファに入れて再生すると
その切れ目の部分でタイミングが取れないとか。

あと、テンポが変えられない気がする。

>>402
DirectSoundのストリーム再生のようにバッファを半分に分けて
再生しながら書きかえるっていうのは
ストリームMIDIでは無理ということなのか？

ごめん、DirectSoundよく知らない。
でも、配列に入ってるデータのパラメーターを書き換えることは
できるかも。

以外とストリームMIDIも内部処理ではtimeSetEvent使ってたりして…

>>402
MIDIストリームはダブルバッファみたいな物で、1つ目を再生中に次のバッファを
作成してAPIを呼び出しておく、という処理をするのでバッファ内を環状するわけじゃない。
で、1つのバッファが終了するとコールバックされるので、そこで次のバッファなりを準備する。

MIDIストリームの形式はデルタタイム、MIDIメッセージを順番に格納したDWORD配列だし
自由に何時でもアクセスできるけど、再生中に書きかえるのは危険とされてるよ。

>>399
1msでバッファリングするならtimeSetEventと違うのかという疑問があったから。
それにコールバック内で重い処理はしない方が良いと思ったから。

>>400
実際に使ったことはないけれど、サンクしてリアルモードで動作してるみたいなので
時間の揺らぎは殆ど起こらないと思うよ。
WinNT/2000で使えるのか疑問だけれど。

えー質問です。

timeSetEventでMIDI再生ルーチンを書くわけですが、
たとえば
ユーザーがテンポをリアルタイムで変更をしたときに変数が共有するという問題が
ありますよね？
(メインスレッドでdword tempo = ....; とかやってるとして
それをコールバックルーチンで読みこむと変数が共有してしまう)

これってCriticalSectionとかMutexとかを使って回避すべきですか？
というかしてもいいんでしょうか？

ただの変数ならいいんですがリストとかを共有する場合にはかならず
共有問題が発生してしまいます；

排他制御してもいいんじゃないかな？
メモリをちょこっと書き換える間
ロックされてる時間はちょっとだけだからね。

変数一つ書き換えるのに排他制御が必要なのかどうかっていうのは
良くわかんないけど
パイプラインとか、プロセスとかの事を考えると
必要な気がする。（アーキテクチャによるけど）
だから、自分がやるなら必ずするようにしてるよ。
そこら辺に詳しい人いないかな？

>>409
いや、timeSetEventってマルチスレッドとはちょっと違うよね。
コールバックルーチンなわけだし
マルチスレッド用のロックとかを普通に使ってよいものか？

>408
各々のスレッドID調べてみろ

ユーザーがテンポを変えるってのは
別スレッドでやってると思うんだけど。

>>412
ユーザがテムポかえるのはメインスレッドでしょ？
timeSetEventはスレッドでエミュレートされてるらしいから
どうなんだろうな。

>>408
たとえ動いても、コールバック内で使えるAPIって決められてるでしょ
SDKドキュメントに書いてある

>>413
例えば、テンポを変えると
再生クラスにメッセージ送るとかだったら
明らかに別スレッドじゃない？

>>414
４０８じゃないけど
コールバックのドキュメント見つけられないっす。
もしよければ、URL教えて。

>>415
これかな

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/mmfunc_5vz7.asp

>>415
＞明らかに別スレッドじゃない？
なぜに？
メインスレッドとコールバックルーチンだけでmidi再生って
成り立つはずでしょ？

int tempo;

とかあってそれをメインスレッドとコールバックルーチンからよむと
共有問題が発生するってことでしょ>>408

それがただの１変数なら問題ないけど、リスト構造とかだと
エラーになっちゃうってことで

コールバックルーチン内でmutexやcriticalsectonつかっていいのかな？
ってことでしょ。

>>417　コールバックじゃなくて
メッセージで貰えばタイミングの事考えなくてもよくなるよ

あ　ごめん　timeSetEventの話か・・・・

そういう微妙な場面では　CriticalSectionとかMutexとか　使うと
場合によっては実際に別スレッドでないなんて事になるとそこでロックしてしまう

リアルタイム処理でも安全なデータ構造を使うと良いのでは？

１、双方で書かない　メインで書かれるデータはコールバックでは読むだけ
２、ワード単位に変更される構造にする
　　たとえば、メインスレッド変更する場合は、構造体・クラスのコピーを作って
　　変更して最後に、ポインタを書き換える

>>416
ありがと
すべきではないって事だから
使っても平気じゃない？

>>417
じゃあさ、MIDIを再生してるスレッドがあるよね。
そのスレッドが、ユーザーからの処理を受け取るの？

>>420
>場合によっては実際に別スレッドでないなんて事になるとそこでロックしてしまう
そうなの？
具体例を教えてもらえるとうれしいんだけど。

ワード単位っていうのはいいかもな。

いや、ドキュメントに曖昧にしか書かれていないのだから、実際にどうかは
9x系 NT系　それから将来の実装でどうなるか判らない。
どうなるか判らなくても安全ならいいけど、安全でないから恐いよという意味です

MIDIの再生程度なら、排他処理しなくても共有しても安全な方法はあるのだからと

まず、片方が書くだけで片方は読むだけというモデルにして
　かつ最終的に１ワードだけ見れば良い仕掛けを作れば安全になるのは前述の通り

例えば FIFOが良いスタイルです。
割込処理内部ではデータを作らないで、FIFO方式にして再生だけに集中させる
FIFOバッファ残が少なくなったらメッセージを送ってメインスレッドで作成させるように
すれば問題ないと思いますよ

>>422
まあ、つまりそれやるとMIDIストリームの形そのまんまだよな。
MIDIストリームもいわゆるFIFOの形でAPIで渡して再生してもらうわけだし。

そういえばtimeSetEventのコールバック内で長時間ブロックさせておくと、
OSごと逝ったりしたことないですか?
とりあえずWin95で「プログラムの強制終了」ダイアログを表示させて
しばらくすると逝った。
これ、クリティカルセクションとか使ってロックしても起きたんだけど話題と関係あるかな。

まあwin95とwin98の違いはかなりのものだし
ましてやNTとなると・・・

話がどんどん明後日の方向に逸れるよね。このスレ

それはどこでも同じでしょ

Delphiみたいなメソッドポインタがある言語なら、
メソッドポインタのFIFOを作っておき
処理は必ずメソッドにしておきそのFIFOに投げる。
で、FIFOを読み出して処理するスレッドは一つにしておけば問題ないでしょ？

FIFOに排他制御が必要ですがなにか？

で、シーケンサーはいつ完成するのかと小一時間問い詰めたい。

この手のスレが完成まで進んだ試しがあるとでもお思いで?
ましてとりあえず作ってみろとなんども助言されてるのに
無視しつづけてるんだから完成させる気など最初からない
ネタスレでしょ

こんだけ山ほどの人を煩わせておいて
シェアウェアにするつもりなら覚悟はしておいた方が良いな。

ソース付きってとこが、妥当だな。

最低でもフリーにするのが仁義ってもんかな。

>>432
だから、完成しないからそんな心配ない。

みみっちい奴がいるよ（w
普段ワレまくってるやつが、うざい事いうなよな。
何千円って世界だろ？
それにシェアウェアの金は、バージョンアップのための開発費に
当てられるのが一般的。
それに、シェアウェアで儲かってんのは秀丸くらい。

>こんだけ山ほどの人を煩わせておいて
おまえスレちゃんと読んだか？
それともアフォ？
役に立つ情報がないから、１は消えたんじゃない？

>>434
みたところお前は1だな。

金なんぞ問題ではない。
コミュニティの善意に報いるのが仁義であるといったまで。
実際頼ったのだから。

役に立つ情報の多寡はあまり問題ではない。

＞コミュニティの善意に報いるのが仁義であるといったまで。
あー、誤解してたスマン。
てっきり、金なし貧乏人かと思った。
やってる事と言動が一致しない奴ってうざさの頂点極めてるから
むかついただけ。

でさ、マジレスするとさ
俺はフリーにしようがシェアにしようが
それは作者の自由だと思うんだが。
別に俺らは（俺はまともなアドバイスできなかったが）
それが使いたくてアドバイスしたわけじゃないだろ？
もし、そうであればやっぱりみみっちい奴だよ。

それに、シェアウェアの「シェア」っていうのは
「分かち合う」って意味だろ？
それって、開発費とか時間を分担で負担して
いい物を作ろうって意味じゃないのか？
だから、俺は秀丸を金払わないで使ってる奴は嫌いだ。
そして、秀丸はもっといいものになって欲しい。

逆に、フリーウェアにする事がコミュニティーの善意に報いることになるのか？
俺はならないと思う。
たかが数千円払わずに個人レベルのMIDIシーケンサーが使えたとこで
なにになる？
コミュニティーに報いるというのは、
コミュニティーの意見を充分活かして、良い物を作り上げる事だと思うが。

>>435
俺なりの意見を書いてみたので、
違う視点からの意見があったら聞かせて欲しい。

ちなみに、最近オープンソースというのが流行っているが、
俺はプログラムにはオープンソースとは違った方向性であるべきものが
あると思っている。
オープンソースは全員の希望を取って平均したようなソフトウェアだが、
一方で自分のポリシーを繁栄させた個性的なプログラムがあってもいいと思う。
プログラミングが面白いと思えるのは、そういうアーティスティックな面じゃないかと
俺は思う。
だから、ソースコードを公開した方がいいとは限らないと思う。

>>436
よくそんな偉そうにしゃべって恥ずかしくないな…

よくここまでマジになれるもんだとｶﾝｼｰﾝ

反論不能になった435が逆ギレ（プ

漏れも436の厨房撃退テク欲しいかも

座を白けさせるテクの間違いだろう。

ケンカ祭り？

　　　　　　　　　　http://1.██▓▓▓▓██
　　　　　　　　http://1.█▓.._▓.._▓▓▓▓█
　　　　　　　http://1.█▓.._.._▓▓▓▓▓▓▓█
　　　　　　　http://1.█▓.._▓▓▓▓▓▓▓▓█
　　　　　　http://1.█▓▓▓▓▓▓▓▓▓▓▓▓█
　　　　　　http://1.█.._▓▓▓▓▓▓▓▓▓▓▓█
　　　　　http://1.█▓▓▓▓▓.._▓▓▓.._▓▓.._▓█
　　　　　http://1.█▓▓▓▓.._█.._▓.._█.._▓▓▓.._█
　　　　http://1.█▓▓▓▓▓▓.._▓▓▓.._▓▓▓▓.._█
　　　　http://1.█▓▓▓▓▓█▓▓▓▓█▓▓▓▓▓█
　　　　http://1.█▓▓▓▓▓▓████▓▓▓▓▓▓█
　　　　　http://1.█▓▓▓▓▓▓▓▓▓▓▓▓▓▓█
　　　　　　http://1.███.._█.._█.._█.._█.._██
　　　　　http://1.█.._█.._█.._█.._█.._█.._█.._.._█
　　　　http://1.█.._█.._██.._█.._█.._█.._█.._█.._█
　　　　　http://1.██.._█.._█.._█.._█.._█.._█.._█

♥

こういう展開の常として、無意味にageてるヤツが悪。

435です。
わたしは435を書きこんでからいままでここに来てませんです。
荒らしは他の人です。

436はおそらく1ではないかと思っているのですが、
もしそうなら、この話題でなのらないのはちょっとまずいのではと思います。

>>436
まず、シェアウェアに金払うのがおしいとか、シェアウェア作家は強欲に
違いないと思ってるわけではないです。払ってますしね。

わかんない部分はどっかの人にどんどん答えてもらって、
で、楽ちんにシェアウェア作って大もうけだせー、な奴だったら嫌だなと
思って「釘さしただけ」です。
今読んで見ると、誤解を招く書き方で申し訳無い。
メーリングリストとかで、お前はメーリングリストに仕事を外注してんの
か？というお方がたまに現れたりして、それの亜種だったら嫌だなと。

わたしの書いた「コミュニティー」っていうのは、このスレのことです。

こういうところの無料の善意をつかって組み立てたシェアウェアって、
フリーのソースを流用したシェアウェアみたいで、あんまり粋じゃない
なあと、個人的には思います。

どっちかというと教えてもらって作った部分が多いなら、自分が教えて
もらったように他の人がソースを読んで参考にできるようにしても良い
んじゃないかと「私は」思うわけです。


わたしのレスとは関係無い事にまでレスが付いてしまっていますが、
せっかくなのでそれにもレスしてみます。

自分の作ったシェアウェアにお金を払わないと怒ってみたりするのは
それは、分かち合うっていうシェアと言う美しい言葉ではあんまり無い
ように思います。
お気に入りなら自由に払ってください、なら解るんだけど、単に売って
る気がします。この辺はこの文章自体より、シェアウェア系のスレの
守銭奴どものカッコ悪さを想像してわたしの気分を汲んでください。

オープンソースの部分は間違って理解しておられます。Linux板とか
とかだと怒られると思います。個性とかは全然関係無いです。


>たかが数千円払わずに個人レベルのMIDIシーケンサーが使えたとこで
>なにになる？
とか434、あとシーケンサーを作ろうということを考えると
高校生かなと思いました。

436が、って事じゃないんですが、
高校生くらいの時に、パソコンやってるとお金が足りない、ソフトウェ
アもハードウェアもどんどん新しいのが出て足りない・・
シェアウェア作って儲けられないかな、と企んだことのある人は結構
いるんじゃないかと思います。
私自身を振り返って見ても、この辺って厨房思考の実に発生しやす
い所で、ベクターにダメなシェアウェアが登録されたりする原動力に
なってたりするんじゃないかと思う次第です。

それもこれも、シェアウェアよりふつうにソフトウェアのアルバイトし
た方が儲かる、というかたんなる普通のアルバイトでもシェアウェ
アよりはましということに気が付くまでのことなんですが。

質問です。

心霊写真を茹でちゃだめですか？　　　

心霊写真を処分するときは燃やしたり川に流すのがいいと聞きますが、
おもいでの写真の場合、破棄するのはもったいないです。

そこでせめて心霊写真を茹でることで浄化できないでしょうか？
高濃度の塩水で茹でるのは効果がありますか？
あ、そうそう、心霊写真を電子レンジでチンするのはだめですか？

日本人が、犯罪に巻き込まれても韓国では警察がまともに捜査しないらしい。
特に美しくて大人しい日本人女性を韓国の男達が強姦するのは当然の権利だと奴らは思っているようだ。
日本人にはどんな事をしてもかまわないというのは韓国人どもの常識のようだ。
韓国人は生来犯罪者民族。
http://www.geocities.co.jp/WallStreet-Bull/6199/
http://isweb24.infoseek.co.jp/area/oslo/
http://www.geocities.co.jp/Athlete-Acropolis/6963/
http://members.tripod.co.jp/koreawatcher/
http://members.tripod.co.jp/anti_2002jwccom/

日本人女性にとって韓国はセブ島よりも高い危険度４です。
まじめな話ですが旅行業界では女性に韓国をすすめるということはもうありません。
未だにレイプの恐れのある国にツアーを進めている業者は皆さんの予想通り在日経営です。
もしくは統一教会の系列です。

>>1の体育教師です。
　>>1は冬休み前からおかしくなり始めました。俺の体を舐めまわすように見ているかにと思ったら次の瞬間には、俺の股間をまさぐり始めました。
「気持ちええだろ」と>>1はまるで俺が喜んでいるかのように同意を求めてくるのです。
　実際、俺はｹﾂの筋肉で角材が折れるほど筋肉質で、ﾀﾝｸﾄｯﾌﾟを着れば腋から毛がはみで胸毛もそして背毛肩毛すらはみでてしまうほど毛深く、ｹﾞｲﾋﾞﾃﾞｵのﾓﾃﾞﾙにｽｶｳﾄされることも日常茶飯事です。そして職場上ｶﾐﾝｸﾞｱｳﾄはしておりませんがｹﾞｲです。
　>>1のような若い男にまさぐられて喜び隠さず(;´Д｀)ﾊｧﾊｧしそうになりましたが、俺の教師としての立場から「何するんじゃ( ﾟДﾟ)ｺﾞﾙｧ!」と>>1の誘惑を拒否しました。
　冬休みに入り>>1のことが気になり、友達のﾊｯｶｰに頼み>>1の行動を知ることができました。
>>1は俺への接触がうまくいかなかったことから、冬厨と化し糞ｽﾚを乱立させているのでしょう。俺がきちんと>>1の気持ちを受け止めなかったが為にこんなことになって申し訳ありません。
　冬休みが明ける前に、>>1を犯すつもりです。>>1に素直になれなかった俺の罪、糞ｽﾚを乱立させた>>1の罪・・・・・・
　>>1を罰してやります。同じ罪を背負った者同士で罰しあいます。
　もう糞ｽﾚはたつことがないでしょう。俺が>>1の全てを包んで（でも>>1のﾁﾝﾎﾟの皮は剥いて）あげるのだから・・・・・・

日本人が、犯罪に巻き込まれても韓国では警察がまともに捜査しないらしい。
特に美しくて大人しい日本人女性を韓国の男達が強姦するのは当然の権利だと奴らは思っているようだ。
日本人にはどんな事をしてもかまわないというのは韓国人どもの常識のようだ。
韓国人は生来犯罪者民族。
http://www.geocities.co.jp/WallStreet-Bull/6199/
http://isweb24.infoseek.co.jp/area/oslo/
http://www.geocities.co.jp/Athlete-Acropolis/6963/
http://members.tripod.co.jp/koreawatcher/
http://members.tripod.co.jp/anti_2002jwccom/

日本人女性にとって韓国はセブ島よりも高い危険度４です。
まじめな話ですが旅行業界では女性に韓国をすすめるということはもうありません。
未だにレイプの恐れのある国にツアーを進めている業者は皆さんの予想通り在日経営です。
もしくは統一教会の系列です。

>436はおそらく1ではないかと思っているのですが、
違うけど。
というか、なんで１だと思ったんだろ・・・・
俺は普段Linux板と自作PC板にいる。
だから、プログラム板なんてたまにしかみない。
面白そうなスレだったから、たまたまだな。

>払ってますしね。
なるほど。

>こういうところの無料の善意をつかって組み立てたシェアウェアって
それはプログラミングを侮辱してないか？
組み立てるって表現はおかしいと思うが。
それとも、プログラム歴短いのか？（気分を悪くしたらスマン）
それから無料の善意ってどういう事だ？
無償の善意だったらいみわかるけど、そんな端的な表現使われても
何がいいたいのかわからん。
有料の善意を善意と呼べるのかどうかもわからん。
少なくても、ココにレスつけてる奴は
共通の興味があって集まってるだけで、
人助けがしたくて２Chにきてないと思うが。
ギブ＆テイクなら１はそれなりのレベルなのだから
２ｃｈの人間なら充分にギブしてると思うぞ。
それに１にギブしてる奴なんてほとんどいないだろ。

>もらったように他の人がソースを読んで参考にできるようにしても良い
なぜそう思うか聞かせて欲しいんだが。
確かに、教えるためにソースコードを嫁、ってのはありかもしれない。
１が無償の善意をしたければの話だが。

>自分の作ったシェアウェアにお金を払わないと怒ってみたりするのは
俺はそこまで言及した覚えはないが
例えば、
きれいな海を使いたいので、みんなで海をきれいにする活動をする一方で
海を利用するだけ利用して、汚していくアフォに対して怒る事は
問題ないんじゃないか？

＞それに１にギブしてる奴なんてほとんどいないだろ。

ガーン。・・・・お邪魔しました・・・・・・・・・バイｯ

>お気に入りなら自由に払ってください、なら解るんだけど、単に売って
>る気がします。
そういう言い方をするなら、
金払ってまで使いたいと思わない奴は使わなければいいだけの話で、
有料にされてキレられてもな、そりゃ逆ギレだよ。
という表現も可能だが。
実際には、正直者が馬鹿を見るよりは、
利益をシェアできる人どうしで使ったほうがいいだろ？
という事だ。
それから、著作権を主張できるのは現代社会のルールであって
なぜ主張する事ができるのか？というのは問題ではない。
もちろん、そういうルールが存在する意義は問えるだろう。
GPLなんてのは、そういう流れだよ。

作者自身が、多くの人に使ってもらいたいと思ってるなら別だが
自分で使いたいからと書いてあったような気がするが。

>高校生かなと思いました
まともなMIDIシーケンサーが作れる高校生がいたら
ちょっと鬱になるな・・・（ｗ

>シェアウェア作って儲けられないかな、と企んだことのある人は結構
>いるんじゃないかと思います。
俺はこれくらいアグレッシブな方がいいと思うぞ。
俺が高校生の時は、まともなプログラム組める程の腕がなかったからな。
ベクターに登録してあるシェアウェアにはもちろんいいのもあるが、
悪いのもあるのは、プログラミングが一般に普及したのと同時に、
プログラミングが複雑化したからじゃないか？
それと、クソシェアウェアは高校生じゃないだろ？

>オープンソースの部分は間違って理解しておられます。
そりゃ、あんたがオープンソースと各種のライセンスを混同してる
だけでしょ？

それから、アルバイトやってコツコツ金貯めてる高校生より
本を読みあさって、クソでもいいからシェアウェア作ろうと
たくらんでる奴の方がカッコイイと思うが。

で、445は結局のところ
１が仮にもMIDIシーケンサーを完成させたら
フリーにするべきだと主張するのか？

450=452が
435=445=作者に操られてるに
5000カノッサ

sage忘れた

おまえらアホかと小一時間問い詰めたい。
シェアだろうが、フリーだろうが
作者にメールでも送ればいいだろーが。
「２ｃｈでアドバイスした者ですが、それください」
それで断る厨房がいるわけないだろ。
そういうわけで１よ、俺にもただで使わせろ。

>>445
>>450
>>452
どこを縦に読むんですか?

>>456
えー、意味がよくわかりませんが

縦に読めない長文はゴミだということだ。

正直、どうでもいいからシーケンサーの話題に戻してくれよ。
＞スレに関係ない議論で*荒らしてる*やつら

忙しかったので、見てはいたのですが（４日に一回くらい（汗））
特に進展はないので書き込まないでいたのですが、
意外な展開になっていますね。
私の他にも作り始めた人がいるようですね。
お互いがんばりましょう。

フリーウェアかシェアウェアにするかは、まだ全然考えていません。
作り出しのスタートが違いますからね。
私はあまり音楽を知らないので、市販のシーケンサーはあわないのでしょう。
だから、プログラマー向けのシーケンサーを・・・ってところです。
あ､それから私は大学生でプログラミングのバイトを・・・・
って前に書きませんでしたっけ？
そういうわけで、豪快に本を買えるわけです。
お金出してもらえるなら、市販のシーケンサーを全部買ってきて
検証、分析、そして・・・（パクリ？）
なんてのはしたいとは思いますけどね。
お金をくれるよりは、コーディングしてくれた方がうれしいんですがね。
それから、ソースコードを全部一般公開する事はたぶんありません。
公開じゃなくて、私と直接会ったことがある人なら問題ないです。
そういうわけで、オフ会でもします？

３月中に絶対にプロトタイプを作るので、期待してください。
ではまた。

＞お金をくれるよりは、コーディングしてくれた方がうれしいんですがね。

SourceForgeでＧＯだとおもうのは私だけ？

>私はあまり音楽を知らないので、市販のシーケンサーはあわないのでしょう。
>だから、プログラマー向けのシーケンサーを・・・ってところです。

太古の昔、ＭＭＬ＋ＦＭ音源の頃から、そういうのをつくった、とか
作りたいという話は聞くし、メディア系の怪しい論文にもこの手合いは
山ほど出てきます。

で、この手合い、全然役に立ったこと無いです。
Ｖｅｃｔｏｒにも、同様の主張で作られたツールがありますが、役に立ちません。

音楽を作りたいのであるなら、音楽ツールになれなさいと言うことかも。
実際、音楽の人が「もっと文字ばっかりではなくて・・・」と言い放つのを聞いたこ
とアリ。

郷に入っては郷に従え
と、音楽とプログラムを中途半端にできる人は、思ってるわけです。

＞際、音楽の人が「もっと文字ばっかりではなくて・・・」と

音楽の人がプログラミングに関して漏らした感想です。
音楽ソフトみたいな機能をどうして取り入れないのかと、ね。

461と462の日本語がよくわからないのだが、
もうちょっとわかりやすく書いてもらえんだろうか？

とりあえず郷ひろみファンであることは分かるな。

>>464
解説プリーズ

SourceForgeでＧＯだからじゃないのか

>>466
なるほど（ｗ

「プログラミングWindows」という本の下巻に
MIDIのAPIに関する解説が載ってます。
それぞれ５０００円くらいです。
それなりに新しい本だと思います。
タイマーの部分はマルチメディアタイマーになってました。

あげ

JDK1.3のjavax.sound.midiやjavax.sound.sampledを
使いこなせばJavaで簡単に作れそうだな。

>>470
あれは素人にはオススメできない。
安定したテンポで再生することすらできない罠。

こんなスレがあったとは・・・

MIDIプログラミングに関して詳しいサイト、何処かに無いかしら？

工房です。MIDIシーケンサ･･･以前作ろうかと企んで、
MIDI規格の解説のブックマークなどしていましたが、挫折しました。
MIDIのI/O、各種規格･音源の対応、UI、ファイルの読み書きなど、
かなり大変です。
>>1さんがんばってください(私の代わりに)。
でも>>1さんはもう見てないようですね。

そういえば、前N88BASICで
FM音源の作曲ソフトを作ったことがあったな。
そのときは完成させました。
今考えると、譜面全体を配列変数にしていたので
すごく効率が悪く遅かったんですが(演奏時MML生成に1、2分かかった)。

>>473 どうぞ。
B# MIDI
ttp://www.b-sharp.com/midi/index.html
MIDIの入出力
ttp://www.ne.jp/asahi/nagoya/ahomaro/builder/cpb-062.html
Aqua Beat Web VB Tips
ttp://www.aqube.pos.to/fly/vb/mm3.html など
自分で鳴らすMIDI講座
ttp://www.h2.dion.ne.jp/~myhobby/music/midi/midi.html
MIDIユーザとプログラマのためのMIDI講座
ttp://www.pluto.dti.ne.jp/~daiki/Midi/Midi.html

age

MidiTest.java
import java.io.File;
import javax.sound.midi.Sequencer;
import javax.sound.midi.Sequence;
import javax.sound.midi.MidiSystem;

public class MidiTest{
/**
* メイン<br>
* @param args[0] MIDIファイル名<br>
* @param args[1] テンポ倍率<br>
* <hr>
* <pre>
* usage: java MidiTest unko.mid 1
* unko.midを倍率x1で再生する。素人にはお勧めできない<hr>
* </pre>
*/
static void main(String args[]){
Sequencer sequencer;
try {
// Get default sequencer.
sequencer = MidiSystem.getSequencer();
if (sequencer == null) {
// Error -- sequencer device is not supported.
// Inform user and return...
} else {
// Acquire resources and make operational.
sequencer.open();
}
File myMidiFile = new File(args[0]);
// Construct a Sequence object, and
// load it into my sequencer.
Sequence mySeq = MidiSystem.getSequence(myMidiFile);
sequencer.setSequence(mySeq);
sequencer.setTempoFactor(Float.parseFloat(args[1]));
sequencer.start();
} catch (Exception e) {
// Handle error and/or return
}
}
}
さんぷるこぴぺそのまんま

これだけで、できるJAVAってすごいよな・・・

>>471

>>476
JAVAか…。
Win + JAVAで波形データって扱えるのかな？

>>479
再生するだけなら波形データも同じ様にできる。キャプチャーも簡単だけど。
midiデータの再生とかはSUNのJDKだとリズムが変なのですが、
IBMのJDKだと良いみたい。SUNのも味があって好いけど。(formatもあるのかね？）
今、Javaでお堅いアプリを作っていてタイトルが******* QUESTとかいう
名前なんでオープニングにドラクエのMIDIを鳴らして例のパースがついた
タイトルをパクッてギャグやろうと思ったけど、リズムはずしまくりで
いかにもアプリ自体にバグがありそうな雰囲気を醸し出すので止めました^^;

何が？

できたの？

おい、１がいつまでたってもつくらないから俺が作るぜ。
手伝えや。

俺は既に結構作り終えてる。
あとはGUIを作るだけ。
まあ､シーケンサーを作るってわけじゃなくて
自動作曲ソフトでも作ろうと思ってやってるんだけどね。

ちなみにここらの書き込みに若干影響を受けていなくもないな。

で、このスレのどこかで似たような意見が出てたと思うけど、
他の言語で機能を作成する事ってできるのかな？
たとえば、独自のクオンタイズをrubyで実装できるとかさ。
プロセス間通信するのが手っ取り早いと思うんだけど、他にあるかな？

483はどんなの作る予定？
ちなみに１は明らかに挫折しただろ（ｗ
まあ､学生？(高校生じゃないよな・・・）でそんなのが作れる奴も少ないだろうし、
また挑戦すればいいと思うよ。

>>484
modruby使え

おいてめえら奇遇ですね。俺もシーケンサ作りかけです。

未だに68のSTed2使ってるんだが、
今更Winの高い市販ソフト買うのもナニだし、
フリーソフトやシェアウェアには満足行くのが見つからんし、
WinでSTed2使うのも時代の流れに取り残されたオヤジみたいで嫌だし。

ノォーーーーー！ずれてる！
486ゲットしちまった！68ユーザとして許せん！

>>486-487
騙るな。
つーか調子に乗って487も取るな。
コプロも無いと我慢できなかったのか？

>>485
たまたまrubyの本をめくってたら
でてきたんですよね。
これも､少し面倒だけどありかもと・・・
ただ、まだ開発段階なようでして。
どちらにせよ、簡単さから言えばやはりプロセス間通信ですよね・・・

あ、ところでみさん再生終了時のノートオフイベント送出はどうする予定ですか？
(あるいは､どう実装しました？）
チャンネル毎に鳴ってるイベントを保持しておくのが無難ですかね。
良いやり方があれば教えてください。
GUI作り出してから気づいたので、データ構造は変えられないもんな・・・
というかデータフォーマットで何とかなる問題でもないだろうし。

オールノートオフぢゃ駄目なんすか？

なんで作る？
買えよ、YAMAHAのキーボード。
で、PC⇔キーボードを
制御するソフト作ったほうが
面白いと思うけどなー

キーボード買ってどうするんだ？

>オールノートオフぢゃ駄目なんすか？
１６＊ポート数msecの時間がかかるんだよね、それだと。
でも､それでいい気がしてきた。
コーディングするの面倒だし・・・
ただループ再生でのダメージがやっぱり大きいんだよな。
迷う。

>で、PC⇔キーボードを
>制御するソフト作ったほうが
>面白いと思うけどなー
どういソフトだよ？

>>489
当然再生位置(Tick値)はカウントしてるでしょう。
で、ノートオン送信時にstd::vectorなんかにノートオフの
予定Tick値/送信チャンネル/ノート番号の情報をpush_backしておいて、
そのTick位置が来たらベロシティ0（又は0x80イベント）で送信する、
とういうわけです。重複ノートオンの対応も忘れないでね

>>495
それって
>チャンネル毎に鳴ってるイベントを保持しておくのが無難ですかね。
と全く同じかも・・・

ついでにstd::vectorは遅いので注意です

>>496
最初は、
想定される最大ノートオンの数分(64くらい?)の静的テーブルを用意しておいて
MMコールバック毎に全レコードを先頭から舐める

という方法でやってたけど、オーバーヘッドが大きいので
可変長配列にしてみたら格段にCPU負荷が下がったんですけど...

あ、読み書きインデックスを使ったリングバッファという手もあったか。
もっと良い方法あったら教えてね

チャンネル毎に音が鳴ってるかどうかを示すフラグを立てておいて、
フラグがたっていれば、オールノートオフを送る。
これだけでいいと思うけど。

vector使うよりは
オブジェクトプーリングをしたlinkedlistを使ったほうがいいと思われる。
チャンネル毎のノート数がせいぜい６程度だと考えれば、
２分木にしても特に効果は無いと思うし。

>>491
YAMAHAのキーボード、高けぇんだもん。

500げとずざー

>>35の移転先知ってる人いないか？とか聞いてみたり

>>498
はキーボードに必ずシーケンサがついているものと思いこんでいるに249ペリカ

そもそも今時キーボードについてるシーケンサー使ってる人なんて
どれくらいいるのだ。

>はキーボードに必ずシーケンサがついているものと思いこんでいるに249ペリカ
そんな面白い事を言ってたのか（ｗ

>>503
PCに弱い人は結構使ってるかも？
PCに弱い人は打ち込まないか・・・

ファイル読み込み＆書き出しは出来た。
んで譜面ウィンドウ描きたいんだけどWinProgのことはわからん。
一応WinAPIだけで出来そうなんだけど他にｲｲ方法とかライブラリとかある?

WinProgって何？

Windowsでのプログラミングのことだろ。
譜面描画する程度ならGDIでいいじゃないか？

BCB使うのと楽チン

エクスクルーシブの後はランニングステータス使えないよね？

>>498
>チャンネル毎に音が鳴ってるかどうかを示すフラグを立てておいて、
>フラグがたっていれば、オールノートオフを送る。

１つのチャンネルに対して同時に和音を送信して、その和音それぞれの
音長(ノートオフのタイミング)が違う場合はどうすんの？

>>510
ノートオンとノートオフの数かぞえとけ

JavaとかC#とかVM環境（ネイティブコードじゃないやつ）でシーケンサーって作れるの？
精度とかどなん？

その辺、嫌な予感がするのでとりあえずC#は見送ってます。
大丈夫なら使いたいんだけどねー。

折れが工房の頃、USBに常駐してEMSに置いたSMFをBGMで演奏するTSRを
1024バイトで書いたのが異様に懐かしくて、つい読みふけってしまった（ｗ
>>262で話題に上ったunyaなんて涙モノ。FGALAV辺りに落ちていたんだよな。
レコポよりも1画面に表示されるノート数が多くて、UIのデザインもカッコ
良かった。よく落ちなければ最高のツールだったんだがな。

小一時間考えて、USBじゃなくてUMBだろうなと気が付いた。

その頃漏れは生まれたなかったりして・・・・

>>512
Javaにはこんなんがあるらしい。
例によって実装が追いついてない可能性が高いが。
http://java.sun.com/products/java-media/jmf/

>>515 UMBだUMB。Upper Memory Blockのことね。

8086では、seg:FFFFh, ofs:10h の場合には0hにアドレッシングされるが、
80286以降では10000hにアドレッシングされる。この仕様の相似を用いて、
それ以前のMS-DOSでは使っていなかったメモリ空間を有効活用しよう
というのがUMBですな。普通はlhでUMBに上げてやるのだが、不要な
PSPまでもが上げられるのが嫌で、MCBを辿って自力でUMBに上がる
プログラムを書いた気がする。

とか自己フォローしつつも、やっぱり恥ずい。鬱だ。

ってそりゃHMAだろ！と自己突っ込み。恥の上塗り鬱だ氏脳。
スレ違いｽﾏｿ

>>519
ﾜﾛﾀ

オールサウンドオフっていうのがあるぞ〜

オールサウンドオフは時間が掛かるぞ〜
ガイシュツだ。

なんで時間がかかるの？
メッセージひとつ送るだけだよ

>>523
メッセージひとつじゃなくて、16でしょ？

それから、1回オールサウンドオフを送出してから、次のメッセージを送るまで
最低何ミリ秒待ちなさいっていう断り書きが説明書に書いてない？

ついでに、オールサウンドオフは、リバーブもディレイも消えてしまうので、
音が途切れて気持ち悪い。それならば、オールノートオフの方がいいと
思うのだが、これだとホールドされている音が消えない。

>>511
ノートオフ送らないで次のノートオン送る場合にはどうするのさ？
小節をまたがった「タイ」ってこう表現することあるでしょ。ノートオンと
オフが帳尻合わないぞ。従って、各ch(0〜16)，各キー(0〜127)の
それぞれに発音中を示すフラグをつけておくのが正解。
ホールド状態の保存も忘れないようにな。

あ、そうか。
そうことか。

指摘どうもです。

俺も作ろうとしたけど、
複雑になりすぎて挫折した・・・

よーし、まずGUI以外のコンポーネント類完備しちゃうぞー。
今風にCppUnit使ってみたりとかしちゃうぞー。

CppUnitってなんか難しいってイメージがある。
具体的に何かは知らないけど。

>>486
よーしパパ、お前に期待しちゃうぞー。

譜面入力式のシーケンサ作っています。
というか、作ろうと思っています。
それで質問があるのですが、一つのトラックに複数のチャンネルが入っている
ファイルが存在するそうなのですが、そういった形式は許されている
のでしょうか？（形式上は可能ですが）
１トラックに１チャンネルということを前提に考えていたのですが、
こういう形式があると変換が面倒そうです。

midiの全機能を利用するアプリを書くつもりか？
どうせ、譜面入力なんだから制限掛けてもいいと思われ

全機能はとても無理だと思いますが、できるところまでやりたいと思っています。
私は、昔ローランドから出ていたBalladeというソフトをいまだに愛用しているのですが
なんせwindows3.1の頃のソフトですから、いろいろと不満もあって、
それで自分で似たのを作ろうと思っているんです。

ところでシーケンサー作っている人はソース公開をするんでしょうか？

フリーソフトにするかもわかんね。すまんち。
でも低レベル層とかプラグイン部くらいは、ねえ。

>>531
SMFフォーマット0のことかな。私の場合はファイル読み込み時に
別々のメモリ(トラック単位)に振り分けてますが

>>536
いえ、フォーマット１です。
たとえば、トラック１に0x90と0x91のステータスをもつイベントが
混在していたりする場合です。（チャンネル０と１の混在）
適当にダウンロードしてきたMIDIファイルのバイナリを見てみると
こういう仕様を持つシーケンサが存在するようなのです。

SMAFファイルの入出力に対応すれば今っぽいかも。
ttp://smaf.yamaha.co.jp/

今SMAF読み込みライブラリ作成中。
既にあるかもしれんが、勉強のため。

>>537
もしかしたら他フォーマットから変換されたファイルとか・・・？

何れにしろ、フォーマット0のデータもあるのでMIDIイベントの
先頭バイトについては 0x0Fでマスクして送信先のチャンネルを求め
た方が良いのでは

あと、SMF読み込み時の注意点を書いときます
　フォーマット0/1/(2)の対応
　分解能(TPQN)の変換
　0x51メタイベントのBPM変換
　MacBinaryのリソースフォーク読み飛ばし
　可変長表現値のデコード
　バイトオーダー変換(WinならBig→Little)
　ランニングステータス対応
など。

その辺はSMF読み出し用のライブラリ使ってるので大丈夫です。

せっかくだから、SMF周りのいいライブラリ教えてちょんまげ。

DirectMusic
・・・とか言ってみたりする。

読み込んで、それをそのままシリアライズすると
元と同じバイナリが得られる物ｷﾎﾞﾝ

DXFファイル対応汁！

DXF？ CADのやつ？

>>545はスレを間違えたのか、
それともファイルの種類を間違えたのか・・・・

SMFなんて対応する必要ないと思われr

>>548
じゃあ何に対応しろと(ase

分からないでもない。最近はオリジナル曲もMP3がふつーだし。

MMLって消えたの？

MMLからSMFに変換するんだろ。

>>549
ネイティブフォーマットでいいんじゃ？

MP３は関係ない。

おれもそーおもう。
CubaseVSTに流れたヘタレですが。

>>553
ネイティブフォーマットって何？

オリジナル曲もMP3で配布するのがふつーになってきたから
SMFでパブリッシュできてもあんまメリットがないと言いたかったのだが。

>>555
独自フォーマットやろ。Photoshopの.PSDとか。

>>551
うむ。消えた。

とか断言してみるテスト

>>551
>>557
着メロ制作者の中ではまだ使われてるよ。

着メロ製作者じゃなくて、
MIDI→着メロコンバーターを作ったやつが、
SMF対応がめんどうだったから、MML使ってるだけ。

レベルの高いやつは、着メロで音楽やりたいとは思わないだろ。

MMLはいままさにブームだよ
http://www.text2music.com

賞もらっちゃったよ(^-^

>>560
おまえが貰ったわけじゃないだろーが。
そもそも審査基準を考えてみろよ（ｗ

掲示板見たけど
やっぱMMLじゃ､ちゃんとしたの作れないね。

私の経験からすると、MMLで管理できるのはFM音源8音までですな。
それ以上になると作業効率が幾何級数的に低下していく。

って別にFM音源に限らないけど。
同時発音数8音までってことにしとこう。

MMLから読み込むルーチンを書くほうが楽というか、
SMFから読み込むのは大変。

>>564
そう？テキストファイルよりバイナリの方が全然楽だと思うが・・・

SMF読み込むだけならCで200〜250行あれば足りるよ。

もともと、リソースの貧弱な昔の機材を想定して作られたフォーマットだし。

>>68がMMLについて面白い事言ってる。
>MMLをXMLベースの規格にするなんでどうでしょう？

確かにXMLベースなら企業戦略やプラットフォームの違いも
影響しないし、パーサーを経由させればユーザはXMLの構文
なんか知らなくていいしね。まあ短所としては、
　ファイルサイズがデカくなる
　ファイルの読み書きが(SMFに比べ)遅くなる
　XMLパーサーが必要（パースロジックを内臓するなら要らないが）
ってとこか。

>>567の言うとおり、SMFは標準ぽいけどもう時代遅れな感じ。
SAMEメジャーやループもサポートしてないし、サポートしようとして
独自メタイベントを定義すると他シーケンサで正しく読めなっちゃう。

ごめん、
×読めなっちゃう
○読めなくなっちゃう
だ

>SMF読み込むだけならCで200〜250行あれば足りるよ。
そりゃ、短絡的な考えだ。
アプリのデータ構造に依存する。
エラー検出も仕込まなきゃいけないし。

XMLにする必要はない。
>企業戦略やプラットフォームの違いも
>影響しないし、パーサーを経由させればユーザはXMLの構文
>なんか知らなくていいしね。
SMFもプラットフォームの違いに影響されないし、
パーサーがあれば、アプリに組み込むだけで済む。
XMLがなんなのかよくわかってないの？

>そりゃ、短絡的な考えだ。

胃弱なので、そうつっかからんでくれい。
読み込むだけならとゆーとる。

まあﾏﾀｰﾘと卓球でもしようぜ。
( ´ー)ρ┳┻┳°σ（ー｀ )

　　　　デルタタイム０でエクスクルーシブ大量サ〜ブ！！
　　　 ￣￣￣￣￣￣￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣
。　　　　ﾟ 。 。　。　　　　ﾋﾞｼﾊﾞｼ
。(；´Д)ρ。　。┳┻┳°Σσ（ﾟДﾟ )
。 　　。。　。　　。
＿＿∧＿＿＿＿
　拾えねぇよ！！

(,,ノ ﾟдﾟ)ノ　彡 ┻━┻ 。ﾟ 。Σ（ﾟдﾟlll）

　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　|　 音源が�d�j･･･
　　＼＿　 ＿＿＿＿＿＿＿＿＿＿＿
　　　　　∨ 　　　 ＿＿__
　　　　　∧∧. 　 ||:::::::::::||
　　　　 （ 　 ；）―||:::::::::::||――――――
　　　　 /　　 つ二二ｌ ニｌ〜[ロ：三] ｼｰﾝ...
　　　|￣￣|__）,―――――――――
　　　`ー┬‐''
　　　　　┴

地味に面白いぞ畜生…畜生…

http://www.text2music.com/tools/sakura/mml_bbs3/bbs.cgi?mode=show&id=187
てめぇら、TextMusicサクラつかえばこんなすげー曲がつくれるんだぞ！！

>>577
age

これのどこがすごいんだと言ってみるテスト

MMLオヤジ必死だな（ｗ
とか煽ってみるテスト

>>579
君はさぞすごい曲を作れるんだろうねー、
うｐしてもろよ（ｗ

>577
別にMML使おうがシーケンサ使おうが
良い作曲家なら良い曲を作る

厨房筆を選ばず。

プロはいい機材を使いますが。

どうも昔からMML使いって、他の道具を試さずに固執する傾向があるな。

金が無いだけ

SMFリファレンス・ブック
編・著：新井 純
発行：エディロール株式会社
発売：リットーミュージック
制作協力：ローランド、新人社
ISBN 4-8456-0162-1
\2800+税

©を見ると９６年に出た本ですね。

インタフェース自体はIEEE1394を使う「mLAN」に移行することが予想されますので、既存のMIDIインタフェースに依存する設計は避けたほうがよろしいでしょう。
http://www.yamaha.co.jp/tech/1394mLAN/

----
あなたの老後にヤマハのサイレント大正琴をどうぞ。
http://www.yamaha.co.jp/product/taishogoto/cont03.html

てか、とっとと作れ

>>584
>>585
市販シーケンサのシンガーソングライターを２年使った後に
TextMusicサクラに以降しましたが？

>>589
以降→移行
MMLの方が自己満足できる。

>>590
同意。
MML実装すればいろいろ楽しめる。
どの携帯用にもコンパイルできるぜ！とか。

まあ、MMLで十分な曲しか打ち込んでないんなら特に止めはしないけど。

>どの携帯用にもコンパイルできるぜ！とか。
はぁ？

MMLの標準(共通)フォーマットみたいなものってある？

>>593
アフォにはわからんのだろ。

>>594
無い。
みゅあっぷ式とかMUSIC.COM式とかMML2mid式とか。

＞どの携帯用にもコンパイルできるぜ！とか。

俺も分からんので説明きぼん

どの携帯の着メロ(バイナリ)も生成できるってことじゃないか？

SMFからだって変換できるじゃん

昔はSMFみたいに共通フォーマットがなかったのだよ。

今の話してるんだろ＜着メロ

MMLてさ、
Music Macro Language って書いてあったり、
Music Markup Language って書いてあったりすんだけど、
どっちが正しいとかじゃなくて、今後どっちで呼びたい？＞MML擁護派

Macroで。
別にMarkup（装飾）してるワケじゃないからな
Makeupならわからんでもないが

＞Music Markup Language って書いてあったりすんだけど、

初めて見た。HTMLから来る誤認識じゃないの？

MMLをXMLでラップしようとする奴らはよく
Music Markup Language と呼んでる。

「『Macro』ではなく」と言ってるんで誤認識であない。

じゃ 2chに貼り付けられるテキスト形式の MMLを作りますか？

>>606
＞テキスト形式の MML
おーい・・・C4E4G4>>C4

それって共通の仕様って訳じゃないでしょ

それと、プリフィックスを決めて、２ｃｈビュアーで検出したら音が流せるようにとかしたら面白いかなと

>>608
いや、だからバイナリのMMLなんかあるんかいな？
みゅあっぷのコンパイル後はMMLじゃないだろうし。

> C4E4G4>>C4
なんで最後に２オクターブ飛ぶんだ。

>>610
意外性。

1は作るのやめたの？？

まあ、分かりきってたことだけどな。

ぴょげ

>>1-614
ﾈﾀ？

結構期待してたんだけど…
2chフォーマットのMMLとか面白そうだったのに。

>>616
それは同意。

見つかったら2chビューア側でハイパーリンクにしてくれてクリックすれば演奏。
応用すればISHデータが来たらそれをデコードする機能。
そしてwarezの巣窟化w

ISHって何だ？

vectorに行ってこい。
パソ通時代の遺品だ。

じゃあ知る必要ないな

MMLとかISHとか、obsoleteな技術ばっか出てくるなあ。
時代の波に取り残されたオヤジが揃ってるﾖｶﾝとか言ってみるﾃｽﾄ

>>621
スレ前半にもネイティブフォーマットは相対時間で書くとか言ってるオヤジが
いるし。

>>621
古いからと言って否定するあなたが素敵。

MMLが書いてあったらそこをデコードして音楽をならす。
良いアイディアだと思うがね。

テキストだけの掲示板という機能的限定の多いシステムでなんとか違うメディアのデータを扱いたい。
そこで、過去にあったMMLやISHと言うテキスト形式での各種データ記述方式に目を付けたわけだ。
これが実装されれば「歌う2ch」や「アップロード2ch（はどうかと思うが）」新たな分野が確立される。

まさに温故知新、いや、温故知産だと思うがね。

あなたはテキストベースのグラフィックなんて古くさいとAAを否定する勇気がありますか？と蛇足。

>>623
時代遅れオヤジ臭い上にウザイ
HTMLの意味わかってんのか？
リンク先を押せば、MP3だろうがなんだろうが鳴るんだよ。
究極のアフォのくせして、そんな事偉そうに書くなよ。

いきなり音が鳴ってもいいなら、アンカータグからリンク先とって来れるんだよ。
IMGタグが許されてれば、AAなんかもいらねーよ

で、シーケンサは出来たのですか

＞IMGタグが許されてれば、AAなんかもいらねーよ

良いこと言った。そう、2chはテキスト以外は許されていない。
そして、データをアップロードするには少なくとも別にデータを置くスペースがいる。
これはデータの寿命がログの寿命と一致しなくなる。
作曲自慢スレとかは致命的だ。ログに全く意味が無くなる。

では、この問題に対処するにはどうすれば良いか。
2ch側がログとともに責任持って対処する。
これが非現実的なのはわかるよね。
テキストだけでひぃひぃ言ってるのに画像や音楽なんて・・・。
もう一つはテキストの形で直接ログに書き込むこと。
この場合、データとログの寿命は完全に一致する。

>>624
表示形式はHTML
書き込み形式はテキスト

問題すり替えすぎ。ｗ

MMLみたいなファイルを埋め込むのはいいけど、
それを毎回ダウンロードする負荷は激しそうだ。

別サーバーに置いて必要な時だけとってくるに1票

ISHなんて言葉聞いたの５年ぶりくらいだ。

>作曲自慢スレとかは致命的だ。ログに全く意味が無くなる。

なにやら怪しげなソリューション提案する前に、楽器・作曲板やDTM板の現状を見てよ。
演奏や自作曲、音源などの評価にはもうmp3へのリンクを貼るのが普通。
標準MIDIファイルすら絶滅間際の気配。
MML関連スレも何回か立ったことがあるがすぐ消えた。

ていうか、MMLでのやりとりにそんなに需要あるなら既にバリバリ書きまくってるでしょ。
聞きたきゃコピペすればいいだけだし、
真のMMLerならMML見ただけで頭の中に音が流れるハズだ。

>>630
　キミの意見は判ったよ。　でもさ、それでもこっちも好きにさせてもらうよ

２CH用という事でストトン形式をベースにするのはどう？
http://www.csl.sony.co.jp/person/masui/Sutoton/

そして誰もついてこないままdat落ちする罠

DTM板からも応援してます！
頑張ってください！

おれも

しろうとなんでよく判らないのだが
ttp://www.text2music.com/tools/sakura/Help/dll.htm

このDLLに流し込むのが一番手軽なのではあるまいか？

>>635
あと、既出だけどStedのソースも使えないかなあ？
Cherryもソース公開してくれれば一番楽そう・・・

ﾆｯﾁ市場はいつも同じ運命か・・・・・

ついにプロトタイプ完成しました

みせてみせて

海外のサイトに投稿しました

そういえば、まだMIDIって流行ってるの？

見たいよ

>>641
従来の低サイズ、低負荷の音楽ではなく、手軽に多数の楽器を使用できるって方にシフトしてるかと。
後、携帯とかリソースの極端に少ない分野。

着メロ制作現場はPC-98 + レコンポーザでワラタ。
恐らく98のFM音源が目当てだろうね。

ﾎｼｭage

midiはマスタリング現場でまだまだ現役ですがなにか？

照明あやつるのにつかうよ俺は。

>442

age

MIDIｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
midiシーケンサじゃなくてmidiレコーダーならもっと簡単ですよね？

http://member.nifty.ne.jp/UDI/stack/makeSMF.hqx

とりあえずピアノロールだけとかイベントリストだけとか、
部品だけ作ってみるのはどうよ？
イベントリストっていうかステップエディタだけなら何度か
作ろうとしてみたんだけど、なんか飽きてやめてしまった。

MMLで十分

皆々様方、私はいまmidiシーケンサーに取り組んでいるところですが、
初歩的なところでつまずいているのでぜひ教えてください♪
それはmidiファイルに保存するとき、音色指定で、
32 の Guitar harmonics まではプレイヤーで聞いてみると音が出るのですが、
33 の Acoustic Bass 以降の音は出ないのですよ。
バイナリエディタで開いてみると、33 の Acoustic Bass 以降の音を指定した場合、
どうもプログラムチェンジがピッチベンドに変わって、それ以降のノートオンオフがメチャクチになっているみたいなんですよ…？
皆々様方、これは一体どういうことなのでしょうか？
どうして33 の Acoustic Bass 以降の音を指定すると、プログラムチェンジがピッチベンドに変わって、それ以降のノートオンオフがメチャクチになるのでしょうか？
ちなみに単にMidiOutShortMessageで音を鳴らすだけなら、32 の Guitar harmonics までも33 の Acoustic Bass 以降も同じように音が出るのですが…？
皆々様方、ぜひ教えてください！！

糞スレあげんなｳﾞｫｹ。

>>653
何をやってるのかがいまいち不明。
SMFを作ってるの？シーケンサを作ってるの？
SMFを作ってるんだったらスレ違い。

<<655
あなた様、自分はシーケンサを作ってるのよ。
市販のソフトには負けるけど、シェアよりは高性能なフリーソフトを目指してるのよ。
でも初歩的なとこでつまずいてるのよね〜。
あなた様、どうして33 の Acoustic Bass 以降の音を指定すると、プログラムチェンジがピッチベンドに変わって、それ以降のノートオンオフがメチャクチになるのでしょうか？
教えてね〜♪

目指すだけなら誰でも出来る。

>>657
保存と編集機能はだいたいできてるのよ。
ピアノの鍵盤を押すと、五線譜の画面に音譜が出て、それを削除したり新しい音譜と入れ替えたり、部分再生したりして保存するところまではうまくいってるのよ。
ただ肝心のmidiの理屈がわからなくてね…。
33 の Acoustic Bass 以降の音を指定すると、プログラムチェンジがピッチベンドに変わって、それ以降のノートオンオフがメチャクチになるかわからんのよ…。
それが解決したら、midiを読み込んで鳴らすのはもっと難しそうに予感がしているわけよ…。できるか心配だけど頑張るよ。

>>658
ていうかSMFの保存のルーチンは自分で作ってるの？
自分で作ってるんなら分からないことはないと思うんだけど。
プログラムチェンジは Cn、ピッチベンドは En。

>>658

お前はまずMIDIとSMFの仕様書をどこかから拾って来い。話はそれからだ。

なんかMIDIとMP3あたりを同列に扱ってるヤシがいるな。全然使い道が違うじゃん。

そもそもは電子楽器のインターフェースだろ。キーボードコントローラーと外部音源
モジュールとか。まあDTMは当初からのものだけどね。

MIDI = Musical Instruments Digital Interface

ついでに。

MIDIって、結局シリアル通信だから分解能で決定的に不利な点がある。
どんなにがんばっても、通信速度31.25kbps（だっけ？）の枠を破れない。
つまり、完全な同時発音というものはありえない、ということ。

あ、シンセのスペックにある同時発音数とは別の話だからね。そこんとこヨロシク。

だれかSPCシーケンサ作ってくれないかなあ

皆々様方〜、自分は先日ここで
「33 の Acoustic Bass 以降の音を指定すると、プログラムチェンジがピッチベンドに変わって、それ以降のノートオンオフがメチャクチになるかわからんのよ」
という質問を発しましたが、無事解決をばいたしましたので、ご報告をば申し上げます。
というもの皆々様方、自分はファイルに書き込むとき、プログラムチェンジのCnに楽器ナンバーを足した２バイト分をいっぺんに書き込んでいたのであります。
この足しかたがどうもうまくなかったみたいで、楽器ナンバーが１６ふえるごとにプログラムチェンジがチャンネルプレッシャーにかわり、
チャンネルプレッシャーがピッチベンドにかわりとなっていたのであります。
そこで自分は２バイトいっぺんに書き込むのをやめ、１バイトづつわけて書き込んだとたん、
ちゃんと音がでたというわけであります♪

>>662
＞MIDIって、結局シリアル通信だから分解能で決定的に不利な点がある。
シリアル通信は関係ない、パラレルでも速度が遅ければ一緒
それは分解能云々の理由ではない
知ったかしたいが為にいちいち用語を引っ張り出して失敗するのはヤメレ

＞どんなにがんばっても、通信速度31.25kbps（だっけ？）の枠を破れない。
とっくにMIDI機器がUSBに移行しているのに、いったいいつの時代の話をしているんだ？
＞あ、シンセのスペックにある同時発音数とは別の話だからね。そこんとこヨロシク。
別の話も何も同時発音数128音の音源を31kbpsで使っている馬鹿がどこにいるんだ？

↑知ったか２号ﾊｹｰﾝ

>>666
恥の上塗りかっこ悪い

最初から読んでみたけど、MBT方式とST/GT方式とどっちがいいわけ？
長所とか短所とかがあんまり語られてないからさ。

MBT方式の長所: イベントの絶対位置が一発で分かる
ST/GT方式の長所: ステップタイムの概念を使える

ってことで異論はないか？
ステップタイムが要らないならMBTでいいけど、
要るならST/GTを使うってことでいいのか？

頭を使えば一発でわかる事なんだが・・・
cubase,logic,sol,sonarはMBT

最近のコンピューターなら再計算は一瞬で終わる

>>669
再計算っていうのは、ステップタイムを変更したときに
それ以後の全イベントの絶対位置をずらす計算のこと？
CubaseもSONARもステップタイムって概念はなかったんだけど。

昔、ポケコンでMIDI送受信プログラムをアセンブラで作ったなぁ。10年以上前かな。
31.25Khzで制御すんだよね。スタートビットと、ストップビットの間に、データビット挟んで。
16chのシーケンサエンジン完成させた後、UI作る段階でめんどくさくなっちゃって。
データはいっつも、機械語モニタで入れてたという罠（ｗ

＞31.25Khz
周波数？

USARTなくても送信するときは　その周期で割り込みかけてポートをパタパタすればいいから
周波数と言えない事もない

>>672
今はKHzでは語らないのか？要は信号クロックってことだが。
ポケコンで制御してたころは、CPUクロックが768KHzとか、1.2MHzなんて世界だったから、
MIDI信号の各bitを立ててる時間は、CPUクロックで何サイクルなんて話し。
31.25KHzからサイクル数を算出してたよ。

UARTなんて無い頃の話し。朝まで生MIDI信号。
めんどくさかったけど、いろんな勉強ができたな。
ポケコン本体の外部ポートから、インピーダンス無視で(笑)リード線２本を
直接MIDI機器側に接続しても、音鳴るんだから。

>>670
いまどきステップタイムで入力したいと思う奴も少ないからな

>>674
でた〜昔は良かった原人
>今はKHzでは語らないのか？
わざとらしいんだよ。
言うわけねぇじゃないか。

どーせそれで鳴らした曲も
「さいた、さいた、ﾁｭｰﾘｯﾌﾟの花が〜」だろ(劇ﾜﾗ
それで返しは
「YMOですが何か」と言うんだろ(ﾊｹﾞﾌﾗ

>それで返しは
>「YMOですが何か」と言うんだろ(ﾊｹﾞﾌﾗ
なかなか、いい予想ですな。

>>676
何か嫌なことでもあったの？

>>678
よくあるただの燃料投下ﾈﾀだよ。
気にしなくていいよ。

不完全燃焼のヨカン(･∀･)

ﾘｱﾙﾄﾞｷｭｿって、行末によく
（ﾜﾗ　(劇ﾜﾗ　(ﾊｹﾞﾜﾗ
なんて付けるよね〜

皆々様方〜、MIDIシーケンサーつくっててまたいきずまってることが出てきたので、ひとつ教えてくださらぬか〜、皆々様方〜♪
それはMIDIシーケンサーの編集画面の中で「拍子」をいろいろ設定できるようにしたいわけよ。
「拍子」というのは、3/4拍子とか4/4拍子とかいうあれな。
だが、この「拍子」という概念がMIDI以前の音楽的にピンとこなくてな…。
3/4拍子が一小節の中に４分音譜が３個分で、4/4拍子が４分音譜が４個分ということくらいはわかるのだが…。
だがこの「小節」という概念もよくわからんのよ…。
たとえば4/4拍子の音楽だって４分音譜が３個分のところで区切って考えて3/4拍子というふうにこじつけても曲の出来自体は変わらんだろ？
だからそう考えると「拍子」とか「小節」というものにどういう意味があるのかわからんのよ…。
皆々様方はわかりますか？
またSMFのメッセージの中に「拍子」を表現するパラメータがあるかどうかさがしたんだけど、どうも見つからんのよ。
そもそもSMFには「拍子」や「小節」を表現するものが存在するのかどうか？
皆々様方〜MIDIシーケンサーで「拍子」を設定するようにするにはどうしたらいい？
編集画面の「小節」の区切りの長さを帰るだけでいいの？そうすると作成する曲には何の影響も与えないことになると思うけど…。
皆々様方〜、そこんとこの疑問を教えてください〜お願いします♪

もっと数値的に考えてもいいのでは。
拍子ってのは、概念だし。
分解能どのくらいなの？
粗めで、四分音符１個＝96クロックと考えると、
１小節は4/4で96x4だろ？
クロックと拍子を対応させるデータ構造にしてみれば？

>>675
> いまどきステップタイムで入力したいと思う奴も少ないからな

でも出来ないよりは出来た方がいいでしょ？

俺は、いまだにバリバリのステップ派ですが、何か？

>>682
小節の単位で強弱のパターンが変化すると考えては？
ロックのリズムでワルツは踊れん。

>>682
拍子も小節も、無いと分かりづらいよ。
文章を適当なところで改行してくれないと見づらいのと同じように。

>>686
小節の単位で強弱のパターンが変化するのですな？
つまり3/4拍子は強弱弱、4/4拍子は強弱弱弱という感じで？
もうひとつ疑問が、それは全音譜は四分音符４つぶんの長さなの？
それとも一小節分の長さなのですか？
一小節分の長さだとすれば拍子によって全音譜の長さは変わるわけ？
また四分音符４つぶんの長さだとすれば3/4拍子にした場合全音譜が次の小節にまたがることになるけどそれでいいわけ？
それから皆々様方〜、SMFに「小節」「拍子」を表現するメッセージがないとすれば、
ファイルを読み取るとき、書かれている曲が何拍子かを判断するにはどうしたらいい？
皆々様方〜ぜひ教えてください〜♪

愛知万博!!愛知万博!!
http://www.expo2005.or.jp/

この調子だと、プログラムが出来上がるまでに
あといくつ質問がくるんだろうか・・・

>>688
http://www.b-sharp.com/midi/spec1/smf007.html
拍子は当然定義されている。
小節は現在地と拍子から計算する。

というか君はMIDIはともかく中学〜高校程度の音楽を勉強した方がいい。

やっぱGUIがめんどいわー。
イベントリスト/ステップエディタに使えるグリッドを
だれか教えて/作ってやー。

>>592
ＧＵＩは得意中の得意よ。
エディタのグリッドなんて普通に描画したって簡単につくれるよ。
ただ画面がちらつくけどね…。

画面がちらつくのを我慢すれば普通に描画してできないエディタはないよ。

普通に描画すればエクセル以上の機能を持ったエディタだってつくれるよ。
ただ画面がものすごくちらついて実用性がないかもね。

12月号のCマガ予告に「MIDIプログラミング」があった。

また被害者が増えるのか。
いまどきMIDIを直接扱う必要なんて一般人にはないと思うけどな。

皆々様方〜また教えてくだされ〜♪
自分は現在リズム音に取り組んでいるのですよ。
ところがリズム音をmidiファイルに保存してそれを開いて聞いてみると、音が出ないんです。
自分はまたデータが変になってるんじゃないかと思ってバイナリエディタで開いて調べてみると、ちゃんとデータは間違いなく保存できてるんですよ。
それで何故音が出ないのでしょうか？
ちなみにこのファイルに普通の楽器音を追加してやると、前に保存したリズム音もちゃんと鳴り出すんですよ。
皆々様方〜、これは一体どういうことでしょうか？
何故、リズム音だけでは音が出ずに楽器音を追加してやると音が出るんでしょうか？
普通に考えるとリズム音だけでも音が出るはずで、自分はどこかにミスがあると思うのですが…？
皆々様方〜、自分はどこが間違っているのか教えてください〜！！お願いします！！

皆々様方〜、これ↓はリズム音だけで保存したファイルです。
これでは音が出ないんです。

[TRACK 1]
ChunkType: "MTrk"
Length: 31
000000 Program: Ch 1 Program 0
000000 NoteOn: Ch 10 Note 44 Vel 127
000016 NoteOff: Ch 10 Note 44 Vel 0
000016 NoteOn: Ch 10 Note 44 Vel 127
000032 NoteOff: Ch 10 Note 44 Vel 0
000032 NoteOn: Ch 10 Note 44 Vel 127
000048 NoteOff: Ch 10 Note 44 Vel 0
000048 EndOfTrack:

でもこの↓ように普通の楽器音を追加してやると音が鳴り出すんです。

[TRACK 1]
ChunkType: "MTrk"
Length: 39
000000 Program: Ch 1 Program 0
000000 NoteOn: Ch 10 Note 44 Vel 127
000016 NoteOff: Ch 10 Note 44 Vel 0
000016 NoteOn: Ch 10 Note 44 Vel 127
000032 NoteOff: Ch 10 Note 44 Vel 0
000032 NoteOn: Ch 10 Note 44 Vel 127
000048 NoteOff: Ch 10 Note 44 Vel 0
000048 NoteOn: Ch 10 Note 84 Vel 127
000064 NoteOff: Ch 10 Note 84 Vel 0
000064 EndOfTrack:

何故〜？教えてください、皆々様方〜！！