Bagian 5 dari serangkaian artikel yang merinci protokol MIDI.

Salah satu dari tiga bagian protokol MIDI adalah spesifikasi format penyimpanan data (ingat, dua lainnya adalah format pesan dan spesifikasi antarmuka perangkat keras). Format pesan telah dibahas dalam tiga artikel pertama dari seri ini, sekarang saatnya untuk format penyimpanan. Itu diusulkan oleh organisasi MMA pada akhir 1987 dan diberi nama Standard MIDI Files (SMF).

Tujuan file MIDI adalah untuk memungkinkan peristiwa (yaitu, pesan MIDI yang dicap waktu) untuk dipertukarkan antara berbagai perangkat dan program. Sebelum munculnya file MIDI standar, pengaturan yang disiapkan dalam satu sequencer tidak dapat dimuat ke yang lain karena format yang tidak kompatibel. Ini bukan untuk mengatakan bahwa dengan munculnya SMF, semua produsen sequencer telah beralih ke format ini. Ada beberapa alasan untuk ini, dan kami juga akan membicarakannya hari ini.

Karena penyimpanan informasi terkait langsung dengan perangkat sequencer, kami akan membahas masalah ini secara lebih rinci, tetapi hanya sejauh yang diperlukan untuk memahami SMF. Dan, tidak diragukan lagi, kami akan mencurahkan salah satu artikel berikutnya dalam siklus untuk sequencer.

Acara
Pesan MIDI yang diberi cap waktu disebut peristiwa... Unit yang berbeda dapat digunakan untuk menunjukkan waktu - tick, pulsa internal, waktu dalam format SMPTE, dll. Penting untuk memahami perbedaan mendasar antara suatu peristiwa dan pesan. Pesan "hidup" selama sepersekian milidetik waktu nyata - dari saat dihasilkan oleh sumber hingga saat dikirim ke penerima untuk dieksekusi. Itu dapat ditangkap dalam proses transmisi melalui kabel MIDI dalam bentuk satu set pulsa. Suatu peristiwa adalah beberapa byte informasi yang direkam dalam memori perangkat, atas dasar yang pesan akan dihasilkan di masa depan, pada waktu yang ditentukan.

Misalnya, sequencer dapat menyimpan acara "pilih catatan" dengan stempel waktu 100 ms dari awal pemutaran. Anda dapat mengedit acara ini dalam dua dimensi: pertama, ubah parameter pesan MIDI itu sendiri (dalam hal ini, nada atau dinamika nada), dan kedua, pindahkan nada di sepanjang trek, yaitu, ubah waktu eksekusi dari pesan.

Peristiwa muncul di memori sequencer saat merekam pesan MIDI. Saat Anda menekan tombol Rekam, sequencer menyalakan generator pulsa perangkat keras (centang) dan mulai "mendengarkan" input MIDI yang ditentukan. Misalnya, saat Anda menekan tombol, input menerima pesan "pilih catatan". Sequencer terlihat - aha, pesan tiba di centang ke-20, dan menulisnya ke memori dengan label 20. Setelah beberapa detik, mereka melepaskan kuncinya - pesan "hapus catatan" datang, generator internal dengan senang hati melambai 64 kutu ke sequencer pada saat itu. Sequencer menyimpan pesan dengan label 64. Sekarang kita berurusan dengan dua event - Note On dan Note Off. Generator pulsa dihidupkan lagi selama pemutaran. Ketika tick ke-20 muncul, pesan Note On dikirim ke output MIDI sequencer, tick ke 64 adalah Note Off. Kami merekam dan kemudian memutar ulang aksi pemain!

Jelas, hal yang sama dapat dilakukan secara offline, yaitu tanpa perlu pertunjukan langsung. Dengan mengklik mouse di tempat yang tepat di trek (dan telah memilih durasi nada sebelumnya), kami akan membangun memori sequencer persis seperti gambar sebelumnya.

