Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 120 426 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
471
Je ne connais pas VST mais DSSI c'est très simple, c'est une des motivations: mettre la complexité dans l'hote et avoir des plugin simples à développer. Pour les outils de debug, il y a les outils standards. Tu penses à quoi en particulier ?

DSSI pourrait être porté sur n'importe qu'elle plateforme. L'avantage c'est qu'il n'est pas soumis au bon vouloir d'une seule entreprise. DSSI est un effort commun et public, ce qui le rapproche plus d'un standard, contrairement à VST qui est une techno proprio de Steinberg. GMPI à pour but d'être un standard: http://www.gmpi-plugins.org/gmpi/requirements.php

Jul

472
Dssi c'est plus pour les instruments virtuel un peu comme les vsti.....

Pour l'avenir du plugin http://lv2plug.in/

l'avennir de linux dans l'audio pro promet d'etre florissant!
473

Citation :
En fait je pense maintenant faire un binding python pour dssi. Enfin un quick hack pour commencer. Ca devrait permettre de faire des plug en python. Je me rappelle que tu as fais une bidouille similaire récemment.



Passe par ctypes. Ca permet de faire le wrapping 100 % en python, c'est vraiment genial pour faire des proto. Typiquement, j'ai wrappe libsndfile et libsamplerate de Erik Castro de Lopo de cette maniere, tu peux voir le code la si tu veux voir comment ca marche:

http://www.ar.media.kyoto-u.ac.jp/members/david/softwares/index.html

En gros, c'est quelques centaines de lignes pour libsndfile, developpe et teste en 1 journee (dont la majorite pour avoir un systeme un minimum intelligent pour extraire les infos de la librairie de maniere dymamique) et 2 heures a tout casser pour libsamplerate (le wrapper est basique pour cette derniere).

Citation :
DSSI n'est pris en charge que par des hôtes linux non ?
Cela est bien dommage alors...car je ne pense pas que linux en audio pour semi pro et home studio percera si il définit ses propres standards.



Il a ete demande maintes et maintes fois a Steinberg si c'etait possible de filer VST en GPL; je crois qu'il n'y a jamais eu de reponse.

Faut voir qu'avec la license actuelle de Steinberg, c'est impossible de distribuer un VST en open source. En gros, t'es oblige de dl les headers VST a travers un processus bien chiant (inscription + mail, dl par mail, etc...).

Il y avait eu un effort de standart sous license open source (GMPI), mais c'est mort, j'ai l'impression. Il y a rien de fait depuis plusieurs annees maintenant.

Citation :
Je ne connais pas du tout le format dssi, mais déjà VST, c'est moche, très moche.



C'est quoi que tu trouves moche ? Il y a quelques problemes, mais le principal, c'est la sous specification/probleme de doc; ensuite, le reste, c'est possible d'ameliorer. Fondamentalement dssi et VST (et les autres) sont proches; apres, les api sont plus ou moins elegantes...
474

Citation :
C'est quoi que tu trouves moche ?


Il ya des menus détails dans la spécification qui peuvent pas mal compliquer le design. Comme par exemple la taille variable des chunks de données à traiter : certains hôtes changent tout le temps la taille des paquets que l'on a à sortir/calculer, ce qui demande une autre approche dans le codage.

Ensuite mon hôte m'envoie que des paramètres compris entre 0 et 1 vers mon synthé. L'hôte n'a pas l'être de connaitre du tout le type, les unités et le domaine de definition d'un paramètre.
En fait je trouve cette impossibilité de préciser ce genre d'info nulle (c'est peut-être mon hôte de test tu me diras, mis je me souviens pas l'avoir vu dans les exemples, les param allant toujours de 0 à 1).

Finalement, je trouve aussi dommage comme tu le fais remarquer le manque évident de doc dessus. Beaucoup d'algos basiques comme les filtres standards aurait pu être inclus dans une lib par exemple. IL n'y a pas eu de ce fait de syntaxe de codage VST qui s'est imposé. Cela aurait facilité grandement mon dev de VST, plutôt que de courir chercher des algos en C,C++, Delphi ou VB sur KVR et musicdsp...

http://soundcloud.com/bat-manson

475

