acaso no paso de moda el csound o algo asi?
ahora todo el mundo ta con el supercollider por lo que se...


On 11/30/06, Andres Cabrera <andres@...> wrote:
> Hola todos,
> Aprovechando la reciente actividad =), quiero hacer saber que estoy
> organizando la traducción del manual de csound al español. Ya hay varios
> voluntarios, pero entre más seamos, más rápido lo lograremos.
> En el grupo de google:
> http://groups.google.com/group/csound-manual-es?hl=en
> se discutirá el proceso, ya que traducir organizadamente más de 2000
> páginas no es tarea fácil.
> Así que si alguien quiere aprender más sobre csound, conocer el bello
> mundo de docbook-xml =), y ayudar a que pronto tengamos un manual
> actualizado en español, bienvenidos!
>
> Saludos,
> Andrés
>
>
>
> http://buenasenal.schtuff.com
> http://buenasenal.schtuff.com/Noticias
> Yahoo! Groups Links
>
>
>
>

A mi me gusta mucho python, personalmente. smalltalk creo que es algo
demasiado academico en mi punto de vista, y la sintaxis un poco
confusa.
Aun asi, para audio uso C/C++, ya que cualquier prueba util que quiero
hacer necesita ser compilada, ya que en python no obtengo la
suficiente performance.

Para interfaces de usuario, creo que evoluciono mucho el mundo y las
filosofias, y hoy en dia en C++ se pueden hacer con mucha facilidad
(usando QT por ejemplo)

Saludos!

Juan

Cual moda reemplazará a supercollider? =)

Mucha gente usa super collider, pero mucha gente aún usa y está
aprendiendo csound. La versión 5 de csound es un salto adelante grande,
e incluye muchas cosas como:
- Un API muy competo (disponible en C, C++, java, python, tcl/tk y lua):
csound puede usarse ahora desde todos estos lenguajes, como motor de sonido.
- Un shell interactivo en tcl/tk, que permite que csound funcione muy
similar a supercollider usando emacs. La única diferencia es que para
agregar instrumentos la orquesta debe recompilarse.
- Posibilidad de construir interfaces graficas usando FLTK, tcl/tk, o
wxwindows desde python.
- Una serie de nuevos opcodes (pvs, loris y ATSA) para tratamiento
espectral en tiempo real
- Soporte nativo para alsa, jack, coreaudio y winmme además del
tradicional portaudio.
- Un manual muy completo y actualizado (más de 2000 páginas) que aún no
esta en español...

Csound es parte del software que será incluído en OLPC (one laptop per
child).

Csound además cuenta con blue, un front-end muy avanzado para
composición y scripting, que no tiene igual para ningún otro lenguaje
(http://www.csounds.com/stevenyi/blue/)
Algunos screenshots:
http://www.csounds.com/stevenyi/blue/screenshots/patternObject.png
http://www.csounds.com/stevenyi/blue/screenshots/pythonScore.png
http://www.csounds.com/stevenyi/blue/screenshots/lineObject.png
http://www.csounds.com/stevenyi/blue/usermanual/html/images/bsb_interface_edit.p\
ng

Tiene una comunidad muy activa y amigable (si le creemos a Nabble.com,
tienen más actividad los foros de csound que los de supercollider)

Personalmente entiendo mejor la lógica de Csound. Super collider me ha
parecido siempre muy raro.

Mi invitación no pretendía ser propanganda para Csound.... Si alguien
está interesado en ayudar con la traducción del manual, muy bienvenido.

Saludos,
Andrés


Juan Linietsky wrote:
>
> acaso no paso de moda el csound o algo asi?
> ahora todo el mundo ta con el supercollider por lo que se...
>
> On 11/30/06, Andres Cabrera <andres@...
> <mailto:andres%40geminiflux.com>> wrote:
> > Hola todos,
> > Aprovechando la reciente actividad =), quiero hacer saber que estoy
> > organizando la traducción del manual de csound al español. Ya hay varios
> > voluntarios, pero entre más seamos, más rápido lo lograremos.
> > En el grupo de google:
> > http://groups.google.com/group/csound-manual-es?hl=en
> <http://groups.google.com/group/csound-manual-es?hl=en>
> > se discutirá el proceso, ya que traducir organizadamente más de 2000
> > páginas no es tarea fácil.
> > Así que si alguien quiere aprender más sobre csound, conocer el bello
> > mundo de docbook-xml =), y ayudar a que pronto tengamos un manual
> > actualizado en español, bienvenidos!
> >
> > Saludos,
> > Andrés
> >
> >
> >
> > http://buenasenal.schtuff.com <http://buenasenal.schtuff.com>
> > http://buenasenal.schtuff.com/Noticias
> <http://buenasenal.schtuff.com/Noticias>
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>

On 11/30/06, Juan Vuletich <jvuletich@...> wrote:
> Hola Hernán,
>
>  Vos sabés que a mí me gusta Smalltalk, pero trato de no ser un "fanático
>  religioso".

:-D

>Antes nunca le había dado bola a Python, pero seguí algunos
>  de los links que mandás, y veo varias ventajas incluso sobre Smalltalk:
>  - Hay un movimiento medio masivo de pasar de Matlab a Python. Eso es muy
>  bueno. Se generan comunidades. No tenés que resolver todos los problemas
>  vos sólo. La mayoría de las otras ventajas son consecuencias de ésta.
>  - Las bibliotecas que nombrás son muy interesantes, y parecen bien hechas.
>  - Hay muchos ejemplos de código interesante para mirar.
>  - Tarde o temprano, todas las bibliotecas libres e interesantes que hay
>  para Matlab van a ser migradas a Python.
>  - La sintaxis es similar a Matlab.
>
>  Tambíén hay algunas ventajas (sobre Matlab) que comparte con Squeak (mi
>  versión preferida de Smalltalk)
>  - Herramientas open source.
>  - Posibilidad de crear aplicaciones completas.
>  - Interface con C sencilla.
>
>  Finalmente, hay algunas ventajas de Squeak sobre Python.
>  - Generación automática de código C (no precisas escribir los algoritmos
>  2 veces).

