Esta seção descreve parte do trabalho no &arts; que está em progresso. O desenvolvimento evolui rapidamente, assim estas informações já devem estar desatualizadas. Você deve verificar o arquivo de lista TODO e os arquivos da lista de discussão para ver quais novas funcionalidades estão sendo planejadas. Sinta-se à vontade para envolver-se em novos projetos e implementações. Este é um rascunho que tenta fornecer-lhe uma visão geral de como novas tecnologias serão integradas ao &arts;. Específicamente, isto cobre o seguinte: Como a interface funciona. Codecs - decodificação de fluxos mp3 ou wav em uma forma que eles possam ser usados como dados. Vídeo. Linhas de execução. Sincronização. Expansão/mascaramento dinâmico. Composição dinâmica. &GUI; &MIDI; Estes são os trabalhos em progresso. No entanto, isto deve ser a base se você deseja ver novas tecnologias no &arts;. Isto deve fornecer uma idéia geral de como estes problemas serão abordados. No entanto, sinta-se à vontade para corrigir qualquer coisa que veja aqui. Coisas que usarão a tecnologia do &arts; (logo por favor, coordene seus esforços): KPhone (voz sobre IP) &noatun; (reprodutor de vídeo / áudio) &artscontrol; (programa de controle do servidor de som, para escopos) Brahms (sequenciador de música) Kaiman (tocador de mídia do &kde;2 - compatível com o kmedia2) mpglib/kmpg (tecnologia para reprodução de áudio e vídeo mpg) SDL (camada de mídia direta para jogos ainda não iniciada mas talvez bem legal) electric ears (o autor contactou-me - estado desconhecido) As interfaces &MCOP; são a base do conceito do &arts;. Elas são a transparência de rede equivalente para classes C++. Sempre que possível você deve orientar seu desenho em função destas interfaces. As interfaces consistem de quatro partes: Fluxos síncronos Fluxos assíncronos Métodos Atributos Eles podem ser misturados de qualquer jeito que desejar. As novas tecnologias devem ser definidas em termos de interfaces. Leia as seções sobre fluxos assíncronos e síncronos, bem como as sobre interfaces KMedia2, que são bons exemplos de como as coisas funcionam. Interfaces são especificadas em código .idl e rodam através do compilador mcopidl. Você deriva a classe Nomeinterface_impl para implementá-las, e usa REGISTER_IMPLEMENTATION(NomeInterface_impl) para inserir sua implementação de objeto no sistema de objetos &MCOP;. As interfaces kmedia2 permitem que você ignore que arquivos wav, mp3s e seja o que for consistem de fluxos de dados. Ao invés disso, você somente implementas métodos para reproduzí-los. Assim, você pode escrever uma rotina de carregamento wave da mesma maneira que você pode reproduzir arquivos wave (com PlayObject), mas ninguém mais usa seu código. Fluxos assíncronos devem ser a alternativa. Você define uma interface que permite passar blocos de dados para ela, e obter blocos de dados dela. Isto se parece assim no &MCOP;: interface Codec { in async byte stream indata; out async byte stream outdata; }; É claro que codecs também podem fornecer atributos para emitir dados adicionais, como informações do formato. interface ByteAudioCodec { in async byte stream indata; out async byte stream outdata; readonly attribute samplingRate, bits, channels; }; Este ByteAudioCodec por exemplo pode ser conectado a um objeto ByteStreamToAudio para criar áudio flutuante real. É claro, outros tipos de Codec podem envolver diretamente emitir dados de vídeo, como interface VideoCodec { in async byte stream indata; out video stream outdata; /* note: video streams do not exist yet */ }; Provavelmente, um conceito de codec deve ser empregado ao invés do modo você sabe como reproduzir e eu não por exemplo o uso atual do WavPlayObject. No entanto, alguém precisa sentar e realizar alguns testes antes de uma API poder ser finalizada. Minha idéia é fornecer vídeo como fluxos assíncronos de algum tipo de dado nativo do &MCOP; que contenha imagens. Este tipo de dado ainda será criado. Fazendo isso, plugins que lidam com imagens de vídeo podem ser conectados da mesma maneira que plugins de áudio podem ser conectados. Existem algumas coisas que são importantes que não sejam deixadas de fora, especificamente: Existem espaços de cores RGB e YUV. O formato deve ser algo vocacionado para fluxo. Sincronização é importante. Minha idéia é deixar possível reimplementar a classe VideoFrame de modo que eu possa armazenar material no segmento de memória compártilhada. Fazendo isso, cada fluxo de vídeo entre processos diferentes serão possíveis sem muito sacrifício. No entanto, a situação padrão para vídeo é que as coisas estão no mesmo processo, da decodificação à renderização. Eu fiz uma implementação de fluxo de vídeo experimental, que você pode baixar aqui. Isto precisará ser integrado ao &MCOP; após alguns testes. Um componente de renderização deve ser fornecido que suporte XMITSHM (com RGB e YUV). Martin Vogt me disse que ele está trabalhado em algo deste tipo. Atualmente, o &MCOP; é todo em linha simples de execução. Talvez para vídeo nós não sejamos capazes de manternos em uma linha simples. Ok. Existem algumas coisas que devem ser tratadas com cuidado: SmartWrappers - eles não são seguros para linhas de execução devido a contagem de referência não segura e coisas semelhantes. Dispatcher / I/O - também não é seguro para linhas de execução. No entanto, o que eu posso imaginar é tornar os módulos selecionados seguros para linhas de execução, tanto para fluxo síncrono como assíncrono. De que modo - com um sistema de fluxo ciente da linha de execução, você pode agendar o fluxo do sinal sobre dois ou mais processadores. Isto também auxiliaria o áudio principalmente em situações de multiprocessamento. Como isto funcionaria: O Sistema de Fluxo decide quais módulos devem calcular o que - o que é: quadros de vídeo (com método process_indata) fluxos de áudio síncrono (calculateBlock) outros fluxos assíncronos, principalmente fluxos de byte Os módulos podem calcular estas coisas em suas próprias linhas de execução. Para áudio, faz sentido reusar linhas (⪚ renderizar em quatro linha de execução para quatro processadores, não importa se 100 módulos estiverem rodando). Para vídeo e descompressão de bytes, seria mais confortável ter uma implementação em blocos em sua própria linha, que é sincronizada com o resto do &MCOP; pelo sistema de fluxo. Módulos não devem usar funcionalidades do &MCOP; (como invocações remotas) durante a operação em linha de execução. Vídeo e &MIDI; (e áudio) devem requerer sincronização. Basicamente, isto é estampa de tempo. A idéia que eu tenho é anexar estampa de tempo aos fluxos assíncronos, adicionando uma estampa de tempo para cada pacote. Se você enviar dois quadros de vídeo, simplesmente crie dois pacotes (eles serão grandes de qualquer jeito), assim você pode ter duas estampas de tempo diferentes. Áudio deve implicitamente ter estampas de tempo, uma vez que ele é síncrono. Deve ser possível dizer: Um efeito FX é composto de seus módulos simples. O FX deve parecer um módulo &MCOP; normal (veja mascaramento), mas de fato consiste de outros módulos. Isto é necessário para o &arts-builder;. Todos os componentes de &GUI; serão módulos &MCOP;. Eles devem ter atributos como tamanho, rótulo, cor, ... . Um construtor RAD (&arts-builder;) deve ser capaz de compô-los visualmente. A &GUI; deve ser salvável salvando os atributos. O material de &MIDI; será implementado como fluxos assíncronos. Existem duas opções, uma é usar estruturas normais do &MCOP; para definir os tipos e outra é introduzir outros tipos customizados. Eu acho que estruturas normais deve ser o bastante, que é algo como: struct MidiEvent { byte b1,b2,b3; sequence<byte> sysex; } Fluxos assíncronos devem suportar tipos de fluxo customizados.