CCgousset : regarde l'api GetDIBits . Perso je n'ai pas de source avec, mais ca devrait etre une bonne piste.

Bonjour, il existe plusieurs tutorials et sources ici traitant de l'optimisation  du code VB.
As-tu réalisé ta comparaison en compilant ton petit programme VB ? car evidemment si tu compares de l'assembleur compilé à un langage interprété, la différence donnera le vertige.
Un rapide coup d'oeil montre que ton programme VB peut considérablement être optimisé : virer l'appel aux objets (If truc.machin = bidule, etc), changer les méthodes de comparaisons, pré-test, boucle déroulé, et API pour la sortie graphique.

Il y a d'autres sources de spectre temps réel sur vbfrance :
http://www.vbfrance.com/codes/SPECTRUM_34733.aspx
http://www.vbfrance.com/codes/ANALYSEUR-SPECTRE-AUDIO-NUMERIQUE_3178.aspx
(pour ne citer que les plus célèbres)
Le principe étant d'écouter le "retour" de la carte son, c'est-à-dire l'après-WaveOut.
Le défaut est donc que le spectre a quelques dizaines de millisecondes de retard par rapport au signal entendu.
Dans cette source, le retard est de 60ms, mais le but original était de faire un enregistreur longue durée fiable (j'm'en sert comme "audiosurveillance") m'enfin chacun son truc :)

tdt63, pour avoir un spectre du signal envoyé en waveout c'est très, très facile... Tu places les données audio à envoyé en mémoire, tu appliques la FFT, et tu syncrhonise l'affichage du spectre avec le moment où tu envoie ces données audio en waveout.
Reste à savoir quel est l'origine des données audio. Un fichier wav ? un mp3 ? une vidéo ?

Pour résumé la pensée :
i = i + 1, c'est aussi rapide dans n'importe quel langage. Le défaut du VB6 compilé c'est qu'il fait inc eax là ou les compilo modernes font add eax,1

Faut pas tirer sur l'ambulance! en vb6, on est pas obligé de faire text1.text = text1.text + label1.caption, il y en a qui connaissent le coup du i = i + 1 (et qui compile en natif et pas p-code)

A ceux qui ont un code vb 10 à 30 fois plus lent qu'un code en C, remettez-vous en question avant d'accuser votre IDE favori ! des dizaines de tutoriaux sur VBFrance exposent comment éviter les pièges à lenteur.

J'aime bien la polémique :)
VB6 est aussi rapide que n'importe quel langage lorsqu'on fait des algorithmes _pur_ et qu'on ne code pas avec ses gros sabots.
La gestion des tableaux et des type utilisateurs et un chouia plus lent qu'en c++ a cause des contrôles anti "seg fault"... et le fait qu'on ne puisse pas utiliser de pointeurs.
Les opérations en virgules flottantes sont aussi un chouia plus lente, dans certains cas, à cause -aussi- de vérifications anti-dépassements.
Par contre il perd en vitesse si on travaille avec les gestions de Variant ou String (concaténation, mid() left() format(), etc...) là ou tous les autres langages ont des routines plus finaudes.
Enfin, l'utilisation d'objets et d'API est un gouffre à performances... à n'utiliser qu'en dernier recours (donc en E/S, et surtout pas dans un algo!).

Et bien evidemment, si vous compilez pas vos programmes VB6, toutes comparaisons avec des autres langages du même niveau est une hérésie... comparez-le plutôt au javascript dans ce cas!

Au final, VB6 est définitivement dépassé en perf parce qu'il ne bénéficie pas d'un compilateur costaud (son compilo date de 1998, et donc il était adatpé au CPU de l'époque, tandis qu'en .net, vc etc... ils sont plus récent, tirent parti du pipelining, des grosses caches, branchement prédictifs si on place les instructions dans un certain ordre...)

Les plus :
- une bonne idée
- résultat visuel sympathique :)
Les moins :
- consommation CPU maximale (car ça utilise a outrance les propriétés des objets au lieu de passer par des variables type Long!)
- impossible de quitter une fois le programme lancé (rajoute quelque chose dans Form1_KeyPress pour stopper le prog!)

L'inverse, pour Philpaul...
Dim Buf() As String
Dim s As Long
Buf = Split(tempsHMS$,":")
s = CLng(Buf(0)*3600 + CLng(Buf(1))*60 + CLng(Buf(2))

Salut Guillaume1136, je n'ai pas de réponses pour .NET ...

Cependant la fameuse DLL ddraw.dll est certainement la réponse (c'est celle utilisé pour l'affichage vidéo/film, ca ne passe donc pas par le GDI:Get/SetPixel... mais ca écrit pratiquement directement dans la mémoire vidéo)

En VB6 c'est pratiquement inutilisable hélas. Peut-etre qu'en .NET c'est plus simple.

Question source, cherche directement dans la msdn online de microsoft, ca m'étonnerai qu'un code source ai jamais été publié en vb.net

Enfin, si tu cherches d'autres formules a modéliser, intéresse toi aux attracteurs étranges (clifford, etc). Le site de Paul Bourke fourni les fonctions mathématiques "prete à l'emploi" pour la programmation.

Ok. Alors c'est impossible avec juste les API de cet exemple... en effet, mcisendstring crée une surface primaire ddraw pour y mettre les pixels de la vidéo directement, c'est "plus bas niveau" que ce que VB peut faire, donc les objets vb resterons au second plan. Je n'ai pas de solutions à te proposer.

La commande qui colle la vidéo dans la picturebox est celle-ci :
mciSendStringA "open MPEGVideo! ... parent " & Picture1.hwnd ...
Il te faut donc un objet qui ai un hwnd. les Imagebox ne le fournissent pas, donc pour la vidéo, tu dois vraiment utiliser une picturebox. Va dans les propriété de la picturebox pour enlever les bordures et autres... comme ca elle sera "invisible" à l'instar d'une imagebox.