como es bien esto? no me cerró del todo... o no entiendo bien a que te
referis...

>  - Smalltalk es realmente muy bueno para hacer aplicaciones grandes, con
>  GUIs complejas, que van a vivir muchos años y cambian constantemente. O
>  sea: productos comerciales.

ya conoceré un poco de esto a traves de tu web... :D
me tenes que recomendar algo (un link o soft) para trabajar con esto desde linux


muy buena descripción del panorama :-D, realmente me sirvió. Como vos
sugeris, la principal ventaja que también veo en python es que ya
tiene "una comunidad" que esta en lo mismo, tratar de hacer lo mismo
que hacia en matlab pero ahora con python, bibliotecas, documentación,
etc

>  Un tema en que no sé quién gana es en performance. Tendríamos que hacer
>  comparaciones Matlab / Python / Squeak.

habria que ver y de última no siempre es lo más importante, ya que
matlab (al menos yo, lo veo como algo para modelar) con python o
squeak veo que ademas de modelar, le puedo dar un uso (o un mejor
"uso", con más posibilidades y libertades) para la mayoria de los
casos y si preciso más performance podría recurrir a c o c++ (o
incluso asembly) con el modelo ya armado

por lo pronto, lo único que se me ocurre sobre este tema es que tanto
matlab como python (e imagino que squeak hará lo mismo) por lo que vi
usan FFTW[1] para calcular la fft y la performance en ese punto debe
ser similar, habria que ver el tema de multiplicaciones de matrices,
etc... seguro alguien ya hizo alguna comparación asi :P

pero estoy seguro que más alla que algún que otro algoritmo interno,
en aspectos generales matlab pierde por goleada...

hay otras cosas que son molestas: por ejemplo matlab tiene una
interfaz muy pesada (sobre todo se nota o yo noto más en la versión de
linux) y hacer cosas (o modificar) que no vienen incluidas tipo
enlazar con bibliotecas propias en c++ es realmente un parto (alguna
vez hice algo de esto para tener un timer más preciso) y del soporte
para GUI no vi demasiado pero me imagino que debe ser básico e
inferior a otras alternativas

[1] http://www.fftw.org
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

On 12/1/06, Juan Linietsky <reduzio@...> wrote:
> A mi me gusta mucho python, personalmente. smalltalk creo que es algo
>  demasiado academico en mi punto de vista, y la sintaxis un poco
>  confusa.

bueno, una de las personas que me hablo muy bien de python fuiste vos :D
de smalltalk todavia no conozco nada y no puedo opinar...

>  Aun asi, para audio uso C/C++, ya que cualquier prueba util que quiero
>  hacer necesita ser compilada, ya que en python no obtengo la
>  suficiente performance.

seguramente con c/c++ vas a obtener mejor performance, pero lo que yo
"propongo"[1] es reemplazar lo que muchos hasta ahora haciamos con
matlab con python

sobre todo para probar cosas (algoritmos por ejemplo) y graficar
resultados, no para hacer cosas en tiempo real... y con la ventaja
extra (en python) de que para muchos casos también puede servir como
implementación final (por ej procesos no muy complejos en los que
perder unos segundos (o milisegundos) no importa)

otras ventajas que veo:

* matlab esta muy extendido desde hace muchos años en el ámbito
academico, lo usan muchisimo en ingenieria y matemáticas (y no se si
también en cs. de la computación). Por lo tanto la sintaxis y uso es
bastante conocida y lo usa mucha gente que no se dedica a programar y
no podrian meter mano en c++ (o tampoco les interesa meterse con eso)
y considero que python no añade demasiada complejidad extra con
respecto a matlab, pero habria que preguntarle a alguien que no
programe todos los días y solo conozca matlab como lenguaje de
programación.

* bueno, como dije antes yo a matlab lo veo más como una herramienta
para "modelar". Luego con el modelo ya testeado, es más facil llevar
la implementación a c++, vhdl, assembly o lo que sea necesario

>  Para interfaces de usuario, creo que evoluciono mucho el mundo y las
>  filosofias, y hoy en dia en C++ se pueden hacer con mucha facilidad
>  (usando QT por ejemplo)

si, es verdad, es muy bueno qt
hablando de esto, vi que con qtdesigner se puede usar en python las
mismas interfaces "diseñadas originalmente para c++" (en realidad yo
las diseñe orginalmente para c++ porque el formato en que las guarda
es standard(xml? no me acuerdo) y se pueden transformar en las
implementaciones que esten disponibles, por lo menos yo ahora solo
conozco que se puede generar código c++ y python :D)


[1] jejej, no estoy diciendo que se me ocurrio a mi, ya esta todo
"inventado" y disponible, solo lo estoy contando :P
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

me olvidé de mencionar otras ventajas que veo:

* en matlab hasta donde se no se puede usar programación orientada a
objetos (en python si y obviamente se puede usar todo lo que soporte
python, oo, estructurado, creo que también soporta programación
funcional y orientada a aspectos aunque no se si de forma nativa)
* el soporte de matlab para scripting es muuuuy básico. Por ejemplo,
algo que a veces es molesto: se puede tener solo una función por
archivo. O sea si uno quiere usar 5 funciones "chicas" y una principal
(el main) precisa 6 archivos...


--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

no se si hay más gente interesada en esto, pero encontré este link:

http://www.scipy.org/Wiki/NumPy_for_Matlab_Users?action=show&redirect=NumPy+for+\
Matlab+Addicts

donde hace una comparación mucho más extensa de la que yo hice entre
las ventajas y desventajas entre usar matlab o
python(+scipy+matplotlib,etc)

y también da otros varios consejos importantes para la "migración"...

--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

Hola Gente.

Preparé una versión en Smalltalk de ejemplo de Hernán.
Mírenlo, sólo les va a llevar unos 10 minutos (aunque está todo en inglés).

Está en www.jvuletich.org .

Saludos,
Juan

