Parte 5 de uma série de artigos detalhando o protocolo MIDI.

Uma das três partes do protocolo MIDI é a especificação do formato de armazenamento de dados (lembre-se, as outras duas são o formato da mensagem e a especificação da interface de hardware). O formato da mensagem foi discutido nos três primeiros artigos da série, agora é a vez do formato de armazenamento. Foi proposto pela organização MMA no final de 1987 e foi denominado Arquivos MIDI Padrão (SMF).

O objetivo dos arquivos MIDI é permitir que eventos (ou seja, mensagens MIDI com registro de data e hora) sejam trocados entre vários dispositivos e programas. Antes do advento dos arquivos MIDI padrão, um arranjo preparado em um sequenciador não podia ser carregado em outro devido a incompatibilidades de formato. Isso não quer dizer que, com o advento do SMF, todos os fabricantes de sequenciadores mudaram para esse formato. Existem várias razões para isso, e também falaremos sobre elas hoje.

Uma vez que o armazenamento de informações está diretamente relacionado ao dispositivo dos sequenciadores, nos deteremos neste assunto com mais detalhes, mas apenas na medida em que for necessário para entender o SMF. E, sem dúvida, vamos dedicar um dos próximos artigos do ciclo aos sequenciadores.

Eventos
Uma mensagem MIDI com registro de data e hora é chamada evento... Diferentes unidades podem ser usadas para indicar marcações de tempo, pulsos internos, tempo no formato SMPTE, etc. É importante entender a diferença fundamental entre um evento e uma mensagem. A mensagem "vive" por uma fração de milissegundo de tempo real - desde o momento em que é gerada pela fonte até o momento em que é enviada ao receptor para execução. Ele pode ser detectado no processo de transmissão por um cabo MIDI na forma de um conjunto de pulsos. Um evento são alguns bytes de informação gravados na memória do dispositivo, com base nos quais uma mensagem será gerada no futuro, na hora marcada.

Por exemplo, o sequenciador pode armazenar um evento "escolha uma nota" com um carimbo de data / hora de 100 ms a partir do início da reprodução. Você pode editar este evento em duas dimensões: em primeiro lugar, altere os parâmetros da própria mensagem MIDI (neste caso, a afinação ou dinâmica da nota) e, em segundo lugar, mova a nota ao longo da faixa, ou seja, altere o tempo de execução da mensagem.

Os eventos aparecem na memória do sequenciador durante a gravação de mensagens MIDI. Quando você pressiona o botão Gravar, o sequenciador liga o gerador de pulso de hardware (tiques) e começa a "ouvir" a entrada MIDI especificada. Por exemplo, quando você pressiona uma tecla, a entrada recebe a mensagem "escolha uma nota". O sequenciador olha - aha, a mensagem chegou no vigésimo tique, e a grava na memória com um rótulo 20. Depois de alguns segundos, eles liberaram a tecla - a mensagem "remova a nota" veio, o gerador interno acenou alegremente 64 tiquetaques para o sequenciador naquele momento. O sequenciador salva uma mensagem com o rótulo 64. Agora estamos lidando com dois eventos - Note On e Note Off. O gerador de pulsos é ligado novamente durante a reprodução. Quando o 20º tique aparece, uma mensagem Note On é enviada para a saída MIDI do sequenciador, o 64º tique é um Note Off. Gravamos e depois reproduzimos as ações do artista!

Obviamente, o mesmo pode ser feito offline, ou seja, sem a necessidade de performance ao vivo. Clicando com o mouse no lugar certo da trilha (e tendo selecionado a duração da nota com antecedência), vamos construir na memória do sequenciador exatamente a imagem anterior.

Tipos de memória
Agora é a hora de aplicar dois termos de computador assustadores: memória primária e secundária. A memória primária (ou interna) é a memória do sequenciador onde as mensagens são gravadas e os eventos são armazenados durante toda a sessão. O conteúdo desta memória é apagado quando a alimentação é desligada. Esta interpretação é mais adequada para sequenciadores de hardware. Em sequenciadores de software, a memória primária é simplesmente a RAM do computador. Para armazenar o conteúdo da memória primária por um longo tempo, utiliza-se a memória secundária, ou seja, suportes de dados. Pode ser um disquete, disco rígido, cartão inteligente e assim por diante.

