Aplaudo la iniciativa de este topic. Si van saliendo más ideas las agruparé ordenadamente en un Postit, ya que ésta puede ser la respuesta a una de las preguntas más recurrentes de este foro.
#2 ...a lo que hace referencia deestreeloi es a la 1a de las tres sugerencias que hice anteriormente en otro post para mejorar el rendimiento del programa. En vez de poner la URL donde lo posteé, lo copiaré de nuevo, (con algun pequeño cambio):
---
Truquillos:
a) Hay un menú ahí escondidito, en Tools/macros/
Switch smart disable for all plugins. Si le damos ahí, lo que ocurre en esencia es que
cuando algún plugin no está en uso, se desactiva... un poco es eso. Lo cual mejora bastante el rendimiento de la CPU. Hay que hacerlo en cada proyecto, es decir, debe realizarse esta acción cada vez que carguemos un proyecto nuevo, pues los plugins varian de un proyecto a otro. Puede hacerse solamente en un determinado plugin si se desea, abriendo la ventana del plugin, dándole al triangulito de la parte superior izquierda, y en el menú que nos aparece, hay la opción "Smart disable", que por defecto está desactivada. Si la activamos, ése, y solo ese plugin trabajará con mejor rendimiento, por eso recomiendo aplicar la herramienta Switch smart disable for all plugins, pues como su nombre indica nos hace este proceso para todos los plugins de forma automática.
b)
ASIO4ALL: Hay una barra, la cual yo llamo la barra de compromiso (barra de
tamaño de buffer el realidad):
En la imagen, dicha barra está en la posición 512 Samples. Si aumentamos el buffer, aumentamos la latencia (retardo en milisegundos ms, cosa mala) pero tenemos menos "Glitches" (cosa buena, ya que no queremos ruidos guarros en definitiva, cuanto menos mejor). Por contra si reducimos el buffer, reducimos la latencia (cosa buena) pero habrá más probabilidades de que aparezcan esos "Glitches" (cosa mala malisimaXD). Es por ello que debemos adoptar un "compromiso" en ese aspecto, mínima latencia con mínimos "Glitches", y depende mucho de cada PC, de cada proyecto... lo suyo es ir probando hasta encontrar un punto estable que nos convenza.
Más sobre ASIO4All en:
http://www.image-line.com/support/FLHelp/html/envsettings_asio4all.htm
c)
FL (Extended memory): Eso nos permite básicamente trabajar con
más RAM. Los samples cargan muchisimo la Memoria RAM y apenas cargan la CPU. Para ejecutar FL en versión de memoria extendida, vamos a donde quiera que tengamos la carpeta "Image-line/FL" y ejecutamos el icono que tiene como nombre "FL (extended memory).exe". Debo decir que mi acceso directo está asociado a la versión de memoria extendida por defecto, y no al FL estándard, es decir, siempre uso en memoria extendida, es una maravilla.
---
#3 ...Con eso que dices, totalmente de acuerdo, poner la misma reverb por inserción cada vez es un despilfarro, pero también se deberia matizar en que casos se puede aplicar y en que casos no. Por ejemplo, si quieres hacer "marcianadas" y poner una reverb a un instrumento, y otra distinta a otro instrumento, es algo que se puede hacer, pero entonces lo tendrás que hacer por envios distintos o directamente por inserción. Lo digo porque corre la leyenda de que la reverb SIEMPRE va por envio (con lo que personalmente no estoy deacuerdo), en todo caso es conveniente trabajar con una reverb general. En música lo de siempre/nunca no va muy bien... siempre es mejor el a veces, normalmente, en algunos casos... jeje.
Pero sí zentrix, estoy contigo, es una forma de optimizar.
Pues eso, se piden más ideas para optimizar FL (tanto proyectos como el programa en si). Si alguien tiene algo que decir sobre lo que se ha dicho, porfavor lo haga
](https://statics.soniccdn.com/images/smilies/eusa_wall.gif "](*,)")
