Old 04-16-2019, 09:58 AM   #1
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default Optimisation CPU.

Bonjour à tous,

Il semblerait que j'ai un problème de CPU sur une session sur un passage un peu chargé.

Le moteur de lecture saccade et hache le son.
Il semblerait que ce ne soit pas un problème de buffer étant donnée que le voyant "buffer" rouge ne clignotte pas dans la fenêtre du compteur.

Quand j'ouvre ma fenêtre de performance.
J'ai effectivement des piques à 80% mais la chose étrange c'est que la sommes des pourcentage par piste m'indique 30% maximum...
Savez vous où se place le restant de la ressource et qui ferait saturé Reaper?

https://drive.google.com/open?id=1MK...4eVoZpSRyn8nF_

Mes préférences sont réglé comme ceci:

https://drive.google.com/open?id=1VR...24sQ4pPgeUBY2U

https://drive.google.com/open?id=1p4...JcbFlvrqua49_f

8000 de block size c'est déjà beaucoup.
Il y a une grande latence entre le moment ou je presse play e le moment où sa joue.

4000 de buffer size me semble aussi déjà pas mal non?

Quelles sont vos conseil pour optimiser votre CPU?

Un grand merci.
Jules.W is offline   Reply With Quote
Old 04-16-2019, 12:31 PM   #2
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

1) Essais d'utiliser un buffer qui se trouve dans un multiple de 512 et dans les limites acceptée par ta fireface. je pense que de toutes façons, les drivers RME ne permettent pas de dépasser 1024 ou 2048 (a vérifier entre les deux valeurs)

D'ailleurs, je te conseille de décocher la case "request block size". La RME fait très bien ca toute seule et c'est plus judicieux de gérer la latence via le fireface settings et de choisir parmis les buffer proposés

Pour la fréquence d'échantillonage, tu peux également décocher la case "request sample rate", comme tu as coché "allow to overide device sample rate", c'est la fréquence d'échantillonage choisie dans les préférences du projet (project settings" qui va être utilisé et encore une fois, les Interfaces RME répondent sans le moindre problème (RME réalisent la majorité de leurs tests sous REAPER, on peut donc s'attendre à une compatibilité optimale)



Par contre Je vois que tu utilises beaucoup de plug-ins qui induisent de la latence (PDC) et le chiffre de 12800 me laisse penser que tu aligne pas mal de plug qui ont besoin de gros temps de calcul

je vais te montrer une expérience en live qui va t'interpeller

https://drive.google.com/open?id=1WQ...kLJ689TS7_exwY


En gros, je place 3 instances de soothe sur une piste (j'ai pris soothe parce que je sais qu'il induit bcp de latence, qu'il oversample et qu'il consomme pas mal)

Je fais play et le CPU real TIme (j'y reviens) grimpe en flèche directement et ca craque de partout

Ensuite, je créer une piste et je glisse ma piste originale dans l'autre piste. J'en profite pour foutre mon 3eme soothe sur la nouvelle piste et je n'en laisse que 2 sur la piste test

D'un point de vue chaine de son, ca ne change STRICTEMENT RIEN ce qui sort du eme plus de la piste test va dans le plug de la piste folder. Si je faisait un bounce audio des deux versions, on aurait Exactement la même chose

et la, si je lance la lecture, mon RT cpu reste tranquillement en bas, sans forcer ni même broncher

Regarde le nombre de core et la puissance que j'ai à dispo sur la machine test

https://drive.google.com/open?id=1x1...404R_1MZOl80yR

COmment se fait-il que j'arrive à mettre a mal une telle machine avec 3 pauvres plug?

C'est à cause du fonctionnement même de l'audio temps réel. Ca na rien a voir avec REAPER ou le DAW utilisé, c'est juste un procédé informatique

En gros, dans ce crash test, j'attaque volontairement le cpu là où je sais qu'il a la mal

Pour faire simple, ce qui se passe sur une piste ne peut être géré que par un seul coeur.

Ok, mais même un seul core i7 à 3.7Ghz, il devrait faire les calculs de trois pauvres plug comme pour rire...

Oui mais non, parce qu'on lui demande de les faire trop vite. il ne galère pas à faire les calculs (le FX cpu ne bronche pas) c'est juste qu'il n'arrive pas à suivre le temps réel et la latence induite par la succession des plug n'arrange rien.

Prenons maintenant un plug lourd en cpu mais qui n'induit pas de latence

https://drive.google.com/open?id=1md...eQlrrpdntmf41u

Je peux en foutre 32 en cascade avant que le cpu ne rende le tablier

Et note l'effet de seuil! c'est quasi de 0 à 100 à une instance près!


En voyant ca, on piurrait se dire, donc, le PC de reno ne peux supporte que 32 instances du compresseur MJCU

et bah non

Je refait une piste folder et je peux en rempiler par dessus

Bref, t'as compris le principe

Pour régler ton problème, tu as 3 solutions

1) préférer les plug qui induisent le moins de latence possible

