Discussion :

[kindyroot]

Désolé pour les quelques jours d'absence
Oui d'accord on fait comme ça moldavi, j'ai aussi repéré un logiciel libre interessant il y a quelques instants qui s'appelle Gnuitar qui fait la même chose que nous, je suis mtn sous BSD j'attend de rebooter sous windows pour l'installer et éxaminer le code source, ça marche sous windows et linux et apparement ça a une latence incroyablement basse sous windows, le code source ressemble à une grosse application, je pense pas que ça nous aidera mais ça reste quand même une source d'inspiration, pour le code de notre programme mon todo le plus immédiat est d'écrire une petite librairie pour récuperer les données d'un fichier .wav (je sais que ça éxiste mais je veux ré-écrire mon propre truc taillé aux besoins de l'application) après je vais éssayer de faire des transformations trèès basiques et de sauvegarder le tout en wav, je vais poster le code aussitôt qu'il sera prêt.

[moldavi]

OK.

Je prépare le petit cahier des charges avec explication des choix ce week-end (un bon week-end de trois jours).

Pour l'histoire de latence, j'ai mon idée sur la chose mais je vais regarder le logiciel dont tu viens de parler.

PS : je viens de tomber sur ceci :

http://www.developpez.net/forums/sho...d.php?t=352477

[kindyroot]

c'est cool si tu peux rédiger un cahier de charches ce weekend, j'ai aussi posté une demande sur le thread que tu m'as montré, je pense que ça serait bien de faire un truc qui travail dans un premier temps en asynchrone, c à dire ouvre un fichier, fait le traitement, et enregistre, comme un plugin VST, on pourra éventuellement passer aussi par le stade plugin VST et après aborder la question du temps réel, car je vois qu'il y a bcp de gens qui se sont focalisé sur la performance et le temps réel comme le Gnuitar mais finalement le son de ce truc c'est de la merde, ce n'est vraiment pas un exemple à suivre, si on travail d'abord sur des fichiers .wav on se concentrera bcp plus sur la technologie que nous développons (puisque c'est bien de technologie qu'il s'agit!), notre cahier de charge de base c'est donc comment simuler un ampli réel sans en copier la réponse (avec de la convolution ou autre) mais en recréant les conditions du traitement de signal dans un ampli réel à lampes voir en les modifiant pour améliorer encore plus la sonorité, il ya bcp de choses fascinantes à mettre au point tu verra!

[moldavi]

Bonjour.

Je synthétise les idées pour avancer dans le cahier des charges :

- faire de l'acquisition audio de guitare avec du matériel informatique. J'ai besoin de renseignements sur la façon dont le signal est récupéré : la guitare est branché sur un ampli et la sortie audio de cet ampli sur le PC ?

- récupérer les frames audio et appliquer un traitement en temps réel.

- enregistrer le signal traité sur le disque (pendant le traitement ?).

Pour ces points :

- DirectShow permet de seléctionner et de paramétrer le matériel audio en vue d'une acquisition.
- L'architecture de DirectShow permet le traitement "temps réel" du signal audio par un système de filtre.
- Le système de filtre permettra d'ajouter de nouveaux effets sans toucher à l'exécutable. Comme un système de pluggin.
- Ce système de filtre permettra de séparer le développement de l'algorithme de traitement du programme principal.
- Pour l'enregistrement du signal, possibilité à terme d'encoder dans plusieurs formats.
- Possiblité pour du "non temps réel", d'appliquer le traitement après enregistrement (voir latence ->).

Je commence à me poser des questions sur cette histoire de latence. Je n'ai pas encore les moyens de tester, il faut que je récupère ma guitare (mon ampli est naze aux dernières nouvelles).

Première chose: "guitare->câble->ampli->câble->carte audio". Avant d'arriver à la carte audio, le son parcours un chemin qui induit déjà un temps de latence. De quel ordre, je ne sais pas.