Jenis memori
Sekaranglah waktunya untuk menerapkan dua istilah komputer yang menakutkan: memori primer dan sekunder. Memori primer (atau internal) adalah memori sequencer tempat pesan direkam dan peristiwa disimpan di seluruh sesi. Isi memori ini dihapus saat daya dimatikan. Interpretasi ini lebih cocok untuk pengurutan perangkat keras. Dalam sequencer perangkat lunak, memori utama hanyalah RAM komputer. Untuk menyimpan isi memori utama dalam waktu yang lama, digunakan memori sekunder, atau dengan kata lain pembawa data. Ini bisa berupa floppy disk, hard drive, kartu pintar, dan sejenisnya.

Jumlah memori utama dalam sequencer perangkat keras dan workstation (ingat, workstation adalah generator nada dan sequencer dalam satu kotak) biasanya dinyatakan dalam jumlah catatan yang disimpan (misalnya, 200 ribu). Terkadang volume dinyatakan dalam peristiwa, dalam hal ini Anda harus waspada - satu nada memerlukan dua peristiwa untuk disimpan (menekan dan melepaskan kunci), dan memutar roda nada atau aftertouch dapat menghasilkan hingga 100 peristiwa atau lebih. Kebetulan ukuran memori sequencer dinyatakan dalam unit komputer asli - kilobyte. Tetapi ini juga sangat tidak nyaman - satu peristiwa dapat menempati jumlah byte yang berbeda (dari lima hingga beberapa puluh).

Dalam pengurutan perangkat lunak modern, hanya sedikit orang yang peduli dengan jumlah memori utama - bahkan pada mesin dengan RAM 128 MB, Anda dapat melupakan batasan apa pun saat bekerja dengan data MIDI. Selain itu, ada sequencer yang dapat memutar aransemen langsung dari disk, tanpa memuatnya ke memori utama (dan, omong-omong, merekamnya juga), yang biasanya menghapus perbedaan antara kedua jenis memori.

Dalam memori sekunder, data biasanya ditulis ke file. Sebagian besar sequencer memiliki format mereka sendiri untuk file ini, yang mempersulit pertukaran pengaturan yang dibuat di perangkat atau program yang berbeda. Disebutkan sebelumnya bahwa inilah alasan utama didirikannya SMF.

Pengukuran waktu
Faktanya, tidak ada "kutu" di dalam sequencer. Ada pengatur waktu perangkat keras yang menghasilkan pulsa dengan frekuensi yang sangat konstan (misalnya, setiap mikrodetik). Memaksa musisi untuk mengukur waktu dalam mikrodetik akan menjadi ejekan yang mengerikan, seperti halnya, dalam satuan waktu nyata lainnya (detik, menit). Musisi terbiasa berpikir dalam bar dan ketukan, dan mengekspresikan waktu dalam satuan relatif (durasi nada), tergantung pada tempo saat ini.

"Tidak masalah," jawab pabrikan, "biarkan mereka mengukurnya karena lebih nyaman bagi mereka." Hanya unit pengukuran minimum yang tidak akan menjadi durasi ke-32, tetapi tick yang diambil secara konvensional (unit ini bahkan lebih kecil, sehingga, misalnya, satu tiga puluh detik dapat berisi 48 tick). Sejak zaman klasik, tempo diukur dengan jumlah seperempat per menit (BPM, denyut per menit), maka mereka memutuskan untuk mengambil seperempat sebagai durasi utama dan menunjukkan jumlah ticks per quarter - PPQN (Pulse Per Seperempat not). Semakin besar PPQN, semakin baik resolusi sequencer dan semakin akurat dalam waktu menangkap pesan selama perekaman dan output ke output MIDI selama pemutaran. Sebagian besar sequencer memungkinkan Anda untuk mengatur PPQN secara sewenang-wenang - misalnya, dari 32 hingga 1536 tick per kuartal (sequencer modern - hingga 15360 PPQN).

Kutu adalah unit yang bergantung pada laju: semakin cepat laju, semakin pendek interval antara kutu dalam satuan waktu nyata. Interval ini dapat ditemukan dengan rumus pada Gambar. satu.