A quantidade de memória primária em sequenciadores de hardware e estações de trabalho (lembre-se, uma estação de trabalho é um gerador de tons e sequenciador em uma caixa) é geralmente expressa no número de notas armazenadas (por exemplo, 200 mil). Às vezes, o volume é expresso em eventos, neste caso você precisa estar em guarda - uma nota requer dois eventos para armazenar (pressionar e soltar uma tecla), e girar a roda de pitch ou aftertouch pode gerar até 100 ou mais eventos. Acontece que o tamanho da memória de um sequenciador é expresso em unidades nativas do computador - kilobytes. Mas isso também não é muito conveniente - um evento pode ocupar um número diferente de bytes (de cinco a várias dezenas).

Nos sequenciadores de software modernos, poucas pessoas se preocupam com a quantidade de memória primária - mesmo em uma máquina com 128 MB de RAM, você pode esquecer todas as restrições ao trabalhar com dados MIDI. Além disso, existem sequenciadores que podem reproduzir um arranjo diretamente do disco, sem carregá-lo na memória primária (e, aliás, gravá-lo também), o que geralmente apaga a distinção entre os dois tipos de memória.

Na memória secundária, os dados geralmente são gravados em um arquivo. A maioria dos sequenciadores tem seu próprio formato proprietário desse arquivo, o que torna difícil a troca de arranjos criados em diferentes dispositivos ou programas. Afirmou-se anteriormente que esta foi a principal razão para a criação do SMF.

Medição de tempo
Na verdade, não há "tiques" dentro do sequenciador. Há um temporizador de hardware que gera pulsos com frequência estritamente constante (por exemplo, a cada microssegundo). Forçar músicos a medir o tempo em microssegundos seria uma zombaria monstruosa, como, aliás, em outras unidades de tempo real (segundos, minutos). Os músicos estão acostumados a pensar em compassos e batidas, e expressar o tempo em unidades relativas (duração das notas), dependendo do andamento atual.

"Sem problemas", responderam os fabricantes, "deixe-os medir como for mais conveniente para eles." Apenas a unidade mínima de medida não terá cerca de 32 a duração, mas um tique convencional (a unidade é ainda menor, de modo que, por exemplo, um trigésimo segundo pode conter 48 tiques). Desde a era clássica, o ritmo era medido pelo número de quartos por minuto (BPM, batimentos por minuto), então eles decidiram tomar um quarto como a duração principal e indicar o número de tiques por trimestre - PPQN (Pulso por Nota semestral). Quanto maior o PPQN, melhor será a resolução do sequenciador e mais preciso no tempo ele pode capturar mensagens durante a gravação e enviá-las para a saída MIDI durante a reprodução. A maioria dos sequenciadores permite definir PPQN arbitrariamente - por exemplo, de 32 a 1536 ticks por trimestre (sequenciadores modernos - até 15.360 PPQN).

Um tique é uma unidade dependente da taxa: quanto mais rápida a taxa, menor o intervalo entre os tiques em unidades de tempo real. Esse intervalo pode ser encontrado pela fórmula da Fig. 1.

Por exemplo, a 120 BPM e 96 PPQN, os tiques ocorrerão a cada 5,208 milissegundos. Na mesma resolução e 180 BPM, o intervalo entre os tiques será reduzido para 3.472 ms. Como um sequenciador conta tiquetaques se seu cronômetro interno pulsa a cada microssegundo? É muito simples: com base no andamento atual e resolução em um quarto, exatamente de acordo com a fórmula especificada. Uma vez que um milissegundo contém 1000 microssegundos, no último exemplo, o sequenciador irá gerar outro tique ao receber 3472 pulsos do cronômetro.

A posição de um evento na linha do tempo é definida no sequenciador, geralmente no formato "barras: batidas: marcações", por exemplo, 22: 3: 152. Isto é: o vigésimo segundo compasso, o terceiro tempo, o 152º tique desde o início do terceiro tempo. Este princípio de tempo (o termo em inglês - Base de tempo) é chamado musical, porque é familiar e conveniente para músicos. Observe que você precisa saber a fórmula de compasso atual para trabalhar neste formato. Ou seja, quantas batidas o compasso contém e a que cada batida é igual.

