lilypond-user-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [question un peu HS] metafont


From: Bertrand Bordage
Subject: Re: [question un peu HS] metafont
Date: Sun, 15 Apr 2012 20:38:41 +0200

Le 15 avril 2012 19:27, René Bastian <address@hidden> a écrit :
Le Sun, 15 Apr 2012 12:05:11 +0200,
Bertrand Bordage <address@hidden> a écrit :
> Et comment obtient-il du PostScript ?  Grâce à MetaPost !

Donc pas Metafont ...

Au moment de la compilation, on n'utilise pas le programme MetaFont, en effet.
Mais la syntaxe reste de la syntaxe MetaFont et MetaPost, en interne, utilise MetaFont.
Bref.

Metafun gared évidemment la structure des langages
Metapost & Metafont qui font du développeur un esclave de
l'ordi. Ce n'est plus nécessaire [En Pascal je devais gérer
les listes ; pour avoir des listes hétéroclites, c'était la
galère ; en Python, je peux y mettre n'importe quoi -
comme déjà proposé dans les années 1980 par le Smalltalk-80
avec le concept de 'bag']

Aucun des MetaXXX ne semble comporter le concept de classe. Or c'est
l'instrument idéal pour enfouir les données assez invariables
pour ne s'occuper que des données variables.

C'est sûr.

Je propose de tout faire en pur Python, flanqué de sympy et numpy.
Pourquoi s'enquiquiner avec des syntaxes tarabiscotées.

Évidemment, mais il faudra soit faire un « parser » capable de comprendre MF, soit réécrire toute la fonte de LilyPond.
Long dans un cas comme dans l'autre...

Bill Schottstaedt - dans son projet CMN - a des descriptions
de glyphes en CommonLisp qui pondent du PostScript;
elles viennent des fontes faites en son temps par
Daniel Taupin et sont traduisibles en Python.

Ah oui, effectivement.  Je ne connaissais pas du tout.
Par contre il n'y a aucune description de glyphe.  C'est juste du PostScript pur et dur pompé sur MusiXTeX.
C'est pas moi qui le dit, c'est l'auteur, dans le fichier cmn-glyphs.lisp de la source.

> Entretemps, l'extension de
> > calcul numérique, numpy, accélère les calculs de vecteurs de grande
> > dimension (sr = 44100 ou plus) de sorte que les temps de calcul
> > deviennent imperceptibles.
> >
>
> Certes.  Mais pour de la résolution d'équations, le plus simple sera
> peut-être d'utiliser sympy, au moins dans un premier temps.  Et lui
> est très lent :(

1) Le bouquin de Langtanen "A Primer on Scientific Progr..."
propose même la solution d'équa-diffs. C'est pas lent.

Cela m'est arrivé de faire des résolutions d'équations différentielles en temps réel avec sympy dans le cadre d'un jeu vidéo.
J'ai abandonné l'idée car on passait de 60 images à la seconde à 7 images à la seconde...
Mais c'est vrai, avec les objectifs qu'on se fixe, ce sera tout à fait acceptable

2) Dans mon pythoneon j'utilise des droites (qu'on peut courber avec
des puissances) et des cubiques (on peut donner les pentes au
début et à la fin) pour dessiner n'importe quelle évolution
(variation de fréquence, variant de fréquence d'accord de filtre,
etc.). On ne voit pas le temps passer, car lors du 2e (ou 3e ? :)
essai, Python utilise les précompilés .pyc.

Si on n'utilise pas les courbes de Bézier, on n'a pas
besoin d'interface graphique interactive.

:o\ Je ne suis pas sûr de comprendre...
En tout cas j'étais parti sur des droites et des Bézier cubiques, comme MetaFont.
Avec une gestion des « pinceaux » et éventuellement toute courbe de Bézier.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]