Misalnya, pada 120 BPM dan 96 PPQN, kutu akan mengikuti setiap 5,208 milidetik. Pada resolusi yang sama dan 180 BPM, interval antar tick akan dikurangi menjadi 3,472 ms. Bagaimana cara sequencer menghitung kutu jika timer internalnya berdenyut setiap mikrodetik? Ini sangat sederhana: berdasarkan tempo dan resolusi saat ini dalam seperempat, persis sesuai dengan rumus yang ditentukan. Karena satu milidetik berisi 1000 mikrodetik, dalam contoh terakhir sequencer akan menghasilkan centang lain ketika menerima 3472 pulsa dari timer.

Posisi suatu peristiwa pada timeline diatur dalam sequencer, biasanya dalam format "bar: beats: ticks", misalnya 22: 3: 152. Yaitu: birama ke dua puluh dua, ketukan ketiga, ketukan ke-152 dari awal ketukan ketiga. Prinsip pengaturan waktu ini (istilah bahasa Inggris - Timebase) disebut musikal, karena akrab dan nyaman bagi musisi. Harap dicatat bahwa Anda perlu mengetahui tanda waktu saat ini untuk bekerja dalam format ini. Artinya, berapa banyak ketukan yang terkandung dalam pengukur dan apa yang sama dengan setiap ketukan.

Jadi, dengan tanda waktu 4/4, satu ketukan sama dengan seperempat, dan satu nada berisi empat ketukan. Pada resolusi 384 PPQN, akan ada 384 tick dalam satu ketukan, dan akan ada 1536 tick dalam setiap tick (384 x 4). Pada 6/8 dan resolusi yang sama, satu ketukan akan menjadi 192 tick (seperdelapan adalah setengah dari seperempat), dan satu ketukan akan memiliki enam ketukan atau 1152 tick (192 x 6). Jadi, 22: 3: 152 dalam kasus pertama berarti 35096 tick dari awal lagu (22 x 1536 + 3 x 384 + 152), dan dalam kasus kedua - 26072 tick (22 x 1152 + 3 x 192 + 152) .

Jadi, untuk menentukan posisi suatu peristiwa dalam satuan waktu nyata berdasarkan format "bar: beats: ticks", Anda perlu mengetahui tiga parameter: tempo saat ini, tanda waktu, dan resolusi dalam ticks per quarter (PPQN).

Ada kemungkinan pengaturan waktu lain, ketika posisi suatu peristiwa di trek dinyatakan dalam satuan absolut yang tidak bergantung pada tempo, paling sering dalam format waktu SMPTE - "jam: menit: detik: bingkai". Prinsip pengaturan waktu ini disebut "berbasis kode waktu" (timecode-based, absolute). Kebutuhan itu muncul ketika sequencer bekerja sama dengan tape recorder atau peralatan film / video. Operasi pengeditan dengan materi film, video dan audio, menentukan posisi awal dan akhir rekaman lebih nyaman untuk dilakukan, diikat ke skala absolut, dan bukan pada ukuran dan ketukan.

Dalam hal ini, koordinat acara pada penggaris waktu tergantung pada tempo saat ini. Jadi dengan tempo 120 BPM, ketukan pertama dari ukuran kedua dapat memiliki waktu SMPTE 00: 00: 02:00, dan dengan tempo 60 BPM - 00: 00: 04: 00. Ketika suatu peristiwa diposisikan dalam sebuah bingkai (antara detik), koordinatnya juga akan berbeda dengan format bingkai yang berbeda (jumlah bingkai per detik). Anda dapat membaca lebih lanjut tentang Kode Waktu SMPTE dan MIDI di artikel seri sebelumnya.

Jumlah panjang variabel
Cukup penyimpangan liris, sekarang tugas kita adalah memahami format penyimpanan data. Dan tantangan pertama yang dihadapi developer SMF adalah bagaimana menjaga waktu event.