Portanto, com uma fórmula de compasso 4/4, uma batida é igual a um quarto e um compasso contém quatro batidas. Na resolução de 384 PPQN, haverá 384 ticks em uma batida e 1536 ticks em cada tick (384 x 4). Em 6/8 e a mesma resolução, uma batida terá 192 ticks (um oitavo tem a metade do comprimento de um quarto), e um compasso terá seis batidas ou 1152 ticks (192 x 6). Assim, 22: 3: 152 no primeiro caso significa 35096 ticks desde o início da música (22 x 1536 + 3 x 384 + 152), e no segundo - 26072 ticks (22 x 1152 + 3 x 192 + 152) .

Portanto, para determinar a posição de um evento em unidades de tempo real com base no formato "barras: batidas: tiques", você precisa conhecer três parâmetros: o tempo atual, a fórmula de compasso e a resolução em tiques por trimestre (PPQN).

Existe outra possibilidade de temporização, quando a posição de um evento em uma trilha é expressa em unidades absolutas que não dependem do andamento, mais frequentemente no formato de hora SMPTE - "horas: minutos: segundos: quadros". Este princípio de temporização é denominado "baseado em código de tempo" (baseado em código de tempo, absoluto). A necessidade surge quando o sequenciador está trabalhando em conjunto com um gravador ou equipamento de filme / vídeo. É mais conveniente realizar operações de edição com filme, vídeo e material de áudio, especificando as posições de início e fim da gravação, estando vinculado a uma escala absoluta, e não a compassos e batidas.

Neste caso, a coordenada do evento na régua de tempo depende do tempo atual. Assim, com um tempo de 120 BPM, a primeira batida do segundo compasso pode ter um tempo SMPTE de 00: 00: 02: 00 e com um tempo de 60 BPM - 00: 00: 04: 00. Quando um evento é posicionado dentro de um quadro (entre segundos), sua coordenada também será diferente com um formato de quadro diferente (número de quadros por segundo). Você pode ler mais sobre SMPTE e MIDI Time Code no artigo anterior da série.

Quantidades de comprimento variável
Chega de digressões líricas, agora nossa tarefa é entender o formato de armazenamento de dados. E o primeiro desafio que os desenvolvedores SMF enfrentaram foi como manter o cronograma do evento.

Existem duas opções aqui: para armazenar para cada evento a hora desde o início da música, ou do último evento antes dela (no mesmo canal). Porém, a primeira opção não é racional, pois na maioria das vezes o intervalo entre os eventos é pequeno, eventos vizinhos possuem tempos de execução próximos entre si. Assim, em uma passagem de três notas, a primeira pode ter um tempo, digamos, 22: 3: 152, a segunda - 22: 3: 244, a terceira - 22: 3: 288. Para armazenar esses números (traduzidos em ticks desde o início da música), você precisa reservar pelo menos quatro bytes para cada um. Se você seguir pelo segundo caminho, então, em vez de três números grandes, você pode salvar um grande começando (22: 3: 152), e depois dele - dois pequenos, a diferença em marcações entre o primeiro e o segundo, e o segundo e terceira notas (neste caso, 92 e 44), um byte é suficiente para eles. Mesmo assim, o problema permanece: dependendo do evento, você precisa alocar um número diferente de bytes para economizar tempo.

Se o SMF estivesse sendo desenvolvido atualmente (e até mesmo pela Microsoft, que geralmente se preocupa pouco com o tamanho de seus arquivos e a memória necessária), este problema passaria despercebido. Alocamos um campo fixo para economizar tempo, digamos, 8 bytes por evento, e não sofremos. No entanto, em 1988, a memória primária (RAM) era muito cara, cada byte era contado e a secundária (mídia de disco) tinha um tamanho muito modesto. Portanto, os desenvolvedores SMF queriam obter o formato mais compacto possível.

Foi decidido manter tempo delta, ou seja, a diferença em ticks entre este evento e o anterior (ou o início da música). Por exemplo, se o primeiro evento - a batida da nota na primeira oitava - ocorreu no tempo de 40 ticks desde o início da música, então seu delta time será 40. Se após quatro ticks a nota F for tocada, então, seu tempo delta será 4. Se dois eventos ocorrerem simultaneamente, um deles terá um tempo delta igual a zero. Se o evento ocorrer exatamente no início da música, também terá um tempo delta zero. No entanto, o próximo evento pode acontecer em uma hora e meia (ou seja, em vários milhões de tiques). Como ser neste caso? Afinal, a memória precisa ser salva e não é desejável alocar um campo fixo de vários bytes para o tempo delta.

