EnergyXT : Désactiver des VST(i) par CC ?
- 14 réponses
- 2 participants
- 675 vues
- 2 followers
alesissss
L'idée étant de désactiver des effets pour économiser de la ressource calcul quand on ne se sert pas de certains effets.
Donc quand je parle de désactiver cela revient à 'pousser sur le bouton on/off de l'effet'.
- 1
- 2
alesissss
Va falloir attendre donc ...
alesissss
Evidement nous sommes à une ère où l'économie de ressource est complètement oubliée par les développeurs car la puissance des machines augmente sans cesse.
Mauvaise philosophie que voilà ...
silicon/silicium
Citation : pour des host je trouve quand meme ca assez élémentaire de se soucier de l'économie des ressources ... or pour ma part je n'ai encore jamais trouvé de host gérant correctement cette possibilité
c'ets pas une question d'oubli de l'economie ou quoi, arrete le delire parano, c'ets juste que comme ça a la volée arreter un process et remplacer son buffer par celui qui passe outre l'effet n'ets pas DU TOUT facile a faire sans faire de gros clics (donc inutile en automation)
alesissss
Ceci dit ne te sens pas visé, je trouve XT vraiment tres bien.
Maintenant que ce soit difficille à faire je ne dis pas le contraire mais quand tu empiles des VST tu es forcément confronté au probleme des perfs ...
Et si les gens d'ableton y arrivent ...
silicon/silicium
maintenant que les developpeurs ne se soucient pas de l'optimisation, c'ets une blague, bien sur on ne pense au pII 233 comme utilisateur moyen, mais tout est fait pour reduire la conso, je participe a pas mal de betatests, et crois moi, ça fait parti des grandes preoccupations. au passage tu m'expliqueras quelle difference ça fait d'avoit une interface skinnable ou une interface fixe en terme de programmation....
alesissss
Ou alors je suis sourd ...
Peux tu me dire quelle est la config de l'utilisateur moyen pour un prog comme Ableton Live ?
Citation : au passage tu m'expliqueras quelle difference ça fait d'avoit une interface skinnable ou une interface fixe en terme de programmation....
La différence se situe au niveau du temps de programmation : c'est une fonctionalité supplémentaire par rapport à l'éssentiel; elle prend donc tu temps de développement, de l'énergie et des sous. Le layout de Live est bien chiadé (on aime ou on aime pas c'est un autre débat) mais tous les contrôles 'standard' ont été redessinés ce qui nécessite un travail de loin non négligeable (développeur, graphistes entre autres).
Personellement je préfèrerais mettre mes sous dans un prog moche (à tout le moins "windows standard" ) pour lequel tout le temps de développement est consacré au son.
Bon une fois que c'est fais je ne crois pas que cela pénalise énormément les perfs (quoique si l'on veut être puriste cela se discute (mais pas avec moi car je ne suis pas programmeur) ... et des puristes dans le son il y en a qq uns ... ), à condition que cela soit bien développé.
silicon/silicium
Citation : mais tous les contrôles 'standard' ont été redessinés ce qui nécessite un travail de loin non négligeable
c'ets pas les codeurs qui font l'interface... skinner, c'ets juste dans le cas d'energyXT remplacer une serie de bitmap par une autre serie de bitmap, c'ets pas tres sorcier, et c'ets pas Jorgen qui fait les skins, t'as juste, telle zone va chercher l'image A, telle autre l'image B, et dans ta skin, t'as une collection d'images indexées. pour ableton, je doute que les codeurs fassent aussi l'interface, mais on est dans le meme delire, une interface ça va SUPER vite a faire par rapport au reste, et souvent c'est pas les memes personnes qui s'en occupent. bref, c'est pas ça qui les detourne va t'inquiete pas...
Citation :
Peux tu me dire quelle est la config de l'utilisateur moyen pour un prog comme Ableton Live ?
a mon avis, on code plus pour les gens en dessous de 1ghz, meme plus a mon avis. c'est comme ça, on fait plus de site en 800*600 non plus, et on hesite pas a charger 700Mo en ram sur des sampleurs/rompleurs...
alesissss
Citation : c'ets pas les codeurs qui font l'interface
M'enfin faut bien l'implémenter ton interface !
La conception d'une interface homme-machine n'est pas si simple que ce que l'on pourrait croire à première vue car dans 'interface homme-machie' il y a le mot 'homme' qui est plutôt complexe.
Je parle ici dans sa globalité : philosophie, architecture, ergonomie, graphisme, programmation.
Tous ces "métiers" coutent.
Dis moi donc pourquoi Traktion V1 a intégré d'office une interface non standardisée ?
Jules a passé du temps dessus et je ne crois pas que ce soit négligeable.
Parce que le look fait vendre.
Et ca n'a rien à voir avec le son.
T'as déjà comparé le look du vu-mètre de Samplitude et de Cubase ?
Dans SAM t'as un applat gris (Windows like) dans une fenêtre Windows. C'est moche. Aucun graphiste n'a travaillé sur ca.
Dans Cubase c'est une image qui est chargée en mémoire. C'est beau, ca a été fait par un graphiste.
Par contre dans SAM c'est redimmenssionnable pour pouvoir LIRE les niveaux et tu as les valeurs max, peak et RMS de tes niveaux.
Je préfère qu'un développeur en fasse un redimenssionnable plutot qu'un graphiste bosse dessus, à cout égal.
C'est une question de philosophie.
De plus, meme si l'on parle perfs, l'image de Cubase il faut la stocker en mémoire alors que l'applat non. Tu vas me dire que c'est négligeable mais si on applique cette remarque à tout le logiciel, on arrive à des log plus performants que d'autres.
Sorry mais quand je vois le temps d'ouverture d'un projet VIDE avec SAMPLITUDE comparé à LIVE ou Cubase, il n'y a pas photo, de meme que la quantité de mémoire utilisée. Et la mémoire d'une machine étant limitée, ce que tu bouffe avec ton host, tu ne l'as plus pour tes plugs'ins.
Il faut qd meme bien reconnaitre que les machines sont de plus en plus puissante maintenant alors que j'ai pas l'impression que le temps que nous passons à attendre devant l'ordi soit plus court !
Cela prouve bien que le "rendement" des applications baisse avec le temps.
silicon/silicium
Citation : je vois le temps d'ouverture d'un projet VIDE avec SAMPLITUDE comparé à LIVE ou Cubase
faut aussi dire que ces 2 conio là scannent a chaque fois les vstis, reteste les drivers, etc... et que c'est pas la methode la plus rapide pour gerer le chargement.
pour en revenir aux interface, c'est assez facile a coder en soi bien sur il faut les penser, ça prends du temps, bien plus que e coder, mais ça en fait gagner a l'utilsateur. en gros c'ets un choix, parfois tu travailles plus vite et mieux dans une interface intuitive et bien pensée que dans des GUI austere a menus deroulants. regarde, meme samplitude, ils ont tres vite skinné la console et les pistes, et leurs parts audio sont tres jolies. franchement, sur une GUI bien pensée, on peut a la fois faire du leger et de l'intuitif.
regarde comment la plupart d'entre nous ont abandonné le hard justement pour beneficier du confort graphique. je ne suis pas de ton avis, je pense au contraire que l'interface, meme lourde, revet une tres grande importance dans le travail.
Citation : Je préfère qu'un développeur en fasse un redimenssionnable plutot qu'un graphiste bosse dessus, à cout égal.
toute l'interface de live et de tracktion sont en vectoriel je crois.
- < Liste des sujets
- Charte
- 1
- 2