Hernán Ordiales escribió:
  >
  > Hola! cómo va?
  >
  > A raíz de:
  >
  > > > Pd. Alguna vez intenté convencerte de programar en Smalltalk? Tiene
  > > > todas las ventajas de Matlab, todas las de C, y algunas extras (bueno
  > > > para interfaces al usuario, por ejemplo). Podés ver algunas cosas que
  > > > hice en Smalltalk en www.jvuletich.org .
  >
  > se me ocurrió que tal vez podía "reemplazar" matlab con python
  > (lenguaje que nunca use hasta ahora pero que me venian hablando muy
  > bien de él y del que habia visto muchas aplicaciones "científicas").
  > Busqué un poco y la "migración" me resultó terriblemente sencilla y
  > directa.
  >
  > Asi que hice un pequeño artículo sobre esta "migración":
  > http://h.ordia.com.ar/blog/index.php?entry=entry061127-202822
  >
  > qué opinas/n sobre esto? Se por ejemplo que python esta influido por
  > algunas de las ideas de smalltalk, pero a pesar de tener buenas
  > referencias no lo conozco en particular, si otros lenguajes de
  > scripting a los que estoy acostumbrado y por lo tanto se me hizo
  > sencillo "pasarme"...
  >
  > igualmente (Juan) no te preocupes que sigo abierto a probar smalltalk
  > en algún momento ;-D
  >
  > mi "problemática" principal con matlab, es la que describo en el
artículo :-D
  >
  > --
  > Hernán
  > http://h.ordia.com.ar
  > GnuPG: 0xEE8A3FE9

Hola Andrés,

Estoy totalmente de acuerdo con vos.

Pero si tuvieras ganas de hacer propaganda para Csound, este es el
lugar indicado!

Saludos,
Juan Vuletich
--- In buenasenal@yahoogroups.com, Andres Cabrera <andres@...> wrote:
>
> Cual moda reemplazará a supercollider? =)
>
> Mucha gente usa super collider, pero mucha gente aún usa y está
> aprendiendo csound. La versión 5 de csound es un salto adelante grande,
> e incluye muchas cosas como:
> - Un API muy competo (disponible en C, C++, java, python, tcl/tk y lua):
> csound puede usarse ahora desde todos estos lenguajes, como motor de
sonido.
> - Un shell interactivo en tcl/tk, que permite que csound funcione muy
> similar a supercollider usando emacs. La única diferencia es que para
> agregar instrumentos la orquesta debe recompilarse.
> - Posibilidad de construir interfaces graficas usando FLTK, tcl/tk, o
> wxwindows desde python.
> - Una serie de nuevos opcodes (pvs, loris y ATSA) para tratamiento
> espectral en tiempo real
> - Soporte nativo para alsa, jack, coreaudio y winmme además del
> tradicional portaudio.
> - Un manual muy completo y actualizado (más de 2000 páginas) que aún no
> esta en español...
>
> Csound es parte del software que será incluído en OLPC (one laptop per
> child).
>
> Csound además cuenta con blue, un front-end muy avanzado para
> composición y scripting, que no tiene igual para ningún otro lenguaje
> (http://www.csounds.com/stevenyi/blue/)
> Algunos screenshots:
> http://www.csounds.com/stevenyi/blue/screenshots/patternObject.png
> http://www.csounds.com/stevenyi/blue/screenshots/pythonScore.png
> http://www.csounds.com/stevenyi/blue/screenshots/lineObject.png
>
http://www.csounds.com/stevenyi/blue/usermanual/html/images/bsb_interface_edit.p\
ng
>
> Tiene una comunidad muy activa y amigable (si le creemos a Nabble.com,
> tienen más actividad los foros de csound que los de supercollider)
>
> Personalmente entiendo mejor la lógica de Csound. Super collider me ha
> parecido siempre muy raro.
>
> Mi invitación no pretendía ser propanganda para Csound.... Si alguien
> está interesado en ayudar con la traducción del manual, muy bienvenido.
>
> Saludos,
> Andrés
>
>
> Juan Linietsky wrote:
> >
> > acaso no paso de moda el csound o algo asi?
> > ahora todo el mundo ta con el supercollider por lo que se...
> >
> > On 11/30/06, Andres Cabrera <andres@...
> > <mailto:andres%40geminiflux.com>> wrote:
> > > Hola todos,
> > > Aprovechando la reciente actividad =), quiero hacer saber que estoy
> > > organizando la traducción del manual de csound al español. Ya
hay varios
> > > voluntarios, pero entre más seamos, más rápido lo lograremos.
> > > En el grupo de google:
> > > http://groups.google.com/group/csound-manual-es?hl=en
> > <http://groups.google.com/group/csound-manual-es?hl=en>
> > > se discutirá el proceso, ya que traducir organizadamente más de 2000
> > > páginas no es tarea fácil.
> > > Así que si alguien quiere aprender más sobre csound, conocer el
bello
> > > mundo de docbook-xml =), y ayudar a que pronto tengamos un manual
> > > actualizado en español, bienvenidos!
> > >
> > > Saludos,
> > > Andrés
> > >
> > >
> > >
> > > http://buenasenal.schtuff.com <http://buenasenal.schtuff.com>
> > > http://buenasenal.schtuff.com/Noticias
> > <http://buenasenal.schtuff.com/Noticias>
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
>

Sabias que SuperCollider está hecho en Smalltalk? Quizás no sea tán
"académico", no?

Trabajo desarrollando productos comerciales en Smalltalk desde hace
10 años. Te puedo asegurar que no es "demasiado académico".

Saludos,
Juan

Juan Linietsky escribió:

> acaso no paso de moda el csound o algo asi?
> ahora todo el mundo ta con el supercollider por lo que se...

y en otro mail
>
> A mi me gusta mucho python, personalmente. smalltalk creo que es algo
> demasiado academico en mi punto de vista, y la sintaxis un poco
> confusa.
> Aun asi, para audio uso C/C++, ya que cualquier prueba util que quiero
> hacer necesita ser compilada, ya que en python no obtengo la
> suficiente performance.
>
> Para interfaces de usuario, creo que evoluciono mucho el mundo y las
> filosofias, y hoy en dia en C++ se pueden hacer con mucha facilidad
> (usando QT por ejemplo)
>
> Saludos!
>
> Juan

