EnergyXT : Désactiver des VST(i) par CC ?

14 réponses
2 participants
730 vues
2 followers

alesissss

2389

AFicionado·a

Membre depuis 22 ans

Sujet de la discussion Posté le 09/08/2005 à 10:22:09

Est ce possible de désactiver des VST(i) par un Control Change ou par une automation quelconque ?
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'.

alesissss

2389

AFicionado·a

Membre depuis 22 ans

2 Posté le 09/08/2005 à 10:50:26

Ok ok ... j'ai la réponse : https://www.kvraudio.com/forum/viewtopic.php?t=98494
Va falloir attendre donc ...

alesissss

2389

AFicionado·a

Membre depuis 22 ans

3 Posté le 09/08/2005 à 11:00:34

N'empêche ... 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é (ca marche avec LIVE mais moyennant bricolage).

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

2662

Squatteur·euse d’AF

Membre depuis 20 ans

4 Posté le 25/08/2005 à 20:14:25

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

2389

AFicionado·a

Membre depuis 22 ans

5 Posté le 25/08/2005 à 21:07:50

T'exite pas Silsic ... c'est pas un délire parano que de penser que les développeurs en ont rien à kiker des perfs actuellement. Suffit de voir qu'ils préfèrent commencer à développer des produits skinables plutot que performants.
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

2662

Squatteur·euse d’AF

Membre depuis 20 ans

6 Posté le 26/08/2005 à 08:14:50

Au pris des seuls cracks et clicks presents dans ableton. mettre un plug in en bypass complet, c'ets assez complexe, il faut passer d'un buffer a l'autre, vider la ram pour les rompler/samplers, tout ça de maniere transparente et sans detruire la synchro de l'ensemble... bref, je pense que Jorgen peut le faire, de la a ce que ce soit utilisable en live....

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

2389

AFicionado·a

Membre depuis 22 ans

7 Posté le 26/08/2005 à 09:27:48

Pas de clicks particuliers quand je fais la manip dans Live.
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

2662

Squatteur·euse d’AF

Membre depuis 20 ans

8 Posté le 26/08/2005 à 15:37:42

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

2389

AFicionado·a

Membre depuis 22 ans

9 Posté le 26/08/2005 à 16:29:57

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

2662

Squatteur·euse d’AF

Membre depuis 20 ans

10 Posté le 26/08/2005 à 19:48:34

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.

alesissss

2389

AFicionado·a

Membre depuis 22 ans

11 Posté le 26/08/2005 à 20:46:02

Pourquoi les relisent ils alors ?
SAM s'en tire tres bien sans, la gestion des VST(i) y est tres bonne.
Je ne suis pas sur que ce soit la seule raison ...

