La metodología de programación basada en flujo para sistemas audiovisuales en tiempo real se fundamenta en tres principios técnicos interdependientes.
El primer principio es la **Estructura y Modularidad Arquitectónica**. Este dicta la necesidad de abandonar las arquitecturas de red monolíticas en favor de una descomposición funcional rigurosa. La lógica del proyecto debe ser segmentada en subsistemas discretos, cada uno encapsulado dentro de un Componente (`Base COMP` o `Container COMP`). Cada componente debe ser diseñado para ejecutar una función específica y bien delimitada (principio de responsabilidad única), presentando una interfaz de E/S (Inputs/Outputs) explícita que abstrae su complejidad interna.
Este enfoque de «caja negra» no solo mejora drásticamente la legibilidad y el mantenimiento de la red, sino que también facilita la depuración aislada, el perfilado de rendimiento por componente y la gestión de estados complejos. Una arquitectura modular permite el desarrollo paralelo y la integración de unidades funcionales probadas, resultando en un sistema final más robusto y escalable.
El segundo principio integra la **Nomenclatura, Codificación Visual y Disposición del Flujo de Datos**.
-La **nomenclatura** debe ser estricta y sistemática. Cada operador ha de ser nombrado inmediatamente después de su creación, empleando una convención coherente que denote su tipo y función (e.g., `geo_particleSystem`, `sel_activeScene`, `math_normalizeRange`). Esta disciplina es crítica para la referenciación mediante scripting (Python, T-Script), la depuración y la legibilidad general del grafo. Los operadores `In` y `Out` dentro de un componente constituyen su API pública y su nomenclatura debe ser inequívoca.
-La **codificación por color** (atajo ‘C’) debe ser empleada como una capa de metadatos visuales para la clasificación funcional de los nodos. Una posible taxonomía cromática podría ser: verde para generadores de datos (fuentes), azul para filtros y procesadores, rojo para selectores y lógica de control (switches, logic OPs), púrpura para conversiones de tipo de datos (e.g., `CHOP to TOP`), y naranja/amarillo para los nodos de salida final (`Out TOP`, `Render TOP`). Esta sintaxis visual acelera la identificación de bloques funcionales.
-La **disposición en la red** debe respetar el paradigma fundamental de flujo de datos de izquierda a derecha, que es una representación visual directa del Directed Acyclic Graph (DAG) subyacente. Las conexiones deben ser predominantemente horizontales, minimizando cruces y rutas inversas para mantener una correlación directa entre la posición espacial y la secuencia de ejecución temporal. La entrada de un operador está fijada a su lado izquierdo y su salida al derecho, independientemente de su ubicación absoluta en el canvas; por tanto, la organización espacial es una convención no opcional para la mantenibilidad profesional.
El tercer principio es la **Creación, Implementación y Reutilización de Componentes**. Se debe priorizar una estrategia de desarrollo que maximice la eficiencia mediante la reutilización de activos. Esto implica la implementación de componentes preexistentes (`.tox`), ya sea desde la `Palette` oficial, repositorios de la comunidad, o librerías internas del proyecto/estudio. Cuando se desarrolla una nueva funcionalidad, el procedimiento estándar debe ser su encapsulación inmediata en un `Container COMP` o `Base COMP`, seguido de su exportación como un archivo `.tox`. Este proceso transforma una sección de la red en una unidad de software modular, portable y versionable. Además, el desarrollo de componentes debe incluir la creación de interfaces de control mediante Parámetros Personalizados (Custom Parameters). Esto permite manipular el comportamiento del componente desde un nivel de abstracción superior, sin necesidad de acceder a su red interna, lo cual es esencial para construir herramientas e interfaces de usuario finales eficientes y amigables.