2) répartir la charge cpu sur des piste en cascade afin d'éviter des cumul de latence sur une même piste

3) freezer les FX qui n'ont plus besoin d'être touché

Pour le freeze, dans RPR, tu peux freezer partiellement une chaine d'effet
regarde, je freeze juste le résultat du VMR et du 1176 en gardant l'eq à portée de main et je défreeze très rapidement quand je le souhaite:

https://drive.google.com/open?id=1P3...F7QUP60H3eIarg


Le freezing peut également être cumulable
https://drive.google.com/open?id=1w8...wLwE3yORgGl-86

Je fais donc plusieurs étape de freezing et quand je défreeze, je le fait également par étape

C'est une feature puissante, souvent ignorée qui m'a permis de faire tenir des gros mix sur des ptites machines
Reno.thestraws is online now   Reply With Quote
Old 04-17-2019, 04:42 AM   #3
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Whoua! Merci pour cette longue réponse!

Quote:
"request block size". La RME fait très bien ca toute seule et c'est plus judicieux de gérer la latence via le fireface settings et de choisir parmis les buffer proposés
Pourrais-tu m'expliquer à quoi correspond cette case? Que veut dire Request block size"?

Quote:
Je vois que tu utilises beaucoup de plug-ins qui induisent de la latence (PDC)
Comment vois tu celà? Que veut dire PDC?

C'est mes aux qui en on la plus grande valeur (est une latence exprimé en ms?) --> 12288 ms exactement? Ce qui ferait 12 secondes de latence? C'est énorme!
Ce serait en sample alors? Mais 12 000 sample ne ferait qu'un quart de seconde et se serait bien peu pour le coup..

Quelle serait une valeur correcte?

Il y a que des Fabfilter. La suite Q3 (EQ) puis C2 (Comp) Puis LM (Comp bande) puis Limiteur dans cette ordre.
4 plugin donc ce qui n'est pas non plus la folie...

Quote:
Pour faire simple, ce qui se passe sur une piste ne peut être géré que par un seul coeur.
Ok!
Effectivement!
Du coup peut être que je devrais faire ca sur tout mes aux.
Les dupliquer et mettre deux plug par tranche.
Les Fabfilter induise de la latence car il corrige la phase des filtre en temps réel. J'imagine que c'est ca qui les rend gourmand.

Quote:
Pour régler ton problème, tu as 3 solutions

1) préférer les plug qui induisent le moins de latence possible

2) répartir la charge cpu sur des piste en cascade afin d'éviter des cumul de latence sur une même piste

3) freezer les FX qui n'ont plus besoin d'être touché
Donc on est d'accord que la technique de la cascade c'est surtout en lien avec la latente PDC, right?

Quote:
Pour le freeze, dans RPR, tu peux freezer partiellement une chaine d'effet
Est ce que ca marche aussi pour les FX dan les Items?
Car en gros, je travaille chaque item avec des FX items pour trouver leurs couleurs et leurs dynamiques. Et ensuite je travaille avec mon bus par instrument pour que cette couleur et cette dynamique trouve sa place dans le mix général.


