00000531

UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CINCIA DA COMPUTAO

ANLISE E PROJETO DE UM SOFTWARE SEQENCIADOR MIDI

Trabalho de concluso de curso submetido Universidade do Estado de Santa Catarina como parte dos requisitos para a obteno do grau de Bacharel em

Cincia da Computao.

Joinville SC

2006

UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CINCIA DA COMPUTAO

Tadeu Rodrigo Becker Gois


Trabalho de concluso de curso submetido Universidade do Estado de Santa Catarina como parte dos requisitos para a obteno do grau de Bacharel em

Cincia da Computao.

verlin Fighera Costa Marques

Joinville, Dezembro de 2006.


Tadeu Rodrigo Becker Gois

Este Trabalho de Concluso de Curso foi julgado adequado para a obteno do ttulo de Bacharel em Cincia da Computao e aprovada em sua forma final pelo Curso de Cincia da Computao do CCT/UDESC.

Banca Examinadora

_______________________________

verlin Fighera Costa Marques, M Sc.

________________________________

Dbora Cabral Nazario, M Sc.

________________________________

Isabela Gasparini, M Sc.

________________________________

Salvador Antonio dos Santos, M Sc.

I

RESUMO

Este trabalho descreve a anlise e projeto de um novo software seqenciador MIDI que trabalhe com a informao musical codificada para pesquisa. Todo o projeto documentado seguindo a metodologia de desenvolvimento de software do RUP, abordando as suas fases iniciais. Em cada documento apresentada uma breve descrio de como obt-lo de acordo com a metodologia abordada. Alm disso, este trabalho tambm apresenta um breve estudo de teoria musical, padro MIDI e das principais caractersticas de um software seqenciador MIDI.

Palavras-chave: Seqenciador MIDI, Anlise e Projeto de Sistemas, Engenharia de Software.

II

ABSTRACT

This monograph describes the analysis and project of new MIDI Sequencer Software that works with music information codify to search. All the project documented following the RUP software development methodology, approaching his initials phases. At each document is showed a short description of how to get it with the methodology. Besides, this monograph also presents a brief of music theory, MIDI standard and the mainly features of MIDI sequencer software.

Key-words: MIDI Sequencer, Analysis and Project of Systems, Software Engineering.

III

LISTA DE FIGURAS

Figura 2.1 Pauta Musical .......................................................................................11 Figura 3.6a Conexo MIDI instrumento-instrumento (RATTON, 1997b). ..............22 Figura 3.6b Conexo MIDI instrumento-computador (RATTON, 1997b)...............23 Figura 4.3.1a Notation View, Winjammer (SEQUENCER, 2006) ..........................28 Figura 4.3.1b Notation View com um evento selecionado (SEQUENCER, 2006).29 Figura 4.3.2 Mixer Winjammer, (SEQUENCER, 2006).........................................29 Figura 4.3.3 Song View, Winjammer (SEQUENCER, 2006) ................................30 Figura 4.3.4 Piando Roll (Sonnar, Cakewalk)........................................................30 Figura 4.3.5 Track View , Winjammer (SEQUENCER, 2006)................................31 Figura 4.3.6 Event View (Sonnar, Cakewalk) ........................................................32 Figura 4.3.7 Controller View, Winjammer (SEQUENCER, 2006) ..........................32 Figura 4.4.1a Notas tocadas (PINTO, 2000) .........................................................33 Figura 4.4.1b Notas no Event List (PINTO, 2000).................................................33 Figura 4.4.2 Channel Pres. No Event List (PINTO, 2000) .....................................34 Figura 4.4.3 Progam Change no Event List (PINTO, 2000)...................................35 Figura 4.4.4 Control Change no Event List (PINTO, 2000)....................................35 Figura 4.4.5 Pitch Wheel no Event List (PINTO, 2000) .........................................36 Figura 5.1 As fases e os marcos de um projeto RUP (RUP, 2003).......................39 Figura 6.2.1 Casos de Uso....................................................................................73 Figura 6.2.2 Conceitos. .........................................................................................74 Figura 7.1 Casos de Uso expandidos....................................................................82 Figura 7.2a Diagrama de Seqncia gravar trilha MIDI.........................................84 Figura 7.2b Diagrama de Seqncia gravar trilha udio. ......................................84 Figura 7.2c Diagrama de Seqncia editar trilha. .................................................85

IV

LISTA DE TABELAS

Tabela 3.3 Comandos MIDI (PINTO, 2000). ..........................................................16 Tabela 3.5a Valores de Balance (RATTON, 1996b) ..............................................20 Tabela 3.5b Valores de Pan (RATTON, 1996b) ....................................................20 Tabela 3.7 Os 128 instrumentos musicais e efeitos sonoros do MIDI ...................24 Tabela 6.1.2a Levantamento de requisitos (WAZLAWICK, 2004) .........................52 Tabela 6.1.2b Requisito funcional 1 e requisitos no-funcionais. ..........................54 Tabela 6.1.2c Requisito funcional 2 e requisitos no-funcionais. ..........................55 Tabela 6.1.2d Requisito funcional 3 e requisitos no-funcionais. ..........................56 Tabela 6.1.2e Requisito funcional 4 e requisitos no-funcionais. ..........................57 Tabela 6.1.2f Requisito funcional 5 e requisitos no-funcionais. ...........................58 Tabela 6.1.2g Requisito funcional 6 e requisitos no-funcionais. ..........................59 Tabela 6.1.2h Requisito funcional 7 e requisitos no-funcionais. ..........................60 Tabela 6.1.2i Requisito funcional 8 e requisitos no-funcionais. ...........................61 Tabela 6.1.2j Requisito funcional 9 e requisitos no-funcionais. ...........................62 Tabela 6.1.2k Requisito funcional 10 e requisitos no-funcionais. ........................63 Tabela 6.1.2l Requisito funcional 11 e requisitos no-funcionais. .........................64 Tabela 6.1.2m Requisito funcional 12 e requisitos no-funcionais. .......................65 Tabela 6.1.2n Requisito funcional 13 e requisitos no-funcionais. ........................66 Tabela 6.1.2o Requisito funcional 14 e requisitos no-funcionais. ........................67 Tabela 6.1.2p Requisito funcional 15 e requisitos no-funcionais. ........................68 Tabela 6.1.2q Requisito funcional 16 e requisitos no-funcionais. ........................69 Tabela 6.1.2r Requisito funcional 17 e requisitos no-funcionais. .........................70 Tabela 6.1.2s Requisitos suplementares. ..............................................................71 Tabela 6.2.1 Descrio dos Casos de Uso............................................................73 Tabela 6.2.2a Listagem de Conceitos e Operaes de Manuteno (WAZLAWICK, 2004) .........................................................................................................................74 Tabela 6.2.2b Listagem dos conceitos...................................................................75 Tabela 6.2.3 Listagem de Consultas......................................................................75 Tabela 7.1a Expanso do caso de uso Gravar Msica..........................................78 Tabela 7.1b Expanso do de caso uso Editar Msica. ..........................................80 Tabela 7.4a Contrato cadastraMusica ...................................................................87 Tabela 7.4b Contrato alteraMusica........................................................................88 Tabela 7.4c Contrato excluiMusica........................................................................88 Tabela 7.4d Contrato consultaMusica....................................................................88 Tabela 7.4e Contrato listaMusicas.........................................................................89 Tabela 7.4f Contrato gravarMensagem .................................................................89 Tabela 7.4g Contrato salvarTrilha..........................................................................89 Tabela 7.4h Contrato gravarAudio.........................................................................90 Tabela 7.4i Contrato alteraTrilha ...........................................................................90 Tabela 7.6a Caso de Uso Real Gravar msica......................................................95 Tabela 7.6b Caso de Uso Real Editar msica. ......................................................96

V

LISTA DE ABREVIATURAS E SIGLAS

MER Modelo Entidade Relacionamento. MIDI Musical Instrument Digital Interface. SQL - Structured Query Language. RUP Rational Unified Process. SGBD Sistema Gerenciador de Banco de Dados. UML Unified Modeling Language.

6

SUMRIO

Resumo ............................................................................................................... I Abstract .............................................................................................................. II Lista de Figuras................................................................................................. III Lista de Tabelas ................................................................................................ IV Lista de Abreviaturas e Siglas ............................................................................V 1. Introduo ................................................................................................... 8 2. Msica....................................................................................................... 10

2.1. Conceitos Bsicos ............................................................................. 10 2.2. Computer Music................................................................................. 11

3. MIDI........................................................................................................... 12 3.1. Definio............................................................................................ 12 3.2. Tipos de Mensagens MIDI ................................................................. 13

3.2.1. Mensagens que dependem de canal MIDI.................................. 13 3.2.2. Mensagens que no dependem de Canal MIDI.......................... 14 3.2.3. Mensagens transparentes ......................................................... 15

3.3. Tabela com os Comandos MIDI ........................................................ 15 3.4. Status Byte e Data Byte..................................................................... 16 3.5. Control Change.................................................................................. 17 3.6. Conexes MIDI .................................................................................. 22 3.7. Os Canais de MIDI............................................................................. 23 3.8. Msica e Cincia da Computao ..................................................... 25

4. Software Seqenciador MIDI .................................................................... 26 4.1. Trilhas................................................................................................ 27 4.2. Portas MIDI........................................................................................ 27 4.3. Caractersticas Principais .................................................................. 28

4.3.1. Notation View.............................................................................. 28 4.3.2. Mixer ........................................................................................... 29 4.3.3. Song View................................................................................... 30 4.3.4. Piano View e Piano Roll.............................................................. 30 4.3.5. Track View .................................................................................. 31 4.3.6. Event View.................................................................................. 31 4.3.7. Controller View............................................................................ 32

4.4. Exemplo Prtico................................................................................. 32 4.4.1. Notas .......................................................................................... 32 4.4.2. Channel Pres. ............................................................................. 34 4.4.3. Progam Change.......................................................................... 34 4.4.4. Control Change........................................................................... 35 4.4.5. Pitch Wheel................................................................................. 35

4.5. Estado da Arte ................................................................................... 36 5. Metodologia de Desenvolvimento RUP..................................................... 38

