El Jue 15 Sep 2005 08:56, David Asorey Álvarez escribió:
En eso no te puedo ayudar yo, deberás preguntarle a alguien que conozca de laptops, y por otra parte, ese kernel es fantástico, pero no ha sido demasiado testeado: fue modificado y adaptado en gran parte por Free Ekanayaka, de DeMuDi.
No hay problema, sólo tendría que recompilar y listo. Sólo lo mencionaba a título informativo.
Sería interesante si acaso supieras cómo reemplaza un kernel tal como viene en Knoppix, por otro, dado que los tutoriales que leí de la WEB estaban muy desactualizados, y aún no realicé testeos serios al respecto. Así que la solución en nuestro caso fue dejar un kernel-multimedia semi-instalado, que se termina de instalar durante el proceso de volcado a HD, pero sería interesante que fuera una opción dentro del mismo live-cd corriendo como live-cd
Es definitiva, nos encantaría dejar un sólo kernel que hiciera todo bien, pero, es un objetivo a largo plazo.
Pues todo es cuestión de coger el 2.6.12-multimedia, las fuentes y parches y recompilarlo incluyendo más módulos. No creo que se estropee el rendimiento, puesto que los módulos que no se utilizan no se cargan en memoria. Voy a intentar recompilar algún kernel, a ver qué me voy encontrando. Ya os contaré ...
Sería un aporte fantástico a Musix. Te comento que por lo que estuve leyendo en LAU y aGNUla, lo mejor sería tomar un 2.6.13 dado que mucha gente ha encontrado problemas con 2.6.12 Por ejemplo en 2.6.12 no estaban los módulo para las placas layla20 y 24 y toda la línea de la misma fabrica, y además se reportan otros problemas que no recuerdo, con respecto al 2.6.12
¿Por qué eliminar apache? ¿No tendría utilidad? Pregunto desde el desconocimiento total sobre apache.
Apache es un servidor web (mejor dicho, es El Servidor Web), pero no creo que sea necesario. Por cierto, yo haría apt-get remove libapr0 y quitaría todo lo relativo a apache (libapr0 -> "lib apache runtime").
Hecho, me convencí de que, el que quiere apache, es porque ya tiene acceso a Internet, y en tal caso lo instalaría con un simple apt-get. El usuario músico no experimentado en Linux no lo va a extrañar en Musix y, en última instancia, lo volvemos a incluir.
Squid parece no ser importante para Musix, necesitaría saber si realmente lo necesitamos o no.
Creo poder decir con seguridad que no es necesario. Se suele utilizar en redes más o menos grandes (oficinas, empresas) para dar servicio de www a los usuarios.
Quitado.
Claro, no sé cómo estará ahora, pero en su momento cuando probé, pedía 121mb!
El problema con Lilypond es que hasta la versión 2.4 se basaba en TeX, que es un sistema enorme. La nueva versión de Lilypond (2.6) ya no necesita TeX, pero no hay (que yo sepa) un paquete para Debian. Yo lo que se puede hacer es instalar el autopackge de su web. Es muy fácil, reproduzco los pasos que habría que seguir: 1. Bajar el lilypond: wget http://lilypond.org/download/binaries/autopackage/lilypond-2.6.3.1.x86.pack age 2. Ejecutar el "installer" como root: chmod +x lilypond-2.6.3.1.x86.package su -c ./lilypond-2.6.3.1.x86.package 3. Seguir las instrucciones en pantalla. No se cuanto ocupará una vez instalado.
Anotado. Suena interesante, pero creo que lo mejor será compilarlo, hacer un .deb, y de ese modo le damos al usuario una única forma de manejarse con las dependencias, actualización del sistema, etc. Veremos si podemos instalarlo.
Solfege pide 9mb
Para que vaya bien, hay que instalar el paquete python-gnome2-extras. No lo pide como dependencia, pero es necesario (creo que el "bug" ya está reportado).
Anotado, veremos qué hacemos, Ear training program for GNOME2 GNU Solfege is an ear training program for X Window written in python, using the GTK+ 2.0 and GNOME2 libraries. You can practice harmonic and melodic intervals, chords, scales and rhythms, and you can add new exercises using a simple plain text file format.
*Anoté eso para ver en la próxima versión de Musix, realmente es mi intención que lilypond esté allí. " It produces beautiful sheet music using a high level description file as input." Nunca lo vi funcionar.
En pocas palabras: una vez que lo aprendes, es imprescindible. Le da mil vueltas a cualquier Finale, Sibelius o lo que se tercie. Eso sí, cuesta un poco al principio. En mi web tengo algunos ejemplos: http://www.laclavedefa.org/lecciones.html
Luego veré
Tal cual, el problema se presentó porque debimos compilar timidity y tuve un problema en un punto, y no se compiló esa interfaz, pero yo la prefería también, de hecho está así en musix 0.23
Para que se compile la interfaz gtk hay que tener instalado el paquete gtk-devel.
:D
¿Tenés un gtkrc con ese tema? Nos vendría bien testearlo: el tema elegido para gtk tiene que ver casi exclusivamente con que las perillas de Jamin y otros como gamix se vieran bien (además de fbpanel, también)
Mi .gtkrc suele ser un link al gtkrc que viene con el paquete: su -c apt-get install gtk-engines-industrial ln -s /usr/share/themes/Indubstrial/gtk/gtkrc ./gtkrc
De todas formas, hay una pequeña utilidad para probar los temas gtk1.2 y gtk2.x que se llama gtk-theme-switch (incluye dos ejecutables, switch y switch2). Mi sugerencia sería instalar todos los gtk-engines y ésta utilidad. Una vez probados y seleccionado el más adecuado, podrían borrarse los demás: su -c apt-get install gtk-theme-switch gtk-engines-* gtk2-engines-*
Interesantísimas aplicaciones. Y probé todo. El problema con el tema industrial es que no produce resultados visuales lo suficientemente claros en Jamin y otros programas. Por ejemplo el tema xfce4.0 sí lo hace, o el xfce-redmon (que es el presente en Musix) Yo preferiría dejar el actual tema gtk2, modificar el gtk1.2, y quizá cambiar el tema KDE a plastic, que es cierto que quizá moleste menos, aunque es menos "brillante" o "lujoso". Pero en definitiva el usuario puede elegir entro otros temas desde el panel de control de kde: kcontrol, incluso al instalar esos paquetes gtk, en kcontrol apareció, dentro de Aspecto y Temas "GTK Styles and Fonts", y lo que intenta es resolver el problema de la "incompatibilidad" de temas. Yo no sé si esto de la incompatibilidad es tan así, dado que, quizá, preferiría que Jamin se viera distinto al resto, y que se viera lo mejor posible, como es con el tema xfce4.0, otro que me pareció interesante es xfce-kolors, y es totalmente compatible en colores con Plastic de KDE, quizá deberíamos dejar ese :D Además he notado que xfce-kolors achica los requerimientos de resolucion horizontal en pixeles de jamin.... deberíamos probarlo...
Lo que pasa es que, el papel que cumple Musix dentro del Software Libre casi no tendría sentido si hiciéramos algo así: somos parte de un grupo de gente que [... sigue ...]
Estoy de acuerdo en la filosofía de Musix.
No voy a hacer una disgresión sobre si el soft privativo o los algoritmos patentados son éticamente aceptables o no. No es la lista de correo adecuada ;-)
Pero ...
Simplemente quería hacer notar una realidad. El formato mp3 es el formato de audio comprimido más usado y un músico que se acerque a Musix por primera vez creo que esperará poder crear un mp3 con sus creaciones.
Si, es una lamentable realidad. Lo que ocurre básicamente es que si le damos soporte a la codificación hacia mp3 podemos tener problemas en EEUU.
Desde el punto de vista técnico sería sencillo habilitar la compresión mp3: Un "script" que haga un wget http://debian.nsu.ru/debian-marillat/pool/main/l/lame/lame_3.96.1-1_i386.de b y luego dpkg -i lame_3.96.1-1_i386.deb
Y bueno, los que vivan en países en los que no hayan problemas de patentes, pueden hacer eso, en Argentina no hay problemas con eso.
Creo recordar que lame no tiene dependencias raras, así que no habría que tocar el /etc/apt/sources.list
¿Como conciliar estas dos posturas? Por un lado queremos que el soft libre avance y que las ideas (=algoritmos) no sean patentables, o que sean de libre distribución. Por otra parte, tenemos un formato muy difundido que muchos músicos esperarían poder utilizar para registrar sus creaciones. Además, disponemos de otro formato comprimido (ogg) que proporciona una calidad comparable, si no superior, al mp3.
Es exactamente 2 veces superior al mp3. Podés hacer la prueba comprimiendo un .wav a .ogg a 64kb/ps. y luego lo mismo pero hacia mp3 a 64kb/ps: escucharás la mitad de calidad de parte del mp3, y si lo analizás con un analizador de espectros verás que faltan muchas frecuencias que en el ogg no faltan.
Mi idea sería un lanzador titulado "Instalar codificador de MP3" o algo parecido. Cuando el usuario lo "pinchase", mostrarle un mensaje (un cuadro de diálogo o una página HTML en dillo) en el cual se le explicase porqué no debería usar MP3 u otros formatos propietarios, explicándole que existen alternativas de calidad. A continuación un mensaje de confirmación del tipo ... """ Si a pesar de lo que acaba de leer insiste en utilizar formatos propietarios y quiere utilizar el algoritmo propietario de codificación MP3, por favor siga estos pasos: wget http://debian.nsu.ru/debian-marillat/pool/main/l/lame/lame_3.96.1-1_i386.de b y luego dpkg -i lame_3.96.1-1_i386.deb El equipo de Musix no se responsabiliza del uso de este programa, bla, bla, bla ... """ o algo parecido.
Es buena idea, pero tengo que consultarlo con gente como Daniel Olivera de Ututo-e, y en última instancia con Richard Stallman, pero creo que no lo podremos hacer, por lo que te comentaba más arriba. Bueno, seguimos en contacto! (estoy tratando de acostumbrarme al "plastik" a ver si va bien) -- Marcos Guglielmetti *Desocupado, busco trabajo.* cel: (0221) 15-5442691 tel: (0221) 427-5391 fecha: vie sep 16 18:00:02 CEST 2005 ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar