Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Effets et traitements logiciels
Agrandir
Effets et traitements logiciels
Logiciels de musique
Effets et traitements logiciels
Produits 8 046 8k
Actu 9 637 9,6k
Articles 435 435
Médias 26 123 26,1k
Tutoriels Tutos 86 86
Avis 3 341 3,3k
Petites annonces Annonces 378 378
Forums 10 943 10,9k

Avis au programmeur et guitariste (gratomatic)

  • 80 réponses
  • 11 participants
  • 1 787 vues
  • 1 follower
Sujet de la discussion Avis au programmeur et guitariste (gratomatic)
Je code actuellement (cpp/mfc) un plug-ins VST permetant de gerer des gerer des chaines de plug-ins.. dans le but d'utilisé un pedalier midi pour controler quel chaine a utilisé etc...
en fait c'est une sorte de amplitube mais ca permet d'utiliser n'importe quel VST ds n'importe quel ordre...

ex :
ch1: flanger => chorus => amplitube
ch2: flanger => warpVST
ch3: warpVST => chorus => fx-verb => jeCpakelVST

ce plug réutilise les VST (il ne se servira que de 1 seul flanger)
il permet de passer d'une chaine a l'autre par une automation VST
chaque chaine stocke les parametre de chaque plug-ins (le flanger dans ch1 auras des parametre différents que celui dans ch2,mm si la ch1 et la ch2 se serviront du mm plug)


si quelqu'un est intéréssé pour m'aider a dévelloper ca...
Afficher le sujet de la discussion
41

Citation :
Alors 2 Mo au lieu de 20...... j'ai du passer a cote de quelque chose



Ben par exemple, est ce que tu laisses les symboles de débugage, etc...
42
Moi je me sert pas de .NET j'aime pas,et ca va moins vite que du natif...
mais je me sert des VS.net pour faire des trucs non .NET..
pour pas se prendre la tete (comme les mec de emule font, il faut include les 2 ou 3 dll nécéssaire dans le repertoire de l'application et c'est bon...)

pour .NET c'est la merde,donc encore un point negatif pour moi..

pourkoi mettre les MFC dans mon plug??
ben pq pour rapelle c'est un plug qui utilise des plug et que j'avais pas envie de tous gerer en win32 natif...
pour l'instant l'interface est trés provisoire mais,les MFC permettent de coder bien plus facilement et avec beaucoups de moins de galere que sans mfc...

pr un plug normal ya pas besoin de MFC (mm au contraire) vu que son role principalement c'est de faire des calculs, alors que le role du plug la c'est surtt de gerer des fenetres et d'autre classe...
43
Gabou -> le probleme reside dans le fait que tu sois apparement obligé d'installer toutes les librairies .net (donc 23Mo......) avant ton programme. Maintenant, j'espere ne pas encore avoir trouvé la bonne façon de faire...

a plus........
44
Avec .NET ya pas de notion d'assemblage statique il me semble,son fonctionnement est similaire a java un peu (c'est une machine virtuel) donc pour que ton code compilé en .NET marche il lui faut forcément la VM (le framework .NET)

donc inclure les 23MO en question...
et je suis quasiment certains qu'il n'y a pas d'autre solution...

a par attendre que ts le monde est un PC ac .NET dessus.. (surrement qd tt le monde aura du 64bit(e)(s) (yen a qui accorde!!menfin ca fait un peu beaucoups non??))
45

Citation :
pour .NET c'est la merde,donc encore un point negatif pour moi..



.NET de la merde ? T'es bien le premier à le dire, tiens ! Tous ceux que j'entends n'en disent que tu bien.

Et une machine vm n'est pas forcément plus lente que du C++. Par exemple, en java, on commence à voir des calculs plus rapides qu'en C ou C++. Il commence à y avoir des techniques de malades de compilation 'online' (je connais pas le vrai terme, je connais pas beaucoup java ou c#).
46
##gratomatic à été mis a jour (correction de bug fatal !)

bon, toujours aucun beta testeur ???

j'ai pas dis de la merde,mais "la merde" cad la galere (pq il faut distribuer le framework)..

quand a la rapidité,ya rien a faire du natif c'est forcément un peu plus rapide que du interprété à qualité de compilateur égale...

mais les applis .NET marchent bien c'est pas le pb,mais c'est un peu plus (par rapport au teste que j'en ait fait)
47
D'ailleurs vous savez si on peut utiliser les librairies VST en c#(en dynamique forcément j'imagine... quoique je crois que c# peut insérer du code non managé en c++)
48
Moi je veux bien beta tester mais c'est juste un dll ou faut autre chose?
Non, rien.
49
En c# ca me parait faisable,mais doit yavoir quelque modif a faire a la compil....(en mm tps je connais pas bps c#)

ben pour le faire tourner suffit de mettre la dll dans vstplugins et c'est bon..
(faut renommer controlsgui.dll_stat en controlsgui.dll)
50

Citation :
quand a la rapidité,ya rien a faire du natif c'est forcément un peu plus rapide que du interprété à qualité de compilateur égale...



Ben non, justement. Parce qu'un interpréteur peut faire des choses qu'un compilo ne pourra jamais faire (utiliser des trucs propres au contexte d'exécution).

Par contre, pour le temps réel, là, le c#, en tout cas pour le corps DSP, tu évites direct. Il faut que le ou les thread s'occupant de l'audio soient le plus rapide et le plus indépendants possibles, donc entre autre pas d'appel système. Alors le c# avec tout ce qui est gc et cie.

Même en C, il faut jamais faire de malloc, de manipulation de fichier, etc.... Idéalement, il faudrait même pas de processus de synchronisation: il faudrait que le thread audio n'ait besoin d'aucune ressource particulière; mais peu d'OS le permettent. Alors le c#, bof bof ;)