5.1. Conceito............................................................................................. 38 5.2. Fase de Iniciao ou Concepo....................................................... 40 5.3. Fase de Elaborao........................................................................... 42 5.4. Fase de Construo........................................................................... 44 5.5. Fase de Transio ............................................................................. 46 5.6. Definio das Tarefas e Atividades ................................................... 48

6. Concepo ................................................................................................ 50 6.1. Levantamento de Requisitos ............................................................. 50

7

6.1.1. Viso Geral do Sistema .............................................................. 50 Software Seqenciador MIDI (Viso Geral do Sistema) ........................ 50

6.1.2. Requisitos ................................................................................... 51 6.2. Organizao dos Requisitos .............................................................. 72

6.2.1. Organizao dos Requisitos em Casos de Uso.......................... 72 6.2.2. Organizao dos Requisitos em Funo de Conceitos .............. 74 6.2.3. Organizao dos Requisitos em Consultas ................................ 75

6.3. Marco dos Objetivos de Ciclo de Vida ............................................... 76 7. Elaborao ................................................................................................ 77

7.1. Expanso dos Casos de Uso............................................................. 77 7.2. Operaes e Consultas de Sistema................................................... 82 7.3. Modelagem Conceitual ...................................................................... 85 7.4. Contratos ........................................................................................... 87 7.5. Projeto da Camada de Domnio......................................................... 90 7.6. Projeto da Camada de Interface ........................................................ 92 7.7. Projeto da Camada de Persistncia................................................... 96

8. Concluso ................................................................................................. 99 Referncias .................................................................................................... 101 Anexo 1 .......................................................................................................... 103

8

1. INTRODUO Com o advento da informtica e a difuso dos micro-

computadores, muitas tarefas antes realizadas manualmente hoje so realizadas com o auxlio de um software de computador.

No universo musical no diferente. Msicos profissionais que trabalham arduamente com a partitura nas composies de jingles, trilhas para novelas e cinema, ou at mesmo para uma nova cano, deparam muitas vezes com desafios inerentes. Alm de pesquisar qual estilo musical, ritmo, escala a ser usada, toda essa documentao representada atravs de partituras. O software seqenciador MIDI surgiu com esta facilidade para o msico. Nele possvel passar a msica diretamente do instrumento para o computador, e do computador para o instrumento, e assim, pode-se editar, alterar, corrigir a msica, grav-la em vrias trilhas e gerar a partitura entre outras funcionalidades j existentes nos softwares atuais.

A Cincia da Computao na busca de melhores e mais inovadas solues para os usurios vm em busca de mais uma. Segundo o trabalho realizado por SCHROEDER (2005), que foi o estudo do padro MIDI e o comparativo de softwares seqenciador MIDI existente no mercado, apontou que existem softwares muito bons atualmente, mas todos com basicamente as mesmas funcionalidades para o msico, mudando apenas a forma de apresentao, sua interface e alguns outros recursos de um software para outro, tais como mais efeitos numa trilha, entre outros. Mas todos estes recursos levantados nesta pesquisa no foram to relevantes a ponto de SCHROEDER (2005) apontar algumas necessidades que seriam muito interessantes que um software seqenciador MIDI tivesse. Estas necessidades so a busca da informao MIDI propriamente dita e a quantizao mais inteligente. Este ltimo, um grande problema nos seqenciadores atuais. Outra melhoria interessante seria uma interface mais intuitiva e usvel ao profissional da msica, que nem sempre um usurio avanado em computao e encontra algumas dificuldades para trabalhar com todas as ferramentas contidas no software seqenciador MIDI.

9

Com o objetivo de criar um seqenciador com essas caractersticas no encontradas, este trabalho descreve a anlise e projeto deste software. Inicia-se no captulo 2 com um breve estudo definindo tecnicamente o que msica, som, suas caractersticas, sua representao atravs de smbolos numa pauta musical, e finaliza o captulo com a apresentao e definio do conceito de computer music conforme (RATTON, 1998b).

No terceiro captulo realizado um estudo do padro MIDI, discriminando os tipos de mensagens, os comandos e canais MIDI, e de que maneira realizada a conexo.

O software seqenciador MIDI o tema central do captulo 4. Mostra-se o que so trilhas e as caractersticas principais de um seqenciador MIDI encontrado hoje em dia. Um exemplo prtico apresentado, mostrando a maneira que ele trabalha para uma seqncia de mensagens MIDI. Finalizando este captulo, faz-se a proposta do novo software seqenciador MIDI que foi definida segundo as necessidades levantadas por (SCHROEDER, 2005).

No captulo 5 apresentada a metodologia de desenvolvimento de software usada neste trabalho, o RUP. Sua conceituao e todas as fases que ele comporta, finalizando com a definio das tarefas e atividades deste trabalho.

Todas as atividades incumbidas concepo do software esto descritas no capitulo 6. Ou seja, o levantamento dos requisitos e a organizao dos requisitos em casos de uso, conceitos e consultas.

No captulo 7 contm a fase de elaborao do software. Subdividida nas subfases de anlise, onde esta a expanso dos casos de uso, a anlise de operaes e consultas de sistema, modelagem conceitual e o contrato de operaes e consultas de sistema. E na subfase de projeto, que contem o projeto da camada de domnio, interface e persistncia.

10

2. MSICA

2.1. Conceitos Bsicos

De acordo com MED (1996), msica a arte de combinar os sons simultnea e sucessivamente, com ordem, equilbrio e proporo dentro do tempo. Formada pela melodia que o conjunto de sons dispostos em ordem sucessiva (concepo horizontal da msica), a harmonia que o conjunto de sons dispostos em ordem simultnea (concepo vertical da msica), o contraponto que o conjunto de melodias dispostas em ordem simultnea (concepo ao mesmo tempo horizontal e vertical da msica) e o ritmo que a ordem e proporo em que esto dispostos os sons que constituem a melodia e a harmonia.

O som a sensao produzida no ouvido pelas vibraes de corpos elsticos. Uma vibrao pe em movimento o ar na forma de ondas sonoras que se propagam em todas as direes simultaneamente. As vibraes podem ser regulares e irregulares. A vibrao regular produz sons de altura definida, chamados sons musicais ou notas musicais, por exemplo, o som do piano, do violino, etc. A vibrao irregular produz sons de altura indefinida, chamados de barulhos, por exemplo, som do avio, de automvel, de uma exploso, etc. Na msica so usados tanto os sons regulares (instrumentos musicais como notas definidas), como os sons irregulares (instrumentos de percusso) (MED, 1996).

As principais caractersticas do som so: a altura que determinada pela freqncia das vibraes, isto , da sua velocidade, quanto maior for a velocidade da vibrao, mais agudo ser o som. A durao que a extenso de um som, determinada pelo tempo de emisso das vibraes. A intensidade que a amplitude das vibraes, determinada pela fora ou pelo volume do agende que o produz, portanto, o grau de volume sonoro. E o timbre que a combinao de vibraes determinadas pela espcie do agende que os produz. O timbre a cor do som de cada instrumento ou voz, derivado da intensidade dos sons harmnicos que acompanham os sons principais. Todo e qualquer som musical tem, simultaneamente, as quatro propriedades (MED, 1996).

11

A notao musical so os sinais que representam a escrita musical, tais como, pauta (Figura 2.1), claves, notas, etc.

Figura 2.1 Pauta Musical

Na escrita musical as propriedades do som so representadas pela altura que a posio da nota no pentagrama1 e pela clave2. A alternncia de notas de alturas diferentes resulta em melodia. A simultaneidade de sons de alturas diferentes resulta em acordes, que so a base da harmonia; a durao representada pela figura da nota e pelo andamento. A alternncia de notas de duraes diferentes resulta em ritmo; Intensidade representada pelos sinais de dinmica. A alternncia de notas de intensidades diferentes resulta em dinmica; O timbre pela indicao da voz e instrumento que deve executar a msica. A alternncia e a combinao de timbres diferentes resulta em instrumentao (MED, 1996).

2.2. Computer Music

RATTON (1998b), define computer music como "informtica musical", isto , no a msica que computadorizada, mas na realidade so os recursos do computador (e da informtica como um todo) que so aplicados para a criao, manipulao, execuo e reproduo da msica. Ou seja, todo o universo tecnolgico vinculado ao computador (e informtica em geral) que dispomos para fazer nossa arte, a msica.

Mas o uso do computador s se tornou verdadeiramente intensivo a partir da dcada de 80, por duas razes: o barateamento e conseqente popularizao dos microcomputadores, e o advento do MIDI (RATTON, 1998b).

__________________

1 Pentagrama ou Pauta Musical a disposio de cinco linhas paralelas horizontais e quatro

espaos intermedirios, onde se escrevem as notas musicais (MED, 1996). 2 Clave um sinal colocado no inicio da pauta que da seu nome nota escrita em sua linha

(MED, 1996).

Clave

Notas

12

3. MIDI

3.1. Definio

A notao musical atravs da pauta musical e seus smbolos como claves, notas, entre outros, permitem que a msica seja descrita e representada de uma maneira simblica. Com base nesta representao, o padro MIDI (Musical Instrument Digital Interface) usa tcnicas similares s pautas musicais e define como codificar todos os elementos musicais.

MIDI um sistema de transmisso digital de informaes voltado para aplicaes musicais. Criado a partir de um acordo entre fabricantes de instrumentos musicais eletrnicos japoneses e americanos, permitiu a interconexo de instrumentos musicais eletrnicos, e tornou realidade a automao musical pelo computador atravs do uso de seqenciadores e inmera outros aplicativos de controle (RATTON, 2005).

Pode-se dizer que o MIDI uma maneira computacional de representao do som. Pois o MIDI no transmite udio, apenas mensagens que comandam aparelhos que sejam capazes de entend-las.

O sistema MIDI usa digitais (bits e bytes), levando informaes que dizem respeito a execuo musical, como notas musicais, volume, acionamento de pedais, troca de timbres, etc (na verdade, h tambm algumas outras informaes no-musicais, como configuraes de equipamentos de estdio, por exemplo) RATTON (1998b). Os arquivos MIDI so muito compactos. Um arquivo MIDI pode ser 1000 vezes menor que um arquivo CD udio. Alm disso, a representao MIDI modificvel.

