PutoOver escribió:
Lo que descubrimos Sharl y yo, en el consumo del mixer es:
Que cuando cargas un plugin que ya has cargado no consume CPU o muy poco. Sin embargo, su haces un ruteo en el mixer en serie, con canales que estan cargados el susodicho plugin, vuelve a consumir. Esto produce que el FL se sature cuando el marcador de consumo del FL llega a niveles altos, aunque tu CPU este desahogada.
Ejemplo:
Cargamos un plugin de alto consumo en el track 1. Cargamos el mismo plugin en el track 2, track 3, track 4, etc.. el consumo de CPU apenas subira aunque hayamos metido un plugin que te consuma un 30% (por ekemplo).
En el momento que ruteemos en SERIE el track 1 con el track 2 y sucesivamente, el uso de CPU (segun FL) se disparara, provocando underruns.
Me parece logico que sea asi. Asi sin meternos en estudios mas profundos porque yo personalmente no soy un ingeniero ni un programador para meterme en camisas de once varas de las que luego no sepa salir,
,pero a simple lógica:
Si un plugin esta cargado por ejemplo en dos pistas diferentes, Fl, trabajando a tiempo real, puede hacer lo siguiente. Cargar ese plugin (subprograma) en memoria, una sola vez. Dado que se esta utilizando en dos canales por ejemplo, y la posibilidad de enviar una cantidad "X"de datos es muy superior al que el de flujo real de bits de audio, puede enviar alternadamente los datos de un track y de otro con sus correspondientes parametros, y a traves de un solo subprograma tener el plugin trabajando en dos pistas.
Ahora bien, ruteamos la pista uno a la pista dos. Los datos entran al subprograma (plugin) con sus correspondientes parametros y se procesan. (ya hemos realizado la misma operacion, con su correspondiente demora temporal que en el caso anterior). Ahora bien, en el caso de que solo utilice un mismo subprograma tambien para la pista dos, los datos que se habran almacenado en un buffer temporal, vuelven a entrar con los parametros ahora de la pista dos. Esto conlleva muchas operaciones por lo que es mas eficiente volver a cargar otro subprograma de nuevo igual en memoria. Por lo que ya estamos ocupando mas cpu, tanto en procesos como en uso de memoria.
Vamos que mi opinion, si tienes un plugin en varios tracks al mismo tiempo el motor de audio puede apañarselas para teniendolo solo una vez en memoria (ese conjunto de instrucciones y funciones ocupando solo una vez al memoria) conseguir que las señales procedentes de varios tracks, con sus parametros del efectos (imaginemos por ejemplo el ratio de un compresor) sean procesadas.
Si despues hacemos ruteos mas complejos al programa no le queda mas remedio que utilizar acumuladores o buffers para reintroducir los valores en el subprograma, o bien crear ese mismo subprograma en otro "lugar" de la memoria para que trabaje independiente. Esto logicamente consume mas recursos.
Como ya digo es mi forma de abstraer de manera muy basica el funcionemiento de los motores de audio (que por cierto, luego al parecer cada uno es un mundo), por supuesto que puede ser muy simplista y ahora puede llegar cualquier informaitco a darle la vuelta a todo lo que he dicho. Pero he leido en mas de una ocasion que a grandes rasgos el sistema en que un daw trabaja con los plugins vst y nativos debe enfocarse como el de un gran estudio que utiliza dispositivos hardware y sumadores, combinadores, buses... para lograr sacarle el maximo partido a todo. Esto esquematicamente. Luego la diferencia es que a tiempo real un mismo subprograma puesto que la velocidad de proceso es mucho mayor que la del audio le de tiempo a procesar 4 señales o mas segun la latencia a la que estemos trabajando. Los plugins nativos de cualquier daw seran los que mejor entiendan a cada sistema y puedan hacerlo de esa manera. A lo mejor por ello a veces sacrifican la calidad, con sus execpciones claro, y por eso los vst independientes suelen ser mejores.