Ada dua opsi di sini: untuk menyimpan untuk setiap acara waktu dari awal lagu, atau dari acara terakhir sebelumnya (pada saluran yang sama). Namun, opsi pertama tidak rasional, karena paling sering interval antara peristiwa kecil, peristiwa tetangga memiliki waktu eksekusi yang dekat satu sama lain. Jadi, dalam bagian tiga nada, yang pertama dapat memiliki waktu, katakanlah, 22: 3: 152, yang kedua - 22: 3: 244, yang ketiga - 22: 3: 288. Untuk menyimpan angka-angka ini (diterjemahkan ke dalam tanda centang dari awal lagu), Anda perlu memesan setidaknya empat byte untuk masing-masing. Jika Anda mengikuti jalur kedua, maka alih-alih tiga angka besar, Anda dapat menyimpan satu awal yang besar (22: 3: 152), dan setelah itu - dua yang kecil, perbedaan kutu antara yang pertama dan kedua, dan yang kedua dan catatan ketiga (dalam hal ini, 92 dan 44), satu byte sudah cukup untuk mereka. Tapi tetap saja, masalahnya tetap: tergantung pada acaranya, Anda perlu mengalokasikan jumlah byte yang berbeda untuk menghemat waktu.

Jika SMF sedang dikembangkan saat ini (dan bahkan oleh Microsoft, yang umumnya tidak terlalu peduli dengan ukuran file dan memori yang dibutuhkan), masalah ini akan ditutup-tutupi. Kami mengalokasikan bidang tetap untuk menghemat waktu, katakanlah, 8 byte per peristiwa, dan tidak menderita. Namun, pada tahun 1988, memori primer (RAM) sangat mahal, setiap byte dihitung, dan sekunder (media disk) memiliki ukuran yang sangat sederhana. Oleh karena itu, pengembang SMF ingin mendapatkan format yang paling ringkas.

Diputuskan untuk tetap waktu delta, yaitu, perbedaan tanda centang antara acara ini dan yang sebelumnya (atau awal lagu). Misalnya, jika peristiwa pertama - pemukulan not ke oktaf pertama - terjadi pada waktu 40 tik dari awal lagu, maka waktu deltanya adalah 40. Jika setelah empat tik not F dimainkan, maka waktu deltanya adalah 4. Jika dua peristiwa terjadi secara bersamaan, maka salah satunya diberi waktu delta sama dengan nol. Jika peristiwa itu terjadi tepat di awal lagu, ia juga memiliki waktu delta nol. Namun, peristiwa berikutnya dapat terjadi dalam satu setengah jam (yaitu, dalam beberapa juta tick). Bagaimana menjadi dalam kasus ini? Bagaimanapun, memori perlu disimpan, dan tidak diinginkan untuk mengalokasikan bidang tetap beberapa byte untuk waktu delta.

Disebut panjang variabel... Mereka menyediakan cara yang nyaman untuk menulis bilangan bulat, dari terkecil ke terbesar, tanpa harus mengalokasikan sejumlah byte tetap untuk nomor tersebut. Bit dari nomor asli dikemas menjadi satu atau lebih byte: setiap byte memiliki tujuh bit (di sebelah kanan, bit 0 sampai 6). Bit paling signifikan dalam satu byte adalah layanan; semua byte dalam seri, kecuali yang terakhir, harus berisi satu, yang terakhir - nol. Beberapa contoh kemasan ditunjukkan pada Gambar. 4.

Misalnya, Anda perlu mengemas nomor 64 (hex 0x40) ke dalam format panjang variabel. Dalam bentuk biner, angka ini ditulis sebagai 0100 0000. Hanya ada tujuh bit signifikan, jadi angka ini dikemas menjadi satu byte tanpa perubahan - 0100 0000 (juga merupakan byte terakhir dari rangkaian), bit paling signifikan adalah 0 .