Autre exemple : avec un projet de 1 piste audio VIDE le process SAM.exe occupe 20Mo en ram alors que celui de Live4 utilise ... 40Mo !! Et je n'ose m'imaginer combien Cubase occupe (si qq veut bien regarder, moi j'ai pas le soft).
C'est assez révélateur ...
Idem pour la conso CPU : moyenne de 15% pour LIVE et 0 à 2 % pour SAM.

Tu explique ca comment Sil ?

Pour moi une interface LOURDE, aussi belle et ergonomique soit elle est parfaitement RATEE.

Par ailleurs je trouve que le visuel a trop d'imporance actuellement.
L'important n'est ce pas le son ?
Il y a pas mal de gens ici qui te dirons qu'un tel plug sonne hyper bien car il est ... beau !
C'est dommage, ca les coupe de l'essentiel ...

silicon/silicium

2662

Squatteur·euse d’AF

Membre depuis 20 ans

12 Posté le 26/08/2005 à 20:52:21

Citation : Autre exemple : avec un projet de 1 piste audio VIDE le process SAM.exe occupe 20Mo en ram alors que celui de Live4 utilise ... 40Mo !! Et je n'ose m'imaginer combien Cubase occupe (si qq veut bien regarder, moi j'ai pas le soft).
C'est assez révélateur ...
Idem pour la conso CPU : moyenne de 15% pour LIVE et 0 à 2 % pour SAM.

pour le cas de live, c'ets pas dur:
lance ta lecture dans samplitude, change le tempo sans rien arreter, charge un vst sans rien arreter, puis un presets de ce vst sans rien arreter.... live le fait, samplitude non. alors effectivement, cette souplesse doit avoir un cout considerable (par contre, pas la moindre idée de comment il font precisement).
vraiment, en accusant les GUI, je ne pense pas que tu aies trouvé le bon coupable.

alesissss

2389

AFicionado·a

Membre depuis 22 ans

13 Posté le 26/08/2005 à 21:08:53

Citation : pour le cas de live, c'ets pas dur:
lance ta lecture dans samplitude, change le tempo sans rien arreter, charge un vst sans rien arreter, puis un presets de ce vst sans rien arreter.... live le fait, samplitude non.

Ca n'a rien à voir, SAM fait plein de choses que LIVE ne fait pas.
Et ce n'est pas cela qui justifie le double d'occupation mémoire et 15 % de CPU en plus!!!!
Et franchement, les 15% je ne crache pas dessus ...

Non je crois simplement que les développeurs actuels ont moins en tete les préoccupations de perfs, et ce car les machines sont plus puissantes. Enfin ne généralisons pas, XT semble (tres) bien se comporter il me semble.

Ceci dit, effectivement les GUI ne sont certainement pas seules en cause, évidement.
J'ai juste pris cette partie d'un développement comme exemple révélateur de la mentalité actuelle de développement ...

Tiens je viens d'essayer, dans SAM on peut tres bien couper et mettre en marche un VST en insert sur une piste audio sans coupure dans le flux ... je ne vosi vraiment pas ou est le problème !?

silicon/silicium

2662

Squatteur·euse d’AF

Membre depuis 20 ans

14 Posté le 26/08/2005 à 22:10:34

Franchement, ce que fait live en temps reel est un exploit, je ne sais pas comment marche leur truc exactement, mais de tres loin, ça veut dire a mon avis que quelque part, ils se prennent le luxe d'assurer le flux, ce qui ne doit pas etre sans consequence niveau cpu. c'est aussi simple que ça, t'as deux outils qui n'ont pas les memes fonctionnalités, d'un coté un sequenceur audio comme on en fait depuis cakewalk pro audio 7, c'ets a dire aucune contraite de temps reel, de l'autre, un bouzin capable de stretcher a la volée 12 pistes d'audio, de recaler tout les delais, et d'importer des fichiers sans le moindre craquement. pour "assurer" ce genre d'exploit (parce que c'ets vraiment un exploit, qu'ils sont assez peu a reproduire), c'ets evident qu'il se passe quelque chose partout en permanence dans live.
au passage pour des gens qui se soucient eu de l'optimisation, live 5 consomme moins de cpu a projet egal que live 4, et permet le freeze horizontal et vertical...

bref, comparer live a sam n'est VRAIMENT pas une bonne idée, live pourrait consommer le double, vu ce qu'il offre comme fonctionnalité, et qu'il est le seul a offrir, il cartonnerait autant.

Citation : Tiens je viens d'essayer, dans SAM on peut tres bien couper et mettre en marche un VST en insert sur une piste audio sans coupure dans le flux ...

ben si tu codais un peu, tu le verrais ou il est le probleme, un vst ça travaille avec des paquets de samples, et si au milieu de ça tu lui dis stop, ben il faut que ton soft sache quoi faire de ce paquet, qu'il aille recuperer un paquet non traité, comment reagir si le vsti vide ou remplit la ram quand tu l'actives. bref, beaucoup de programmation pour pas grand chose, a froid comme ça, je dirais que ça implique de garder un signal dry pour chaque effet, de s'arranger pour pas que le changement tombe ailleurs que sur un 0 de l'onde. tout ça pour que 2% des utilisatuers puissent faire tourner le soft sur leur athlon 1ghz.... dans sam, tu peux assigner le on/off a un cc??? c'est un vrai on off??

alesissss

2389

AFicionado·a

Membre depuis 22 ans

15 Posté le 28/08/2005 à 20:44:04

Citation : bref, beaucoup de programmation pour pas grand chose, a froid comme ça, je dirais que ça implique de garder un signal dry pour chaque effet, de s'arranger pour pas que le changement tombe ailleurs que sur un 0 de l'onde. tout ça pour que 2% des utilisatuers puissent faire tourner le soft sur leur athlon 1ghz.... dans sam, tu peux assigner le on/off a un cc??? c'est un vrai on off??

OK je code pas et j'ai pas envie non plus, sinon je le ferais.
Ceci dit je viens d'essayer la manip sur EnergyXT et cela fonctionne également.
Fais l'essais, tape un VST, lance le flux audio et coupe ton VST, tu verras il n'y a pas de coupure du flux. Alors je ne vois toujours pas ou est le probleme !!??
Tout ce que je demande c'est, à la place de switcher en poussant sur le bouton on/off avec la souris, de pouvoir le faire avec un CC. C'est pinuts par rapport à ce qui existe déjà !
Et si cela pose un probleme ca ne me dérange pas qu'une latence soit établie entre la récption du CC et le changement de flux ... ainsi t'as le temps de consruire ton flux dry et de passer "smoothly" à celui ci ...

Concernant le nombre d'utilisateur intéressé par une telle fonction tu m'étonnes un peu car dès que tu empile un certain nombre de plug sur un mix d'un nombre raisonnable de piste (genre 30, on y arrive vite) tu sature vite ton CPU. Ma machine n'est pas un foudre de guerre mais c'est tout de meme un P4 2,4 avec 1 GB de RAM et du raid0 ...

Ah oui, dans SAM c'est un vrai on/off mais on ne peut pas l'assigner à un CC.

< Liste des sujets
Charte

Liste des modérateurs