O assim chamado comprimentos variáveis... Eles fornecem uma maneira conveniente de escrever inteiros, do menor ao maior, sem ter que alocar um número fixo de bytes para o número. Os bits do número original são compactados em um ou mais bytes: cada byte possui sete bits (à direita, bits de 0 a 6). O bit mais significativo em um byte é o serviço; todos os bytes da série, exceto o último, devem conter um, o último - zero. Vários exemplos de embalagens são mostrados na Fig. 4

Por exemplo, você precisa empacotar o número 64 (hex 0x40) em um formato de comprimento variável. Na forma binária, este número é escrito como 0100 0000. Existem apenas sete bits significativos, portanto, este número é compactado em um byte sem alterações - 0100 0000 (é também o último byte da série), o bit mais significativo é 0 .

Agora o número é 128 (0x80). Na forma binária, é escrito como 1000 0000. Existem oito bits significativos, então nem tudo caberá em um byte, você precisa dividi-lo em dois. O primeiro byte deve ter um no bit mais significativo, o segundo (como o byte final da série) - zero. No segundo byte colocamos os sete bits menos significativos do número original, o resultado é 0 000 0000. Colocamos o bit (um) restante no lado direito do primeiro byte - obtemos 1000 0001. Como resultado, o número 0x80 é escrito como dois bytes: 0x81 0x00. Descompactar é muito simples. Não sabemos com antecedência quantos bytes existem na série. Lemos o primeiro byte - 1000 0001. O bit de serviço mais significativo (1) indica que este não é o último byte da série, há mais bytes. Descartamos a unidade de serviço, deixando sete bits - 000 0001. Lê o segundo byte - 0000 0000. O bit de serviço mais significativo (0) indica que este é o byte final da série (ou seja, há apenas dois bytes no Series). Nós descartamos o bit de serviço. Também há sete bits restantes - 000 0000. Adicionamos a eles sete bits alocados à esquerda do primeiro byte, obtemos 000 0001 000 0000. Descartando os primeiros seis zeros, obtemos o número necessário 1000 0000 (0x80).

Portanto, o método de comprimentos variáveis ​​permite que diferentes números de bytes sejam alocados para diferentes números: para números no intervalo de 0 a 127 - um byte, de 128 a 16383 - dois bytes, e assim por diante. O número máximo representado desta forma não é, em princípio, limitado. No entanto, no SMF, o comprimento do burst é limitado a quatro bytes (três com o conjunto de bits mais significativo e um terminando com um zero). Como resultado, o tempo delta máximo pode ser 0x0FFFFFFF (ou 268 435 455 ticks), que a uma taxa de 500 BPM e uma resolução de 96 PPQN é de cerca de quatro dias. Mais do que suficiente!

Na forma de valores de comprimento variável, o SMF indica não apenas o tempo delta, mas também a duração de alguns eventos.

Formato de arquivo de intercâmbio (IFF)
A estrutura do arquivo MIDI padrão é quase inteiramente derivada do IFF (Interchange File Format), desenvolvido em 1985 pela Electronic Arts. É um formato de armazenamento e troca de dados que facilitou a vida de usuários e desenvolvedores de software por quase vinte anos. A Electronic Arts não apenas forneceu documentação de código aberto, mas também o código-fonte C para ler e escrever arquivos IFF.

O formato IFF é compatível com versões anteriores e extensível. O primeiro significa que a nova versão do programa pode ler arquivos criados pela versão anterior sem problemas. Em segundo lugar, você não precisa inventar um novo formato para armazenar informações adicionais; basta inserir sua própria extensão no IFF. A estrutura do formato permite que programas de diferentes fabricantes troquem dados que não possuem acordos comerciais apropriados entre si. Tudo isso agrada os usuários - depois de salvar os dados no formato IFF, eles não ficam mais presos ao formato fechado de seu sistema e podem usar os dados em qualquer ambiente de software e hardware compatível com IFF.

Um arquivo IFF é uma coleção de dados organizados de forma que programas diferentes e não relacionados possam lê-los. Por outro lado, o programa pode armazenar informações específicas no IFF que são significativas apenas para ele. A estrutura IFF torna isso fácil. Outros programas que não sabem lidar com tais informações podem ignorá-las sem comprometer a leitura do conteúdo principal.

Existem vários tipos de arquivos IFF. Por exemplo, os arquivos ILBM e GIFF contêm informações gráficas, os arquivos SMUS contêm notação musical e os arquivos AIFF e WAVE contêm áudio digital.