Sekarang jumlahnya 128 (0x80). Dalam bentuk biner, ditulis 1000 0000. Ada delapan bit signifikan, jadi semuanya tidak akan muat menjadi satu byte, Anda harus membaginya menjadi dua. Byte pertama harus memiliki satu di bit paling signifikan, yang kedua (sebagai byte pengakhiran seri) - nol. Pada byte kedua kami menempatkan tujuh bit paling tidak signifikan dari angka aslinya, ternyata 0 000 0000. Kami menempatkan satu bit yang tersisa (satu) di sisi kanan byte pertama - kami mendapatkan 1000 0001. Akibatnya, angka 0x80 ditulis sebagai dua byte: 0x81 0x00. Membongkar sangat sederhana. Kami tidak tahu sebelumnya berapa banyak byte dalam seri. Kami membaca byte pertama - 1000 0001. Bit layanan paling signifikan (1) menunjukkan bahwa ini bukan byte terakhir dari seri, ada lebih banyak byte. Kami membuang unit layanan, meninggalkan tujuh bit - 000 0001. Baca byte kedua - 0000 0000. Bit layanan paling signifikan (0) menunjukkan bahwa ini adalah byte terakhir dari seri (yaitu, hanya ada dua byte dalam seri). Kami membuang bit layanan. Ada juga tujuh bit yang tersisa - 000 0000. Kami menambahkannya di sebelah kiri tujuh bit yang dialokasikan dari byte pertama, kami mendapatkan 000 0000 000 0000. Membuang enam nol pertama, kami mendapatkan angka yang diperlukan 1000 0000 (0x80).

Jadi, metode panjang variabel memungkinkan jumlah byte yang berbeda dialokasikan untuk angka yang berbeda: untuk angka dalam kisaran dari 0 hingga 127 - satu byte, dari 128 hingga 16383 - dua byte, dan seterusnya. Jumlah maksimum yang diwakili dengan cara ini, pada prinsipnya, tidak terbatas. Namun, dalam SMF, panjang burst dibatasi hingga empat byte (tiga dengan set bit paling signifikan dan satu berakhir dengan nol). Akibatnya, waktu delta maksimum dapat menjadi 0x0FFFFFFF (atau 268 435 455 tick), yang pada kecepatan 500 BPM dan resolusi 96 PPQN adalah sekitar empat hari. Lebih dari cukup!

Dalam bentuk nilai panjang variabel, SMF menunjukkan tidak hanya waktu delta, tetapi juga panjang beberapa peristiwa.

Format File Pertukaran (IFF)
Struktur file MIDI standar hampir seluruhnya berasal dari IFF (Interchange File Format), yang dikembangkan pada tahun 1985 oleh Electronic Arts. Ini adalah penyimpanan data dan format pertukaran yang telah membuat hidup lebih mudah bagi pengguna dan pengembang perangkat lunak selama hampir dua puluh tahun. Electronic Arts tidak hanya menyediakan dokumentasi open source, tetapi juga kode sumber C untuk membaca dan menulis file IFF.

Format IFF kompatibel ke belakang dan dapat diperluas. Yang pertama berarti bahwa versi baru program dapat membaca file yang dibuat oleh versi sebelumnya tanpa masalah. Kedua, Anda tidak perlu menemukan format baru untuk menyimpan informasi tambahan, cukup memasukkan ekstensi Anda sendiri ke dalam IFF. Struktur format memungkinkan program dari produsen yang berbeda untuk bertukar data yang tidak memiliki perjanjian bisnis yang sesuai di antara mereka sendiri. Semua ini menyenangkan pengguna - setelah menyimpan data dalam format IFF, mereka tidak lagi dirantai ke format tertutup sistem mereka dan dapat menggunakan data dalam perangkat lunak dan lingkungan perangkat keras yang kompatibel dengan IFF.

File IFF adalah kumpulan data yang diatur sedemikian rupa sehingga program yang berbeda dan tidak terkait dapat membacanya. Di sisi lain, program dapat menyimpan informasi spesifik dalam IFF yang hanya berarti bagi dirinya sendiri. Struktur IFF membuatnya mudah. Program lain yang tidak tahu bagaimana menangani informasi tersebut dapat mengabaikannya tanpa mengorbankan pembacaan konten utama.

Ada beberapa jenis file IFF. Misalnya, file ILBM dan GIFF berisi informasi grafik, file SMUS berisi notasi musik, dan file AIFF dan WAVE berisi audio digital.

File IFF terdiri dari elemen serupa yang disebut potongan. Blok adalah struktur data yang terdiri dari pengenal alfabet (empat karakter ASCII), ukuran blok (empat byte), dan data itu sendiri (Gambar 5). Lebih mudah untuk menganggap blok sebagai shell di mana data "dibungkus". Data itu sendiri dapat berisi apa saja: grafik, teks, animasi, suara, kumpulan objek 3D, dan sebagainya.

