Esta secção descreve algum do trabalho do &arts; que se encontra em progresso. O desenvolvimento progride rapidamente, por isso esta informação poderá estar desactualizada. Você deverá ver o ficheiro da lista TODO e os arquivos das listas de correio para ver quais as novas funcionalidades que estão planeadas. Sinta-se à vontade para se envolver no novo desenho e implementação. Este é um rascunho do documento que lhe tenta dar uma ideia geral de como as novas tecnologias serão integradas no &arts;. Nomeadamente, cobre o seguinte: Como é que as interfaces funcionam. Codificadores - a descodificação de sequências de MP3 ou WAV num formato em que possam ser usados como dados. Vídeo. Multi-tarefa. Sincronização. Expansão/máscara dinâmicas. Composição dinâmica. &GUI; &MIDI; Isto ainda é trabalho em progresso. Contudo, deverá ser a base se você quiser ver tecnologias novas no &arts;. Ele dever-lhe-á dar uma ideia geral de como esses problemas serão tratados. Contudo, sinta-se à vontade para corrigir tudo o que verá aqui. As coisas que serão utilizadas pela tecnologia do &arts; (por isso, coordenem os vossos esforços): KPhone (voz sobre IP) &noatun; (leitor de áudio / vídeo) &artscontrol; (programa de controlo do servidor de som, para os âmbitos) Brahms (sequenciador de música) Kaiman (leitor multimédia do &kde;2 - compatível com o kmedia2) mpglib/kmpg (tecnologia de reprodução de áudio e vídeo mpg) SDL (camada multimédia directa para jogos que ainda não começou, mas que se tornará óptima) electric ears (o autor contactou-me - o estado é desconhecido) As interfaces do &MCOP; são a base do conceito do &arts;. Elas são o equivalente transparente na rede das classes de C++. Sempre que possível, você deverá orientar o seu desenho para as interfaces. Estas consistem em quatro partes: Sequências síncronas Sequências assíncronas Métodos Atributos Estes poderão ser misturados da forma que você desejar. As novas tecnologias deverão ser definidas em termos de interfaces. Leia as secções sobre as sequências assíncronas e síncronas, assim como as interfaces do KMedia2, os quais são um bom exemplo sobre como as coisas funcionam As interfaces são especificadas no código .idl e executadas através do compilador mcopidl. Você deriva da classe NomeInterface_impl para as implementar e usa a função REGISTER_IMPLEMENTATION(NomeInterface_impl) para inserir as implementações do seu objecto no sistema de objectos do &MCOP;. As interfaces do 'kmedia2' permitem-lhe ignorar que os ficheiros WAV, MP3 entre outros consistem em sequências de dados. Em alternativa, você só implementa os métodos para os tocar. Deste modo, você poderá criar uma rotina de carregamento de WAVE's de forma a que você possa tocar ficheiros WAVE (como PlayObject), mas mais ninguém pode usar o seu código. As sequências assíncronas seriam a alternativa. Você define uma interface que lhe permite passar os blocos de dados para dentro extrair blocos de dados para fora. Isto parece ser mesmo assim no &MCOP;: interface Codificador { entrada async byte stream indata; saida async byte stream outdata; }; Claro que os codificadores também poderão fornecer parâmetros para emitir dados adicionais, tais como a informação do formato. interface CodificadorAudioByte { entrada async byte stream indata; saida async byte stream outdata; readonly attribute amostragem, bits, canais; }; Este CodificadorAudioByte, por exemplo, poder-se-ia ligar a um objecto ByteStreamToAudio para suportar áudio de vírgula flutuante. Claro, outros tipos de codificadores poderiam envolver directamente a emissão de dados de vídeo, como por exemplo interface CodecVideo { entrada async byte stream indata; saida video stream outdata; /* nota: as sequências de vídeo ainda não existem */ }; Muito provavelmente, o conceito de um codificador deveria se aplicado em vez da forma você sabe como tocar e eu não como, por exemplo, o WavPlayObject usa no momento. Contudo, alguém precisa de parar e fazer algumas experiências antes de API API ser finalizada. A ideia é fornecer o vídeo como sequências assíncronas de algum tipo de dados nativo do &MCOP; que contenha imagens. Este tipo de dados ainda está por ser criado. Ao fazê-lo, os 'plugins' que lidem com as imagens de vídeo poderão ser ligados da mesma forma que os 'plugins' de áudio. Existem algumas coisas que são importantes não deixar de fora, nomeadamente: Existem os espaços de cores RGB e YUV. O formato deverá ser associado de qualquer forma à sequência. A sincronização é importante. A ideia é deixar possível a reimplementação da classe VideoFrame (ImagemVideo) para que possa armazenar a informação num segmento de memória partilhada. Ao fazê-lo, até a difusão de vídeo entre os diferentes processos seria possível sem muito trabalho. Contudo, a situação normal para o vídeo é que as coisas estão todas no mesmo processo, desde a descodificação até ao desenho. Foi feita uma implementação em protótipo de emissão de vídeo, a qual poderá obter aqui. Isto teria de ser integrado no &MCOP; ao fim de algumas experiências. Uma componente de desenho deveria ser fornecida que suportasse o XMITSHM (com o RGB e o YUV); o Martin Vogt comunicou que estava a fazer algo do género. De momento, o &MCOP; é todo ele monotarefa. Talvez para o vídeo não seja mais possível dar a volta a essa questão. Ok. Existem algumas coisas que têm de ser tratadas com cuidado: SmartWrappers - estes não são seguros em multitarefa devido à contagem de referências insegura, entre outras questões similares. 'Dispatcher' / E/S - Também inseguros em multitarefa. Contudo, o que é possível imaginar é tornar os módulos seguros em multitarefa para ambos os casos de sequências, síncronas e assíncronas. Desta forma - com um sistema de fluxo que suporte multitarefa, você poderá escalonar o fluxo do sinal por dois ou mais processadores. Isto iria ajudar bastante no áudio em sistemas multi-processador. Como iria funcionar: O Sistema de Fluxo decide que módulos deverão calcular o quê - isto é: imagens de vídeo (com o método 'process_indata') sequências de áudio síncronas ('calculateBlock') outras sequências assíncronas, nomeadamente sequências de 'bytes' Os módulos poderão calcular estas coisas em tarefas próprias. Para o áudio, faz sentido reutilizar as tarefas (⪚ aplicar em quatro tarefas por quatro processadores, independentemente de estarem a correr 100 módulos). Para a descompressão de vídeo e de 'bytes', poderá ser mais confortável ter uma implementação bloqueante numa tarefa própria, a qual está sincronizada com o resto do &MCOP; pelo sistema de fluxo. Os módulos não poderão usar a funcionalidade do &MCOP; (como as invocações remotas) durante a operação multitarefa. O vídeo e o &MIDI; (e o áudio) poderão necessitar de sincronização. Basicamente, baseia-se em marcas temporais. A ideia que existe é anexar as marcas temporais às sequências síncronas, adicionando esse campo a cada pacote. Se você enviar duas imagens de vídeo, simplesmente crie dois pacotes (eles são grandes, de qualquer forma), por isso poderá ter duas marcas temporais diferentes. O áudio deverá ter implicitamente marcas temporais, dado que é síncrono. Deveria ser possível dizer: um FX de efeito é composto a partir destes módulos mais simples. O FX deverá funcionar como um módulo de &MCOP; normal (veja a máscara), mas de facto consiste noutros módulos. Isto é necessário para o &arts-builder;. Todos os componentes &GUI; serão módulos do &MCOP;. Eles deverão ter atributos do tipo 'size' (tamanho), 'label' (texto), 'color' (cor), ... . Um construtor RAD (como o &arts-builder;) deverá ser capaz de os compor visualmente. A &GUI; deverá ser gravável, ao registar os atributos. A funcionalidade do &MIDI; será implementada como sequências assíncronas. Existem duas opções, em que uma usa estruturas normais de &MCOP; para definir os tipos e o outro para introduzir ainda outros tipos personalizados. Pensa-se que as estruturas normais serão suficientes, isto é, algo do tipo: struct EventoMidi { byte b1,b2,b3; sequence<byte> existe; } As sequências assíncronas deverão suportar os tipos de sequências personalizados.