Por outro lado, o padro, apesar de fixo em seu carter bsico, vem tendo vrias adies ao longo dos anos, fazendo-o cada vez mais abrangente e capaz de lidar com as mais diversas caractersticas de instrumentos que venham a implementar MIDI, de simples teclados at sistemas de iluminao, passando pela indstria cinematogrfica, alm dos mais modernos controladores musicais, muitos at mesmo sem teclado (PINTO, 2000).

13

3.2. Tipos de Mensagens MIDI

3.2.1. Mensagens que dependem de canal MIDI

So as mensagens que, quando enviadas, afetam apenas o canal MIDI selecionado. De acordo com PINTO (2000), so elas:

Note On comando para tocar uma determinada nota, com uma determinada velocidade velocidade, que na prtica significa intensidade.

Note Off comando para desligar a nota que est sendo tocada. Tambm h dentro do comando a velocidade de desligamento da nota, mas poucos teclados a usam, e so mais raros os seqenciadores que deixam que manipulemos estes dados. Muito comum, porm, usar o comando Note On com velocidade zero para desligar a nota. Por qu? Para economizar alguns bytes, num processo chamado running status.

Aftertouch - um comando que disparamos ao colocarmos presso na tecla em que tocamos. Note que, para cada tecla pode ser colocada uma presso diferente, gerando, portanto, mensagens diferentes.

Control Change comandos que podem controlar diversas partes do teclado, como o volume (control 7) e o pedal de sustain (control 64). Basicamente, h 128 comandos para serem usados, sem contar algumas combinaes por exemplo, o Control 0 e Control 32 em conjunto formam, poderamos dizer, um Control 129. por causa dessa enorme possibilidade de combinaes de controles que o padro MIDI no ficou obsoleto.

Program Change (patch) o comando que muda de um timbre para outro. Este comando tem um alcance de, no mximo, 128 timbres.

Channel Pressure Outra forma de Aftertouch, mas que monofnica, isto , atua indistintamente para todas as notas do teclado. Por ser mais barato de se construir, a forma de aftertouch mais comum nos teclados mais baratos, e tambm nos que tm peso, isto , imitam a ao do piano acstico.

14

Pitch Wheel uma mensagem especfica para a rodinha que normalmente est do lado esquerdo do teclado e muda a sua afinao.

3.2.2. Mensagens que no dependem de Canal MIDI

Estas mensagens tm mais relao com o contexto em que esse instrumento deve ser tocado, ou seja, elas so utilizadas para o MIDI tocar o instrumento. De acordo com PINTO (2000) so:

System Exclusive Muitas vezes quer-se mandar outro tipo de informao ao instrumento mudar a velocidade do vibrato, ou mesmo mandar um timbre inteiramente novo que pegamos na Internet e no havia no teclado neste caso usada uma mensagem system exclusive, que transmite essas e outras informaes mais exotricas. A nica coisa que uma mensagem exclusive tem em comum com outra so os bytes de comeo e fim. Elas podem ter qualquer tamanho. Praticamente todo o aparelho MIDI tem seu cdigo exclusive, e, como uma impresso digital, nico para cada modelo de instrumento. Desta forma, no h chance de uma mensagem destinada a um instrumento ser interpretada por outro. Exclusive pode ser acessado normalmente por um computador, mas por assumir formas to diversas de aparelho para aparelho, uma das mensagens mais difceis de se dominar.

Existem algumas mensagens exclusive que no so to exclusivas assim, pois a maioria dos instrumentos atuais responde a elas, e so estas:

GM System Enable/Disable Um comando exclusive que pe o instrumento receptor no modo GM.

Master Volume No confundir com a mensagem control change, que controla o volume de cada canal MIDI. Este controla o volume global do instrumento, com todos os seus canais de uma vez.

15

3.2.3. Mensagens transparentes

So mensagens que normalmente no so manipuladas pelo msico, mas que existem para controle de diversos sistemas PINTO (2000):

MIDI Clock mensagem usada para que dois sequencers andem no mesmo andamento. Basicamente, h 24 delas para cada semnima. Numa msica de andamento constante, elas iro aparecendo tambm a uma velocidade constante. Mas num ralentando, por exemplo, elas iro ter um espaamento maior entre uma e outra. A maior desvantagem dessa mensagem , depois de gravar uma msica com sincronismo baseado em MIDI Clock, qualquer alterao de andamento ser impossvel. Hoje em dia, ela quase no mais usada, em favor de outra mensagem.

MIDI Time Code mensagem que carrega em si o tempo absoluto da msica. Isto quer dizer que ela vai aparecendo a intervalos regulares, independente do andamento da msica. A sua grande vantagem que, se quisermos mudar este andamento depois, ela no atrapalhar em nada, pois estava apenas marcando o tempo, e o sequencer poder se mover livremente por cima dessa marcao. Seu uso mais comum em conjunto com o padro SMPTE, de sincronismo de vdeo.

Song Position Pointer Quando tem-se dois sequencers funcionando juntos por exemplo, um computador e uma bateria eletrnica com o ritmo programado internamente, essa mensagem faz com que, ao tocar-se uma msica no meio dela no sequencer mestre, o outro comece a tocar sua parte no mesmo compasso daquele.

3.3. Tabela com os Comandos MIDI

Na terceira coluna da tabela 3.3 esto todos os comandos MIDI existentes. A quarta coluna mostra quantos bytes compem cada comando (cada < > representa um byte) (PINTO 2000).

16

Tabela 3.3 Comandos MIDI (PINTO, 2000). Note On Note Off Poly Key Pressure

Channel Pressure Program Change Control Change

Voice

Pitch Bend Change

Local Control (off/on)

All Notes Off Omni Mode Off Omni Mode On Mono Mode On

CHANNEL

Mode

Poly Mode On Song Position Pointer 242>

Sont Select Tune Request

Common

EOX Timing Clock Start Stop Continue Active Sensing

Real Time

System Reset

SYSTEM

System exclusive messages ***

3.4. Status Byte e Data Byte

Todas as mensagens MIDI s tm dois tipos de bytes: o status e o data.

Numa mensagem MIDI, o primeiro byte sempre distingue qual a mensagem que est sendo transmitida, e os demais levam os valores desta mensagem. Este primeiro byte o chamado status byte. Ele sempre maior que 127. Ou seja, o primeiro bit sempre "1". Com isso, tem-se que todo byte de mensagem (Data byte) menor que 127, ou seja, o primeiro bit "0" (PINTO, 2000).

17

Status Bytes (MSB 1XXXXXXX) -> isto , o nmero maior que 127 (Em outras palavras, pode ser um nmero entre 128 at 255). Lembrando que 10000000 em binrio o equivalente a 128 em decimal.

Data Byte (MSB 0XXXXXXX) -> isto , o nmero no maior que 127 (isto , entre 0 e 127), e usado para transmitir o contedo da mensagem, caso haja algum. Por esse motivo o nmero 128 redondo em MIDI: tem-se 128 notas, 128 timbres possveis com Program Change, 128 velocidades para uma determinada nota, e assim por diante.

A taxa de transmisso de 31,25 Kbaud (31250 bits por segundo, precisando 10 bits para cada poro de informao. Uma nota tem trs bytes para tocar, portanto consegue-se mais ou menos 1000 notas por segundo).

Tocando-se uma nota em um sintetizador ele transmitir 3 bytes, caso transmita outra nota, sem mexer em mais nada, o teclado ir transmitir apenas mais dois bytes data sem o status byte. O aparelho que estiver recebendo, por sua vez, ir entender que aqueles dois bytes seguintes no so outra coisa alm de mais uma nota. Esta conveno chamada de running status. Com ela, o aparelho receptor presume que bytes data (que ele conhece por serem menores que 128) sem o status so do mesmo tipo que a ltima mensagem recebida. Num acorde de quatro notas, portanto, sero transmitidas 9 bytes (tres bytes para a primeira nota e dois para cada uma das outras trs notas), e no 12 - uma economia de 25%. Em certas situaes este tipo de comportamento permite um trfego de informao bem menos congestionado (PINTO, 2000).

3.5. Control Change

Quando foi criado o padro MIDI, no s foram definidas as caractersticas eltricas da transmisso de informaes entre equipamentos, como tambm foram estabelecidos os cdigos digitais para diversas mensagens de comando a serem transferidas de um instrumento para outro, como a execuo de notas, por exemplo. Dentre essas mensagens, h uma categoria que engloba todos os tipos de controles, como ajuste de volume e de

18

pan, posio do pedal de sustain, ajuste de tempo do portamento, de intensidade de efeitos, etc, e essas mensagens so chamadas de control change messages, ou mensagens de alterao de controle (RATTON, 1996b).

Os comandos de control change se subdividem em dois subgrupos: controles contnuos (cujo valor pode variar gradualmente), e controles liga/desliga (que atuam como chaves de dois estados).Todas as mensagens de control change contm identificao de canal, para que possam ser dirigidas ao instrumento desejado, que est configurado para receber no mesmo canal em que a mensagem est sendo transmitida (RATTON, 1996b).

Quando o msico move algum dos dispositivos de controle de seu instrumento (pedal de volume, alavanca de modulation, etc), so transmitidas mensagens correspondentes de control change, que contm trs cdigos, compondo o seguinte formato (RATTON, 1996b): control change / canal, nmero do controle, valor do controle.

O primeiro cdigo identifica que a mensagem MIDI de control change, e tambm informa qual o nmero do canal de MIDI em que ela est sendo transmitida; o segundo cdigo identifica qual o controle (volume, pan, etc) que se est ajustando; o terceiro cdigo indica qual o valor do ajuste a ser feito naquele controle (RATTON, 1996b).

A seguir so apresentados alguns comandos de control change com seus respectivos valores:

Controle N 0 Bank Select: Esta mensagem tem a funo de selecionar determinado timbre em um banco de timbres. Atravs da qual pode-se selecionar via MIDI um banco especfico de timbres e ento, no banco selecionado, escolher qual dos 128 timbres dele se deseja selecionar.

Controle N 1 Modulation: O controle de modulation um dos mais antigos dispositivos a ser implementado nos sintetizadores. Usado desde os primeiros Moogs, no final da dcada de 60, em quase todos os instrumentos o modulation est localizado esquerda do teclado. Ao se mover o dispositivo de controle de modulation, so geradas inmeras mensagens MIDI de control change n1, cada uma indicando cada posio em que passa o controle.