Um arquivo IFF é composto de elementos semelhantes chamados chunks. Um bloco é uma estrutura de dados que consiste em um identificador alfabético (quatro caracteres ASCII), um tamanho de bloco (quatro bytes) e os próprios dados (Figura 5). É conveniente pensar em um bloco como um shell no qual os dados são "empacotados". Os dados em si podem conter qualquer coisa: gráficos, texto, animação, som, um conjunto de objetos 3D e assim por diante.

Os blocos no arquivo IFF podem ser aninhados, fig. 6. Na verdade, um arquivo IFF nada mais é do que um bloco de nível superior contendo um ou mais blocos dentro dele. Este princípio de armazenamento de dados permite que você "empacote" vários dados heterogêneos em um arquivo, incluindo vários arquivos IFF, que já se parecem com um sistema de arquivos dentro de um arquivo. É verdade que, com a organização de dados aninhados, há uma desvantagem - o arquivo se torna difícil de interpretar, para isolar blocos dele.

A maioria dos arquivos IFF contém um bloco de nível superior com o identificador "FORM". Inclui outros blocos (Fig. 7). Os únicos dados no bloco FORM são quatro bytes que descrevem o tipo de arquivo (por exemplo, "ILBM", Mapa de bits intercalados). Imediatamente atrás deles estão blocos aninhados como "BMHD" (cabeçalho da imagem), "CMAP" (paleta) e "BODY" (os próprios pixels). Os nomes dos blocos e o formato dos dados são inventados pelo desenvolvedor do tipo de arquivo específico. Outros programas, se encontrarem um bloco com um nome desconhecido, podem pulá-lo com segurança, guiados pelo campo que contém o comprimento do bloco.

Todos os dados numéricos em arquivos IFF são armazenados na ordem big-endian, ou seja, o byte mais significativo do número (MSB) é armazenado primeiro e, em seguida, o byte menos significativo. Veja a barra lateral para mais informações. Os blocos em um arquivo devem sempre começar com um byte par. Se o bloco anterior contiver um número ímpar de bytes, ele será preenchido com um byte nulo para ser par.

Estrutura SMF
Arquivos MIDI padrão, como arquivos IFF, são compostos de blocos. Existem dois tipos de blocos no total: Bloco do cabeçalho e Bloco da trilha. Pode haver apenas um bloco de cabeçalho e um ou mais blocos de trilha em um arquivo SMF. O bloco tem uma estrutura IFF típica: os primeiros quatro bytes são o identificador, os próximos quatro bytes são o comprimento do bloco em bytes, excluindo o tipo / comprimento de oito bytes. O identificador de bloco de cabeçalho tem quatro caracteres "MThd" e o identificador de bloco de trilha tem quatro caracteres "MTrk". Essa estrutura permitirá que novos tipos de bloco sejam definidos no futuro, e um bloco desconhecido pode ser facilmente ignorado com base em seu comprimento. A especificação SMF avisa: "Os programas devem ser preparados para ignorar blocos de tipos desconhecidos quando os encontrarem."

O bloco de cabeçalho contém informações gerais sobre o arquivo, o bloco de trilha contém o fluxo de mensagens MIDI com carimbos de data / hora. Além disso, o arquivo MIDI armazena informações adicionais necessárias para sequenciadores: tempo, fórmula de compasso, tonalidade, configurações do metrônomo e assim por diante. Essas informações não são transmitidas por meio da interface MIDI e os eventos que as formam são chamados de metaeventos.

Um arquivo MIDI sempre começa com um bloco de cabeçalho seguido por um ou mais blocos de trilha (Figura 9). Ou seja, qualquer arquivo MIDI padrão começa com as quatro letras "M", "T", "h", "d". Isso significa que o arquivo MIDI não está de acordo com a especificação IFF (que exige que todo arquivo compatível com IFF comece com um bloco de nível superior de um dos três tipos - "FORM", "CAT" ou "LIST"). Existem outras diferenças: os SMFs não podem conter blocos aninhados e o comprimento do bloco não precisa ser uniforme. No entanto, converter um SMF em um arquivo compatível com IFF é simples. Basta preencher os blocos de comprimento ímpar com um byte zero (se houver) e colocar todo o conteúdo no bloco FORM. Uma operação semelhante é usada no formato RMID proposto pela Microsoft (consulte a barra lateral).