Hola Pablo,

Dónde es? Cuándo es? Tenés algun link? Quizás sería interesante ir, no?

Saludos,
Juan Vuletich

Pablo Sastre escribió:
>
> Señaleros:
>
> Eso mismo queria preguntarles, si va alguno; yo desde Córdoba; asi
nos vemos
> por alla.
>
> Un saludo
>
> --
> Juan Pablo Sastre
> * Usuario / colaborador de Musix GNU+Linux, 100% Software Libre
> * Descarga el CD de Musix y reemplaza tu Windows: http://www.musix.org.ar
> * Videos, y otras cosas en: ftp://musix.ourproject.org/pub/musix/
> * Reporta errores a:
> https://www.musix.org.ar/wiki/index.php?title=Problemas-Bugs

On 12/3/06, Juan Vuletich <juan@...> wrote:
> Hola Gente.
>  Preparé una versión en Smalltalk de ejemplo de Hernán.
>  Mírenlo, sólo les va a llevar unos 10 minutos (aunque está todo en inglés).

:D

>  Está en www.jvuletich.org .

che, lo estuve viendo...

Para ser sincero, apenas vi algo de código me resultó demasiado
criptico y complejo (más que assembly incluso :P), pero después con
las explicaciones que pusiste más abajo todo cobró sentido y se
entendió perfecto.

Lo que me quedó de la primera impresión de smalltalk (nunca habia visto nada):

* al principió no entendí nada del código (después con la explicación
entendí todo)
* me gustó la facilidad para extender clases
* una sintaxis extraña, que no conocia, que imagino (o calculo) que
recien a la larga da sus frutos (como me pasó con la notación RPN
(Notación Polaca Inversa) de las calculadoras hp, je)
* por lo menos con el ejemplo en cuestión me parece que gana python (o
cualquier matlab syntax based), para ser justos el código equivalente
a lo que hiciste vos es:

from pylab import *

X = fft( ones(10), 100 )
horiz = arange(0,100,1)
subplot(211)
plot( horiz, abs(X) )
subplot(212)
plot( horiz, angle(X) )
savefig( 'dft100.png' )
show()

que es tan corto como el último que mostras pero mucho más claro y
sencillo desde mi punto de vista, aunque me viene la duda de si es
porque yo estoy familiarizado con matlab y entonces lo "leo claro" o
si fuese c/c++ lo mismo y como vos estas familiarizado con smalltalk
"lees claro" el código smalltalk... pero "tratando" de ser objetivo me
parece que es más claro el de python/matlab (incluyo matlab porque al
menos para este ejemplo es practicamente el mismo)

igual entiendo (e imagino) que los beneficios pueden estar "a la
larga" o en aplicaciones más complejas

Dame alguna punta/consejo/link para instalar squeak bajo linux, al
menos en los paquetes de los repositorios que tengo no esta, si esta
"gnu-smalltalk - GNU Smalltalk - an implementation of Smalltalk-80"


Otras conclusiones que saco:

* por lo menos para reemplazar matlab, hasta ahora veo mucho mejor
perfilado "python + scipy + matplotlib" frente a cualquiera: octave,
scilab, smalltalk, etc
(en este punto dudo mucho que alguien que solo programa en matlab se
acostumbre rápidamente y de buena gana a la sintaxis smalltalk)

* estamos "comparando" con un ejemplo de algo muy sencillo, habria que
ver que ventajas (o no) pueden surgir al agregar complejidad

* falta comparar performance

* en particular para trabajar con audio: en python al menos vi: pyjack
(para interactuar con jack), pyalsa (para interactuar con alsa),
pymidi (para interactuar con midi), pyaudio (para interactuar con
audio en general, hacer conversiones), bibliotecas para re-sampling...
hay bastante hecho, aunque faltan cosas y se esta desarrollando
bastante, esta pksampler por ejemplo como lo "más grande" que encontré
hasta ahora
de signal processing, creo que hay un par de bilbiotecas más, aunque
todavia no me pude poner a ver

* que tan grande es "la comunidad" de smalltalk? (yo ni idea)
en este punto creo que también entran otras cosas, por ejemplo si uno
encara un proyecto grande, donde vaya a trabajar mucha gente, si uno
elije una teconlogia poco usada, por más que sea muy buena después es
dificil encontrar gente ya capacitada para programar
por ejemplo a mi me pasa en los 2 trabajos que tengo, que nos cuesta
encontrar gente para programar en c++ (que es muy conocido! pero poco
popular últimamente por estos lares y muchos prefieren
"especializarse" en otras como java por ejemplo...)


--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

El Lunes 04 Diciembre 2006 03:01, Juan Vuletich escribió:
> Hola Pablo,

Hola Juan

> Dónde es? Cuándo es? Tenés algun link? Quizás sería interesante ir, no?

Es en Capital Federal; y el temario esta muy interesante (por lo menos para
mi) Aca te dejo el link de la institucion

http://argentina.aes.org/


> Saludos,

Saludos; espero verte por allá; asi vamos en barra

--
Juan Pablo Sastre
* Usuario / colaborador de Musix GNU+Linux, 100% Software Libre
* Descarga el CD de Musix y reemplaza tu Windows: http://www.musix.org.ar
* Videos, y otras cosas en: ftp://musix.ourproject.org/pub/musix/
* Reporta errores a:
https://www.musix.org.ar/wiki/index.php?title=Problemas-Bugs
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

sobre la performance de python con calculos numéricos, encontré esto,
que parece bastante interesante por cierto:
http://www.scipy.org/PerformancePython

todavia no tuve tiempo de leerlo completo, solo lo vi por arriba, pero
por ejemplo en la comparación que hace, el tiempo que tarda desde
python llamando a funciones fortran, es apenas mayor que una
implementación en c++ (aunque no optimizada)


--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