Du coup j'ai deux type de PLugin. Ceux dans les items et ceux sur mes track aux.
Mes plugin d'aux (les fabfilter), je les utilise et les retouche constamment en mode full automation. Difficile donc pour moi de les freezer...

En revanche, les Fx items ce serait plus jouable dès lors que la couleur choisis me plait, je vérouille.
On est d'accord pour dire que les FX sur les items ne sont actif que quand l'item est joué, right?

Last edited by Jules.W; 04-17-2019 at 05:15 AM.
Jules.W is offline   Reply With Quote
Old 04-17-2019, 06:00 AM   #4
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

Quote:
Pourrais-tu m'expliquer à quoi correspond cette case? Que veut dire Request block size"?
C'est une case inutile en ce qui te concerne, elle sert à fixer le buffer du system audio. La plupart des interface audio pro, ont leur propre page de settings pour le gérer. REAPER propose cela dit une solution interne pour les syteme audio ne permettant pas de changer le buffer ou pour les vieilles interfaces qui ne gèrent pas bien ca. Dasn ton cas, décoche et choisis la taille de ton buffer dans le fireface settings

Quote:
Comment vois tu celà? Que veut dire PDC?
Je le vois par les chiffre que affiché dans ta conso cpu

PDC veut dire Plug-in delay compensation : Pour faire simple et bref, certains plug ont besoin d'un temps de calcul et/ou d'une fenetre d'analyse du signal plus ou moins large pour executer leur algo.

cette latence est exprimée en sample. Un plug-in qui à une PDC de 2048 à dcon besoin d'une durée de 2048 samples pour faire son job. Alors évidement, le plug informe le DAW de cette valeur et le DAW retarde les autres pistes ou avance le signal de la piste concernée afin que tu n'entendent pas le signal de la dite piste en retard

Si tu met la piste en monitoring direct avec ce plug chargé, tu entendra cette latence (en temps réel, le DAW ne peut pas compenser)

Alors, quand tu enchaine sur la même pistes 3 ou 4 plug qui induisent une forte latence, et bien ,la latence se cumule

Je reprend du exemple
Q3 -> C2 -> MB -> Limiteur

SI Q3 induit une latence de 2048 samples parce que le met en lineaire, ton signal est retardé de 2048 sample

Le c2 lui, il doit attendre le résultat du calcul du Q3, puis induit une latence de 2048 (chiffre hypothétique)

ton signal a donc déjà 4096 samples de retard

Pro MB: lui il doit aussi attendre le résultat du calcul de C2 et induit encore une latence de 4096

Ton signal cumul alors 8192 sample de retard

Le limiteur, pareil, il doit attendre et puis induire encore 4096 samples

Le traitement de ta chaine prend donc au total 12288 samples pour être calculé

en 48Khz (soit 48000 samples par secondes) ca fait 260 millisecondes de retard de signal à compenser... et ca demande beaucoup de travail au processeur. Surtout que, comme dit précédemment, comme cette tache est cumulative et rapide, elle ne peut être effectuée que par un seul core

Alors, certes, même un seul core de 3Ghz peut effectuer 3 milliard d'opération à la seconde, mais là, on lui demande de faire plus vite et donc arrive à un moment où il rend le tablier

C'est d'ailleurs pour ca, que, contrairement à ce que beaucoup de vendeur informatique conseillent, pour le travail audio, il vaut mieux un processeur avec moins de coeurs mais de très haute cadence que d'avoir plein de core disponible (à nuancer cela dit selon le DAW et le type de projet)

Alors en plus, toi, ces grosses latences sont posés sur des pistes auxiliaires qui... doivent attendre le résultat des calculs des pistes d'envois pour effectuer leur traitements

Bah oui, si tu envois une piste de caisse claire dans une reverb en AUX, la reverb, elle doit attendre de savoir ce qui vient de la piste snare

et si, sur la piste snare, tu as des plug qui induisent de la latence (disons 2048) en bien entre la lecture du sample sur la piste snare et le résultat en sortie d'aux tu as un procédé qui dure 2048 + 12288 samples, soit 14336 samples (soit près de 300 ms en 48Khz)

