Nouveautés

La Taylor, à mon avis, l'intérêt n'est pas de savoir si c'est made in us ou pas, mais plutôt de savoir que si c'est taylor c'est irréprochable, perso c'est l'impression que ça m'a donné, y'a rien à dire, c'est parfaitement construit, et juste.

Maintenant, même si c'est bleuffant pour 600 euros, bien sûr, même très très bleuffant, à mon avis ça ne souffre évidemment pas la comparaison avec une gratte haut de gamme en terme de richesse de son. Mais on est très très très loin d'avoir une guitare pas terrible entre les mains, et c'est là que c'est très fort.

comme Denis je suis aussi convaincu qu'en société avec d'autres gratteux dotés d'engins haut de gamme, on peut s'en sortir plus qu'honorablement

perso je ne l'ai toujours pas achetée, question de moyens pour le moment, et si je le fais ça sera pour remonter dessus mon système capteur/flottant et en faire ma guitare de travail pour le duo. Mais je dois dire aussi être de plus en plus attaché à ma guitare de luthier, qui n'est pas non plus du très très haut de gamme, mais qui a un truc à elle seule... mais qui est un peu difficile en live car les fréquents changements d'accord que je pratique son difficiles à faire rapidos avec une gratte de ce type, toute massive et qui bouge facilement, alors qu'avec une gratte genre taylor, ça bouge beaucoup moins.