Bueno, la propaganda ya está hecha... Sigue en pie la invitación a
traducir =)

Saludos,
Andrés

Hola Hernán,

Hernán Ordiales escribió:
  >
  > On 12/3/06, Juan Vuletich <juan@...> wrote:
  > > Hola Gente.
  > > Preparé una versión en Smalltalk de ejemplo de Hernán.
  > > Mírenlo, sólo les va a llevar unos 10 minutos (aunque está todo en
inglés).
  >
  > :D
  >
  > > Está en www.jvuletich.org .
  >
  > che, lo estuve viendo...
  >
  > Para ser sincero, apenas vi algo de código me resultó demasiado
  > criptico y complejo (más que assembly incluso :P), pero después con
  > las explicaciones que pusiste más abajo todo cobró sentido y se
  > entendió perfecto.

:)

  > Lo que me quedó de la primera impresión de smalltalk (nunca habia
visto nada):
  >
  > * al principió no entendí nada del código (después con la explicación
  > entendí todo)

Es lógico. La sintaxis es distinta de la de la mayoría de los lenguajes,
y no incluí una explicación de la sintaxis, sólo el ejemplo. Que se
entendiera con lo que puse, ya es bastante.

  > * me gustó la facilidad para extender clases

Si, en eso Smalltalk es excelente.

  > * una sintaxis extraña, que no conocia, que imagino (o calculo) que
  > recien a la larga da sus frutos (como me pasó con la notación RPN
  > (Notación Polaca Inversa) de las calculadoras hp, je)

No sé si realmente "da sus frutos". Yo creo que cuando te acostumbrás un
poco te parece natural, cómoda. Creo que es más natural que la notación
polaca inversa... Si realmente te gusta la RPN, tenés que aprender Forth!

  > * por lo menos con el ejemplo en cuestión me parece que gana python (o
  > cualquier matlab syntax based), para ser justos el código equivalente
  > a lo que hiciste vos es:
  >
  > from pylab import *
  >
  > X = fft( ones(10), 100 )
  > horiz = arange(0,100,1)
  > subplot(211)
  > plot( horiz, abs(X) )
  > subplot(212)
  > plot( horiz, angle(X) )
  > savefig( 'dft100.png' )
  > show()
  >
  > que es tan corto como el último que mostras pero mucho más claro y
  > sencillo desde mi punto de vista, aunque me viene la duda de si es
  > porque yo estoy familiarizado con matlab y entonces lo "leo claro" o
  > si fuese c/c++ lo mismo y como vos estas familiarizado con smalltalk
  > "lees claro" el código smalltalk... pero "tratando" de ser objetivo me
  > parece que es más claro el de python/matlab (incluyo matlab porque al
  > menos para este ejemplo es practicamente el mismo)

Habría que preguntarle a alguien que no sepa programar en ningún
lenguaje. De cualquier manera, yo creo que no hay que hacer mucho
incapié en la sintaxis. La sintaxis es lo de menos.

  > igual entiendo (e imagino) que los beneficios pueden estar "a la
  > larga" o en aplicaciones más complejas
  >
  > Dame alguna punta/consejo/link para instalar squeak bajo linux, al
  > menos en los paquetes de los repositorios que tengo no esta, si esta
  > "gnu-smalltalk - GNU Smalltalk - an implementation of Smalltalk-80"

Entrá a http://www.squeak.org/Download . Hay un link para Linux.

  > Otras conclusiones que saco:
  >
  > * por lo menos para reemplazar matlab, hasta ahora veo mucho mejor
  > perfilado "python + scipy + matplotlib" frente a cualquiera: octave,
  > scilab, smalltalk, etc
  > (en este punto dudo mucho que alguien que solo programa en matlab se
  > acostumbre rápidamente y de buena gana a la sintaxis smalltalk)

Estoy de acuerdo.

  > * estamos "comparando" con un ejemplo de algo muy sencillo, habria que
  > ver que ventajas (o no) pueden surgir al agregar complejidad

Si. Para aplicaciones completas, medianas para arriba, Smalltalk es
buenísimo.

  > * falta comparar performance
  >
Si.

  > * en particular para trabajar con audio: en python al menos vi: pyjack
  > (para interactuar con jack), pyalsa (para interactuar con alsa),
  > pymidi (para interactuar con midi), pyaudio (para interactuar con
  > audio en general, hacer conversiones), bibliotecas para re-sampling...
  > hay bastante hecho, aunque faltan cosas y se esta desarrollando
  > bastante, esta pksampler por ejemplo como lo "más grande" que encontré
  > hasta ahora
  > de signal processing, creo que hay un par de bilbiotecas más, aunque
  > todavia no me pude poner a ver
  >
En Smalltalk la estrategia usual es incluir en la imagen lo necesario,
tratando de evitar usar bibliotecas externas. La ventaja de hacerlo así
es que tenés todo el código para estudiarlo, y es muy cómodo para
mejorarlo (no tenés que cambiar de lenguaje ni llamar a un compilador).
Squeak incluye soporte para audio, midi y algunas cosas de procesamiento
de señales. Aunque no sé si la máquina virtual para Linux tiene soporte
completo para audio y midi. Creo que sí.

  > * que tan grande es "la comunidad" de smalltalk? (yo ni idea)

No hay una única comunidad de Smalltalk. La comunidad activa de Squeak
(o sea gente que participa, se comunica, etc) es de unas 500 personas.
Cuánta gente usa Smalltalk en el mundo, no se. Pero mirá
http://www.whysmalltalk.com/production/index.htm . Vas a ver que somos
un montón.

  > en este punto creo que también entran otras cosas, por ejemplo si uno
  > encara un proyecto grande, donde vaya a trabajar mucha gente, si uno
  > elije una teconlogia poco usada, por más que sea muy buena después es
  > dificil encontrar gente ya capacitada para programar
  > por ejemplo a mi me pasa en los 2 trabajos que tengo, que nos cuesta
  > encontrar gente para programar en c++ (que es muy conocido! pero poco
  > popular últimamente por estos lares y muchos prefieren
  > "especializarse" en otras como java por ejemplo...)