Blok dalam file IFF dapat disarangkan, gbr. 6. Faktanya, file IFF tidak lebih dari blok tingkat atas yang berisi satu atau lebih blok lain di dalamnya. Prinsip penyimpanan data ini memungkinkan Anda untuk "membungkus" beberapa data heterogen ke dalam file, termasuk beberapa file IFF, yang sudah menyerupai sistem file di dalam file. Benar, dengan organisasi data bersarang, ada satu kelemahan - file menjadi sulit untuk ditafsirkan, untuk mengisolasi blok darinya.

Sebagian besar file IFF berisi blok tingkat atas dengan pengenal "FORM". Ini termasuk blok lain (Gbr. 7). Satu-satunya data di blok FORM adalah empat byte yang menjelaskan jenis file (misalnya "ILBM", InterLeaved Bit Map). Tepat di belakangnya adalah blok bersarang seperti "BMHD" (tajuk gambar), "CMAP" (palet), dan "BODY" (piksel itu sendiri). Nama-nama blok dan format data ditemukan oleh pengembang jenis file tertentu. Program lain, jika mereka menemukan blok dengan nama yang tidak dikenal, dapat dengan aman melewatinya, dipandu oleh bidang yang berisi panjang blok.

Semua data numerik dalam file IFF disimpan dalam urutan big-endian, yaitu byte paling signifikan dari angka (MSB) disimpan terlebih dahulu, kemudian byte paling tidak signifikan. Lihat bilah sisi untuk lebih lanjut tentang ini. Blok dalam file harus selalu dimulai dengan byte genap. Jika blok sebelumnya berisi jumlah byte ganjil, blok tersebut diisi dengan byte nol untuk menjadi genap.

struktur SMF
File MIDI standar, seperti file IFF, terdiri dari Potongan. Ada dua jenis potongan total: Header Chunk dan Track Chunk. Hanya ada satu blok header dan satu atau lebih blok trek dalam file SMF. Blok memiliki struktur IFF yang khas: empat byte pertama adalah pengidentifikasi, empat byte berikutnya adalah panjang blok dalam byte, tidak termasuk jenis/panjang delapan byte. Pengidentifikasi blok header adalah empat karakter "MThd", dan pengidentifikasi blok trek adalah empat karakter "MTrk". Struktur ini akan memungkinkan jenis blok baru untuk didefinisikan di masa depan, dan blok yang tidak dikenal dapat dengan mudah diabaikan berdasarkan panjangnya. Spesifikasi SMF memperingatkan: "Program harus siap untuk mengabaikan blok dari tipe yang tidak diketahui ketika mereka menemukannya."

Blok header berisi informasi umum tentang file, blok track berisi aliran pesan MIDI dengan cap waktu. Selain itu, file MIDI menyimpan informasi tambahan yang diperlukan untuk sequencer: tempo, tanda waktu, kunci, pengaturan metronom, dan sejenisnya. Informasi ini tidak ditransmisikan melalui antarmuka MIDI, dan peristiwa yang membentuknya disebut peristiwa meta.

File MIDI selalu dimulai dengan blok header diikuti oleh satu atau lebih blok track (Gambar 9). Artinya, setiap file MIDI standar dimulai dengan empat huruf "M", "T", "h", "d". Ini berarti bahwa file MIDI tidak sesuai dengan spesifikasi IFF (yang mengharuskan setiap file yang sesuai dengan IFF dimulai dengan blok tingkat atas dari salah satu dari tiga jenis - "FORM", "CAT" atau "LIST"). Ada perbedaan lain: SMF tidak dapat berisi blok bersarang, dan panjang blok tidak harus genap. Namun, mengonversi SMF ke file yang sesuai dengan IFF sangatlah mudah. Cukup dengan mengisi blok dengan panjang ganjil dengan byte nol (jika ada) dan meletakkan semua konten di blok FORMULIR. Operasi serupa digunakan dalam format RMID yang diusulkan oleh Microsoft (lihat bilah sisi).