Citation :
Il ya des menus détails dans la spécification qui peuvent pas mal compliquer le design. Comme par exemple la taille variable des chunks de données à traiter : certains hôtes changent tout le temps la taille des paquets que l'on a à sortir/calculer, ce qui demande une autre approche dans le codage.



LADSPA faisait pareil, et il me semble que d'autres aussi. C'est inherent au temps reel, je crois; je vois pas comment tu peux implementer des trucs comme la compensation de latence, etc... sans ca. Au debut, tu vas avoir des chunks de petite taille, et ensuite des chunks de taille plus grande une fois que l'hote a ses buffers remplis de donnees, par exemple.

Je sais pas, mais si tu regardes lv2, vst, dssi, audio unit, il y a pas de grandes differences, fondamentalement. C'est des questions d'implementations, des trucs qui peuvent etre importants, mais rien de fondamental. Ils ont tous une api pour charger des plugins a la volee, initialisation, filer les donnees en flottant, se renseigner sur les capacites de l'hote, la gestion des evenements, etc...

Citation :
Ensuite mon hôte m'envoie que des paramètres compris entre 0 et 1 vers mon synthé. L'hôte n'a pas l'être de connaitre du tout le type, les unités et le domaine de definition d'un paramètre.



Ca ok, c'est un probleme qui a ete beaucoup debattu, ainsi que les timestamp sur les donnees sur la ML GMPI lorsque c'etait actif; je remarque que ni l'in ni l'autre ne sont encore implementes avec ladspa ou sa version v2 (c'est en projet d'apres la page lv2 pour lv2). Ca peut etre ameliore. Faudrait une fois que je regarde comme marche les plugins sous mac os X.

Lorsque je suivais GMPI, je me souviens que pas mal de dev disaient que finalement, VST c'etait pas trop mal. Il y avait le probleme de docs et de sous specification (entre autre multi thread, ordre des appels cote hote, etc...), quelques trucs importants mais qui peuvent etre rajoutes a VST, surtout si on s'autorise a abandonner la compatibilite binaire, j'imagine (J'ai jamais essaye de comprendre comment rester compatible niveau ABI, j'avoue que ca m'interesse pas trop de toute facon).
476

Citation :
Faudrait une fois que je regarde comme marche les plugins sous mac os X.


A priori, c'est la même chose. J'utilise Juce comme crossplateforme, et je fais l'export pour tous ces formats à partir de cet overlay.

La taille des chunks varie constamment sur FL Studio...lors de l'augmentation de la polyphonie, qui doit entraîner une surcharge CPU à ce moment, les chunks sont plus petits...

Ce que je trouve aussi dommage est l'ncompatibilité de VST avec d'autres environnements non Windows...je ne me sers jamais d'appel spécifique windows dans mes plugins, et Juce y aide grandement tu me diras !

Enfin bon, mon petit synthé VST est en route, il arrivera avant Janvier c'est sûr !

http://soundcloud.com/bat-manson

477
Recoucou les gens,

Dsl j'ai pas les capacités techniques pour vous suivre, je commence à peine avec le Java ...

Je souhaitais savoir si vous pouviez m'expliquer si c'est possible de se faire un plug vst avec java ? Si oui comment ?
Et si qqun a déjà essayé de le faire avec Puredata ( logiciel de prog graphique, proche de maxdsp) ? Je sais qu'ils ont un module permettant d'en sortir avec ...

cptn.io

478
Les headers VST sont en fait une interface C, avec un wrapper C++. Concretement, ca veut dire que tu peux wrapper avec n'importe quel langage a la base, car je connais aucun langage qui ne soit pas capable d'etre etendu en C (et le C++ est en general une tres mauvaise idee pour les wrappers).

En java, tu as jni qui permet de faire ca, mais c'est pas super commode a utiliser. En plus sympathique, tu as swig qui permet de sortir du java.

Si t'es debutant, c'est pas le plus facile non plus, quand meme, interfacer avec le C. Surtout que tu vas devoir avoir un systeme d'instanciation de ton plugin complexe (l'hote s'attend a voir un wrapper avec des fonctions C/C++, donc va falloir lancer une machine virtuelle, exposer ton plug in, etc....). Ca doit etre possible, mais loin d'etre facile.