Ca fait beaucoup

Si tu met donc tous les plug en mode low latency, tu va directement constaté un grande amélioration (sans pour autant changer fondamentalement la qualité de son)

Quote:
Les Fabfilter induise de la latence car il corrige la phase des filtre en temps réel. J'imagine que c'est ca qui les rend gourmand.
C'est ca. Sauf qu'il n corrige pas la phase. ils n'induisent tout simplement pas de rotation de phase. Ce qui n'est pas forcément une bonne ou une mauvaise chose (il y'a d'autres problèmes qui résultent de ce genre de traitement), c'est juste différent. Personnellement, en dehors du buss master, j'utilise rarement la phase linéaire, mais je ne connait pas ton type d'activité, donc je ne peux connaitre la pertinence du choix.

je peux cependant te conseiller de visionner cette très interessante vidéo de fabfilter sur le sujet -> https://youtu.be/efKabAQQsPQ

Je pense qu'ils ont publié ca, justement parce que tous leur clients ont cru que c'était d'office une bonne chose de foutre tout en maximum processing

Quote:
Donc on est d'accord que la technique de la cascade c'est surtout en lien avec la latente PDC, right?
Vi

Quote:
Est ce que ca marche aussi pour les FX dan les Items?
Car en gros, je travaille chaque item avec des FX items pour trouver leurs couleurs et leurs dynamiques. Et ensuite je travaille avec mon bus par instrument pour que cette couleur et cette dynamique trouve sa place dans le mix général.
Non, point de freeze pour les items FX, par contre, tu peux utiliser l'action (render item as a new take) qui applique alors l'effet à l'item en créant une nouvelle take... tu peux alors switcher entre take 1 et take 2 à ta guise via un simple click (si l'option "show take in lane est activé, sinon, tu peux switcher via le raccourcis "t", si tu ne l'a pas modifié)

https://drive.google.com/open?id=10_...Fcmd4vQ9i37100


Quote:
On est d'accord pour dire que les FX sur les items ne sont actif que quand l'item est joué, right?
Oui, mais je vais préciser

En fait, c'est un tout petit plus long


Le temps exact est :

Temps de l'anticipative processing (process propre à REAPER qui permet une plus grande souplesse CPU, modifiable dans les préférences, buffering avec une valeur par défaut de 200 ms (mêm si déconseille de modifier cette valeur)

+

temps de l'éventuel look ahead du plug in

+ durée de l'item

+ durée de la tail choisie dans les préférences -> media -> take fx tail lengh : def 2000 ms

La tail est le temps du maintien du traitement du plug après la fin de l'item afin d'éviter, par exemple, une coupure nette d'une queue de reverb lorsque la lecture arrive au bout de l'item


Par contre, en observant tes gif, je constate que tu utilise des pistes folder mais que tu coupe l'envoi au parent sur les piste filles?

Tu achemine le signal des pistes fille vers ou?

Quand je regarde ce gif -> https://drive.google.com/file/d/1MKd...pSRyn8nF_/view

J'ai l'impression que tu as placé les piste 35 à 50 dans une piste folder (34) mais que leur signal est envoyé non pas vers cette piste 34 mais vers un autre buss de sommation???

En gros, tu essaies de reproduire le système PT

mais tu te complique la vie

La piste 34, c'est un buss de sommation! quand une piste est folder, elle agit comme MASTER pour toute ses filles!

Donc t'as pas besoin de créer une piste aux en plus...

J'ai fait un tuto vidéo sur le sujet afin de demystifier cet aspect



https://youtu.be/wHm5BHyj2oQ
Reno.thestraws is online now   Reply With Quote
Old 04-17-2019, 06:01 AM   #5
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Ok.

Je viens de corrigé mes paramètres comme indiqué dans la fenêtre Preference Settings.

Et je viens de créer des pistes group pour repartir mes chaines Fabfilter sur deux pistes séparés comme tu l'a proposé.

