Avec un gros workspace
Même si je désactive le moteur audio la consomation CPU monte � 20%
Je suis sous mac el capitan.
consomation CPU
Voir cette page : cpu-consumption
Désolé mais ça ne m'apporte aucune explication.
Même toutes mes fenetres cachées je suis à 20% de cpu moteur audio éteint et 80 moteur audio allumé.
Même toutes mes fenetres cachées je suis à 20% de cpu moteur audio éteint et 80 moteur audio allumé.
Bon j'ai réussi à réduire sensiblement la charge cpu en augmentant un peu la taille des blocks. C'est déjà ça !
Bonsoir Joffo,
C'est etrange ta consommation de CPU. Tu parles bien du CPU affiche dans Usine, en haut a gauche.
Normalement, moteur audio eteint, il descend presque a zero, meme avec un gros workspace.
Si tu augmentes le block size, ou le buffer, tu vas augmenter la latence, de 3ms par pas de 128 en 44,1kHz. Pas forcement un
probleme si tu ne fais pas de temps reels (avec des musiciens par exemple).
Ensuite, quelques pistes, recherches le patch qui consomme le plus, en les allumant un par un. Vois s'il est bien cable, car parfois ca fait ce qu'on veut, mais y'a un noeud en plein milieu (pas facile a trouver....).
Le CPU qu'affiche Usine n'est pas le CPU globale, mais le CPU du thread le plus consommateur, donc 80% ne veut pas dire qu'Usine consomme 80% du CPU de l'ordi (pour s'en rendre compte, il suffit d'ouvrir Activity Monitor du Mac).
Essaies de dispatcher des gros patchs sur plusieurs rack, ainsi tu vas travailler sur plusieurs thread et donc sur plusieurs core de ton processeur.
C'est bien explique dans la doc, mais toujours un peu esoterique.
Enfin, si tu travailles sur de la video, le CPU affiche correspond au CPU audio, pour la video, tres gourmand, c'est autre chose. J'ai fait des patchs qui a priori affichait 20% et le ventilo de l'ordi était a donf, dans Activity Monitor, j'etais a 400%.
Senso pourra confirmer ou corriger tout ceci. J'espere que ca t'aidera.
Bonne continuation
Sylvain
P.S.: peut-etre, essaies de poser tes question sur le forum anglais, meme si comme moi tu n'es pas tres a l'aise avec l'anglais. Je pense que pleins de tes questions interesserons les nouveaux utilisateurs de HH3.
C'est etrange ta consommation de CPU. Tu parles bien du CPU affiche dans Usine, en haut a gauche.
Normalement, moteur audio eteint, il descend presque a zero, meme avec un gros workspace.
Si tu augmentes le block size, ou le buffer, tu vas augmenter la latence, de 3ms par pas de 128 en 44,1kHz. Pas forcement un
probleme si tu ne fais pas de temps reels (avec des musiciens par exemple).
Ensuite, quelques pistes, recherches le patch qui consomme le plus, en les allumant un par un. Vois s'il est bien cable, car parfois ca fait ce qu'on veut, mais y'a un noeud en plein milieu (pas facile a trouver....).
Le CPU qu'affiche Usine n'est pas le CPU globale, mais le CPU du thread le plus consommateur, donc 80% ne veut pas dire qu'Usine consomme 80% du CPU de l'ordi (pour s'en rendre compte, il suffit d'ouvrir Activity Monitor du Mac).
Essaies de dispatcher des gros patchs sur plusieurs rack, ainsi tu vas travailler sur plusieurs thread et donc sur plusieurs core de ton processeur.
C'est bien explique dans la doc, mais toujours un peu esoterique.
Enfin, si tu travailles sur de la video, le CPU affiche correspond au CPU audio, pour la video, tres gourmand, c'est autre chose. J'ai fait des patchs qui a priori affichait 20% et le ventilo de l'ordi était a donf, dans Activity Monitor, j'etais a 400%.
Senso pourra confirmer ou corriger tout ceci. J'espere que ca t'aidera.
Bonne continuation
Sylvain
P.S.: peut-etre, essaies de poser tes question sur le forum anglais, meme si comme moi tu n'es pas tres a l'aise avec l'anglais. Je pense que pleins de tes questions interesserons les nouveaux utilisateurs de HH3.
Merci Sylvain pour cette réponse détaillée. Mon patch est vraiment très gros. Je ne suis pas surpris qu'il consomme tant et ne peux malheureusement le dispatcher sur plusieurs racks. J'arrive un peu à fonctionner en augmentant les buffers donc pas de soucis. En revanche la consommation moteur éteint m'inquiète un peu plus.
Bonne soirée.
JF
Bonne soirée.
JF
`http://www.sensomusic.org/forums/upload ... evices.zip
Le voici. Il te faut aussi installer mes devices pour que ça fonctionne
Le voici. Il te faut aussi installer mes devices pour que ça fonctionne
C'est un workspace complet.
Il faut passer en IB
Il faut passer en IB
Salut Joffo,
Et bien ca bosse!!! Y'a du patch, haha. Beau boulot. Avec il me semble de belle idees (j'aime beaucoup le 16rec)
Bon, j'ai pas tout essaye de comprendre, c'est pas le but. Et il me manque quelques VST(i) pour que ton workspace fonctionne entierement chez moi.
Tous les patchs ON, en 128 de block size Usine et 128 de buffer asio, le CPU d'Usine monte a 40% chez moi, pas dramatique. Cependant on est a 125% du processeur de l'ordi.
Alors quelques idees :
- deja , fais le menage, il me semble en regardant ici et la avoir vu pas mal de trucs qui ne te servent pas. 0,5% + 0,5% + 0,5% ..... je ne te fais pas un dessin.
- ensuite, ton workspace est tres lourd. Beaucoup (enormement) de bus internes (plus de 300 ...
). Sont-ils tous necessaires? Beaucoup d'audio buses, qui prennent beaucoup de puissance. Y'a aussi beaucoup beaucoup de cablage.
Tout ca prend des ressources non negligeables, voir a partir d'un moment tres importantes.
J'ai aussi une facheuse tendance a charger la mule. Mes workspaces sont toujours au bord du cataclisme. Ce que mon experience avec Usine m'a appris est la suivante : ce logiciel est indeniablement a mettre au sommet, pour sa liberte et pour ces qualites, sonores entre autres. Mille fois plus rapide et intuitif que MaxMSP et un rendu sonore mille fois plus convaincant qu'Ableton ou NI. Le revers de la medaille, c'est la consommation CPU. On a rien sans rien. Alors il faut faire des compromis, ne rien lacher du cote du son, mais si tel truc ne sert quasiment jamais, ou si tel autre n'est pas fondamentalement indispensable, il faut s'en separer.
Ton patch BeatStepMegaControl consomme directement 21% et il genere 256 buses. Whaou...... Tu te sers vraiment de ces 256 buses?
Je pense que le noeud de ton workspace viens un peu de la .
Ensuite, ton arborescence audio est originale. Beaucoup de bus audio (donc latence), et tout va dans un seul rack. Bon, je sais que Senso propose cette methode, mais je n'ai pas toujours compris pourquoi, ca me semble plus complexe et moins CPU friendly que de sortir chaque rack sur le stereo output (device dans laquelle tu pourrais mettre tout le traitement que tu fais sur le rack 14). Bon, a voir.
Apres, ton workspace est tres complexe, et pour aller plus loin dans les recherches de surcharge CPU, il faudrait le voir en situation et avoir des explications.
Evidemment, je ne sais pas ce que tu fais avec tout ca, mais simplifie.
Oh, un dernier truc, la reverb a convolution est plutot tres gourmande aussi.
J'espere que ca t'aidera.
Sylvain
Et bien ca bosse!!! Y'a du patch, haha. Beau boulot. Avec il me semble de belle idees (j'aime beaucoup le 16rec)
Bon, j'ai pas tout essaye de comprendre, c'est pas le but. Et il me manque quelques VST(i) pour que ton workspace fonctionne entierement chez moi.
Tous les patchs ON, en 128 de block size Usine et 128 de buffer asio, le CPU d'Usine monte a 40% chez moi, pas dramatique. Cependant on est a 125% du processeur de l'ordi.
Alors quelques idees :
- deja , fais le menage, il me semble en regardant ici et la avoir vu pas mal de trucs qui ne te servent pas. 0,5% + 0,5% + 0,5% ..... je ne te fais pas un dessin.
- ensuite, ton workspace est tres lourd. Beaucoup (enormement) de bus internes (plus de 300 ...
). Sont-ils tous necessaires? Beaucoup d'audio buses, qui prennent beaucoup de puissance. Y'a aussi beaucoup beaucoup de cablage. Tout ca prend des ressources non negligeables, voir a partir d'un moment tres importantes.
J'ai aussi une facheuse tendance a charger la mule. Mes workspaces sont toujours au bord du cataclisme. Ce que mon experience avec Usine m'a appris est la suivante : ce logiciel est indeniablement a mettre au sommet, pour sa liberte et pour ces qualites, sonores entre autres. Mille fois plus rapide et intuitif que MaxMSP et un rendu sonore mille fois plus convaincant qu'Ableton ou NI. Le revers de la medaille, c'est la consommation CPU. On a rien sans rien. Alors il faut faire des compromis, ne rien lacher du cote du son, mais si tel truc ne sert quasiment jamais, ou si tel autre n'est pas fondamentalement indispensable, il faut s'en separer.
Ton patch BeatStepMegaControl consomme directement 21% et il genere 256 buses. Whaou...... Tu te sers vraiment de ces 256 buses?
Je pense que le noeud de ton workspace viens un peu de la .
Ensuite, ton arborescence audio est originale. Beaucoup de bus audio (donc latence), et tout va dans un seul rack. Bon, je sais que Senso propose cette methode, mais je n'ai pas toujours compris pourquoi, ca me semble plus complexe et moins CPU friendly que de sortir chaque rack sur le stereo output (device dans laquelle tu pourrais mettre tout le traitement que tu fais sur le rack 14). Bon, a voir.
Apres, ton workspace est tres complexe, et pour aller plus loin dans les recherches de surcharge CPU, il faudrait le voir en situation et avoir des explications.
Evidemment, je ne sais pas ce que tu fais avec tout ca, mais simplifie.
Oh, un dernier truc, la reverb a convolution est plutot tres gourmande aussi.
J'espere que ca t'aidera.
Sylvain
dans le patch qui s appelle "16 rec2017version" mets ceci pour l eteindre completement, tu gagneras autour de 15% de cpu
Merci Nay je vais essayer. Encore faut il que je trouve le moyen de "clearer" les sampler du patch avant de les désactiver (genre wait one bloc ou data delay).
Sylvain merci infiniment pour tes conseils. C'est trïès réconfortant d'avoir du retour sur son travail. En effet c'est un très gros boulot et je serais très heureux de le partager avec d'autres personnes. Concernant le BeatStepMegaControl il s'agit d'un essai récent peut concluant qui est d'ailleurs déactivé Je l'ai supprimïé depuis même si je garde toujours cette idïée au fond de mon cerveau (j'ai soumis la problïématique à senso, l'idïée étant de réflechir à la possibilitïé de piloter plusieurs paramètres avec le même encodeur d'un contrôleur sans avoir de problème de conflit ou de saute de valeurs).
Pour l'histoire des buses audio, j'ai conscience que ce n'est pas idéal. Mais j'avoue ne pas avoir troué d'autre solutions compte tenu que la matrice est le centre nïévralgique du workspace, qu'elle est pilotée avec un launchpad et que tous les signaux transits par là
En gros le concept du truc:
Tu disposes de 4 racks où tu peux mettre des entrées audios ou des vsti. Ces 4 entrées peuvent être routïés dans des effets ou dans 4 loopers qui sont synchrionisïées selon une méthode assez sophistiquée (Pas de quantisation à respecter en entrrée afin de conserver une approche intuitive).
Ces 4 loopers sont également accessibles dans la matrices pour être routées vers les effets ou vers eux mêmes (enfin les uns dans les autres). Tout cela permet une flexibilité rarement atteinte avec d'autres système de loopers (je ne suis pas personnellement un gros fan de cet outil à cause des restrictions qu'il impose en temps normal). A cela s'ajoutent des fonctions avancées de slice stretch pitch et autre.
Donc ce n'est pas étonnant que cela demande pas mal de ressources. Le problème est que comme il s'agit d'un environnement global, il est compliqué de gèrer les ressources en faisant de l'optimisation. Après, je me doute qu'il doit se balader dans mes patchs une somme conséquente de résidus de trucs qui ne servent plus à rien. Je pense aussi qu'il existe un bon nombre d'action rébarbatives qui pourraient être remplacés par des scripts ou carrément des modules. Mais cela dépasse largement le champ de mes compétences.
Sylvain merci infiniment pour tes conseils. C'est trïès réconfortant d'avoir du retour sur son travail. En effet c'est un très gros boulot et je serais très heureux de le partager avec d'autres personnes. Concernant le BeatStepMegaControl il s'agit d'un essai récent peut concluant qui est d'ailleurs déactivé Je l'ai supprimïé depuis même si je garde toujours cette idïée au fond de mon cerveau (j'ai soumis la problïématique à senso, l'idïée étant de réflechir à la possibilitïé de piloter plusieurs paramètres avec le même encodeur d'un contrôleur sans avoir de problème de conflit ou de saute de valeurs).
Pour l'histoire des buses audio, j'ai conscience que ce n'est pas idéal. Mais j'avoue ne pas avoir troué d'autre solutions compte tenu que la matrice est le centre nïévralgique du workspace, qu'elle est pilotée avec un launchpad et que tous les signaux transits par là
En gros le concept du truc:
Tu disposes de 4 racks où tu peux mettre des entrées audios ou des vsti. Ces 4 entrées peuvent être routïés dans des effets ou dans 4 loopers qui sont synchrionisïées selon une méthode assez sophistiquée (Pas de quantisation à respecter en entrrée afin de conserver une approche intuitive).
Ces 4 loopers sont également accessibles dans la matrices pour être routées vers les effets ou vers eux mêmes (enfin les uns dans les autres). Tout cela permet une flexibilité rarement atteinte avec d'autres système de loopers (je ne suis pas personnellement un gros fan de cet outil à cause des restrictions qu'il impose en temps normal). A cela s'ajoutent des fonctions avancées de slice stretch pitch et autre.
Donc ce n'est pas étonnant que cela demande pas mal de ressources. Le problème est que comme il s'agit d'un environnement global, il est compliqué de gèrer les ressources en faisant de l'optimisation. Après, je me doute qu'il doit se balader dans mes patchs une somme conséquente de résidus de trucs qui ne servent plus à rien. Je pense aussi qu'il existe un bon nombre d'action rébarbatives qui pourraient être remplacés par des scripts ou carrément des modules. Mais cela dépasse largement le champ de mes compétences.
pour info, les devices sont toujours calculées même moteur éteint, d'où les 20%
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Ah yes ! Je comprends mieux. C'est logique bien sûr !
En revanche j'observe un comportement bizarre quand j'interviens dans mes patchs. Il arrive souvent que je n'ai plus accès aux fonctions de mon clavier (suppr, ctrl+c ctrl+v ....).
Généralement je suis obligé de redémarrer pour que tout rentre dans l'ordre, parfois ça revient tout seul...
Généralement je suis obligé de redémarrer pour que tout rentre dans l'ordre, parfois ça revient tout seul...
Nay. Si je mets un patch of dans mon 16 rec le signal ne passe plus quand il n'est pas activé.
Joffo,
Logique les devices, mais pas que et c'est pas ca qui fait 20%
Ton rack 13 est "always calculated", voulu, pas voulu.
Donc moteur eteint il est calcule, d'ou les 20% de CPU, plus que les devices.
Ensuite, l'idee de Nay avec le patch On/Off est bonne, si tu eteins le moteur tu mets ton patch off.
S'il n'y a plus de son, c'est parce que tout va dans ton rack 14 qui n'est pas "always calculated".
Si joint un reecriture de ton patch, qui consomme pas mal de CPU en moins.
Peut-etre que 16 samplers c'est beaucoup et qu'avec une grille de 9 tu aurais un resultat similaire et un patch more CPU friendly.
http://www.sensomusic.com/forums/upload ... ylvain.pat
A+
Logique les devices, mais pas que et c'est pas ca qui fait 20%
Ton rack 13 est "always calculated", voulu, pas voulu.
Donc moteur eteint il est calcule, d'ou les 20% de CPU, plus que les devices.
Ensuite, l'idee de Nay avec le patch On/Off est bonne, si tu eteins le moteur tu mets ton patch off.
S'il n'y a plus de son, c'est parce que tout va dans ton rack 14 qui n'est pas "always calculated".
Si joint un reecriture de ton patch, qui consomme pas mal de CPU en moins.
Peut-etre que 16 samplers c'est beaucoup et qu'avec une grille de 9 tu aurais un resultat similaire et un patch more CPU friendly.
http://www.sensomusic.com/forums/upload ... ylvain.pat
A+
Pour le rack 13 non ce n'est pas voulu. Je vais regarder ça. Merci pour le correctif. Je pense en effet que 8 ou 9 sampler suffiraient. Ou pourquoi pas les remplacer par des délays
Who is online
Users browsing this forum: No registered users and 7 guests