Commentaires de Proger sur tout CodeS-SourceS

191 commentaire(s) de Proger sur des sources sur tout CodeS-SourceS

Le : 15/12/2007 00:03:32
Source : ENREGISTREUR WAVEIN, FILTRE ET ANALYSE SPECTRALE

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 ?

Le : 11/12/2007 18:44:59
Source : AVOIR LA SOURCE ASM DE VOTRE PROJET VB

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.

Le : 11/12/2007 14:44:49
Source : AVOIR LA SOURCE ASM DE VOTRE PROJET VB

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...)

Le : 01/12/2007 01:01:49
Source : SHAPE SPOTS LINE LAZER EFFET DE LUMIERE POUR LES NULS

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!)

Le : 29/11/2007 23:55:42
Source : CONVERSION D'UN TEMPS EN SECONDES AU FORMAT HH:MM:SS

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))

Le : 15/11/2007 14:56:04
Source : EXPLORATEUR FRACTALE MANDELBROT HAUTE DEFINITION

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.

Le : 23/06/2007 17:25:59
Source : LECTEUR VIDEO (MULTIMEDIA) SANS OCX NI WMP - COMPLET

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.

Le : 23/06/2007 11:56:52
Source : LECTEUR VIDEO (MULTIMEDIA) SANS OCX NI WMP - COMPLET

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.

Le : 22/06/2007 10:26:05
Source : LECTEUR VIDEO (MULTIMEDIA) SANS OCX NI WMP - COMPLET

Tu détecte la fin de lecture du fichier avec un timer qui appelle mciSendStringA "status ... position notify" souvent,
Puis tu utilises mciSendStringA "seek ... to 0" ou mciSendStringA "play ... from 0".
L'écran noir devrai etre très bref, meme imperceptible.

Le : 05/06/2007 12:43:47
Source : AFFECTATION D'UNE VARIABLE LORS DE LA DÉCLARATION

Oui, la grosse boucle est la seule "bonne" solution. Quand ton programme est compilé, c'est rapide. Surtout si tu n'as qu'une dimension.

Cependant tu peux aussi utiliser l'API RtlFillMemory si vraiment la boucle te dérange (ou que tu as plusieurs dimensions à ton tableau), mais ca rempli tous les octets (byte) sans distinction integer ou long.

Une dernière astuce si ton tableau est vraiment de grande taille, tu crées une ligne avec des 3, et tu utilises l'API RtlCopyMemory pour le copier à chaque "colonne"...
Cependant j'insiste qu'une fois compilé, c'est la boucle "mano" qui sera le plus rapide.