19

Controle N 2 Breath Controller: O controle por sopro ou breath controller um dispositivo que permite ao msico usar o sopro para controlar algum parmetro do som do sintetizador.

Hoje, muitos equipamentos que no implementam breath controller usam o control change 2 para outra funo, em geral controlado por um boto deslizante (slider) no painel, de funo programvel.

Controle N 4 Foot Controller: O control change 4 foi definido na especificao original como um comando para ser gerado por um dispositivo de pedal de ao contnua (gradual), e sua atuao especfica (o parmetro que altera) pode ser programada no instrumento. O movimento do pedal gera mensagens MIDI de control change 4, que transmitem a sua posio fsica, identificada por valores de 0 (pedal totalmente para trs) a 127 (pedal totalmente para a frente). J no E-mu Proteus, o comando MIDI de control change 4 no tem funo especfica, e ao ser recebido via MIDI pode ser direcionado para atuar em um dentre diversos parmetros.

Controle N 5 Portamento Time: Este controle foi idealizado para ajustar, via MIDI, o tempo do portamento, que um efeito semelhante ao pitchbend, obtido quando se passa da freqncia de uma nota para a de outra. o efeito que o violinista faz ao deslizar o dedo da mo esquerda na corda, enquanto passa o arco sobre ela. O tempo do portamento , portanto, o intervalo de tempo que decorre para ir da nota inicial at a nota final (RATTON, 1996b).

Controle N 6 Data Entry MSB: Este controle serve para efetuar ajustes de parmetros diversos via MIDI. o controle onde se faz o ajuste fino de valores de parmetros de edio. Em muitos instrumentos e equipamentos ele designado por Value (RATTON, 1996b).

Controle N 7 Volume: A mensagem MIDI de control change n7 destinada ao controle de volume. Quando se move um boto deslizante - ou um pedal - de controle de volume, o equipamento transmite inmeras mensagens de control change n7 correspondentes s posies que o boto ou pedal passam no decorrer do movimento. Mas, se o objetivo efetuar uma alterao imediata de volume, ento, no caso de se estar trabalhando com um seqenciador, muito mais conveniente criar este valor exato atravs do software, e no gravando-o a partir do equipamento transmissor. Isso porque

20

no software pode-se inserir um nico comando de control change n7 com o valor desejado, enquanto que pelo equipamento controlador provavelmente sero gerados inmeros comandos, que acabaro por ocupar memria desnecessariamente (RATTON, 1996b).

Controle N 8 Balance: O control change n8 usado como comando de Balance (equilbrio), que determina o equilbrio de volume entre dois sons diferentes (Tabela 3.5a), um situado esquerda e outro direita (RATTON 1996b).

Tabela 3.5a Valores de Balance (RATTON, 1996b) Valor Situao

0 Volume mximo para o som da direita. Volume mnimo para o som da esquerda.

64 Volumes iguais para ambos os sons

127 Volume mnimo para o som da direita. Volume mximo para o som da esquerda.

Controle N 10 Pan: Controle que determina o posicionamento de um som no estreo, campo esquerda-direita (Tabela 3.5b).

Tabela 3.5b Valores de Pan (RATTON, 1996b) Valor Situao

0 Som todo para esquerda.

64 Som no centro (igualmente na esquerda e na direita).

127 Som todo para direita.

importante perceber que alguns equipamentos usam uma notao diferente da apresentada acima, de forma que o valor 0 muitas vezes indica a posio central, e os extremos seriam representados por -64 e +63. H tambm equipamentos que no possuem 63 ou 64 nveis para cada lado, de forma que o ajuste se d em passos mais largos, de forma anloga ao controle de volume (RATTON 1996b).

21

Controle N 11 Expression: O comando de Expression (expresso) uma forma de acentuao do volume principal. Atua como uma espcie de volume global, aps o controle de volume normal (control change 7). Dessa forma, se for transmitido um valor baixo de control change 11, pode ocorrer do som de um equipamento ficar muito baixo, mesmo que se altere o volume (control change 7) (RATTON, 1996b).

Controle N 64 Sustain On/Off: O control change 64 o pedal de sustain (s vezes designado como damper pedal ou hold pedal). Sua funo ativar ou no a sustentao do som, que, dependendo da caracterstica deste, pode ter efeitos ligeiramente diferentes. Os movimentos (pressionar ou soltar) feitos pelo msico no pedal de sustain so codificados como comando de control change n 64, que a mensagem de Sustain Pedal On/Off. Ao pressionar o pedal, o equipamento transmite um comando de control change 64 com valor 127, e ao soltar o pedal o equipamento transmite um comando de control change 64 com valor 0 (RATTON, 1996b).

Controle N 65 Portamento On/Off: O portamento um efeito obtido nos instrumentos musicais no-cromticos como o violino, por exemplo, onde o msico executa a nota deslizando o dedo sobre a corda, subindo ou descendo continuamente a afinao, para ir de uma nota a outra. Em muitos instrumentos musicais eletrnicos, tambm possvel conseguir esse efeito, desde que seja ativada a funo especfica. Isso pode ser feito atravs de uma tecla no painel do equipamento ou por um pedal. Ao se ligar o efeito de portamento, o equipamento transmite o comando (mensagem) MIDI de control change n 65, com valor 127 (On), e ao se desligar o efeito, transmitido o comando de control change n 65, com valor 0 (Off) (RATTON, 1996b).

Controle N 68 Legato On/Off: O controle de Legato On/Off usado para ligar ou desligar a funo de legato monofnico. Quando esta funo est ligada, o instrumento passa a operar em modo monofnico (s executa uma nota de cada vez - no faz acordes), e atua de acordo com o seguinte procedimento: se uma nota j est sendo executada e o msico tocar outra nota, soar somente a nota nova (a antiga deixar de tocar), mas sem que haja um novo ataque de envoltria. Ao se desligar a funo de legato monofnico, o instrumento volta ao modo polifnico normal.

22

possvel ativar ou desativar via MIDI o modo legato monofnico, enviando para o instrumento o comando de control change 68 (Legato On/Off). Sendo este tambm um comando do tipo liga/desliga, o valor 127 significa On (ativar legato), enquanto o valor 0 significa Off (desativar legato) (RATTON, 1996b).

Controle N 98 e 99 RPN e NRPN: Os parmetros registrados (RPN - "Registered Parameters Numbers") e os parmetros no-registrados (NRPN - "Non-Registered Parameters Numbers") so usados para representar parmetros do som ou de performance nos instrumentos, sendo que os parmetros registrados so aqueles que j foram definidos em comum acordo entre os fabricantes participantes da MMA (MIDI Manufacturers Association) e JMSC (Japan MIDI Standard Comittee). Os comandos NRPN, por sua vez, tm sido usados pelos fabricantes para atuar sobre parmetros ainda no padronizados (RATTON, 1996b).

3.6. Conexes MIDI

Dentre as formas de conexo de equipamentos MIDI uma delas (figura 3.6a), quando a sada de um instrumento MIDI Out conectada a entrada de outro instrumento MIDI In.

Figura 3.6a Conexo MIDI instrumento-instrumento (RATTON, 1997b).

Outra forma de conexo MIDI (figura 3.6b) entre o computador e o instrumento. Nesta, porm, o computador pode funcionar tanto como receptor quanto como transmissor.

23

Figura 3.6b Conexo MIDI instrumento-computador (RATTON, 1997b).

Porm a conexo fsica com o cabo MIDI no a nica coisa que tem que ser feita para que equipamentos possam operar interligada via MIDI. preciso selecionar corretamente os canais de MIDI, bem como verificar alguns outros parmetros relativos transmisso e recepo das informaes (RATTON, 1997b).

3.7. Os Canais de MIDI

Para transmitir informaes de notas e outros eventos musicais (como o acionamento de pedais, por exemplo), o sistema MIDI dispe de 16 canais. O sistema funciona de forma bastante semelhante ao sistema de TV: se o transmissor utiliza um determinado canal MIDI (diga-se, canal 1), o equipamento receptor s poder efetivamente receber as informaes se estiver ajustado tambm para mesmo canal MIDI (no caso, o canal 1). Os equipamentos atuais possuem ajustes separados de canal de transmisso e de recepo, o que significa, por exemplo, que um sintetizador pode estar configurado para transmitir MIDI pelo canal 2, e receber pelo canal 4. Na verdade, como os instrumentos mais modernos so "multitimbrais", podem receber em vrios canais simultneos, independentemente do ajuste do seu canal de transmisso (RATTON, 1998a).

Ento, uma providncia essencial ao se conectar dois ou mais equipamentos MIDI verificar se eles esto configurados corretamente quanto aos canais de transmisso e recepo.

24

O nmero mximo de canais de MIDI "trafegando" pelo cabo 16, mas esse limite no significa que no poder trabalhar com mais do que 16 instrumentos individuais. Nos estdios profissionais, para se ultrapassar o limite dos 16 canais, usam-se equipamentos (ex: interfaces MIDI) com mltiplas portas de sada MIDI Out, de forma que por cada uma so transmitidos simultaneamente 16 canais MIDI. Assim, um sistema com oito sadas MIDI Out pode trabalhar com at 128 canais de MIDI, o que significa poder comandar at 128 instrumentos diferentes, ao mesmo tempo. Na verdade, como o MIDI utilizado para controlar outros equipamentos alm dos instrumentos musicais, alguns canais so usados para controlar processadores de efeitos, mesas de mixagem e outros recursos de estdio (RATTON, 1998a).

A tabela 3.7, mostra a conveno utilizada para definir os efeitos sonoros do MIDI num respectivo cdigo.

Tabela 3.7 Os 128 instrumentos musicais e efeitos sonoros do MIDI Nmero de Programa Tipos de Instrumentos Exemplos

1-8 Pianos 1= Grande Acstico, 7= Cravo 9-16 Percusso Cromtica 10= Sistro, 14=Xilofone