Ensuite, faire de l'acquisition avec un PC, il faut abandonner l'idée du "temps réel", dans le sens ou un PC ne peut pas rivaliser avec un ampli. Les OS ne sont pas "temps réel", il faut faire avec et voir dans quelle mesure c'est utilisable ou pas. J'ai d'ailleurs des doutes sur le système ASIO. Même les drivers sous XP ne sont pas les maîtres du PC. XP est en mode protégé, les drivers ne peuvent pas faire les interruptions comme ils voudraient. Je n'ai pas trouvé de détails sur la manière dont les drivers d'ASIO optimisent la latence. Je reste sceptique jusqu'à preuve du contraire. D'ailleurs ASIO n'est pas compatible avec tous les matériels.
C'est la raison pour laquelle je parle de traitement post-acquisition. Une manière de contourner cette histoire de latence, dans la mesure ou ce serait une vrai problématique.

Voilà le débat est ouvert sur ces points. Nous devons dégrossir les choses encore et surtout faire apparaître les points délicats qui pourraient être un gros souci dans le développement. Je connais trop bien le développement du multimédia et l'influence du matériel sur cela, pour me lancer tête baissée.

Pour tester l'acquisition avec DirectShow, il y a des programmes dans le SDK qui pourront permettre de se faire une idée de ce que ça peut donner. Je pourrais indiquer si nécessaire la démarche.

PS : la qualité du matériel audio utilisé influence beaucoup la qualité de l'enregistrement.

[kindyroot]

Bonjour ,
Oui en effet quand je dis "temps réel" ça veut pas dire "traitement instantanée" mais une "latence" inférieur à un certain degré determiné (de 5 à 10ms), Direct Audio est connu pour avoir un temps de latence particulièrement grand (expérience sur d'autres logiciels et avec du materiel différent à l'appui), je ne sais vraiment pas comment ASIO arrive à offrire des latences vraiment spéctaculaires (pratiquement inaudibles) et même sur du materiel ancient, mais ça marche pas sur toutes les cartes son.
Pour l'acquisition elle sensée se faire directement à partir de la guitare en la branchant sur la carte son sans ampli (notre logiciel devant justement faire office d'un ampli), pour ne pas trop nous encombrer avec la technologie et la question de latence, je propose qu'on travail dans un premier temps en asynchrone afin de pouvoir tester nos algorithmes et nos idées, on enregistre alors le son naturel de la guitare avec un logiciel quelconque, on exporte le truc en .Wav et notre logiciel s'occupe d'ouvrire ce fichier wav et d'apporter le traitement nécéssaire, cette démarche est nettement plus simple et moins restrictive que le fait de faire l'acquisition à l'entrée, de traiter en temps réel et d'éxporter à la sortie de la carte son, deuxième avantage: on va savoir plus rapidement si nos idées valent le coup, si ce qu'on va apporter va vraiment créer une grosse difference au niveau grain et qualité du son par rapport aux autres logiciels ou au materiel hardware réel qu'il y a, si c'est bon on aura touché le jakpot! on pourra alors trouver rapidement un moyen de faire une version temps réel performante et on se penchera plus du coté de la fonctionnalité et de l'érgonomie et tout, on pourra même vendre notre technologie telle quelle à l'un des fabriquants de pédaliers numériques à modélisation comme BOSS, KORG, ZOOM et les autres.
Si tu es d'accord avec moi sur cette façon de voir, nos proncipales fonctions à implémenter pour l'instant se réduisent à cela:
- Lire un fichier Wav et récuperer les données audio dans un []
- apporter n'importe quel traitement bidon au son (exemple: modifier le volume).
- Exporter la sortie dans fichier Wav.
c'est tout!!
Je pense que je peux faire ce travail en quelques heures maximum deux jours.
toi de ton coté tu pourrais nous trouver une librairie convenable pour faire des traitements fréquentiels (équalisation, analyse spéctrale, filtrage, ...) mais surtout pour l'équalisation (donc il nous faut truc hyper simple).
Une fois que ce sera fait nous pourrons nous lancer dans le design de notre solution technique proprement dite pour modéliser un ampli guitare à lampes (éventuellement le haut parleur de guitare aussi (oui il n'est pas du tout linéaire lui aussi !!)).
Je file coder le truc, ah et pour le langage en travail en C pour l'instant? ou C#? ou quoi? je code pour l'instant en C pour m'amuser un peu et on retraduit éventuellement vers autre chose, à bientôt.