Mais je n'ai pas l'impression que le CPU soit réduit pour autant.
En tout cas, ca crack de la même manière... :/

Ici un gif pour te montrer les nouvelles valeurs ainsi que ma nouvelle répartition de plugin.

https://drive.google.com/open?id=1wr...FRJa5C6ziy5UQA

Il y a peu de plug en insert sur les pistes.
Seulement mes chains Fabfilter sur mes aux mais il y a beaucoup plus de truc sur mes Items. (Simulation de préamp, EQ, Simu de Compressor analog, ect...)
Comment peut on visualisé la ressource des Fx Items?
Jules.W is offline   Reply With Quote
Old 04-17-2019, 07:08 AM   #6
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

J'ai déjà un peu de mal à comprendre le routing? pourquoi t'a deux pistes folders drums l'un dans l'autre et les pistes filles qui n'ont pas leur master/parent engagés?

j'ai l'impression que tu créer des bouclages de routing inutile qui font en sorte que la charge cpu se cumule inutilement
Reno.thestraws is online now   Reply With Quote
Old 04-17-2019, 07:35 AM   #7
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Quote:
Je reprend du exemple
Q3 -> C2 -> MB -> Limiteur

SI Q3 induit une latence de 2048 samples parce que le met en lineaire, ton signal est retardé de 2048 sample

Le c2 lui, il doit attendre le résultat du calcul du Q3, puis induit une latence de 2048 (chiffre hypothétique)

ton signal a donc déjà 4096 samples de retard

Pro MB: lui il doit aussi attendre le résultat du calcul de C2 et induit encore une latence de 4096

Ton signal cumul alors 8192 sample de retard

Le limiteur, pareil, il doit attendre et puis induire encore 4096 samples

Le traitement de ta chaine prend donc au total 12288 samples pour être calculé
Oui mais si on suit le raisonnement, ca devrait être la même chose si tu les mets en cascade sur deux pistes différentes. La latence sera la même théoriquement puisque le signal devra traverser et être processer par les plugin? 300 ms, ca ne me semble pas insurmontable?
Dans Protools, j'ai bien souvent cette même chaine sur des aux sans que ca pose la moindre latence. Mais mon setting Delay Compensation est toujours réglé en conséquence dans mes sessions PT.

Quote:
Si tu met donc tous les plug en mode low latency, tu vas directement constaté un grande amélioration (sans pour autant changer fondamentalement la qualité de son)
Comment tu peux paramétrer tes plugs en mode Low Latency?
Pour les fabfilter, j'ai déjà décoché l'oversampling et je bascule mes plug en Dynamique phase.

Quote:
Je pense qu'ils ont publié ca, justement parce que tous leur clients ont cru que c'était d'office une bonne chose de foutre tout en maximum processing
Oui elle est très intéressante cette vidéo.

Quote:
Non, point de freeze pour les items FX, par contre, tu peux utiliser l'action (render item as a new take) qui applique alors l'effet à l'item en créant une nouvelle take...
Ok super!
Ca c'est top!
J'ai l'impression que c'est ca qui saturait mon CPU.
Après avoir freezé la majorité des items sur cette partie de morceau mon CPU est bien descendu.
Voici un nouveau gif maintenant -->

https://drive.google.com/open?id=1Hx...J43cLhPWMTxz3A

Au départ, j'avais essayé "Apply track/take Fx to item as new take" mais je ne retrouvais pas exactement le même son.
Render items as news take semble être exactement ca.
En gardant la take originale avec les plug inclut, il est facile de revenir en arrière ou de modifier un paramètre.

Quote:
Par contre, en observant tes gif, je constate que tu utilise des pistes folder mais que tu coupe l'envoi au parent sur les piste filles?
haha.
Exacte sans suprise, j'utilise ce que tu appelles dans ta vidéo tuto (très réussis d'ailleurs ) la technique ---> Protools!

Et oui, c'est ce qui me parait le plus adapté à ce que je veux faire.
Notamment apporter des traitements de compression et d'EQ sur mes bus d'instrument.