17-24 rgos 19= rgo de Rock, 23= Harmnica 25-32 Violes 25= Violo Acstico (Nylon) 33-40 Baixo 33= Baixo Acstico 41-48 Cordas 41= Violino, 43= Violoncelo 49-56 Conjunto de Cordas 49= Conjunto de Cordas 1 57-64 Metais 57= Trompete, 61= Trompa Francesa 65-72 Palhetas 65= Sax Soprano 73-80 Flautas 73= Piccolo, 76= Flauta Pan 81-88 Introduo Sintetizada 81= Introduo 1, 82= Introduo 2 89-96 Enchimento Sintetizado 89= Enchimento 1 (New Age) 97-104 Efeitos Sintetizados 97= FX (chuva), 102= FX 6 (Duendes) 105-112 tnico 105= Ctara, 106= Banjo, 111= Rabeca 113-120 Percusso 113= Tringulo, 116= Bloco de madeira 121-128 Efeitos Sonoros 123= Beira-mar, 126= Helicptero

Quando o seqenciador manda uma nota via MIDI para ser executada por um instrumento, codifica esse comando numa mensagem digital, que leva quatro informaes bsicas (RATTON 1998a):

- tipo de comando (neste caso: execuo de nota - note on)

25

- nmero do canal de MIDI (1 a 16) em que est sendo transmitido o comando

- nmero da nota a ser executada (de 0 a 127; o d central a nota 60)

- intensidade (key velocity) com que a nota deve ser executada (de 0 a 127)

Assim, o nmero do canal funciona como se fosse uma identificao do destinatrio da mensagem e somente os equipamentos que estejam configurados para receber mensagens naquele canal de MIDI (MIDI Receive Channel) que ir efetuar o respectivo comando (RATTON, 1998a).

Na grande maioria dos seqenciadores, possvel indicar qual o canal de MIDI que ser usado para se transmitir os eventos de cada trilha. Essa indicao feita numa das colunas de parmetros existentes na janela principal das trilhas (Tracks), geralmente designada como Channel (ou abreviada como Chn). O nmero do canal de MIDI no tem qualquer ligao com o nmero da trilha, podendo, inclusive, haver duas ou mais trilhas operando no mesmo canal de MIDI (RATTON, 1998a).

3.8. Msica e Cincia da Computao

Neste captulo foi apresentado o padro MIDI e os tipos de mensagens MIDI. Observa-se que atravs deste padro, dispositivos musicais distintos podem trocar informaes entre si, pois estas informaes musicais so transferias pelas mensagens MIDI seguindo um padro. Ou seja, uma nova forma de representao da msica atravs de uma seqncia de mensagens MIDI.

O programa de computador que armazena estas mensagens para posterior alterao, execuo das mesmas, capacidades estas que no so possveis caso a msica seja gravada em udio, o Software Seqenciador MIDI. Este ser apresentado no captulo 4, com as suas funcionalidades bsicas encontradas atualmente. Alm de um exemplo prtico da forma como o software trabalha com as mensagens MIDI.

26

4. SOFTWARE SEQENCIADOR MIDI O Software Seqenciador MIDI chamado de seqenciador

porque grava seqncias de mensagens MIDI, comandos de notas (note on, note off), ou comandos de controle (ajuste de volume, pan, pitchbend, pedais, etc). Dentre vrias funes disponveis para o msico sua funo bsica gravar a informao MIDI, seja ela, de um sintetizador (podendo ser alterada pelo software antes da execuo), ou, atravs da entrada de notas manualmente. Estas mensagens podem ser reproduzidas pelo prprio software no computador ou ento enviadas a um sintetizador para que o mesmo as reproduza.

Como se sabe a mensagem MIDI no transmite som, somente instrues para que se possa fazer som. E o conjunto de vrias mensagens MIDI forma uma msica. Vale frisar que, estas mensagens no so enviadas em paralelo, ou seja, uma mensagem enviada sempre uma em seguida da outra.

As mensagens so armazenadas pelo seqenciador, medida que executada (teclado, guitarra MIDI). E no final da execuo, a seqncia conter todas as mensagens registradas cronologicamente, um a um (RATTON, 1997a).

No entanto, o software seqenciador MIDI possui muitas outras funcionalidades do que apenas um seqenciador de mensagens MIDI. Em alguns softwares pode-se gravar trilhas de udio digital junto com outra trilha MIDI, operando como gravador de udio. Ou seja, uma msica pode ter numa trilha uma seqncia em MIDI e em outra em udio digital.

E como afirma RATTON (1997a) o seqenciador MIDI tem um papel fundamental na msica atual, pois traz imensos recursos para a criao e experimentao de idias, mas tambm pelo fato de agilizar o processo criativo, aumentando a eficincia do trabalho, condio extremamente importante no mercado cada vez mais competitivo da msica profissional.

27

4.1. Trilhas

Para facilitar o processo de armazenamento, o seqenciador organiza os eventos em trilhas (pistas), de forma que o msico escolhe uma trilha para gravar a execuo, e todos os comandos enviados pelo instrumento ficaro registrados naquela trilha. Assim, cada parte do arranjo pode ser registrada numa trilha separada: ao criar um arranjo de trs instrumentos (timbres), como, por exemplo, piano, baixo e bateria, o msico executa cada parte separadamente, registrando-as em trilhas individuais (ao gravar uma nova trilha, o msico pode ouvir simultaneamente a execuo das trilhas j gravadas) (RATTON, 1997a).

A separao da seqncia em trilhas oferece grandes facilidades (RATTON, 1997a):

Desativar (mute) uma ou mais trilhas, de forma que as partes do arranjo registradas nelas no sejam executadas; isso timo para se ouvir isoladamente certas partes do arranjo;

Escolher outro timbre para executar a mesma trilha; permite experimentar a mesma execuo com outras sonoridades;

Efetuar algum tipo de edio somente numa trilha, como efetuar a transposio de um ou mais instrumentos do arranjo, sem alterar os demais;

Efetuar uma mixagem inicial entre as trilhas, indicando valores de controles de volume e pan;

4.2. Portas MIDI

As portas MIDI so os caminhos que o seqenciador dispe para receber/transmitir os eventos MIDI de/para os instrumentos e equipamentos MIDI. Elas esto diretamente relacionadas com as tomadas de MIDI In e MIDI Out das interfaces MIDI instaladas no computador (RATTON, 1997a).

A grande maioria dos softwares seqenciadores pode manipular mltiplas portas MIDI, de forma que se voc tiver uma placa de som e mais uma interface MIDI de mltiplas sadas, todas as portas MIDI aparecero

28

disponveis no software. Os seqenciadores tambm podem reconhecer mltiplas portas de entrada MIDI simultneas (RATTON, 1997a).

4.3. Caractersticas Principais

Dentre as principais caractersticas de um software seqenciador MIDI, pode-se constatar que basicamente a maioria composta por estes: notation view ou window, mixer, measure ou song view, piano view, piano roll view, song view, track view, event view, controller view SEQUENCER (2006). Que so explicados a seguir.

4.3.1. Notation View

A Figura 4.3.1a mostra a janela onde exibida a informao da msica em notao musical, ou seja, na partitura. Ela chamada de Notation View.

Figura 4.3.1a Notation View, Winjammer (SEQUENCER, 2006)

Nesta janela, notation view, tambm possvel digitar as notas, modificar a altura, intensidade, durao e velocidade.

29

Figura 4.3.1b Notation View com um evento selecionado (SEQUENCER, 2006)

Como se observa na figura 4.3.1b quando uma nota for selecionada, o seqenciador traz os seguintes dados:

O volume/velocidade 122 a nota E (mi), na 5 oitava Esta sendo tocada no canal 2 Sua durao de 1 quarto de tempo, semnima

4.3.2. Mixer

A janela apresentada na figura 4.3.2 a figura de uma pequena mesa mixer, semelhantes a de estdios, com controles tais como volume, reverb e chorus.

Figura 4.3.2 Mixer Winjammer, (SEQUENCER, 2006)

30

4.3.3. Song View

Song view janela no qual mostra toda a msica em uma matriz ou tabela. apresenta na figura 4.3.3.

Figura 4.3.3 Song View, Winjammer (SEQUENCER, 2006)

Esta janela (figura 4.3.3) mostra nas linhas as trilhas e nas colunas toda a msica. Esta janela til para grandes alteraes na msica. Lembrando que no necessariamente todas as trilhas devem ser MIDI, podendo algumas ser udio digital.

4.3.4. Piano View e Piano Roll

O piano view um teclado virtual no qual podemos selecionar as teclas que deveram ser tocadas pelo computador.

O piano roll (figura 4.3.4) contem retngulos em certas posies e em certos tamanhos, correspondendo a notas e a durao da notas.

Figura 4.3.4 Piando Roll (Sonnar, Cakewalk)

31

Qualquer outro elemento MIDI tambm pode ser representado pelo piano roll (figura 4.3.4).

4.3.5. Track View

A Track View que esta na figura 4.3.5 mostra todas as informaes das trilhas da msica, como o nmero de notas e outros eventos, o nome da trilha, qual instrumento/patch usado primeiro, qual canal e porta utilizada.

Figura 4.3.5 Track View , Winjammer (SEQUENCER, 2006)

Nesta janela (Figura 4.3.5) tambm pode se observar quais trilhas esto em formato MIDI e quais esto em formato udio.

4.3.6. Event View

O Event View, mostrada na figura 4.3.6 a lista de todos os itens da trilha. Mostra a intensidade, compasso, velocidade (volume) da nota, a durao e todos os marcadores e valores de controle. onde se obtm com maior detalhe as informaes MIDI.

32

Figura 4.3.6 Event View (Sonnar, Cakewalk)

4.3.7. Controller View

Por intermdio de um grfico ou histograma as notas da msica so apresentadas. Como se observa na figura 4.3.7, a altura no grfico traz o valor do que se esta observando. Pode se observar um pitch bend, a velocidade das notas, ou outra informao.

Figura 4.3.7 Controller View, Winjammer (SEQUENCER, 2006)

4.4. Exemplo Prtico

4.4.1. Notas

No necessrio administrar os comandos de note on e note off separadamente. Na maioria dos seqenciadores mostra-se a nota, no lugar que ela comea (em termos de compasso, tempo e a subdiviso de tempo,

33

chamada tick) e quanto esta nota dura (tambm em termos de compasso, tempo e ticks) (PINTO, 2000).