Pourrais-tu détailler un peu plus sur ce fameux ISF ? (je parle de l'Américain bien sur  )

Dans ce que j'ai lu en dessous de midi on a un son plus US (6L6) et au dessus plus British (EL 34 ?), mais en pratique ça donne quoi ?

Faut m'excuser les amplis à lampes, je ne connais pas ...  

Sinon Blackstar a sorti des ampli à modélisation (la série ID) qui ont l'air tout ce qu'il y a de bien d'après les tests, as-tu aussi essayé ?

Merci d'avance.

Non, je n'ai pas essayé les versions à modélisations...

Pour l'ISF, effectivement c'est bien ce que tu dis (sauf que c'est dans l'autre sens je pense).

Alors, on a d'abord mis le gain sur un léger crunch et là rien... tourner le potard ISF n'avait pas d'effet audible. En mon fort intérieur, j'ai pesté à l'arnaque marketing de plus...
Mais en montant le gain pour avoir un crunch plus franc, ou une saturation, alors la différence est nette.
Ca agit clairement sur l'égalisation : le son devient plus sombre en position US, et avec plus de médiums dans la position GB (mais pas caricatural, c'est subtil, du coup, les positions intermédiaires ne m'ont pas paru tellement pertinentes).
Ca doit agir aussi sur la boucle de retroaction : le son est plus ouvert, granuleux en position GB, et plus "boxy" et lisse en position US, ce qui correspond bien à une des nuances entre un Marshall et un Mesa.

Par ailleurs, ca reste globalement un ampli moyen de gamme, il donne un son facile à jouer, il n'y a pas des masses de dynamique. D'où mon idée que c'est un ampli qui va bien pour du rock, mais faut pas chercher des subtilités, ni des sons aérés.
C'est un bon ampli pour débuter par exemple.

Sur la tête transat, par contre, là il y a de la dynamique et de l'air. Mais en crunch c'est assez lisse. Faut faire plus gaffe à ses attaques : ça claque vite.
Bon, c'est ce qu'on attend d'un ampli à lampe digne de ce nom aussi...  
Je viens d'essayer un truc : il y a un boost sur les deux canaux. Sur la canal clair, le boost agit aussi sur l'égalisation.
Du coup, le canal clean seul est fendérien (pas loin d'un HotRod), mais avec le boost, il s’assombrit un peu et ressemble plus à un AC 15 (mais pas tout à fait, mais ça se rapproche).

C'est pas pour tout de suite dans le commerce, mais l'IRCAM met au point des trucs intéressant :




Ici sur un violon samplé :





Là c'est un synthé avec un clavier en silicone :




Et la première pédale d'effets OpenSource !




Là c'est un clavier avec un rangement des notes intéressant :

OWL m'intéresse bien. Dommage que je n'aie pas connu le projet avant ! Peut-être que je l'achèterai ou la suivante s'ils développent vraiment un module synthé pour guitare dont je rêve depuis longtemps.

A suivre donc...  

Elle est belle la nouvelle tele de Billy Gibons (par John Bolin, comme d'hab) :

JeanBaptiste a écrit:

C'est pas pour tout de suite dans le commerce, mais l'IRCAM met au point des trucs intéressant :
Ici sur un violon samplé :
Là c'est un synthé avec un clavier en silicone :
Et la première pédale d'effets OpenSource !
Là c'est un clavier avec un rangement des notes intéressant :

LE OWL!!!   alors là c'est révolutionnaire...j'avais survolé sur sur un blog mais je n'avais pas saisi...c'est saisissant!

Karmatotal a écrit:

OWL m'intéresse bien. Dommage que je n'aie pas connu le projet avant ! Peut-être que je l'achèterai ou la suivante s'ils développent vraiment un module synthé pour guitare dont je rêve depuis longtemps.

Tu as déjà essayé des pédales synth, modulateur? pigtronix, micro synth?
qu'en penses tu?

Karmatotal a écrit:

OWL m'intéresse bien. Dommage que je n'aie pas connu le projet avant ! Peut-être que je l'achèterai ou la suivante s'ils développent vraiment un module synthé pour guitare dont je rêve depuis longtemps.

Tu peux peut-être réaliser tes rêves rapidement, il y a le Roland VG-99 qui est bluffant : aucune latence, tracking impeccable du fait qu'il utilise un système qui s'apparente plus à un vocoder qu'à un synthé traditionnel (il y a quand même un très bon convertisseur MIDI pour pouvoir utiliser des modules extérieurs), possibilités impresssionnantes.
Et Fishman vient de sortir le Triple Play qui soulève l'enthousiasme de Guitar Player lors de son essai (inconvénient il faut un ordi sous Win 7 ou un Mac OS.X je ne sais plus quoi).

@Stan : j'ai eu l'occasion d'essayer le ROLAND VG 99. Très bien mais plutôt orienté modélisation (comme d'ailleurs la plupart de ces bestiaux) et pour réellement fabriquer des sons nouveaux, avec les boutons tactiles et autres, c'est assez décourageant, je trouve. 1000 euros c'est encore un peu cher pour moi pour cette utilisation.
Je trouve le système OWL (sur le papier en tout cas) bien meilleur : tu achètes la pédale et tu programmes toi-même (en C++, c'est pas ma tasse de thé, je préfère le Pascal, mais bon je m'adapterai) les sons que tu veux faire sortir de la bête. Tu peux tester ces sons sur ton PC avec un SDK qu'ils te fournissent gratuitement. Le tout pour moins de 300 euros, compact, format pédale, pratique, ça me tente.

@Paddy : j'ai pu  tester les electro harmonix (minisynth, et HOG). La HOG je l'ai trouvée très bien mais il faut un contrôleur E.H en plus pour pouvoir vraiment s'en servir sur scène (les mains sont prises en général pour un guitariste ... )alors quand tu ajoutes le prix de la HOG + Le contrôleur  ça te fait rapidement autour de 600 euros voire plutôt 700. Je trouve que les possibilités ne sont pas assez développées pour ce prix. En fait je m'oriente soit vers un PC dédié aux synthés + Ardour, Rosegarden et tutti quanti avec possibilité d'utiliser les sons de synthés pour la guitare avec un boîtier en interface mais c'est un système fragile (sur le plan informatique s'entend) donc sur scène, assez peu exploitable en situation de live "jazz". Ou alors une petite boîte type OWL justement, commode, robuste, que tu programmes chez toi et dont tu ressorts les prog sur scène grâce à des patches. Il faut sans doute un contrôlleur midi aussi pour gérer les banques de sons, mais, du coup, c'est plus valable. Donc je réfléchis (de toute façon la workstation équipée pour le son c'est pour dans quelques mois maximum).

stan_fr a écrit:

Tu peux peut-être réaliser tes rêves rapidement, il y a le Roland VG-99 qui est bluffant : aucune latence, tracking impeccable du fait qu'il utilise un système qui s'apparente plus à un vocoder qu'à un synthé traditionnel (il y a quand même un très bon convertisseur MIDI pour pouvoir utiliser des modules extérieurs), possibilités impressionnantes.

         Il faut un midi contrôleur au pied plus un capteur sur la guitare pour le faire fonctionner. C'est un peu usine à gaz. Pas moyen de brancher un PC pour servir de générateur de sons. Bof-bof

stan_fr a écrit:

Et Fishman vient de sortir le Triple Play qui soulève l'enthousiasme de Guitar Player lors de son essai (inconvénient il faut un ordi sous Win 7 ou un Mac OS.X je ne sais plus quoi).

 

J'ai vu les démos de ce truc que je ne connaissais pas. Très impressionnant ! En fait ce serait vraiment ça qu'il me faudrait mais avec un logiciel qui puisse tourner sous Linux et qui soit ouvert (i.e qu'il puisse communiquer avec d'autres synthés virtuels pour qu'on puisse vraiment faire ses propres sons, la modélisation ne m'intéresse absolument pas). En fait je voudrais un bon capteur pour guitare qui n'ait pas de latence et puisse se brancher (via USB ou Jack) ou avec un transmetteur wireless comme le fishman à un PC sous Linux pour piloter des synthés virtuels ou des banques de sons fabriquées avec CSOUND ou PureData.

 Ca c'est mon rêve. Je pense que ça va sortir un jour...

Karmatotal a écrit:

... En fait je voudrais un bon capteur pour guitare qui n'ait pas de latence et puisse se brancher (via USB ou Jack) ou avec un transmetteur wireless comme le fishman à un PC sous Linux pour piloter des synthés virtuels ou des banques de sons fabriquées avec CSOUND ou PureData.

 Ca c'est mon rêve. Je pense que ça va sortir un jour...

La latence n'est pas liée au capteur (ou très peu) mais au fait que pour extraire la note jouée il faut une période complète de celle-ci c'est une loi purement physique ... Et pour le Mi grave d'une guitare (~ 80Hz) ça fait 12,5 milliseconde ce qui s'entend.
Ça pourrait être compensé en jouant (très) en avant du temps, le problème c'est que tous les convertisseurs MIDI que j'ai essayés convertissent plus vite les notes aigües que les graves ce qui complique sérieusement la manœuvre ...  

Peut-être que Fishman fera une version Linux de son soft, je te le souhaite mais je pense que c'est plus probablement de la communauté Linux que les drivers nécessaires viendront.

Tu as raison, j'ai dit "capteur" par flemme, mais j'aurais dû dire "système de numérisation du son d'une guitare". Ce qui me gêne justement dans les systèmes que j'ai essayés c'est que comme tu le dis la latence n'est pas la même selon que tu joues dans les aigus ou dans les graves... Ca c'est l'enfer.

 Pour le reste, je pense qu'effectivement ça viendra de la communauté Linux (perso je vais essayer d'apprendre à écrire un driver dès que j'aurai un peu de temps devant moi) et je pense aussi qu'il y aura de plus en plus de matos programmable en open-source type OWL. Ca va dans le sens de l'histoire et les petites start-up ont tout intérêt à s'y mettre pour bénéficier du crowdsourcing, donc j'ai confiance en l'avenir sur ce point.

Juste un conseil et je parle d'expérience là : si tu veux écrire un driver apprend le C plutôt que le C++**, tu auras un bien meilleur contrôle de bas niveau  

** d’ailleurs la plupart des compilateurs C++, préprocessent ton source C++ pour en faire un source C pur ...

J'ai déjà écrit du C, je peux en refaire, mais c'est un langage que je n'aime pas notamment pour ses (nombreux) effets de bords et parce que je le trouve (c'est un avis perso) fragile : depuis le temps qu'il a été inventé il n'est toujours pas possible d'utiliser <scan> sans problème, par exemple, il faut sempiternellement réécrire du code par dessus.. Je préfère encore écrire de l'assembleur inline.

 En C++ on a aujourd'hui parfois quasiment le même contrôle (sauf sur de l'embarqué c'est évident) car progressivement le C est devenu un sous-ensemble inclus dans le C++ (c'était prévu comme ça au départ mais il a fallu pas mal de temps pour passer de la théorie à la pratique). Avec un bon pre-processeur, il te sort du C99 effectivement. Tous les kernel à ma connaissance (Linux, Win au moins) sont passés de C à C++.

Je connais des développeurs qui sont censés passer leurs journées à écrire en C et qui écrivent en fait en C++ (mais ils n'utilisent pas les classes of course ni la STL) parce que le compilo n'est pas une vraie passoire. Mais s'il faut (re)faire du C, je referai, pas de pb. De toute façon ce n'est pas pour tout de suite, le FreePascal suffit largement à mes besoins (essentiellement des programmes pour piloter LaTeX ou Beamer ou des trucs dans le genre). 

En C tu écris très vite, après le débogage est très très long...

Pétard  

C'est quoi un effet de bord en C ???  

En C tu n'as pas de "procédures", uniquement des "fonctions". Or une fonction normalement renvoie une valeur. Il faut donc inventer des fonctions "vides" qui ne renvoient pas de valeur mais modifient l'état des données ou du système. Un effet de bord (side effect in english, qu'on devrait traduire plutôt par effet secondaire) se produit en informatique quand une fonction modifie autre chose que sa valeur de retour.

Comme tout le langage C (et dans une moindre mesure le C++ qui a un peu introduit de la rigueur là-dedans) est basé sur ce principe, dans un programme C tu n'as quasiment que des effets de bord qui compliquent considérablement la lisibilité et le comportement prévisionnel du programme.

Ok, dont acte  

Karmatotal a écrit:

En C tu n'as pas de "procédures", uniquement des "fonctions". Or une fonction normalement renvoie une valeur. Il faut donc inventer des fonctions "vides" qui ne renvoient pas de valeur mais modifient l'état des données ou du système. Un effet de bord (side effect in english, qu'on devrait traduire plutôt par effet secondaire) se produit en informatique quand une fonction modifie autre chose que sa valeur de retour.
...

Euh ...  

En C tu peux faire ça sans aucun problème : une fonction de type void (type prédéfini en C rien à inventer ici) à laquelle tu passes des pointeurs ... Ou encore en déclarant les variables à l'extérieur de ta fonction elles sont alors globales et reconnues comme telles dans la fonction ...

Ex (bidon, c'est juste pour l'exemple) :

int a, b;

void add(void)
{
a = 2 * b ;
return; /* Optionnel puisque le type de la fonction est void ... */
}

int main (void)
{
b=4;
add();
printf("%d",a);
return 0 ; /* Valeur conventionnelle pour dire que tout s'est bien passé */
}


Tu peux aussi utiliser le passage par adresse (pointeurs) :

void add(int *c, int *d)
{
c = 2 * d ;
return; /* Optionnel puisque le type de la fonction est void ... */
}

int main (void)
{
int a, b=4;
add( &a, &b);
printf("%d",a);
return 0 ; /* Valeur conventionnelle pour dire que tout s'est bien passé */
}

Le seul réel avantage de C++, pour un programmeur solo, c'est effectivement la gestion des erreurs** (catch/try ...) et les librairies de GUI genre Qt (mais pour un driver ça ne s'impose pas vraiment).  

Pour une équipe de programmeurs C++ peut être intéressant c'est vrai, puisqu'il suffit de décrire les méthodes publiques des classes.

Pour le débugging, j'ai eu de mes plus gros cauchemars en C++ avec les memory leaks ...  (Et jamais de problème avec scanf).

Putain  

Là ça devient vraiment technique !  

  génial! mais j'y entrave que dalle !
respect les deux .

On est complétement barrés dans le H.S. là   (bon c'est pas la première fois ...).

Pour moi aucun mérite : j'ai passé les dix dernières années de ma vie professionnelle comme programmeur pour de l'acquisition et du traitement rapide de signal ...

stan_fr a écrit:

En C tu peux faire ça sans aucun problème : une fonction de type void (type prédéfini en C rien à inventer ici) à laquelle tu passes des pointeurs ... Ou encore en déclarant les variables à l'extérieur de ta fonction elles sont alors globales et reconnues comme telles dans la fonction ...

Ex (bidon, c'est juste pour l'exemple) :

int a, b;

void add(void)
{
a = 2 * b ;
return; /* Optionnel puisque le type de la fonction est void ... */
}

int main (void)
{
b=4;
add();
printf("%d",a);
return 0 ; /* Valeur conventionnelle pour dire que tout s'est bien passé */
}


Tu peux aussi utiliser le passage par adresse (pointeurs) :

void add(int *c, int *d)
{
c = 2 * d ;
return; /* Optionnel puisque le type de la fonction est void ... */
}

int main (void)
{
int a, b=4;
add( &a, &b);
printf("%d",a);
return 0 ; /* Valeur conventionnelle pour dire que tout s'est bien passé */
}

Pour le débugging, j'ai eu de mes plus gros cauchemars en C++ avec les memory leaks ...  (Et jamais de problème avec scanf).

   j'ai l'impression que notre petite conversation va lasser nos amis mais je voudrais quand même ajouter à ton "euh ?" un autre "euh ?" si tu le permets  :
  D'un point de vue strictement informatique peux-tu me dire ce que c'est qu'un type "vide" (ou void) ? Parce qu'un type, nous sommes bien d'accord que c'est un gabarit de donnée, un modèle général de donnée. Donc en C nous avons un gabarit général de donnée... inexistante. C'est quand même ça cela signifie du point de vue de la sémantique du langage. Ca ne veut pas dire que cela ne fonctionne pas, cela veut dire qe cela pose des problèmes d'effets de bord.

  Quant à scanf, on peut certes l'utiliser avec beaucoup de précautions mais les problèmes de débordements de la pile sont légion et très connus, cf http://stackoverflow.com/questions/3456106/problem-using-scanf
Tiens voici un petit code avec boucle infinie liée à l'utilisation de scanf si l'utilisateur tape une lettre par exemple.

Code:

#include <stdio.h>
 
int main(void)
{
    int n = 0;
 
   while (n != 1)
    {
        printf("Tapez 1 pour quitter.\n");
        scanf("%d", &n);
    }
 
   return 0;
}

 Pour finir, je pense que C est un langage intéressant (sinon il n'aurait pas eu le succès qu'il a connu même si c'est aussi pour des raisons conjoncturelles de passage de l'assembleur à un langage qui ressemblait suffisamment à de l'assembleur pour qu'on ne soit pas dérouté). Simplement il a des défauts (comme tout langage par ailleurs) qui le rendent un peu dangereux et surtout complexe à utiliser : il faut tout vérifier. C'est l'anti ADA en fait (que je n'aime pas trop non plus). Pour de l'embarqué, c'est souvent le seul langage possible, pour le reste, quand j'ai le choix, je choisis autre chose, si je n'ai pas le choix je fais du C. Je comprends qu'en acquisition cela reste le langage de choix si on ne veut pas faire d'assembleur, c'est un domaine que je ne connaît pas en plus (j'avoue donc mon ignorance).

 Pour les fuites mémoire, j'ai eu des problèmes sur quelques gros programmes aussi bien en Pascal, qu'en C++ ou en C. C'est bien pourquoi Java et consort implantent un garbage collector (même si ça pose aussi des problèmes). Je ne suis pas sûr que C++ induise plus de memory leaks que C mais je ne suis pas assez compétent dans ces deux langages pour dire ça.


 Bref pour un programme d'une centaine de lignes ou deux, ça va, on peut [edit : je peux] vérifier tout. Quand ça dépasse j'ai du mal, sans compter que pour moi le C n'est pas particulièrement lisible comparé aux langages dérivés d'Algol. Mais voilà, c'est juste une opinion perso, je comprends qu'on puisse aimer. Cela dit les effets de bords, c'est pas perso, c'est dans n'importe quel cours structuré sur le C, il n'y a guère que ce langage qui confonde procédure et fonction et qui soit donc obligé d'inventer le concept de type vide.

lasser non, le forum est là pour échanger,à deux ou a dix  
c'est ce qui fait sa force.

pour Karma :Scoop : Ubuntu Studio 13.10 est chargé avec une foule de drivers multimédias.

Syndesmo Jean a écrit:

lasser non, le forum est là pour échanger,à deux ou a dix  
c'est ce qui fait sa force.

pour Karma :Scoop : Ubuntu Studio 13.10 est chargé avec une foule de drivers multimédias.

 Oui j'ai vu ça. Je n'y suis pas encore passé parce que je suis assez conservateur en informatique :lol: mais je le ferai bientôt dès que j'ai ma workstation.

Tu as une liste fiable des cartes sons et autre matos compatibles sur LinuxMao