#53
qué maravilla
#48
no, trabajo en Hospitalet pero no soy de allí. Tan chungo parezco?
qué maravilla
#48
no, trabajo en Hospitalet pero no soy de allí. Tan chungo parezco?
Pues no es para tanto uad como pensaba
OFERTASVer todas
-
beyerdynamic DT-770 Pro
-
-35%Set de grabación completo de Focusrite
-
-26%AKAI MPC Key 61
robinette escribió:por la longevidad de Scope.
Cuidado que las placas se van.
Gracias por el apunte del adaptador de PCi, aunque ¿dónde se colocan?
robinette escribió:Son solo 6... pero de los modernos. Casi ná.
http://www.johnbowen.com/solaris-overview.html
y ya ves lo que cuesta, ya sabemos que no son mismos productos, pero usan componetes supuestamente a misma capacidad o mas, no creo que un pulsar 2 se quede atras a lado de este solaris... por que el pulsar es sobretodo un comglomerado de herramientas y instrumentos virtuales que suenan desde la propia tarjeta sin tener queenviar el sonido a otra tarjeta.
recordemos que con pulsar 2 tienes emulaciones de prophet y minimoog, mas algunas herremaientas plugin de la misma tarjeta que funcioan con las DSP´s. y funcionan perfectos en windows 10 de 32 y 64bit, con esto digo que antes que UAD ya estaba esto desde tiempos remotos asi que UAD no es pinonera en esto, como dicen algunos...
[Este vídeo ya no está disponible en Youtube]
mod
Hola. Pedía Carmelo que interviniera para comentar un poco lo de la ¿locura? ¿utilidad? de los DSPs, a tenor de la incomprensión por el precio de los sistemas y plugins desarrollados para sistemas con DSP dentro.
Ya habéis derivado en otras cosas, pero me sabe mal no poner algo.
De precios no hablaré, porque eso siempre depende de cosas que no son el coste de las partes físicas, sino los esfuerzos de desarrollo y más aún lo que se espera que se pueda pagar por ello en el mecado. Pero sí puedo intentar contar qué es lo que hace diferente un DSP frente a un procesador convencional generalista.
Allá por los últimos 80s y primeros 90s sí era fácil comentar qué era un DSP y qué lo diferenciaba de un microprocesador ordinario o de un microcontrolador. A día de hoy todo es mucho más híbrido, con núcleos de DSP metidos en un microprocesador, lógica programable o FPGAs pequeñas dentro de los microcontroladores, y todo otro tipo de cruces. Y por supuesto sigue habiendo DSPs, que, al igual que los demás, han ido creciendo y transformándose, y que a día de hoy incorporan elementos que hace años parecían ajenos a ellos.
Tendemos a la integración de funciones en un solo chip y son tiempos de mestizaje electrónico que hacen borrosas las fronteras.
En esencia los DSPs nacen del deseo de proporcionar una arquitectura de procesamiento que responda de forma conveniente a las formas específicas de cálculo que demanda el uso de técnicas de procesado digital de señal. Las técnicas DSP con procesadores convenionales (muy limitados) en los 70s y 80s tenían unos tiempos de ejecución que se iban muy fuera de tiempo real. En los algoritmos de procesado de señal hay dos o tres tipos de cálculo muy reiterados (y relativamente parientes entre sí): convolución (o filtrado FIR), filtrado recursivo (IIR) y transformación de ida y vuelta entre dominio del tiempo y dominio de la frecuenia (la FFT). Analizando qué requisitos tienen este tipo de cálculos se definieron arquitecturas específicas para esos propósitos que dieron lugar a los DSPs, muy variados entre sí. En común a todos ellos la necesidad de acumular (sumar) el resultado de toda una cadena de productos (muestras por coeficientes de un filtro, por ejemplo).
Los DSPs eran sistemas, comparados con los procesadores convencionales de aquellos años, mucho más 'paralelos'. Era típico que hubiera dos buses de datos y dos buses de direcciones, para poder estar simultaneando los accesos a la RAM de muestras y a la ROM/Flash/RAM de coeficientes (por ejemplo los coeficientes de un filtro, o la respuesta impulsiva para una convolución, etc.). Las operaciones de multiplicación se hacían en un único ciclo, algo que necesita una lógica bastante compleja y que gasta por tanto mucho silicio, mientras los procesadores normales dilataban cada multiplicación durante varios ciclos porque tenían un multiplicador 'parcial' simple que había que rellamaar varias veces para completar un simple producto. En un DSP de hecho la operación de multiplicar se hacía a la vez que la de sumar porque había multiulicador y sumador independientes, dado que acumular (sumar) productos es algo frecuentísimo en cálculo DSP. Además existían unidades de direccionamiento (varias) específicamente pensadas para cálculo DSP. Por ejemplo el cálculo de FFT requiere lo que se llama dreccionamiento 'swap', algo que hacía temblar (gastar mucho tiempo) a un procesador normal, pero que en os DSPs quedaba resuelto por hardware en un único ciclo y en paralelo con la suma y el producto. Y así podríamos seguir.
Había también diferencias de resolución. Por ejemplo, los filtros a menudo trabajan con valores 'normales' de señal de entrada y de salida, pero internamente generan valores altísimos y que necesitan muchos más bits que las señales que tratan. En los DSPs, los valores intermedios de los cálculos se guardaban en registros de enorme número de bits (para la época) para evitar la pérdida de precisión. Y no siempre hacer las cosas en punto flotante vale. Porque es la diferencia (pequeña) entre valores gigantescos la que define el resultado, de forma que no siempre es admisible la pérdida de precisión de un punto flotante con una mantisa corta. Se necesitan mantisas de mucha resolución.
Y mil cosas más. No me extiendo. Pero eso justifica diferencias de orientación entre procesador genérico y procesador específico para tareas DSP.
A día de hoy, lo que decía. Hay mucho hibridaje, pero los DSPs también han ido avanzando a poder ofrecer más.
Pero esa es la teoría sobre el papel. En la práctica el hardware es sólo una parte. Y aprovechar bien el hardware exige saber de hardware, no bastan las típicas competencias de un programador 'normal'. Siempre pongo el ejemplo (segunda mitad de los 90) de un codificador de voz del que nos pasaron el código en C oficial de la ITU. Compilándolo con el compilador cruzado que permitía generar código para un DSP (no diré cuál) y que supuestamente realizaba muchas optimizaciones y sacaba provecho del DSP, el cálculo se salía más de 1000 veces de tiempo real. Es decir, para trata un segundo de audio necesitaba (ya el DSP) unos 16 minutos. Realizando una optimización de muchas de las funciones en C y además una codificación en ensamblador del DSP de las funciones más llamadas lo bajamos bastante pero aún lejos de lo que hacía falta para tiempo real. Acabamos teniendo que trabajar dos personas (ya muy formadas y con experiencia) durante un mes para conseguir llevar todo a ensamblador del DSP, cambiar estrategias de algoritmos para que fueran más eficientes en ese hardware concreto de ese DSP, etc. etc.
Me refiero a que dudo mucho de que haya tal grado de optimización en buena parte de los plugins que se venden para determinados DSPs. Las herramientas de compilación son ahora algo más inteligentes, y es cierto que la arquitectura de un procesador DSP mantiene aún hoy diferencias con uno genérico. Pero muchas de estas empresas pequeñas de nuestro mundo audio, en el caso de que lleguen a contar con esa experiencia, se ven obligadas a casarse con un determinado modelo de DSP para poder aprovechar el esfuerzo realizado. No sé cómo vamos a estar con esos sistemas DSP en cuanto a soporte/mantenimiento dentro de unos años, etc... Es más fácil mantener código genérico que algo tan especializado.
Ventajas en cómputo más que haberlas de partida, las hay si se aprovecha bien la arquitectura. Personalmente los DSPs los veo especialmente cara a sistemas móviles/portables sensibles al uso de la batería. No es comparable el comsumo de una CPU con el consumo de un DSP que refleja una arquitectura pensada al 100% para hacer lo que hace Ciertamente hay ventajas en el número de operaciones de punto flotante que puede calcular (en teoría) un DSP frente a un procesador normal, pero sólo se llega a ese rendimiento teórico con un esforzadísimo desarrollo de código adaptada al milímetro al DSP concreto del que se trate, y por otra parte los procesadores normales ante la pujanza de los temas multimedia / audio / vídeo... han ido incorporando algunas estrategias y recursos que antes parecían terreno exclusivo de los DSPs.
En definitiva. Lo que decía al principio. Hoy es tal el hibridaje que no existe una dicotomía tan clara DSP / Procesador, y es muy difícil valorar en términos generales, y sin olvidar que la enorme y costosísima experiencia y cercanía al hardware que exige aprovechar bien un DSP es algo que exige unos recursos bastante importantes por parte de los desarrolladores.
Ya habéis derivado en otras cosas, pero me sabe mal no poner algo.
De precios no hablaré, porque eso siempre depende de cosas que no son el coste de las partes físicas, sino los esfuerzos de desarrollo y más aún lo que se espera que se pueda pagar por ello en el mecado. Pero sí puedo intentar contar qué es lo que hace diferente un DSP frente a un procesador convencional generalista.
Allá por los últimos 80s y primeros 90s sí era fácil comentar qué era un DSP y qué lo diferenciaba de un microprocesador ordinario o de un microcontrolador. A día de hoy todo es mucho más híbrido, con núcleos de DSP metidos en un microprocesador, lógica programable o FPGAs pequeñas dentro de los microcontroladores, y todo otro tipo de cruces. Y por supuesto sigue habiendo DSPs, que, al igual que los demás, han ido creciendo y transformándose, y que a día de hoy incorporan elementos que hace años parecían ajenos a ellos.
Tendemos a la integración de funciones en un solo chip y son tiempos de mestizaje electrónico que hacen borrosas las fronteras.
En esencia los DSPs nacen del deseo de proporcionar una arquitectura de procesamiento que responda de forma conveniente a las formas específicas de cálculo que demanda el uso de técnicas de procesado digital de señal. Las técnicas DSP con procesadores convenionales (muy limitados) en los 70s y 80s tenían unos tiempos de ejecución que se iban muy fuera de tiempo real. En los algoritmos de procesado de señal hay dos o tres tipos de cálculo muy reiterados (y relativamente parientes entre sí): convolución (o filtrado FIR), filtrado recursivo (IIR) y transformación de ida y vuelta entre dominio del tiempo y dominio de la frecuenia (la FFT). Analizando qué requisitos tienen este tipo de cálculos se definieron arquitecturas específicas para esos propósitos que dieron lugar a los DSPs, muy variados entre sí. En común a todos ellos la necesidad de acumular (sumar) el resultado de toda una cadena de productos (muestras por coeficientes de un filtro, por ejemplo).
Los DSPs eran sistemas, comparados con los procesadores convencionales de aquellos años, mucho más 'paralelos'. Era típico que hubiera dos buses de datos y dos buses de direcciones, para poder estar simultaneando los accesos a la RAM de muestras y a la ROM/Flash/RAM de coeficientes (por ejemplo los coeficientes de un filtro, o la respuesta impulsiva para una convolución, etc.). Las operaciones de multiplicación se hacían en un único ciclo, algo que necesita una lógica bastante compleja y que gasta por tanto mucho silicio, mientras los procesadores normales dilataban cada multiplicación durante varios ciclos porque tenían un multiplicador 'parcial' simple que había que rellamaar varias veces para completar un simple producto. En un DSP de hecho la operación de multiplicar se hacía a la vez que la de sumar porque había multiulicador y sumador independientes, dado que acumular (sumar) productos es algo frecuentísimo en cálculo DSP. Además existían unidades de direccionamiento (varias) específicamente pensadas para cálculo DSP. Por ejemplo el cálculo de FFT requiere lo que se llama dreccionamiento 'swap', algo que hacía temblar (gastar mucho tiempo) a un procesador normal, pero que en os DSPs quedaba resuelto por hardware en un único ciclo y en paralelo con la suma y el producto. Y así podríamos seguir.
Había también diferencias de resolución. Por ejemplo, los filtros a menudo trabajan con valores 'normales' de señal de entrada y de salida, pero internamente generan valores altísimos y que necesitan muchos más bits que las señales que tratan. En los DSPs, los valores intermedios de los cálculos se guardaban en registros de enorme número de bits (para la época) para evitar la pérdida de precisión. Y no siempre hacer las cosas en punto flotante vale. Porque es la diferencia (pequeña) entre valores gigantescos la que define el resultado, de forma que no siempre es admisible la pérdida de precisión de un punto flotante con una mantisa corta. Se necesitan mantisas de mucha resolución.
Y mil cosas más. No me extiendo. Pero eso justifica diferencias de orientación entre procesador genérico y procesador específico para tareas DSP.
A día de hoy, lo que decía. Hay mucho hibridaje, pero los DSPs también han ido avanzando a poder ofrecer más.
Pero esa es la teoría sobre el papel. En la práctica el hardware es sólo una parte. Y aprovechar bien el hardware exige saber de hardware, no bastan las típicas competencias de un programador 'normal'. Siempre pongo el ejemplo (segunda mitad de los 90) de un codificador de voz del que nos pasaron el código en C oficial de la ITU. Compilándolo con el compilador cruzado que permitía generar código para un DSP (no diré cuál) y que supuestamente realizaba muchas optimizaciones y sacaba provecho del DSP, el cálculo se salía más de 1000 veces de tiempo real. Es decir, para trata un segundo de audio necesitaba (ya el DSP) unos 16 minutos. Realizando una optimización de muchas de las funciones en C y además una codificación en ensamblador del DSP de las funciones más llamadas lo bajamos bastante pero aún lejos de lo que hacía falta para tiempo real. Acabamos teniendo que trabajar dos personas (ya muy formadas y con experiencia) durante un mes para conseguir llevar todo a ensamblador del DSP, cambiar estrategias de algoritmos para que fueran más eficientes en ese hardware concreto de ese DSP, etc. etc.
Me refiero a que dudo mucho de que haya tal grado de optimización en buena parte de los plugins que se venden para determinados DSPs. Las herramientas de compilación son ahora algo más inteligentes, y es cierto que la arquitectura de un procesador DSP mantiene aún hoy diferencias con uno genérico. Pero muchas de estas empresas pequeñas de nuestro mundo audio, en el caso de que lleguen a contar con esa experiencia, se ven obligadas a casarse con un determinado modelo de DSP para poder aprovechar el esfuerzo realizado. No sé cómo vamos a estar con esos sistemas DSP en cuanto a soporte/mantenimiento dentro de unos años, etc... Es más fácil mantener código genérico que algo tan especializado.
Ventajas en cómputo más que haberlas de partida, las hay si se aprovecha bien la arquitectura. Personalmente los DSPs los veo especialmente cara a sistemas móviles/portables sensibles al uso de la batería. No es comparable el comsumo de una CPU con el consumo de un DSP que refleja una arquitectura pensada al 100% para hacer lo que hace Ciertamente hay ventajas en el número de operaciones de punto flotante que puede calcular (en teoría) un DSP frente a un procesador normal, pero sólo se llega a ese rendimiento teórico con un esforzadísimo desarrollo de código adaptada al milímetro al DSP concreto del que se trate, y por otra parte los procesadores normales ante la pujanza de los temas multimedia / audio / vídeo... han ido incorporando algunas estrategias y recursos que antes parecían terreno exclusivo de los DSPs.
En definitiva. Lo que decía al principio. Hoy es tal el hibridaje que no existe una dicotomía tan clara DSP / Procesador, y es muy difícil valorar en términos generales, y sin olvidar que la enorme y costosísima experiencia y cercanía al hardware que exige aprovechar bien un DSP es algo que exige unos recursos bastante importantes por parte de los desarrolladores.
Sí, a los Motorola 68xxx se les denominaba procesadores tontos por ser hábiles para hacer sólo una cosa.
Y, una cosa, estos nuevos DSP mejores, baratos no son, ¿verdad?
Y, una cosa, estos nuevos DSP mejores, baratos no son, ¿verdad?
pablofcid escribió:En definitiva. Lo que decía al principio. Hoy es tal el hibridaje que no existe una dicotomía tan clara DSP / Procesador, y es muy difícil valorar en términos generales, y sin olvidar que la enorme y costosísima experiencia y cercanía al hardware que exige aprovechar bien un DSP es algo que exige unos recursos bastante importantes por parte de los desarrolladores.
hola, pablo, antes que nada, gracias por la aportacion con tu comentario, con esto que dices aqui ¿te refieres a que en años anterioes a principios de este siglo, existio una dicotomia mucho mas clara de DSP/procesador que en la actualidad?
Libertizer escribió:existio una dicotomia mucho mas clarra de DSP/procesador que en la actualidad?
Sin esperar a que responda Pablo, por supuesto; eso ya lo apuntaba ayer, por encima, yo.
mod
Hace años eran dos mundos totalmente diferentes. Hoy muchos procesadores e incluso microcontroladores llevan además de la CPU 'normal' algún copro de tipo DSP y los DSPs llevan elementos para poder completar un sistema completo sin necesidad de otros procesadres adicionales. Y en general tenemos por todas partes chips que son realmente varios procesadores, periféricos, y mil cosas más conviviendo.
Un DSP hoy sigue teniendo como foco y como argumento su arquitectura específica para cálculo tipo DSP y su voracidad para realizar a toda mecha suma de productos. Y un procesador normal no va a gastar silicio en implementar tantas funciones específicas porque la gente que vaya a usar un reproductor MP3 o un procesador de texto no las necesita.
Diferencias claro que sigue habiendo. Aquello de 'zapatero a tus zapatos'.
Pero lo que no está tan claro es que tanto especialización como requiere el tema de desarrollo de código para procesadores DSP sea algo 'asequible' para los desarrolladores de temas audio en las empresas. Muchos DSPs se pensaron para el mercado (de millones de unidades) de móviles y semejantes, no para esto nuestro. El que cuesten tanto los sistemas DSP 'nuestros' pese a que usen DSPs que también pueden en algunos casos estar presentes en móviles que no cuestan gran cosa, hemos de entenderlo desde esa perspectiva.
Mi miedo es que estos entornos son de 'alto riesgo' para quien compra. Caros y con un único proveedor, pero todavía ligados a las necesidades de actualización permanente para que sigan siendo operativos, porque están al final integrados con ordenadores, puentes hacia los DAWs, y bla bla...Interesante paa un ámbito profesional que amortice ese gasto de forma más o menos segura y temprana. Pero mucho menos justificable (salvo como capricho, que es un argumento tan bueno como cualquier otro) para algo menos profesional.
Un DSP hoy sigue teniendo como foco y como argumento su arquitectura específica para cálculo tipo DSP y su voracidad para realizar a toda mecha suma de productos. Y un procesador normal no va a gastar silicio en implementar tantas funciones específicas porque la gente que vaya a usar un reproductor MP3 o un procesador de texto no las necesita.
Diferencias claro que sigue habiendo. Aquello de 'zapatero a tus zapatos'.
Pero lo que no está tan claro es que tanto especialización como requiere el tema de desarrollo de código para procesadores DSP sea algo 'asequible' para los desarrolladores de temas audio en las empresas. Muchos DSPs se pensaron para el mercado (de millones de unidades) de móviles y semejantes, no para esto nuestro. El que cuesten tanto los sistemas DSP 'nuestros' pese a que usen DSPs que también pueden en algunos casos estar presentes en móviles que no cuestan gran cosa, hemos de entenderlo desde esa perspectiva.
Mi miedo es que estos entornos son de 'alto riesgo' para quien compra. Caros y con un único proveedor, pero todavía ligados a las necesidades de actualización permanente para que sigan siendo operativos, porque están al final integrados con ordenadores, puentes hacia los DAWs, y bla bla...Interesante paa un ámbito profesional que amortice ese gasto de forma más o menos segura y temprana. Pero mucho menos justificable (salvo como capricho, que es un argumento tan bueno como cualquier otro) para algo menos profesional.
mod
#66
De precios hace años que no estoy puesto. De hecho hace siglos que no reviso qué es lo que ofrece el mundo de los DSPs.
Lo que sí hay es una variación de precio por volumen de compra salvaje. Y no hace falta decir que estos fabricantes de nuestro sector piden bien poquito.
De precios hace años que no estoy puesto. De hecho hace siglos que no reviso qué es lo que ofrece el mundo de los DSPs.
Lo que sí hay es una variación de precio por volumen de compra salvaje. Y no hace falta decir que estos fabricantes de nuestro sector piden bien poquito.
Cuanto odio veo por aquí. Me da la sensación que no es que no os gusten sus plugins, es que no queréis que gusten a nadie.
Además, me da la sensación que no habéis usado sus plugins.
Los 1176 mkii son realmente increíbles, son los únicos que puedo configurarlos tan rápido como mi ua 1176 real, además que suenan bastante mejor que cualquier otra emulación que haya probado (y tengo el mercury original por cierto).
El Manley Massive-Passive suena de escándalo, al igual que la colección la2a, distressor, ssl4009 mkii lo mismo.
Los pultec mkii no suenan para nada como mis cartec (numero de serie n50 y 51) pero suenan bastante más dulces que los waves puigtech.
Para cuando no quiero usar mis 1073 reales, mis capi vp28 o cualquiera d emis equipos, el unison es una maravilla (que no veo que habléis mucho de ello).
La estabilidad de las Apollo son dignas de mención, jamás me dio un solo problema desde 2015 que la tengo).
Que tiene plugins mierdosos, pues si, pero cuales son, versiones de 2010 para uad 1 que no han sido actualizadas, versiones de brainworxs como el shadowhills Hills o algunas basuras de Softube (aunque las últimas están bien).
Curioso que cuando la gente echa pestes de algo, muchos no saben de qué hablan y otros solo hablan de lo malo.
Que es un producto caro? Si.
Que tiene emulaciones viejas que suenan meh, también.
Que es el mejor sistema dsp actualmente, también.
Que puedes usarlo en tiempo real mientras grabas, sep.
Que tiene emulaciones bestiales, si.
Que es hyper estable, lo mismo.
Que es un producto sencillo de vender en el mercado de segunda mano, si.
Que te compras una satélite solo para aprovechar el 50% de la tecnología de uad, haberte informado mejor.
Saludos
Además, me da la sensación que no habéis usado sus plugins.
Los 1176 mkii son realmente increíbles, son los únicos que puedo configurarlos tan rápido como mi ua 1176 real, además que suenan bastante mejor que cualquier otra emulación que haya probado (y tengo el mercury original por cierto).
El Manley Massive-Passive suena de escándalo, al igual que la colección la2a, distressor, ssl4009 mkii lo mismo.
Los pultec mkii no suenan para nada como mis cartec (numero de serie n50 y 51) pero suenan bastante más dulces que los waves puigtech.
Para cuando no quiero usar mis 1073 reales, mis capi vp28 o cualquiera d emis equipos, el unison es una maravilla (que no veo que habléis mucho de ello).
La estabilidad de las Apollo son dignas de mención, jamás me dio un solo problema desde 2015 que la tengo).
Que tiene plugins mierdosos, pues si, pero cuales son, versiones de 2010 para uad 1 que no han sido actualizadas, versiones de brainworxs como el shadowhills Hills o algunas basuras de Softube (aunque las últimas están bien).
Curioso que cuando la gente echa pestes de algo, muchos no saben de qué hablan y otros solo hablan de lo malo.
Que es un producto caro? Si.
Que tiene emulaciones viejas que suenan meh, también.
Que es el mejor sistema dsp actualmente, también.
Que puedes usarlo en tiempo real mientras grabas, sep.
Que tiene emulaciones bestiales, si.
Que es hyper estable, lo mismo.
Que es un producto sencillo de vender en el mercado de segunda mano, si.
Que te compras una satélite solo para aprovechar el 50% de la tecnología de uad, haberte informado mejor.
Saludos
pablofcid escribió:Mi miedo es que estos entornos son de 'alto riesgo' para quien compra. Caros y con un único proveedor
No te falta razón; pero mira cómo cambian los precios del otro único proveedor y lo vulnerables que son los usuarios, de está comunidad (y actividad más o menos) sin ir más lejos.
Imaginemos que toda la cúpula y entramado de Intel se hacen Jipis o deciden no ganar más, que las plusvalías son muy malas,todo el mundo a por Power Pc como locos...
LolA m 7 escribió:estos nuevos DSP mejores, baratos no son, ¿verdad?
si me los regalan en navidad, son gratis...
no creo que el dinero de una DSP moderna sea mejor y por ello este justificado su coste... una pulsar 2+ en 2002 costaba 1590euros nuevo en tienda, una power pulsar+ 3299 y una pulsar XTC 1290, mientras que la luna 2 costaba 450, creamware luna box costaba mas que una digigram VX222...
tengo pruebas del delito
francesco k escribió:Cuánto odio veo por aquí
Hombre, yo creo que es es mucho imputar; sí que me quedo con que alguno no ha probado las emulaciones de UAD (y puede que tampoco conozca el original) y que incluso haya quién prefiera gastar en Intel y seguir con la descarga de programas demo.
LolA m 7 escribió:incluso haya quién prefiera gastar en Intel y seguir con la descarga de programas demo.
no te olvides que hay quien tenga viejos hardware con sus software original de ha hace 16 años como tengo yo ( creo que tu ere uno) y en mi casono se note nada diferente con mi nuevo UAD comprado hace 2 años... hay gente para todo y para todos los gustos y colores, el lo bonito de esta vida, sino seria muy aburrido todo.
Hilos similares
Nuevo post
Regístrate o identifícate para poder postear en este hilo