Supondo-se que tenha tocado esta seqncia (figura 4.4.1a).

Figura 4.4.1a Notas tocadas (PINTO, 2000)

A seqncia tocada foi: d no primeiro tempo, mi no segundo e um acorde de trs notas em dois tempos.

No seqenciador as mensagens aparecero conforme apresentado na figura 4.4.1b. O seqenciador est trabalhando com uma resoluo de 120 divises por semnima, isto , entre um tempo e outro existe uma grade de 120 buraquinhos para que ele possa colocar algum evento (PINTO, 2000).

Figura 4.4.1b Notas no Event List (PINTO, 2000)

Observando a figura 4.4.1b da direita para a esquerda. A primeira coluna da direita tem sempre trs valores: o nome da nota, a velocidade e finalmente sua durao. O primeiro do ento dura 119 espaos, praticamente igual a uma semnima, bem como o mi. A coluna esquerda desta mostra qual tipo da mensagem MIDI, no caso notas. Seguindo esquerda temos o canal MIDI em que esses comandos esto gravados, e, alm disso, temos a coluna que indica em que lugar da msica, em termos de compasso, tempo do compasso e tick. (no exemplo, uma nota no comeo do

34

primeiro tempo, uma no comeo do segundo e trs no terceiro tempo). A coluna seguinte mostra em termos de tempo de relgio, isto , horas, minutos, segundos e frames, quando as notas aparecem. Por fim, a ltima coluna nos diz que tudo isto est apenas no track 1 do seqenciador (PINTO, 2000).

4.4.2. Channel Pres.

Suponha que, ao tocar o acorde eu aperto mais o teclado gerando um aftertoutch. Isto ficaria registrado mais ou menos assim (figura 4.4.2):

Figura 4.4.2 Channel Pres. No Event List (PINTO, 2000)

Aps o acorde, vrios comandos de aftertoutch so registrados, j que este tipo de modulao feito de modo contnuo. Percebe-se que apesar de a modulao continuar aps o espao que h na janela, a modulao no passou nem do terceiro tempo do compasso. Modulaes assim contnuas gastam muita memria, geralmente (PINTO, 2000).

4.4.3. Progam Change

Suponha que se quisesse mudar o som do instrumento na hora em que fosse tocar o acorde: isso se faz com o comando program change. No exemplo (figura 4.4.3) muda-se o timbre para o nmero 2 (que neste teclado corresponde ao som chamado Celesta). No caso o acorde estaria soando com este som (PINTO, 2000).

35

Figura 4.4.3 Progam Change no Event List (PINTO, 2000) 4.4.4. Control Change

Neste exemplo (Figura 4.4.4) mostra-se como abaixar o som usando. Para isso usa-se o comando Control Change.

Figura 4.4.4 Control Change no Event List (PINTO, 2000)

Na coluna que identifica o tipo de mensagem (Figura 4.4.4) est especificado contrl, ou seja, control change. Tem-se em seguida sua identificao (no 7, ou seja, volume) seguida do valor. No caso, o volume est no mximo e sendo abaixado.

4.4.5. Pitch Wheel

Semelhantemente ao caso anterior, as mensagens contnuas so colocadas seguidamente. Tem-se aqui (Figura 4.4.5) um exemplo de um glissando para o grave do acorde (PINTO, 2000).

36

Figura 4.4.5 Pitch Wheel no Event List (PINTO, 2000)

4.5. Estado da Arte

Como apresentado na seo anterior, o software seqenciador MIDI possui algumas caractersticas bsicas. E o que muda de um software para outro a maneira como estas caractersticas so apresentadas, e o modo como cada software trabalha. Porm h softwares com inmeros outros recursos, que alm da gravao de udio e MIDI em trilhas distintas, contm vrios efeitos a ser aplicados na msica. Como um exemplo de um bom seqenciador, o software Sonnar da Cakewalk, considerado o melhor na pesquisa realizada por (SCHROEDER, 2005).

Mas, no entanto, segundo SCHROEDER (2005), h algumas necessidades levantadas que atualmente no h em nenhum software seqenciador que so:

Pesquisa por seqncia armazenada. Considerando um banco de msicas grande, no existem recursos para busca de uma seqncia j gravada. Poderia ser cha-mado de reconhecimento MIDI;

Quantizao3 mais inteligente. Os algoritmos de quantizao dos seqenciadores so limitados, uma se-

__________________

3Quantizao uma ferramenta de edio que existe na maioria dos seqenciadores, e que permite ao msico acertar no tempo adequado as notas MIDI gravadas na seqncia. Ao se determinar ao seqenciador que quantize determinado trecho de notas, necessrio definir qual a figura musical de referncia (colcheia, semicolcheia, etc) que deve ser usada, isto , para quais tempos (ou fraes de tempos) as notas devero ser movidas (RATTON, 1996c).

37

qncia de notas rpidas executadas no quantizada muito inteligentemente pelo computador. Evolues neste sentido so necessrias;

Trabalhos em paralelo esto sendo realizados nesta rea de Tecnologia Musical do CCT/UDESC. Um destes o trabalho que envolve o armazenamento MIDI em banco de dados que de suma importncia para o projeto final, e que vem como complemento a este.

O presente trabalho uma fase de um projeto maior que um software seqenciador MIDI, contemplando todas essas necessidades levan-tas, e com o diferencial de ter o uso efetivo da informao musical codificada para a pesquisa SCHROEDER (2005), o que facilitar muito o trabalho do m-sico, principalmente se este conta com um banco de dados de msica muito grande. Assim o msico poder buscar seqncias de msicas j gravadas, podendo reutilizar algumas partes, ou para servir como modelo para outras, ou da melhor maneira como este novo recurso venha lhe convir.

38

5. METODOLOGIA DE DESENVOLVIMENTO RUP

5.1. Conceito

A metodologia de desenvolvimento na qual se baseia este tra-balho o RUP (Rational Unified Process), tambm chamado de UP (Unified Process), Processo Unificado, que est fortemente associado notao UML.

De acordo com RUP (2003), o RUP um processo de engenha-ria de software que oferece uma abordagem baseada em disciplinas para atri-buir tarefas e responsabilidades dentro de uma organizao de desenvolvi-mento. Sua meta garantir a produo de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e de um or-amento previsvel. A figura 5.1a exibi uma viso geral dos processos envol-vido no RUP.

Figura 5.1a RUP, viso geral (RUP, 2003)

O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao de desenvolvimento. Sua meta garantir a produo de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e de um oramento previsveis (RUP, 2003).

39

A figura 5.1a mostra a arquitetura geral do RUP, com suas dimenses:

O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo medida que se desenvolve.

O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lgica, por natureza.

A primeira dimenso representa o aspecto dinmico do processo quando ele aprovado e expressa em termos de fases, iteraes e marcos. A segunda dimenso representa o aspecto esttico do processo, como ele descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo (consulte Conceitos-chave). O grfico mostra como a nfase varia atravs do tempo. Por exemplo, nas iteraes iniciais, dedicamos mais tempo aos requisitos. J nas iteraes posteriores, gastamos mais tempo com implementao.

O RUP comporta, em suas recomendaes, as antigas fases de estudo de viabilidade, anlise de requisitos, anlise de domnio, e o projeto em mltiplas camadas (WAZLAWICK, 2004).

O ciclo de vida de software do RUP dividido em quatro fases seqenciais (Figura 5.1), cada uma concluda por um marco principal, ou seja, cada fase basicamente um intervalo de tempo entre dois marcos principais.

Figura 5.1b As fases e os marcos de um projeto RUP (RUP, 2003)

40

A fase de iniciao ou concepo incorpora o estudo de viabili-dade e uma parte da anlise de requisitos. A fase de elaborao incorpora a maior parte da anlise de requisitos, a anlise de domnio e projeto. A fase de construo corresponde programao e testes, e a fase de transio consiste na instalao e manuteno do sistema (WAZLAWICK, 2004).

5.2. Fase de Iniciao ou Concepo

A fase de concepo, (inception), deve ser a primeira do pro-cesso de desenvolvimento de software, na qual se procura levantar os princi-pais requisitos e compreender o sistema de forma abrangente (WAZLAWICK, 2004).

Esta fase inicial indica o nascimento da idia sobre um novo software. Pode consistir da discusso sobre um problema que ocorre na em-presa ou nos clientes e que eventualmente poderia ser resolvido ou minimizado com o desenvolvimento de um sistema informatizado (QUADROS, 2002).

Nesta etapa, no realizado nenhum tipo de estudo aprofun-dado sobre o sistema, no entanto, podem ser feitas algumas projees grossei-ras que permitam inferir, ainda que com pouca preciso QUADROS (2002): Quanto tempo o software levaria para ser desenvolvido? Quanto o software custaria para ser desenvolvido? Quais benefcios o projeto traria para a em-presa ou para o cliente?

Segundo RUP (2003) os principais objetivos da fase de concepo incluem:

a) Estabelecer o escopo do software do projeto e as condies limite, incluindo uma viso operacional, critrios de aceitao e o que deve ou no estar no produto.

b) Discriminar os casos de uso crticos do sistema, os principais cenrios de operao e o que direcionar as principais trocas de design.

c) Exibir, e talvez demonstrar, pelo menos uma opo de arquitetura para alguns cenrios bsicos.

41

d) Estimar o custo geral e a programao para o projeto inteiro (e estimativas detalhadas para a fase de elaborao imediatamente a seguir).

e) Estimar riscos em potencial (as origens de imprevistos). f) Preparar o ambiente de suporte para o projeto.

As atividades bsicas incluem (RUP, 2003): I. Formular o escopo do projeto. Isso envolve capturar o

contexto, bem como os requisitos e as restries mais importantes, para que seja possvel depreender critrios de aceitao para o produto final.

II. Planejar e preparar um caso de negcio. Avaliar alternativas para o gerenciamento de riscos, a organizao da equipe, o plano do projeto e as mudanas de custo/programao/lucros.

III. Sintetizar uma possvel arquitetura, avaliando as mudanas no design e em fazer/comprar/reutilizar, para que seja possvel estimar custo, programao e recursos. O objetivo aqui demonstrar a possibilidade de execuo atravs de alguma forma de prova de conceito. Isso pode ter a forma de um modelo que simula o que exigido, ou de um prottipo inicial que explora as reas consideradas de alto risco. O esforo do prottipo durante a iniciao deve se limitar a ganhar confiana na possibilidade de uma soluo - a soluo ser executada durante a elaborao e a construo.

