Esta sección describe algunos de los trabajos que están en progreso dentro de &arts;. El desarrollo avanza rápidamente, así que esta información podría estar obsoleta. Debería comprobar la lista del archivo TODO y los archivos de la lista de correo para ver qué nueva funcionalidad se está planeando. Considérese libre para involucrarse en el nuevo diseño e implementación. Este documento es un borrador que intenta dar una idea sobre cómo se integrarán las nuevas tecnologías en &arts;. En concreto, se ocupa de lo siguiente: Cómo funcionan los interfaces. Los códecs: La decodificación de transmisiones mp3 o wav de forma que puedan ser utilizados como datos. Vídeo. Hilos. Sincronización. Expansión/enmascaramiento dinámico. Composición dinámica. &GUI; &MIDI; Este trabajo está en progreso. Sin embargo, debería ser la base si lo que usted desea es encontrar nuevas tecnologías en &arts;. Además debería de dar una idea de cómo se van a afrontar esas cuestiones. Pero, por supuesto, corrija cualquier cosa que considere que se puede mejorar. Elementos que utilizarán la tecnología de &arts; (así que, por favor, coordine sus esfuerzos): KPhone (voz sobre IP). &noatun; (reproductor de vídeo y audio). &artscontrol; (programa de control del servidor de sonido). Brahms (secuenciador musical). Kaiman (reproductor de medios de &kde;2, compatible con kmedia2). mpglib/kmpg (tecnología de reproducción de audio y vídeo mpg). SDL (capa de medios directa para los juegos, aún no se ha comenzado a trabajar en ella pero será interesante). electric ears (el autor se puso en contacto conmigo. Estado desconocido). Los interfaces &MCOP; están basados en el concepto de &arts;. Son transparentes a la red de forma equivalente a las clases de C++. Siempre que sea posible, debería orientar sus diseño hacia los interfaces. Éstos constan de cuatro partes: Flujos síncronos. Flujos asíncronos. Métodos. Atributos. Estos pueden mezclarse como usted prefiera. Las nuevas tecnologías deberían definirse en términos de interfaces. Lea las secciones sobre las transmisiones síncronas y asícronas, así como los interfaces KMedia2, ya que son buenos ejemplos sobre cómo funcionan las cosas. Los interfaces se especifican en código .idl y se ejecutan a través del compilador mcopidl. Se deriva la clase Nombreinterfaz_impl para implementarlos, y se utiliza REGISTER_IMPLEMENTATION(Nombreinterfaz_impl) para insertar las implementaciones de los objetos en el sistema de objetos de &MCOP;. Los interfaces de kmedia2 permiten ignorar que los archivos wav, mp3 y otros se construyen a base de transmisiones de datos. En vez de eso, se implementan métodos para reproducirlos. Por lo tanto, usted puede escribir una rutina de carga de ondas de forma que se puedan reproducir los archivos de ondas (como PlayObject), pero nadie más puede utilizar su código. Las transmisiones asíncronas pueden ser una alternativa. Se define un interfaz que permite introducir y sacar bloques de datos. Se parece a la de &MCOP;: interface Codec { entrada async byte stream indata; salida async byte stream outdata; }; Por supuesto los códecs también proporcionan atributos para emitir datos adicionales, como información sobre el formato. interface CodificadorAudioByte { entrada async byte stream indata; salida async byte stream outdata; readonly attribute ratioMuestra, bits, canales; }; Este CodificadorAudioByte, por ejemplo, puede conectarse a un objeto ByteStreamToAudio, para hacer audio real en coma flotante. Por supuesto, otros tipos de códecs podrían incorporar la emisión directa de información de vídeo, como interface VideoCodec { entrada async byte stream indata; salida video stream outdata; /* nota: las transmisiones de vídeo aún no existen */ }; En la mayoría de los casos, se debería emplear el concepto de un códec más que el método «tu sabes hacerlo funcionar y yo no» que ahora utiliza, por ejemplo, WavPlayObject. Sin embargo, alguien debería ponerse a experimentar un poco antes de que se pueda dar por finalizada la API. Mi idea es proporcionar el vídeo como transmisiones asíncronas de algún tipo de datos nativo de &MCOP; que contenga imágenes. Este tipo de datos aún no está creado. Al hacerlo así, los conectores que tratan con las imágenes de vídeo pueden establecer enlaces de la misma manera que lo hacen los conectores de audio. Estas son algunas de las cosas que no se deben olvidar: Hay espacios de color RGB y YUV. El formato debería estar de algún modo unido al flujo. La sincronización es importante. Mi idea es permitir la posibilidad de volver a implementar la clase VideoFrame (imagen de vídeo) de forma que pueda almacenar información en un segmento de memoria compartida. De esa manera, serían posibles incluso las transmisiones de vídeo entre distintos procesos sin mucha dificultad. Sin embargo, la situación normal del vídeo es que las cosas estén en el mismo proceso, desde la decodificación hasta el dibujado. He hecho un prototipo de una implementación de transmisiones de vídeo, que se puede descargar aquí. Esto se deberá integrar en &MCOP; después de algunos experimentos. Se debería proporcionar un componente del procesado que soporte XMITSHM (con RGB y YUV), Martin Vogt me ha dicho que está trabajando en algo de ese tipo. En la actualidad, &MCOP; funciona en un solo hilo. Seguramente ésto no se podrá seguir manteniendo para el vídeo. De acuerdo. Estas son algunas de las cosas que hay que abordar con cuidado: SmartWrappers. No son seguros para multihilo debido al contador de referencias no seguro y otras cosas similares. Dispatcher / E/S. Tampoco es seguro. Sin embargo, lo que imagino es que habrá que hacer algunos módulos seguros en multihilo, tanto en transmisiones síncronas como asíncronas. De esa manera, con un sistema de flujo multihilo, se puede planificar la transmisión de señal sobre dos o más procesadores. Esto también ayudaría mucho al audio en los entornos multiprocesador. Cómo funcionaría: El sistema de transmisión decide qué módulos deberían calcular qué, así: Fotogramas de vídeo (con el método process_indata). Transmisiones de audio síncronas (calculateBlock). Otros transmisiones asíncronas, sobre todo transmisiones de bytes. Los módulos pueden calcular estas cosas en sus propios hilos. Para el audio, tiene sentido reutilizar los hilos (⪚, crear cuatro hilos para cuatro procesadores, independientemente de si están funcionando 100 módulos). Para el vídeo y la descompresión de bytes, puede ser más cómodo tener una implementación con bloqueos en un hilo propia, lo que se sincroniza con el resto de &MCOP; a través del sistema de transmisión. Los módulos pueden no utilizar funcionalidad de &MCOP; (como las llamadas remotas) durante las operaciones multihilo. El vídeo y el &MIDI; (y el audio) requieren sincronización. Básicamente ésto viene determinado por unos códigos de tiempo. La idea que tengo es conectar los códigos de tiempo con transmisión asíncrona, añadiendo un código de tiempo en cada paquete. Si envía dos fotogramas de vídeo, hágalo en dos paquetes (serán grandes de todas formas), para que pueda tener dos códigos de tiempo diferentes. El audio tienen códigos de tiempo implícitos, ya que es síncrono. Debería ser posible decir: un efecto especial se componen de estos módulos más sencillos. Los efectos especiales deberían tener el aspecto de un módulo &MCOP; normal (véase el enmascaramiento), pero de hecho constar de otros módulos. Esto es lo que hace falta en &arts-builder;. Todos los componentes del &GUI; serán módulos &MCOP;. Deberían de tener atributos como size (tamaño), label (etiqueta), color, etc. Un constructor RAD (&arts-builder;) debería ser capaz de componerlos visualmente. El &GUI; debería ser almacenable, mediante el almacenamiento de los atributos. El &MIDI; se implementará como transmisiones asíncronos. Hay dos opciones, una es utilizar las estructuras normales de &MCOP; para definir los tipos y la otra es introducir otros tipos propios. Creo que las estructuras normales deberían bastar, algo como: struct EventoMidi { byte b1,b2,b3; sequence<byte> existe; } Las transmisiones asíncronas deberían soportar tipos de transmisión propios.