Donc oui mon routing est le suivant:
J'ai des plusieurs pistes pas instrument. Chaque pistes de chaque instrument est routé vers une piste bus (folder) qui est effectivement routé vers une piste MIX (Master) qui elle seule est routé vers le parent master chanel.

Voici un gif qui te montrera ca en image -->

https://drive.google.com/open?id=1Hx...J43cLhPWMTxz3A

Donc là, tu verras, j'ai deux pistes folder pour répartir ma chaine fabfilter comme tu l'avais proposé.
C'est bien comme ca que tu pensais?

Last edited by Jules.W; 04-17-2019 at 08:01 AM.
Jules.W is offline   Reply With Quote
Old 04-17-2019, 08:29 AM   #8
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

Quote:
Originally Posted by Jules.W View Post
J'ai des plusieurs pistes pas instrument. Chaque pistes de chaque instrument est routé vers une piste bus (folder) qui est effectivement routé vers une piste MIX (Master) qui elle seule est routé vers le parent master chanel.
Mais c'est inutile... tu créer des routing inutiles

Quote:
Notamment apporter des traitements de compression et d'EQ sur mes bus d'instrument.
Justement, utilise les folder de façon classique, c'est bcp plus simple!

Si une groupe de piste est glissé dans une autre piste (folder), et bien la piste folder est un buss de sommation! tu peux y foutre un compresseur, une eq... ca agira EXACTEMENT comme un buss groupe ou aux sauf que, tu ne solicite pas de send/receive...

C'est fou! Tout ceux que je croise qui viennent de PT font exactement la même chose!

OUBLIE les habitudes de routing de PT et applique tes connaissances avec les outils de RPR, tu verras que tu y gagneras parce que cumuler les pistes, en plus de faire perdre du temps dans la navigation, fait consommer du CPU


Quote:
Au départ, j'avais essayé "Apply track/take Fx to item as new take" mais je ne retrouvais pas exactement le même son.
Parce que, tu applique l'fx de litem et de la piste à l'item sans pour autant virer le plug -in de la piste... donc tu appliques l'fx à la piste tout en gardant l'effet de piste actif.

Quote:
Oui mais si on suit le raisonnement, ca devrait être la même chose si tu les mets en cascade sur deux pistes différentes. La latence sera la même théoriquement puisque le signal devra traverser et être processer par les plugin? 300 ms, ca ne me semble pas insurmontable?
Non, sur deux pistes différentes, la charge va être répartie sur DEUX CORE (sauf si évidemment, tu boucle ton routing )

Après, je pense que tu te prend les pieds dans le tapis parce qu'on parle en langage PT et donc en piste. On devrait plutot parler en Bus

D'ailleurs, la question qui turlupine tous les PT users :

A quoi ca sert ca ?

https://drive.google.com/open?id=1kx...csswXz7e_cDEcz


J'ai pris cet exemple parce qu'il reflète bien la différence de routing

En rouge : l'inversion de phase du send (pas de la piste qui recoit, ni de la piste qui envoi, celle du buss!)

En vert : Le commutateur mono du send (pas de la piste qui recoit, ni de la piste qui envoi, celle du buss!)

En bleu, les canaux de départ et de destination audio et MIDI

Le multicanal te permet de faire bcp de chose sur bien moins de prise

Imagine cette situation

Une piste de snare avec EQ gate et comp

Tu veux envoyer ta snare dans une reverb auxiliaire mais tu voudrais prélever le signal entre la gate et le comp, tu fais comment (déjà, si tu viens de PT, tu le fais pas, parce que comme le routing est archaique, ca ne t'es même jamais venu à l'esprit mais passons :-) )


et bien dans RPR, je fais ceci

https://drive.google.com/open?id=1lQ...l_m3w2t22o1hF-

Je préleve les canaux 3-4 de la piste qui envoi et je dérive le signal qui sort de gate vers ces canaux 3-4