IV. Preparar o ambiente para o projeto, avaliando o projeto e a organizao, selecionando ferramentas e decidindo quais partes do processo devem ser melhoradas.

Esta etapa a de definio do escopo do projeto. Ao final desta, tem-se o primeiro Marco (milestone), o Lifecycle Objective Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

Sumrio Executivo ou Documento de viso Geral do Sistema, incluindo requerimento, recursos principais e restries.

Glossrio do projeto, explicando os termos peculiares ao desenvolvimento do mesmo (opcional).

Caso de uso inicial (descrito utilizando a UML).

42

Levantamento dos requisitos. Um ou mais prottipos.

5.3. Fase de Elaborao

No incio da elaborao, o profissional tem uma vaga idia dos requisitos que o software dever atender. Nesta fase, o profissional dever investigar a fundo os obstculos (riscos) que o projeto pode encontrar. Tais riscos como: Riscos de requisitos, riscos tecnolgicos, riscos de habilidades, riscos polticos (QUADROS, 2002).

Alm da anlise dos riscos, a elaborao marcada pela definio detalhada do escopo e dos requerimentos do software a ser desenvolvido. Esta definio dos requerimentos deve ser formalizada por escrito atravs de um documento denominado Documento de Levantamento e Especificao de Requerimentos de Usurio (DLERU). O DLERU deve ser submetido ao usurio/cliente sempre que possvel para que ele seja avaliado (QUADROS, 2002).

A meta da fase de elaborao criar a baseline (a base de sustentao) para a arquitetura do sistema a fim de fornecer uma base estvel para o esforo da fase de construo. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que tm grande impacto na arquitetura do sistema) e de uma avaliao de risco. A estabilidade da arquitetura avaliada atravs de um ou mais prottipos de arquitetura (RUP, 2003).

Segundo RUP (2003), os objetivos primrios da etapa de elaborao incluem:

a) Assegurar que a arquitetura, os requisitos e os planos sejam estveis o suficiente e que os riscos sejam suficientemente diminudos a fim de determinar com segurana o custo e a programao para a concluso do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca tambm corresponde transio de uma operao rpida e de baixo risco para uma operao de alto custo e alto risco com uma inrcia organizacional freqente.

43

b) Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.

c) Estabelecer uma arquitetura da baseline derivada do tratamento dos cenrios significativos do ponto de vista da arquitetura, que normalmente expem os maiores riscos tcnicos do projeto.

d) Produzir um prottipo evolutivo dos componentes de qualidade de produo, assim como um ou mais prottipos descartados para diminuir riscos especficos como:

a. Trocas de design/requisitos b. Reutilizao de componentes c. Possibilidade de produo do produto ou

demonstraes para investidores, clientes e usurios finais.

e) Demonstrar que a arquitetura de baseline suportar os requisitos do sistema a um custo justo e em tempo justo.

f) Estabelecer um ambiente de suporte.

E as suas atividades bsicas so (RUP, 2003): I. Definir, validar e criar a baseline da arquitetura com

rapidez e eficincia. II. Refinar a Viso, com base nas informaes novas

obtidas durante a fase, estabelecendo uma compreenso slida dos casos de uso mais crticos que conduzem as decises de arquitetura e planejamento.

III. Criar planos de iterao detalhados e baselines para a fase de construo.

IV. Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automatizao necessria para dar assistncia equipe de construo.

O objetivo dessa etapa analisar o domnio do problema, estabelecer uma fundao, desenvolver o plano de projeto e eliminar os elementos de maior risco do projeto. Ao final dela, tem-se o segundo Marco

44

(milestone), o Lifecycle Architecture Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

Um caso de uso praticamente pronto com uma descrio completa dos atores e cenrios de uso.

Descrio das operaes e consultas de sistema. Modelagem Conceitual Os Contratos de operaes e consultas de sistema.

5.4. Fase de Construo

A construo a fase do processo cujo final marcado pela disponibilizao do produto de software (um arquivo executvel ou uma pgina Web, por exemplo) para os clientes ou usurios (QUADROS, 2002).

Durante essa etapa, os profissionais estaro primeiramente modelando o software utilizando alguma notao, tais como a definida pela UML. Aps a modelagem, a fase de construo marcada pela codificao do software, onde os desenvolvedores estaro fazendo uso de alguma ferramenta de programao, bem como criando as estruturas de apoio, tais como o banco de dados com suas tabelas e outros elementos (QUADROS, 2002).

A fase de construo tambm composta pela homologao que consiste na realizao de testes de garantia de qualidade como o produto antes do envio para o cliente. A documentao do produto encerra essa fase do processo de desenvolvimento, juntamente com a disponibilizao de todo o conjunto do produto para o cliente (software, manuais de treinamento e referncia). A vantagem desta abordagem est em se permitir definir deadlines (limites) intermedirios pra os vrios subprojetos, impedindo que os problemas e os atrasos se evidenciem apenas no final do projeto (QUADROS, 2002).

A meta da etapa de construo esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construo de certa forma um processo de manufatura, em que a nfase est no gerenciamento de recursos e controle de operaes para otimizar custos, programaes e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transio do desenvolvimento da propriedade

45

intelectual durante a iniciao e elaborao, para o desenvolvimento dos produtos que podem ser implantados durante a construo e transio (RUP, 2003).

Segundo RUP (2003) os objetivos principais da etapa de construo incluem:

a) Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e retrabalho desnecessrios.

b) Atingir a qualidade adequada com rapidez e eficincia. c) Atingir as verses teis (alfa, beta e outros releases de

teste) com rapidez e eficincia. d) Concluir a anlise, o design, o desenvolvimento e o teste

de todas as funcionalidades necessrias. e) Desenvolver de modo iterativo e incremental um produto

completo que esteja pronto para a transio para a sua comunidade de usurios. Isso implica descrever os casos de uso restantes e outros requisitos, incrementar o design, concluir a implementao e testar o software.

f) Decidir se o software, os locais e os usurios esto prontos para que o aplicativo seja implantado.

g) Atingir certo nvel de paralelismo entre o trabalho das equipes de desenvolvimento. Mesmo em projetos menores, normalmente h componentes que podem ser desenvolvidos um independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos permitirem). O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas tambm aumenta a complexidade do gerenciamento de recursos e da sincronizao dos fluxos de trabalho. Uma arquitetura sofisticada ser essencial para atingir um paralelismo significativo.

E as suas atividades bsicas so (RUP, 2003): I. Gerenciamento de recursos, otimizao de controle e

processo. II. Desenvolvimento completo do componente e teste dos

critrios de avaliao definidos. III. Avaliao dos releases do produto de acordo com os

critrios de aceitao para a viso.

46

Ao final desta etapa, temos o terceiro Marco (milestone), o Initial Operational Capability Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):

O produto (software) completamente operacional. Os manuais do produto.

O marco Capacidade Operacional Inicial determina se o produto est pronto para ser implantado em um ambiente de teste beta (RUP, 2003).

5.5. Fase de Transio

Nesta fase, o produto j foi entregue e so feitas as manutenes corretivas e as otimizaes de pequeno porte (que no envolvam uma completa reconstruo do software) (QUADROS, 2002).

O foco da Fase de Transio assegurar que o software esteja disponvel para seus usurios finais. A Fase de Transio pode atravessar vrias iteraes e inclui testar o produto em preparao para release e ajustes pequenos com base no feedback do usurio. Nesse momento do ciclo de vida, o feedback do usurio deve priorizar o ajuste fino do produto, a configurao, a instalao e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto (RUP, 2003).

No fim do ciclo de vida da Fase de Transio, os objetivos devem ter sido atendidos e o projeto deve estar em uma posio para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o incio de outro ciclo de vida no mesmo produto, conduzindo nova gerao ou verso do produto. Para outros projetos, o fim da Transio pode coincidir com uma liberao total dos artefatos a terceiros que podero ser responsveis pela operao, manuteno e melhorias no sistema liberado (RUP, 2003).

A Fase de Transio entra quando uma baseline estiver desenvolvida o suficiente para ser implantada no domnio do usurio final. Isso normalmente requer que algum subconjunto usvel do sistema tenha sido concludo com nvel de qualidade aceitvel e documentao do usurio, de

47

modo que a transio para o usurio fornea resultados positivos para todas as partes (RUP, 2003).

Segundo RUP (2003) os objetivos principais da Fase de Transio so:

a) Teste beta para validar o novo sistema em confronto com as expectativas do usurio.

b) Teste beta e operao paralela relativa a um sistema legado que est sendo substitudo.

c) Converso de bancos de dados operacionais. d) Treinamento de usurios e equipe de manuteno. e) Introduo a marketing, distribuio e equipe de vendas. f) Engenharia voltada para implantao, como preparao,

empacotamento e produo comercial, introduo a vendas, treinamento de pessoal em campo.

g) Atividades de ajuste, como correo de erros, melhoria no desempenho e na usabilidade.

h) Avaliao das baselines de implantao tendo como base a viso completa e os critrios de aceitao para o produto.

i) Obteno de auto-suportabilidade do usurio. j) Obteno do consentimento dos envolvidos de que as

baselines de implantao esto completas. k) Obteno do consentimento dos envolvidos de que as

baselines de implantao so consistentes com os critrios de avaliao da viso.

E as suas atividades bsicas so (RUP, 2003): I. Executar planos de implantao.

II. Finalizar o material de suporte para o usurio final. III. Testar o produto liberado no local do desenvolvimento. IV. Criar um release do produto. V. Obter feedback do usurio.

VI. Ajustar o produto com base em feedback. VII. Disponibilizar o produto para os usurios finais.

48

No fim na etapa de transio est o quarto marco mais importante do projeto, o Product Release Milestone. Onde so apresentados os seguintes resultados (QUADROS, 2002):

Distribuio do produto para Beta-testers. Operao em paralelo com sistemas legados do cliente

(legacy system). Com base na anlise feita neste Marco, a empresa poder