Fondamentalement, c'est pas une bonne idee de faire des plugs en java, je pense, a cause du garbage collector. Je connais pas beaucoup java, mais je pense pas qu'il soit possible, au moins facilement, de lancer un thread avec un systeme d'allocation memoire compatible avec le "temps reel". Et java ne permet pas non plus un prototypage rapide, donc je suis pas sur que ca ait un grand interet pour les plugs ins; je suis pas un gros fan de java, faut dire, donc bon, je suis pas forcement objectif :)

Citation :
La taille des chunks varie constamment sur FL Studio...lors de l'augmentation de la polyphonie, qui doit entraîner une surcharge CPU à ce moment, les chunks sont plus petits...



Oui, c'est oblige d'avoir des tailles variables, donc de ce cote la, VST est pas en faute. Par contre, je suis d'accord sur le fait qu'ils pourraient avoir un exemple qui traite de ce probleme (taille variable en E/S-> taille constante pour l'algo interne).

Citation :
Ce que je trouve aussi dommage est l'ncompatibilité de VST avec d'autres environnements non Windows.



Ca, c'est inexact. Je crois que certains softs steinberg ont ete developpes sous IRIX a la base (entre autre nuendo ?), et ardour supporte VST. Ce qui est fondamentalement imconpatible, c'est la GUI, mais de toute facon, tu peux pas le faire de facon cross platform, ca (je parle du framework; si tu imposes un quelconque toolkit, ca marchera pas sous linux, parce que tu as gtk et qt, etc...)

Citation : A priori, c'est la même chose. J'utilise Juce comme crossplateforme, et je fais l'export pour tous ces formats à partir de cet overlay.



JUCE le fait pour toi, ou tu dois gerer ca toi meme ?

Le probleme de JUCE et de VST, c'est qu'en theorie, je crois pas que ce soit possible d'utiliser les deux en meme temps question license (a moins que tu developpes avec la version non GPL de JUCE).

Encore une fois, c'est vraiment chiant cette histoire de redistribution de VST.
479

Citation :
JUCE le fait pour toi, ou tu dois gerer ca toi meme ?


Juce le fait pour moi. Tu as une classe qui s'appelle filtre et qui correspond plus ou moins à l'interface de VST. Ensuite à la compilation, tu spécifies quelle est le chemin de la classe prototype de filtre, et tu choisis entre VST, AU et RTAS.
C'est super pratique, car avec un seul code, tu peux compiler les trois versions.
Pour les GUI, Juce est aussi crossplateform. De la même manière, tu changes des options dans la compilation pour faire une GUI mac windows ou linux...mais ça, t'as même pas à t'en soucier pour les plugins audio, si tu prends VST, il prends par défaut la version windows etc...

Citation :
Le probleme de JUCE et de VST, c'est qu'en theorie, je crois pas que ce soit possible d'utiliser les deux en meme temps question license (a moins que tu developpes avec la version non GPL de JUCE).



Juce vends une licence commerciale effectivement. Mais rien ne t'empêche de fournir tes sources. Il faut pour l'utilisateur qui voudra compiler tes sources, inclure le chemin vers VSTSDK lors de la compilation (donc le télécharger).

Juce ne fournit pas ce SDK, il faut le télécharger soit même. Juce est juste une overlay de VSTSDK...

Par contre, il est tout à fait possible question licence d'utiliser Juce et VST-SDK en même temps, sauf que le résultat n'est pas GPL.
Je me demande si VST SDK est si complexe que cela, et que l'on ne pourrait pas reprendre l'intégralité du code dans une version GPL...mais cela risque d'être impossible niveau juridique...

http://soundcloud.com/bat-manson

480

Citation :
un plug vst avec java


Un coup de google est tu aurais trouvé :
http://jvstwrapper.sourceforge.net/
Jamais utilisé de mon côté, je sais qu'ils ont des très bons résultats.
PS : je hais Java.

Citation :
Et si qqun a déjà essayé de le faire avec Puredata


Oui. Mais je suis pas un grand fan de Pure Data pour faire des produits finis. Je préfère reprendre les protos Pure Data tout le code en C++ ou en C...
(en fait j'utilise plus Reaktor, il est vraiment super ce truc).

En plus les GUI PD sont minables et consomment énormément de ressouces. J'ai jamais vu une aussi mauvaise gestion des graphismes que sous Pure Data.

http://soundcloud.com/bat-manson