j'ai l'impression, mais dites-moi si je me trompe, qu'il manque sur
fr.* un groupe d=E9di=E9 au traitement audio (num=E9rique ou analogique).
Par exemple sur les outils pour cr=E9er des MP3, comment enregistrer une
source analogique sur un PC, etc...
fr.comp.musique pourrait =EAtre celui-l=E0, mais le mot "musique" est un
peu restrictif, de m=EAme que "comp".
fr.rec.son-image.hifi, ben c'est la hifi, quoi, un sujet tr=E8s
particulier.
Sur hardware.fr, il existe un forum "traitement audio" plut=F4t actif.
Est-ce qu'un nouveau groupe fr.rec.son-image.audio ne serait pas
justif=E9 ?
Ce qui ne répond pas à ma question "quelle audio" car audio ça va de
- quel balladeur choisir - convertir du WMA en MP3 (gratos) - convertir du MP3 en WMA (gratos) - recopier mes cassettes sur CD - mon lecteur de salon lit pas mon CD
à
- Genelec ou NS10? - Cubase, ProTools - Fairlight et Oberheim - mixage, prise de son - prédiction linéaire - synthèse granulaire
et que ça n'est pas vraiment miscible, comme me semble le prouver l'évolution de son-image.video, en particulier .materiel. Allez, je vous prie, y COMPTER le nombre de questions relatives à la réalisation alors que la charte était très explicite.
Si vous voulez un nouveau groupe (et je pense aussi qu'il en faudrait un) il faut une charte et un placement béton pour éviter ça.
Je suis d'accord avec ça et je comprends ce genre de réticences. Il faudrait rester centré sur la notion de "création"/"réalisation", ce qui est loin d'être gagné avec un placement dans fr.rec.son-image.*
Dans fr.comp.musique, ce n'est pas "musique" qui me gêne, mais "comp". fr.comp.* est la sous-hiérarchie dédiée à l'informatique. Or faire de la réalisation musicale, même en utilisant des outils informatiques, ce n'est pas faire de l'informatique.
Une sous-hiérarchie fr.rec.musique.*, avec les sous-groupes qu'il faut, serait plus appropriée.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
Jean-Yves Bernier wrote:
Ce qui ne répond pas à ma question "quelle audio" car audio ça va de
- quel balladeur choisir
- convertir du WMA en MP3 (gratos)
- convertir du MP3 en WMA (gratos)
- recopier mes cassettes sur CD
- mon lecteur de salon lit pas mon CD
à
- Genelec ou NS10?
- Cubase, ProTools
- Fairlight et Oberheim
- mixage, prise de son
- prédiction linéaire
- synthèse granulaire
et que ça n'est pas vraiment miscible, comme me semble le prouver
l'évolution de son-image.video, en particulier .materiel. Allez, je
vous prie, y COMPTER le nombre de questions relatives à la réalisation
alors que la charte était très explicite.
Si vous voulez un nouveau groupe (et je pense aussi qu'il en faudrait
un) il faut une charte et un placement béton pour éviter ça.
Je suis d'accord avec ça et je comprends ce genre de réticences. Il faudrait
rester centré sur la notion de "création"/"réalisation", ce qui est loin
d'être gagné avec un placement dans fr.rec.son-image.*
Dans fr.comp.musique, ce n'est pas "musique" qui me gêne, mais "comp".
fr.comp.* est la sous-hiérarchie dédiée à l'informatique. Or faire de la
réalisation musicale, même en utilisant des outils informatiques, ce n'est
pas faire de l'informatique.
Une sous-hiérarchie fr.rec.musique.*, avec les sous-groupes qu'il faut,
serait plus appropriée.
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
Ce qui ne répond pas à ma question "quelle audio" car audio ça va de
- quel balladeur choisir - convertir du WMA en MP3 (gratos) - convertir du MP3 en WMA (gratos) - recopier mes cassettes sur CD - mon lecteur de salon lit pas mon CD
à
- Genelec ou NS10? - Cubase, ProTools - Fairlight et Oberheim - mixage, prise de son - prédiction linéaire - synthèse granulaire
et que ça n'est pas vraiment miscible, comme me semble le prouver l'évolution de son-image.video, en particulier .materiel. Allez, je vous prie, y COMPTER le nombre de questions relatives à la réalisation alors que la charte était très explicite.
Si vous voulez un nouveau groupe (et je pense aussi qu'il en faudrait un) il faut une charte et un placement béton pour éviter ça.
Je suis d'accord avec ça et je comprends ce genre de réticences. Il faudrait rester centré sur la notion de "création"/"réalisation", ce qui est loin d'être gagné avec un placement dans fr.rec.son-image.*
Dans fr.comp.musique, ce n'est pas "musique" qui me gêne, mais "comp". fr.comp.* est la sous-hiérarchie dédiée à l'informatique. Or faire de la réalisation musicale, même en utilisant des outils informatiques, ce n'est pas faire de l'informatique.
Une sous-hiérarchie fr.rec.musique.*, avec les sous-groupes qu'il faut, serait plus appropriée.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
pehache grmpf
siger wrote:
Parce que "comp" signifie ordinateur, et qu'on ne peut pas dire qu'un appareil utilisant le numérique est un ordinateur, sinon tous le sont ou presque, les machines à laver, etc.
C'est surtout que "comp" doit s'entendre au sens "informatique". Et utiliser un ordinateur n'a jamais fait de personne un informaticien, tout comme utiliser une voiture n'a jamais fait de personne un mécanicien.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
siger wrote:
Parce que "comp" signifie ordinateur, et qu'on ne peut pas dire qu'un
appareil utilisant le numérique est un ordinateur, sinon tous le sont
ou presque, les machines à laver, etc.
C'est surtout que "comp" doit s'entendre au sens "informatique". Et utiliser
un ordinateur n'a jamais fait de personne un informaticien, tout comme
utiliser une voiture n'a jamais fait de personne un mécanicien.
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
Parce que "comp" signifie ordinateur, et qu'on ne peut pas dire qu'un appareil utilisant le numérique est un ordinateur, sinon tous le sont ou presque, les machines à laver, etc.
C'est surtout que "comp" doit s'entendre au sens "informatique". Et utiliser un ordinateur n'a jamais fait de personne un informaticien, tout comme utiliser une voiture n'a jamais fait de personne un mécanicien.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
redgiantstarNO$PAM
Gérald Niel wrote:
Si c'est de moi dont-il est question, c'est Gérald Niel. Merci.
Oops, désolé ;)
Ah non. Ce ne doit pas être de moi dont il est question. Mon problème (et c'est pourquoi je suis intervenu dans cette discussion) ce situe bien en amont du séquenceur. Et bien en aval ensuite aussi.
Maintenant que tu l'as spécifié, j'ai plus à me tourner des films.
Gérald Niel wrote:
Si c'est de moi dont-il est question, c'est Gérald Niel. Merci.
Oops, désolé ;)
Ah non. Ce ne doit pas être de moi dont il est question. Mon problème
(et c'est pourquoi je suis intervenu dans cette discussion) ce situe
bien en amont du séquenceur. Et bien en aval ensuite aussi.
Maintenant que tu l'as spécifié, j'ai plus à me tourner des films.
Si c'est de moi dont-il est question, c'est Gérald Niel. Merci.
Oops, désolé ;)
Ah non. Ce ne doit pas être de moi dont il est question. Mon problème (et c'est pourquoi je suis intervenu dans cette discussion) ce situe bien en amont du séquenceur. Et bien en aval ensuite aussi.
Maintenant que tu l'as spécifié, j'ai plus à me tourner des films.
redgiantstarNO$PAM
Thierry Boudet wrote:
On 2005-11-15, siger wrote:
Tu peux poser ta question ici car il y a tellement de HC bien pire, que ça passera pour une question en charte à côté.
Donc: je vais bientôt avoir un tx81z, et je vais tenter d'écrire un éditeur/compilateur/jesépatro tournant en mode texte sur un système Unix. Quels sont les soucis que je vais rencontrer, et où puis-je trouver de la doc technique sur cette machine ?
Si ça c'est pas en charte, je penserais très fort que tu n'es qu'un fufeur nevropathe.
Th.
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je te conseillerais d'utiliser Perl comme langage de programmation (de mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage qui a été très populaire pour la création de cgi mais il ne fait pas que cela (loin de là). En plus cerise sur le gâteau, il est porté sur Windows et certainement sur Mac.
Thierry Boudet wrote:
On 2005-11-15, siger <guinness@hic.invalid> wrote:
Tu peux poser ta question ici car il y a tellement de HC bien pire, que
ça passera pour une question en charte à côté.
Donc: je vais bientôt avoir un tx81z, et je vais tenter d'écrire
un éditeur/compilateur/jesépatro tournant en mode texte sur un
système Unix. Quels sont les soucis que je vais rencontrer, et
où puis-je trouver de la doc technique sur cette machine ?
Si ça c'est pas en charte, je penserais très fort que tu n'es
qu'un fufeur nevropathe.
Th.
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je
te conseillerais d'utiliser Perl comme langage de programmation (de
mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage
qui a été très populaire pour la création de cgi mais il ne fait pas que
cela (loin de là). En plus cerise sur le gâteau, il est porté sur
Windows et certainement sur Mac.
Tu peux poser ta question ici car il y a tellement de HC bien pire, que ça passera pour une question en charte à côté.
Donc: je vais bientôt avoir un tx81z, et je vais tenter d'écrire un éditeur/compilateur/jesépatro tournant en mode texte sur un système Unix. Quels sont les soucis que je vais rencontrer, et où puis-je trouver de la doc technique sur cette machine ?
Si ça c'est pas en charte, je penserais très fort que tu n'es qu'un fufeur nevropathe.
Th.
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je te conseillerais d'utiliser Perl comme langage de programmation (de mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage qui a été très populaire pour la création de cgi mais il ne fait pas que cela (loin de là). En plus cerise sur le gâteau, il est porté sur Windows et certainement sur Mac.
Alex Marandon
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je te conseillerais d'utiliser Perl comme langage de programmation (de mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage qui a été très populaire pour la création de cgi mais il ne fait pas que cela (loin de là). En plus cerise sur le gâteau, il est porté sur Windows et certainement sur Mac.
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis différents OS. De là à la surcouche en n'importe quel langage de script, il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je
te conseillerais d'utiliser Perl comme langage de programmation (de
mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage
qui a été très populaire pour la création de cgi mais il ne fait pas que
cela (loin de là). En plus cerise sur le gâteau, il est porté sur
Windows et certainement sur Mac.
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en
C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis
différents OS. De là à la surcouche en n'importe quel langage de script,
il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par
rapports à d'autres langages plus modernes, il faudrait peut-être y
réfléchir à deux fois...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
Au vu des mots clefs : unix/editeur/compilateur et surtout jesépatro, je te conseillerais d'utiliser Perl comme langage de programmation (de mémoire il y a des bibliothèques de manipulation MIDI). C'est un langage qui a été très populaire pour la création de cgi mais il ne fait pas que cela (loin de là). En plus cerise sur le gâteau, il est porté sur Windows et certainement sur Mac.
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis différents OS. De là à la surcouche en n'importe quel langage de script, il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
redgiantstarNO$PAM
Alex Marandon wrote:
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis différents OS. De là à la surcouche en n'importe quel langage de script, il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
J'aurais dû m'en douter que lorsque l'on parle de perl il y a toujours python en embuscade.
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web mais cela n'enlève en rien les qualités intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les bases de données...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la formidable richesse de la library CPAN, n'a pas d'équivalent chez python (en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini (avant la 3ème guerre mondiale d'après les auteurs) soit de démarrer dés ce W.E. avec MIDI perl.
Alex Marandon wrote:
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en
C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis
différents OS. De là à la surcouche en n'importe quel langage de script,
il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par
rapports à d'autres langages plus modernes, il faudrait peut-être y
réfléchir à deux fois...
J'aurais dû m'en douter que lorsque l'on parle de perl il y a toujours
python en embuscade.
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp,
jsp ou php dans le monde du web mais cela n'enlève en rien les qualités
intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec
tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les
bases de données...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la
formidable richesse de la library CPAN, n'a pas d'équivalent chez python
(en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini
(avant la 3ème guerre mondiale d'après les auteurs) soit de démarrer dés
ce W.E. avec MIDI perl.
Il existe aussi des bibliothèque d'abstraction multiplateformes écrites en C, ou pire en C++, qui permettent un accès uniforme au MIDI depuis différents OS. De là à la surcouche en n'importe quel langage de script, il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
J'aurais dû m'en douter que lorsque l'on parle de perl il y a toujours python en embuscade.
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web mais cela n'enlève en rien les qualités intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les bases de données...
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la formidable richesse de la library CPAN, n'a pas d'équivalent chez python (en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini (avant la 3ème guerre mondiale d'après les auteurs) soit de démarrer dés ce W.E. avec MIDI perl.
Emmanuel Florac
Le Wed, 16 Nov 2005 11:19:24 +0000, Alex Marandon a écrit :
Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin d'avoir la maturité de perl, et Python a ses défauts que certains jugent rhédibitoires (en particulier le choix de l'indentation signifiante), quant à php, c'est encore un jouet. Perl rulez :)
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Wed, 16 Nov 2005 11:19:24 +0000, Alex Marandon a écrit :
Vu comment Perl est en perte de vitesse par
rapports à d'autres langages plus modernes, il faudrait peut-être y
réfléchir à deux fois...
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin
d'avoir la maturité de perl, et Python a ses défauts que certains jugent
rhédibitoires (en particulier le choix de l'indentation signifiante),
quant à php, c'est encore un jouet. Perl rulez :)
--
Les défauts n'apparaissent qu'après que le programme a passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Le Wed, 16 Nov 2005 11:19:24 +0000, Alex Marandon a écrit :
Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin d'avoir la maturité de perl, et Python a ses défauts que certains jugent rhédibitoires (en particulier le choix de l'indentation signifiante), quant à php, c'est encore un jouet. Perl rulez :)
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Emmanuel Florac
Le Wed, 16 Nov 2005 12:45:28 +0100, redgiantstarNO$PAM a écrit :
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web
Faut le dire vite quand même; Amazon.com, slashdot et pleins d'autres sites sont en Perl...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Wed, 16 Nov 2005 12:45:28 +0100, redgiantstarNO$PAM a écrit :
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp,
jsp ou php dans le monde du web
Faut le dire vite quand même; Amazon.com, slashdot et pleins d'autres
sites sont en Perl...
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Wed, 16 Nov 2005 12:45:28 +0100, redgiantstarNO$PAM a écrit :
Qu'est ce qui te fais dire cela ? Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web
Faut le dire vite quand même; Amazon.com, slashdot et pleins d'autres sites sont en Perl...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
redgiantstarNO$PAM
Emmanuel Florac wrote:
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin d'avoir la maturité de perl, et Python a ses défauts que certains jugent rhédibitoires (en particulier le choix de l'indentation signifiante), quant à php, c'est encore un jouet. Perl rulez :)
N'entrons pas dans une gueguerre stérile Perl/Python. Grâce au CPAN, Perl est capable de faire beaucoup de choses. De part ses qualités de pâté cornichon (pattern recogniction) c'est un outils de choix sur de l'Unix pour de la manipulation MIDI ou toute autre opération de filtrage, composition algorithmique etc...
Emmanuel Florac wrote:
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin
d'avoir la maturité de perl, et Python a ses défauts que certains jugent
rhédibitoires (en particulier le choix de l'indentation signifiante),
quant à php, c'est encore un jouet. Perl rulez :)
N'entrons pas dans une gueguerre stérile Perl/Python. Grâce au CPAN,
Perl est capable de faire beaucoup de choses. De part ses qualités de
pâté cornichon (pattern recogniction) c'est un outils de choix sur de
l'Unix pour de la manipulation MIDI ou toute autre opération de
filtrage, composition algorithmique etc...
Perte de vitesse, faut pas exagérer tout de même... Ruby est loin d'avoir la maturité de perl, et Python a ses défauts que certains jugent rhédibitoires (en particulier le choix de l'indentation signifiante), quant à php, c'est encore un jouet. Perl rulez :)
N'entrons pas dans une gueguerre stérile Perl/Python. Grâce au CPAN, Perl est capable de faire beaucoup de choses. De part ses qualités de pâté cornichon (pattern recogniction) c'est un outils de choix sur de l'Unix pour de la manipulation MIDI ou toute autre opération de filtrage, composition algorithmique etc...
Alex Marandon
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
Qu'est ce qui te fais dire cela ?
- pas d'interpréteur interactif - pas d'exceptions - pas de backtrace en cas de plantage - des fonctionalités OO rajoutées sur le tard avec les moyens du bord - des fonctionalités de réflexivité ésotériques
Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web mais cela n'enlève en rien les qualités intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec
Faramineuse, il faut le dire vite, on en trouve les limites. En revanche la bibliothèque standard est particulièrement pauvre, si bien qu'on est rapidement amener à gérer des dépendances sur une tripotée de modules ce qui entraine des pertes de temps non négligeables lors des déploiements. Les outils Perl pour faciliter l'installation des modules et la gestion des dépendances entre modules sont loin de réduire ce coût à néant.
Avec python, les piles sont incluses, on a juste besoin de modules pour le domaine métier de l'application qu'on développe. Les fonctionalités de base sont déja là.
tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les bases de données...
Oui bon, le texte et les bases de données, trouvez-moi un langage utilisé en production qui ne propose pas le nécessaire, même des CommonLisp et autres Objective Caml tiennent la route de ce côté.
Pour ce qui est de l'audio, on peut mentionner qu'une install standard de python permet déja de manipuler des fichier audio. On trouve ensuite tout ce qu'il faut pour accéder aux interfaces audio.
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la formidable richesse de la library CPAN, n'a pas d'équivalent chez python (en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini
Ou d'y contribuer, ou de faire du C/C++. Sinon, en fait, en googlant un minimum on se rends compte qu'il existe déja des choses opérationnelles en Python également pour faire du MIDI.
Un point sur lequel Perl est beaucoup plus riche, c'est la documentation, mais c'est peut-être simplement un symptôme de la complexité du langage.
Il n'en reste pas moins que coder du Perl est très amusant :-) Mais lorsqu'on veut mener un projet à long terme, on est obligé de mettre de côté tous les aspects amusants du langage et d'en utiliser un sous-ensemble pour conserver un code lisible.
Pour un CGI, un script d'admin, de traitement de fichier texte ou pour faire quelques essais avec du MIDI, Perl sera parfait. Mais pour un projet un peu important, on ne m'y reprendra plus.
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par
rapports à d'autres langages plus modernes, il faudrait peut-être y
réfléchir à deux fois...
Qu'est ce qui te fais dire cela ?
- pas d'interpréteur interactif
- pas d'exceptions
- pas de backtrace en cas de plantage
- des fonctionalités OO rajoutées sur le tard avec les moyens du bord
- des fonctionalités de réflexivité ésotériques
Les cgi ont été remplacé par des asp,
jsp ou php dans le monde du web mais cela n'enlève en rien les qualités
intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec
Faramineuse, il faut le dire vite, on en trouve les limites. En revanche
la bibliothèque standard est particulièrement pauvre, si bien qu'on est
rapidement amener à gérer des dépendances sur une tripotée de modules ce
qui entraine des pertes de temps non négligeables lors des déploiements.
Les outils Perl pour faciliter l'installation des modules et la gestion
des dépendances entre modules sont loin de réduire ce coût à néant.
Avec python, les piles sont incluses, on a juste besoin de modules pour
le domaine métier de l'application qu'on développe. Les fonctionalités
de base sont déja là.
tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les
bases de données...
Oui bon, le texte et les bases de données, trouvez-moi un langage
utilisé en production qui ne propose pas le nécessaire, même des
CommonLisp et autres Objective Caml tiennent la route de ce côté.
Pour ce qui est de l'audio, on peut mentionner qu'une install standard de
python permet déja de manipuler des fichier audio. On trouve ensuite
tout ce qu'il faut pour accéder aux interfaces audio.
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la
formidable richesse de la library CPAN, n'a pas d'équivalent chez python
(en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini
Ou d'y contribuer, ou de faire du C/C++. Sinon, en fait, en googlant un
minimum on se rends compte qu'il existe déja des choses opérationnelles
en Python également pour faire du MIDI.
Un point sur lequel Perl est beaucoup plus riche, c'est la
documentation, mais c'est peut-être simplement un symptôme de la
complexité du langage.
Il n'en reste pas moins que coder du Perl est très amusant :-) Mais
lorsqu'on veut mener un projet à long terme, on est obligé de mettre de
côté tous les aspects amusants du langage et d'en utiliser un
sous-ensemble pour conserver un code lisible.
Pour un CGI, un script d'admin, de traitement de fichier texte ou pour
faire quelques essais avec du MIDI, Perl sera parfait. Mais pour un
projet un peu important, on ne m'y reprendra plus.
On 2005-11-16, redgiantstarNO$PAM <"redgiantstarNO$PAM"@free.fr> wrote:
il n'y a qu'un pas. Vu comment Perl est en perte de vitesse par rapports à d'autres langages plus modernes, il faudrait peut-être y réfléchir à deux fois...
Qu'est ce qui te fais dire cela ?
- pas d'interpréteur interactif - pas d'exceptions - pas de backtrace en cas de plantage - des fonctionalités OO rajoutées sur le tard avec les moyens du bord - des fonctionalités de réflexivité ésotériques
Les cgi ont été remplacé par des asp, jsp ou php dans le monde du web mais cela n'enlève en rien les qualités intrinsèques de Perl ainsi que la faramineuse bibliothèque CPAN avec
Faramineuse, il faut le dire vite, on en trouve les limites. En revanche la bibliothèque standard est particulièrement pauvre, si bien qu'on est rapidement amener à gérer des dépendances sur une tripotée de modules ce qui entraine des pertes de temps non négligeables lors des déploiements. Les outils Perl pour faciliter l'installation des modules et la gestion des dépendances entre modules sont loin de réduire ce coût à néant.
Avec python, les piles sont incluses, on a juste besoin de modules pour le domaine métier de l'application qu'on développe. Les fonctionalités de base sont déja là.
tout ce qu'il faut pour manipuler du MIDI, de l'Audio, le texte, les bases de données...
Oui bon, le texte et les bases de données, trouvez-moi un langage utilisé en production qui ne propose pas le nécessaire, même des CommonLisp et autres Objective Caml tiennent la route de ce côté.
Pour ce qui est de l'audio, on peut mentionner qu'une install standard de python permet déja de manipuler des fichier audio. On trouve ensuite tout ce qu'il faut pour accéder aux interfaces audio.
D'ailleurs, on recrute chez Python : http://pythonmidi.sourceforge.net/
Python (1990) n'est pas plus moderne que Perl (1987). Par contre la formidable richesse de la library CPAN, n'a pas d'équivalent chez python (en tout cas en MIDI)
http://www.cpan.org/modules/by-module/MIDI/
Notre ami a donc le choix soit d'attendre que pythonMIDI soit fini
Ou d'y contribuer, ou de faire du C/C++. Sinon, en fait, en googlant un minimum on se rends compte qu'il existe déja des choses opérationnelles en Python également pour faire du MIDI.
Un point sur lequel Perl est beaucoup plus riche, c'est la documentation, mais c'est peut-être simplement un symptôme de la complexité du langage.
Il n'en reste pas moins que coder du Perl est très amusant :-) Mais lorsqu'on veut mener un projet à long terme, on est obligé de mettre de côté tous les aspects amusants du langage et d'en utiliser un sous-ensemble pour conserver un code lisible.
Pour un CGI, un script d'admin, de traitement de fichier texte ou pour faire quelques essais avec du MIDI, Perl sera parfait. Mais pour un projet un peu important, on ne m'y reprendra plus.