decidir finalmente pela disponibilizao do produto para os clientes. Ao final do projeto, deve ser feita tambm uma reviso do cronograma fsico-financeiro de forma a avaliar a adequao final do projeto com relao ao planejamento inicial. A fase de transio poder, dependendo do feedback dos usurios, coincidir com o incio de um novo ciclo de desenvolvimento (QUADROS, 2002).

5.6. Definio das Tarefas e Atividades

Com base no Processo Unificado de desenvolvimento de software, apresentado na seo anterior este trabalho vai ater-se s fases de concepo e elaborao, deixando as fases de construo e transio para trabalhos futuros.

A fase de concepo onde se buscam as primeiras informaes sobre o sistema a ser desenvolvido vai ter as seguintes atividades:

Levantamento de requisitos Organizao dos requisitos.

A etapa de levantamento de requisitos corresponde a buscar junto ao usurio, seus sistemas e documentos, todas as informaes possveis sobre as funes que o sistema deve executar e as restries sob as quais o sistema deve operar. O produto desta etapa ser o documento de requisitos, primeiro componente do anteprojeto de software (WAZLAWICK, 2004).

A etapa de organizao dos requisitos serve para estruturar os requisitos para que possam ser abordados nos ciclos de desenvolvimento. Grande parte dos requisitos ser acomodada em processos de negcio conhecidos como casos de uso. Outros requisitos podero ser associados a

49

operaes simples (como cadastros), outros ainda sero meramente consultas. Os casos de uso, cadastros e consultas sero abordados nos diferentes ciclos, priorizando-se os elementos mais crticos (normalmente casos de uso), e deixando-se para o final os mais elementares (cadastros e consultas) (WAZLAWICK, 2004).

A fase de elaborao se inicia com uma subfase anlise e prossegue com uma subfase de projeto. A subfase de anlise em si comporta trs atividades distintas realizadas na seguinte ordem (WAZLAWICK, 2004):

Expanso dos casos de uso e determinao dos eventos de sistema.

Construo do modelo conceitual. Elaborao dos contratos de operaes de sistema.

A expanso dos casos de uso corresponde ao aprofundamento da anlise de requisitos. J a modelagem conceitual corresponde anlise de domnio em seus aspectos estticos. Por fim, a elaborao dos contratos corresponde especificao funcional dos aspectos dinmicos da anlise de domnio (WAZLAWICK, 2004).

A subfase de projeto pode se dividir em diversas tarefas com objetivos distintos WAZLAWICK (2004). As tarefas sero:

Projeto da camada de domnio. Projeto da camada de interface. Projeto da camada de persistncia.

O projeto da camada de domnio compe-se basicamente de duas atividades: definir os diagramas de colaborao e elaborar o diagrama de classes de projeto (WAZLAWICK, 2004).

O projeto da camada de interface mostra como manter a independncia entre a camada de domnio e a interface do software. O projeto da camada de persistncia mostra como implementar um sistema de persistncia que automatiza o salvamento e a recuperao de dados em disco (WAZLAWICK, 2004).

50

6. CONCEPO

6.1. Levantamento de Requisitos

Na fase de concepo ou iniciao, a anlise de requisitos rpida e genrica: feita em extenso e no em profundidade. O analista deve entender a extenso do que o sistema deve fazer, mas sem detalhar como ele vai fazer (WAZLAWICK, 2004).

Esta fase produz dois documentos: a viso geral do sistema e os requisitos funcionais e no-funcionais.

6.1.1. Viso Geral do Sistema

A viso geral do sistema, ou sumrio executivo, um documento que descreve aquilo que se consegue descobrir de relevante sobre o sistema aps as conversas com clientes e usurios. No so propostas regras aqui sobre como deve ser escrito esse documento. Mas sugere-se que no seja longo demais. Uma a duas pginas so suficientes para descrever de maneira resumida a maioria dos sistemas. apenas uma descrio desestruturada, onde existem informaes de nvel gerencial e de nvel operacional (WAZLAWICK, 2004).

A seguir apresentada a viso geral do sistema seqenciador MIDI.

Software Seqenciador MIDI (Viso Geral do Sistema)

proposto o desenvolvimento de um software seqenciador MIDI que tenha o uso efetivo da informao musical codificada para a pesquisa. Contemplar todas as caractersticas bsicas principais pesquisadas que um software seqenciador MIDI contm atualmente. Estas funcionalidades so encontradas em janelas como o Notation View, Mixer, Song View, Piano View, Piano Roll, Track View, Event View, Controller View. Tambm ter a possibilidade de gravaes em trilhas distintas, tanto de udio digital quanto de seqncias MIDI. Sendo o objetivo principal ter o diferencial de trabalhar com a

51

informao MIDI propriamente dita, ou seja, armazenamento e recuperao das mensagens MIDI em um banco de dados, e conseqentemente usufruir das facilidades do mesmo para efetuar pesquisas pela informao musical desejada. Outro objetivo ter uma quantizao mais inteligente, que a ferramenta onde permite acertar o tempo adequado das notas. E por fim ter-se uma interface com tima usabilidade seguindo critrios ergonmicos. Utilizando-se de ferramentas freewares para todo o desenvolvimento.

6.1.2. Requisitos

Os requisitos so a definio do que o programa precisa fazer dentro de quais restries ANQUETIL (2002). E, de acordo com WAZLAWICK (2004), os requisitos podem ser classificados em duas grandes categorias:

a) Os requisitos funcionais correspondem listagem de tudo que o sistema deve fazer.

b) Os requisitos no-funcionais so restries colocadas sobre como o sistema deve realizar seus requisitos funcionais.

Os requisitos funcionais podem ser ainda classificados em dois grupos:

a) Os requisitos funcionais evidentes, que so efetuados com conhecimento do usurio. Esses requisitos usualmente correspondero a eventos do sistema e respostas do sistema, ou seja, qualquer troca de informao que ocorram pela interface do sistema com o meio exterior.

b) Os requisitos funcionais ocultos que so efetuados pelo sistema sem o conhecimento explicito do usurio.

Os requisitos no-funcionais podem ser classificados em obrigatrios e desejados, isto , aqueles que devem ser obtidos de qualquer maneira e aqueles que podem ser obtidos caso isso no cause maiores transtornos no processo de desenvolvimento.

52

Alm disso, os requisitos no-funcionais podem ser classificados por atributo: se so requisitos de interface, de implementao, de eficincia, de tolerncia a falhas, etc.

Ainda em relao aos requisitos no-funcionais, existem aqueles diretamente associados a uma funo e outros que so gerais para o sistema. Normalmente ser til ter duas tabelas: uma que relacione os requisitos funcionais e suas restries associadas e outra que relacione os requisitos no-funcionais gerais, tambm chamados de requisitos suplementares.

Uma ltima classificao til para os requisitos no-funcionais indicar se so permanentes ou transitrios (WAZLAWICK, 2004).

Como se observa na tabela 6.1.2a, onde temos as descries dos requisitos. Onde, F1 quer dizer Funcional 1, ou seja, o Requisito Funcional 1 seguido do seu ttulo. Pode ser oculto ou no, isso quer dizer se um requisito que o usurio vai ver ou apenas para o sistema. Alm da descrio do dado requisito funcional e a listagem dos requisitos no-funcionais (NF) relacionados ao requisito funcional em questo, a sua categoria, e se ele desejvel e permanente.

Tabela 6.1.2a Levantamento de requisitos (WAZLAWICK, 2004) F1 Registra emprstimos Oculto ( )

Descrio: O sistema deve registrar emprstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do emprstimo e o valor previsto para pagamento na devoluo.

Requisitos No-Funcionais Nome Restrio Categoria Desejvel Permanente NF1.1 Controle de Acesso

A funo s pode ser acessada por usurio com perfil de operador ou superior.

Segurana ( ) ( X )

NF1.2 Identificao de Fitas

As fitas devem ser identificadas por um cdigo de barras.

Interface ( ) ( X )

NF1.3 Identificao do Cliente

O cliente dever ser identificado a partir de seu nome.

Interface ( X ) ( )

53

NF1.4 Tempo de Registro

O tempo para registro de cada fita deve ser inferior a um segundo.

Performance ( X ) ( )

NF1.5 Janela nica

Todas as funes relacionadas a emprstimos devem ser efetuadas em uma nica janela.

Interface ( X ) ( )

A seguir so apresentas as tabelas com os requisitos levantados para o software Seqenciador MIDI.

54

Tabela 6.1.2b Requisito funcional 1 e requisitos no-funcionais.

F1 Gravao de uma seqncia MIDI Oculto ( ) Descrio: O sistema deve gravar uma seqncia MIDI do instrumento que esteja conectado no computador.

Requisitos No-Funcionais Nome Restrio Categoria Desejvel Permanente NF1.1 Conexo MIDI Dever ter uma interface de configurao

para conexes MIDI. Configurao ( ) ( X )

NF1.2 Gravao em trilhas Ter a opo para a escolha da trilha. Interface ( ) ( X )

NF1.3 Possibilidade de interrupo

O usurio poder a qualquer momento interromper/prosseguir a gravao.

Interface ( ) ( X )

NF1.4 Janelas Distintas Cada trilha deve ser mostrada em uma janela diferente.

interface ( ) ( X )

( ) ( )

55

Tabela 6.1.2c Requisito funcional 2 e requisitos no-funcionais. F2 Gravao de udio digital Oculto ( )

Descrio: O sistema dever ter a opo de tambm gravar udio digital atravs de um dispositivo de udio que o computador tenha.

Requisitos No-Funcionais Nome Restrio Categoria Desejvel Permanente NF2.1 Configurao de dispositivo de udio

Dever ter uma interface de configurao dos dispositivos de udio.

Configurao ( ) ( X )

NF2.2 Gravao em trilhas Ter a opo para a escolha da trilha. Interface ( ) ( X )

NF2.3 Possibilidade de interrupo

O usurio poder a qualquer momento interromper/prosseguir a gravao.

Interface ( ) ( X )

NF2.4 Janelas Distintas Cada trilha deve ser mostrada em uma janela diferente.

Interface ( ) ( X )

( ) ( )

56

Tabela 6.1.2d Requisito funcional 3 e requisitos no-funcionais. F3 Gerao de partitura Oculto ( X )

Desc

00000531

Documents

Transcript of 00000531