et ca ne m'empche pas de créer un deuxième envoi de la snare vers la reverb, cette fois-ci en 1/2-> 1/2 qui permet alors d'avoir une sorte de compression parrallelle au sein meme du send (en 3/4, la snare NON compressée, en 1/2, la snare compressée)

https://drive.google.com/open?id=1UC...b6gEzMm_XpHK2V
Reno.thestraws is online now   Reply With Quote
Old 04-17-2019, 04:29 PM   #9
sardonicus
Human being with feelings
 
sardonicus's Avatar
 
Join Date: Jan 2010
Posts: 6,652
Default

Surtout, ce qui est dingue avec le recul: c'est effectivement un réflexe de protoolsien alors que n'importe quel adepte du routage 100% analo ne ferait pas "l'erreur". Faut rester simple et penser câblage, après ça va mieux. Je dis ça sans ironie, hein, mais faut faire au plus simple. PT a induit un tas de pré-établi inhérent au contournement de ses défauts (normal pour un soft qui a un quart de siècle d'histoire), ça ne veut pas dire que toutes les stan doivent se plier à ce contournement. Oublie PT (sauf quand tu fais tourner PT), pense simple, logique et ouvert. C'était ma remarque constructive en dégustant une quetsche de 25 ans et 54°...
__________________
Ignorance ou indifférence: J'en sais rien et je m'en fous.
sardonicus is offline   Reply With Quote
Old 04-17-2019, 10:59 PM   #10
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

je plussoie.

Et c'est un sujet épineux.

La personne ayant utilisé PT répond souvent : "Tu vas quand même pas m'apprendre le routing?"

-Non, j'essaie de te faire desapprendre des habitudes qui, observées avec un peu de recul, n'ont absolument aucun sens dans un environnement extérieur à PT.

C'est pas de l'arrogance ou du pipi plus loin, c'est juste objectif. D'ailleurs, quand le déclic d'esprit est fait, tout devient parfaitement clair.
Reno.thestraws is online now   Reply With Quote
Old 04-19-2019, 02:46 PM   #11
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Bien sûr que ce n'est pas de l’arrogance ou du pipi plus loin.

C'est précieux que des initiés à Reaper soient aussi présents et pédagogues pour nous aider à comprendre ces nouveaux modes de fonctionnement.


Personnellement, je n'ai jamais approfondis un autre soft que PT depuis ses 15 dernières années et je ne pense pas être le seul dans ce cas.
Nous n'avons donc qu'une seule base de référence malheureusement.
Donc oui, moi je veux bien que tu m'apprennes le routing sous Reaper, je n'ai aucun soucis avec ca, bien au contraire.

Du coup c'est tout à fait normal d'essayer de transposer ce qu'on connait dans un premier temps pour commencer à mettre les mains dans le logiciel, quitte à ce que ce ne soit pas optimiser.

Ma volonté est de dépasser ce stade petit à petit en vous écrivant pour trouver un workflow qui soit vraiment adapté à ce soft.

Encore une fois, un grand merci à vous car j'en apprends tous les jours.

Quote:
Mais c'est inutile... tu créer des routing inutiles
Donc si je comprends bien, les pistes folder peuvent faire office de Bus mais rien n'a besoin d'être routé dans la fenêtre de routing. Toutes les pistes, y compris les folders peuvent être routé directement dans ma piste "MIX" qui, elle, sera coché "Master Parent".
Est-ce bien ca?

Quote:
Parce que, tu appliques l'fx de litem et de la piste à l'item sans pour autant virer le plug -in de la piste... donc tu appliques l'fx à la piste tout en gardant l'effet de piste actif.
ok je comprends mieux.

Quote:
Le multicanal te permet de faire bcp de chose sur bien moins de prise
Effectivement, j'ai un projet de ciné-concert avec une session Reaper en Octophonie.
Du coup j'ai eu l'occasion de croiser cette fenêtre et ces choix de sélections de canaux au seins d'un bus.
Ce n'est pas encore hyper claire, mais je commence à comprendre petit à petit.
Ca a l'air bien puissant.

J'ai utilisé ca aussi pour gérer des SideChain dans mon projet.
Jules.W is offline   Reply With Quote
Old 04-19-2019, 04:04 PM   #12
Reno.thestraws
Human being with feelings
 
Reno.thestraws's Avatar
 
Join Date: Nov 2009
Location: Belgium
Posts: 9,665
Default

oui. les folder sont des de buss de sommations

si tu as par exemple 8 pistes batterie et que tu glisses celles-ci dans une piste folder, le folder devient alors un sous groupe/master pour les 8 pistes de batterie

Pour parler en langage PT, c'est comme si les pistes de batterie avaient leurs sorties automatiquement routee vers le folder.

Imagine ceci

tu as une piste caisse claire avec dessus un compresseur et cette piste caisse claire est glissé dans une piste folder qui contient aussi un compresseur

et bien le chemin de ton signal c'est

item - compresseur 1 - fader volume piste - compresseur 2(du folder) - fader volume piste folder
Reno.thestraws is online now   Reply With Quote
Old 04-21-2019, 08:42 AM   #13
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Ok je comprends mieux.

J'ai donc pour le moment routé toutes les pistes en Master Parent et utilise mes doubles piste folder pour chaque BUS instrument.

En tout cas, combiné avec la technique des rendez FX, mon CPU fait la sieste.
Jules.W is offline   Reply With Quote
Old 04-21-2019, 01:57 PM   #14
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Ha aussi dans la continuité de la conversation.

Il y a quelques fois ou le fait de muter/demuter une piste bus/folder me fait cruncher un peu l'audio.
Ce qui parfois est un peu agaçant quand je veux faire des écoutes comparatives.

J'ai l'impression que c'est du au fait les plugins de cette piste s'active et se désactive en fonction de si la piste est muté ou non.

Y a t'il un moyen de paramétrer ca quelque part?
Jules.W is offline   Reply With Quote
Old 04-21-2019, 03:03 PM   #15
Regisfofo
Human being with feelings
 
Regisfofo's Avatar
 
Join Date: Mar 2017
Location: France
Posts: 175
Default

Je crois que c'est quand reaper change la compensation de latence...
si tu mute la seul piste avec un plug qui a de la latence (ou qui en a beaucoup plus que les autre), la compensation se remet immédiatement à 0 (ou un cran de buffer en dessous) d'où le craquement.

Je n'ai pas trouvé de solution, mais j'ai pas vraiment cherché non plus
Peut être qu'en désactivant le non calcul des pistes mutées ça marcherait...
Regisfofo is offline   Reply With Quote
Old 05-07-2019, 09:35 AM   #16
Jules.W
Human being with feelings
 
Join Date: Nov 2018
Posts: 77
Default

Oui c'est surement dut à un temps de calcul mais je n'ai pas trouvé le moyen de ne pas avoir celà.

Il y a une option pour que le traitement des plugins soient désactive quand une piste est muter mais ca ne change rien quand je coche ou décoche...

Si quelqu'un à une idée?
Jules.W is offline   Reply With Quote
Old 05-18-2019, 12:13 PM   #17
albatteur
Human being with feelings
 
albatteur's Avatar
 
Join Date: Jun 2015
Location: France
Posts: 1,103
Default

Quote:
Originally Posted by Jules.W View Post
Ha aussi dans la continuité de la conversation.

Il y a quelques fois ou le fait de muter/demuter une piste bus/folder me fait cruncher un peu l'audio.
Ce qui parfois est un peu agaçant quand je veux faire des écoutes comparatives.

J'ai l'impression que c'est du au fait les plugins de cette piste s'active et se désactive en fonction de si la piste est muté ou non.

Y a t'il un moyen de paramétrer ca quelque part?
As-tu activé l'aniticipative FX dans les péférences/buffering?
Tu peux jouer aussi avec allow live multiprocessing pour voir si ton proco supporte bien le RT.
Avec un proc I7 4C à 4.8 ghz, je n'arrive pas à mettre ma machine à genoux avec des dizaines de plugs et vsti.
albatteur is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:30 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.