Yo prefiero no limitarme por motivos como esos, pero bueno, no dirijo
una empresa...

  > --
  > Hernán
  > http://h.ordia.com.ar
  > GnuPG: 0xEE8A3FE9
  >

Saludos,
Juan Vuletich

Hola gente,

Miren http://www.clarin.com/diario/2006/12/10/espectaculos/c-01401.htm .
Comenta un concierto de música electroacústica en el que tocó el piano
nuestro compañero de grupo Bruno Mesz.

Lamentablemente me enteré tarde y no pude ir. Espero poder ir al próximo!

Felicitaciones Bruno!

Juan Vuletich

Hola señaleros!

El martes pasado (12/12) anduve por los guenos aires; pa`l congreso, vio?
Ahi estuvimos con Ramiro "magoo" Ramirez, de la gente de Meyer Sound; al
principio del dia nos maravillo (o por lo menos a mi) con las configuraciones
de bafles para direccionar los bajos; despues, casi todo el resto del día;
viendo de poner a punto los sistemas de escenario (PA ???); pero no de "hacer
que se escuche", sino, que con dos bichitos de meyer; el SIM III
http://www.meyersound.com/products/sim/sim3/
y el Galileo
http://www.meyersound.com/616/
Me hizo saber que es posible aplicar teoría, que me parecía un
tanto "inaplicable".
Además, de usar el MAPPpro online
http://www.meyersound.com/products/mapponline/pro/measurements.htm
para adecuar el alineamiento de los arrays a la sala; me dí cuenta que con un
par de herramientas, no imposibles de implementar; se puede lograr un sonido
muy bueno, o decente, en condiciones que se  me han planteado como casi
imposibles.
Las preguntas (o molestias :P ) son; si fuera posible que hubiese algo al
estilo del SIM; y algo como el galileo? Desde una PC, y obvio; con GNU+Linux.
Por que, analizar un señal, vi que se puede con cualquier UI de los editores
que veo y uso en Musix; retrasar o alinear una señal; con cualquier delay
estaría al alcanze con plugins generales.
Y si no hubiere; no joder con que se haga algo así; por que no se programar, y
no voy a andar molestando con algo que no se hacer yo mismo.
Por lo que necesiten, preguntar, aclarar; put... jeje :P; tambien; chiflen que
así vemos que hay.

Saludos desde Córdoba Capital; Barrio Jardín;
sede del glorioso Clu Atletico Taiere

--
Juan Pablo Sastre
* Usuario / colaborador de Musix GNU+Linux, 100% Software Libre
* Descarga el CD de Musix y reemplaza tu Windows: http://www.musix.org.ar
* Videos, y otras cosas en: ftp://musix.ourproject.org/pub/musix/
* Reporta errores a:
https://www.musix.org.ar/wiki/index.php?title=Problemas-Bugs





__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Hola amigos,

Escribí una muy pequeña introducción a Smalltalk. Está en
www.jvuletich.org. Espero que les guste!

Felices fiestas para todos.

Juan Vuletich

Hola!

Implementé las funciones equivalentes a wavread y wavwrite de matlab
para poder trabajar en python con archivos wavs como si fueran
vectores (a la manera de matlab). Se las paso por si alguien más
quiere experimentar...

wavread: recibe un wav y devuelve un vector normalizado entre -1 y 1,
su frecuencia de muestreo y la cantidad de bits por muestra.

wavwrite: recibe un vector y una frecuencia de muestreo y genera un
wav a partir de esos datos.

Estan aca: http://audiores.uint8.com.ar/files/code/wav_array.py

Aprovechando estas funciones y a manera de ejemplo también escribí el
equivalente al post "Convolución circular rápida (aplicación en
reverbs)" pero en python. El código es este:
http://audiores.uint8.com.ar/files/code/fast_conv.py

Saludos!
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

Hola gente, cómo están (hace bastante que debí haber hecho esto no?)

  Soy Adrián, desde hace unos 8 años todo el mundo me dice pardo, incluso
algunos creen que ese es mi nombre real. Tengo 20 años, acabo de terminar
tercero de ingeniería en electrónica y empecé licenciatura en informática
en la UNLP.

  Cuando tengo un ratito colaboro con Musix. Bailo tango,
trabajé el verano pasado de taxidancer, estoy viendo de traer la
movida del tango queer a La Plata con un amigo. Ando bastante en
bicicleta y a veces salgo de noche a caminar o correr.

  Tengo gustos musicales muy diversos, ahora por nombrar algo me sale
Utada Hikaru, Cardigans, Nina Gordon / Veruca Salt, Fleur, Children Of
Bodom, Tanghetto, Symphony X, Garbage, Aqualung, Secret Sphere, Lara
Fabian, Everclear, Astillero, MxPx, Coldplay, Curve, Natalie Imbruglia,
Karina Luzabril, Angelina Shabalina, etc.

  Soy bastante conservador en cuanto a los juegos, buscaminas, mahjongg,
UT Doom, juegos de ficción interactiva y cosas  como nethack o moria.
También los viejitos como indiana jones, Zack McKracken o metal mutant.


  Por ahora estoy trabajando en una consola midi hecha con mice viejos y
un framework para IPC sobre sockets unix de baja latencia. Este 2007
tengo también una beca como investigador en "Nuevas Tecnologías,
competencias profesionales y educación científica. Estrategias
didácticas para su articulación."

  Bueno, un saludo; supongo que esto terminará de aclarar cualquier duda.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE/ED/MU/PA/S/M/TW/L/CS d++(---) dx s+:- a-- C++ UL+++>US++ P+ L+++ E--
W+(-) N+ o? K w-(---) O- V-- PS++>+ PE+ Y+ PGP+ t 5 X+ R tv b+>++ DI++(+)
D+ G e++>++++ h-- r+(-) y*(++)
------END GEEK CODE BLOCK------

On 1/3/07, crackerpardo <crackerpardo@...> wrote:
>  Hola gente, cómo están (hace bastante que debí haber hecho esto no?)

más vale tarde que nunca! jeje bienvenido!

>  Por ahora estoy trabajando en una consola midi hecha con mice viejos y
>  un framework para IPC sobre sockets unix de baja latencia.

y eso? de que se trata?
IPC: inter process communications?
ipc, sockets... por que tanta comunicación entre procesos?

--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

--- In buenasenal@yahoogroups.com, "Hernán Ordiales" <hordiales@...>
wrote:
> >  Por ahora estoy trabajando en una consola midi hecha con mice
viejos y
> >  un framework para IPC sobre sockets unix de baja latencia.
>
> y eso? de que se trata?
> IPC: inter process communications?

exactamente

  ...y me puse a jugar al principio con el lirc e hice un intento de
programa para manejar al xmms, despues empecé con los encoder opticos
y cosas mas interesantes con un pic y necesite de infraestructura
necesaria para enlazar el driver del circuito con el resto de las
cosas y no encontre nada que me guste, asi que ahora estoy trabajando
en eso(ademas como experiencia de aprendizaje esta buena). tengo un
par de bicharracos que generan eventos midi para manejar
ardour/jack-rack  o controlan amarok via dcop pero la idea es que una
vez que esté el framework listo cargo un plugin que hace de puente
entre este y cualquier otra cosa, sea midi, OSC , muscle , dbus, etc.

Muy buena info, no tenía idea de que existían JACK
rack ni Amarok.
Pregunta, en vez de usar IPC, ¿no sería mas liviano
usar PThreads?

Saludos

Jose

--- crackerpardo <crackerpardo@...> escribió:

> --- In buenasenal@yahoogroups.com, "Hernán Ordiales"
> <hordiales@...>
> wrote:
> > >  Por ahora estoy trabajando en una consola midi
> hecha con mice
> viejos y
> > >  un framework para IPC sobre sockets unix de
> baja latencia.
> >
> > y eso? de que se trata?
> > IPC: inter process communications?
>
> exactamente
>
>  ...y me puse a jugar al principio con el lirc e
> hice un intento de
> programa para manejar al xmms, despues empecé con
> los encoder opticos
> y cosas mas interesantes con un pic y necesite de
> infraestructura
> necesaria para enlazar el driver del circuito con el
> resto de las
> cosas y no encontre nada que me guste, asi que ahora
> estoy trabajando
> en eso(ademas como experiencia de aprendizaje esta
> buena). tengo un
> par de bicharracos que generan eventos midi para
> manejar
> ardour/jack-rack  o controlan amarok via dcop pero
> la idea es que una
> vez que esté el framework listo cargo un plugin que
> hace de puente
> entre este y cualquier otra cosa, sea midi, OSC ,
> muscle , dbus, etc.
>
>
>
> http://buenasenal.schtuff.com
> http://buenasenal.schtuff.com/Noticias
> Yahoo! Groups Links
>
>
>
>
>


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

--- In buenasenal@yahoogroups.com, Jose Fuentes
<josecarlosfuentes@...> wrote:
>
> Muy buena info, no tenía idea de que existían JACK
> rack ni Amarok.
> Pregunta, en vez de usar IPC, ¿no sería mas liviano
> usar PThreads?

son cosas distintas, pthreads es justamente para programacion
concurrente. lo que estoy haciendo, si bien usa un thread aparte del
codigo usuario para el monitoreo de los sockets y los callbacks, es el
codigo que me permite abstraer la comunicacion via socket y todo el
proceso de marshalling / serializacion de objetos para poder pasar
informacion o comandos entre distintos programas

On 1/8/07, crackerpardo <crackerpardo@...> wrote:
>  > IPC: inter process communications?
>
>  exactamente
>
>  ...y me puse a jugar al principio con el lirc e hice un intento de
>  programa para manejar al xmms, despues empecé con los encoder opticos
>  y cosas mas interesantes con un pic y necesite de infraestructura
>  necesaria para enlazar el driver del circuito con el resto de las
>  cosas y no encontre nada que me guste, asi que ahora estoy trabajando
>  en eso(ademas como experiencia de aprendizaje esta buena). tengo un
>  par de bicharracos que generan eventos midi para manejar
>  ardour/jack-rack  o controlan amarok via dcop pero la idea es que una
>  vez que esté el framework listo cargo un plugin que hace de puente
>  entre este y cualquier otra cosa, sea midi, OSC , muscle , dbus, etc.

uhhh, copado

tenés pensado publicarlo tipo GPL o similar?

btw,
yo uso bemusedlinuxserver (generalmente el kbemusedsrv) para manejar
amarok o xmms vía bluetooth con el móvil, capaz tener en cuenta ese
proyecto te sirva de algo



--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

qué tal grupo?

Les escribo para contarles que hace unos días se contactó conmigo una
persona que me pidió si lo podía poner en contacto con gente que pueda
interesarse en el proyecto (el que le da nombre al asunto) y que tenga
los conocimiento necesarios como para llevarlo a cabo.

Más información en el .doc que va como adjunto (el mismo que me
envió), les copio un par de parrafos para que se vayan haciendo una
idea:

"La propuesta del presente trabajo es construir un instrumento musical
de teclado temperado según la convergente (53 / 31) (ver: Federico
Miyara: "La música de las esferas: de Pitágoras a Xenakis... y más
acá", http://www.eie.fceia.unr.edu.ar/~acustica/biblio/esferas.pdf).
Este temperamento parece adjudicado al célebre matemático Mercator.
Del libro "Acústica musical y organología", Tirso de Olazábal,
Editorial Ricordi Americana, 1977, extraigo el siguiente fragmento:
"El intento más ingenioso ha sido realizado por el famoso matemático
Gerardo Mercator, que propuso en el siglo XVI un sistema basado sobre
una sucesión de 53 quintas, que origina una coma pequeñísima; este
sistema, llamado a veces "sistema de los 53 grados", permite obtener
quintas y terceras mayores casi perfectas. En el siglo pasado fueron
construidos dos órganos con 53 teclas por octava, templados según el
sistema de Mercator, pero no tuvieron éxito debido a su enorme
dificultad de ejecución."
Para simplificar, llamaré a este sistema "sistema Mercator",
"temperamento Mercator" o "escala Mercator". Básicamente este
temperamento consiste en dividir la octava en 53 "microtonos" iguales
entre sí, y usar estos microtonos para obtener los tonos y semitonos
de la escala natural con una gran aproximación" (sigue)

Una pequeña observación que puedo hacer sin profundizar demasiado en
el tema. En este momento se me ocurren 2 caminos básicos. Samplear
algún instrumento en cada frecuencia base requerida y luego asignarlos
a las notas adecuadas o generar sonidos sintéticos teniendo en cuenta
las mismas frecuencias calculadas.

En cuanto a los sonidos sintetizados (generados por computadora) hay
que tener también en cuenta los armónicos de cada nota (porque como
todos sabrán los instrumentos tienen un timbre particular y no se
componen solo de una frecuencia "pura" sino de una frecuencia
fundamental y armónicos que son frecuencias múltiplos de la primera
con diferentes amplitudes)

En cuanto a la parte "física", por ejemplo se podrían recibir los
mensajes convencionales de cualquier teclado MIDI y por medio de este
soft específico reproducir las frecuencias adecuadas a la escala
elegida.

Por mi parte, en este momento no cuento con mucho tiempo debido al
trabajo, pero me ofrecí a ayudarlo en lo que pudiera.

ideas? comentarios? interesados?
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9

Che me gusto la idea, ahora entre la facultad y el trabajo ando algo
corto de tiempo como para ayudar bastante pero me parece que podríamos
usar ZynAddSubFX, si mal no recuerdo con la síntesis aditiva tenés
hasta 64 armónicos con control individual de amplitud y fase por voz,
ajustes de tono en ±10 cents (nota: todavia no lei ninguno de los
papers adjuntados); también para darle algo mas de realismo se le
puede poner un LFO a alguno de los parámetros para hacerlos algo
aleatorios o un filtro pasabajo dependiente de la nota para preservar
el espectro (eso sería ams importante si el sonido fuera sampleado).

bueno, a ver que les parece.
saludos

Hola!

Yo creo que lo mejor es tomar un vsti open source, como
http://sourceforge.net/projects/buffersynth2 o
http://www.kvraudio.com/get/308.html y agregarles la funcionalidad para
elegir la escala, y hacer que usen las frecuencias correctas, no?

Suena como algo que se podria hacer en 1 semana. (Si uno tuviera una
semana libre, por supuesto!)

El proyecto es super interesante. Pero no me animo a ofrecerme como
voluntario por falta de tiempo...

Saludos,
Juan Vuletich

Hernán Ordiales escribió:
>
> qué tal grupo?
>
> Les escribo para contarles que hace unos días se contactó conmigo una
> persona que me pidió si lo podía poner en contacto con gente que pueda
> interesarse en el proyecto (el que le da nombre al asunto) y que tenga
> los conocimiento necesarios como para llevarlo a cabo.
>
> Más información en el .doc que va como adjunto (el mismo que me
> envió), les copio un par de parrafos para que se vayan haciendo una
> idea:
>
> "La propuesta del presente trabajo es construir un instrumento musical
> de teclado temperado según la convergente (53 / 31) (ver: Federico
> Miyara: "La música de las esferas: de Pitágoras a Xenakis... y más
> acá", http://www.eie.fceia.unr.edu.ar/~acustica/biblio/esferas.pdf
> <http://www.eie.fceia.unr.edu.ar/%7Eacustica/biblio/esferas.pdf>).
> Este temperamento parece adjudicado al célebre matemático Mercator.
> Del libro "Acústica musical y organología", Tirso de Olazábal,
> Editorial Ricordi Americana, 1977, extraigo el siguiente fragmento:
> "El intento más ingenioso ha sido realizado por el famoso matemático
> Gerardo Mercator, que propuso en el siglo XVI un sistema basado sobre
> una sucesión de 53 quintas, que origina una coma pequeñísima; este
> sistema, llamado a veces "sistema de los 53 grados", permite obtener
> quintas y terceras mayores casi perfectas. En el siglo pasado fueron
> construidos dos órganos con 53 teclas por octava, templados según el
> sistema de Mercator, pero no tuvieron éxito debido a su enorme
> dificultad de ejecución."
> Para simplificar, llamaré a este sistema "sistema Mercator",
> "temperamento Mercator" o "escala Mercator". Básicamente este
> temperamento consiste en dividir la octava en 53 "microtonos" iguales
> entre sí, y usar estos microtonos para obtener los tonos y semitonos
> de la escala natural con una gran aproximación" (sigue)
>
> Una pequeña observación que puedo hacer sin profundizar demasiado en
> el tema. En este momento se me ocurren 2 caminos básicos. Samplear
> algún instrumento en cada frecuencia base requerida y luego asignarlos
> a las notas adecuadas o generar sonidos sintéticos teniendo en cuenta
> las mismas frecuencias calculadas.
>
> En cuanto a los sonidos sintetizados (generados por computadora) hay
> que tener también en cuenta los armónicos de cada nota (porque como
> todos sabrán los instrumentos tienen un timbre particular y no se
> componen solo de una frecuencia "pura" sino de una frecuencia
> fundamental y armónicos que son frecuencias múltiplos de la primera
> con diferentes amplitudes)
>
> En cuanto a la parte "física", por ejemplo se podrían recibir los
> mensajes convencionales de cualquier teclado MIDI y por medio de este
> soft específico reproducir las frecuencias adecuadas a la escala
> elegida.
>
> Por mi parte, en este momento no cuento con mucho tiempo debido al
> trabajo, pero me ofrecí a ayudarlo en lo que pudiera.
>
> ideas? comentarios? interesados?
> --
> Hernán
> http://h.ordia.com.ar <http://h.ordia.com.ar>
> GnuPG: 0xEE8A3FE9
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.441 / Virus Database: 268.18.3/699 - Release Date: 23/2/2007
01:26 p.m.
>