Sound Designers

Labroue a écrit :

C'est bien AVID qui est en cause

Je ne suis pas trop convaincu... Si le développement des plug-ins suivaient les prescriptions exactes d'Avid en matière de programmation, cela éviterait certainement ce genre de problème.

Tu sors un peu ma phrase du contexte, puisque je suis d'accord avec toi sur le fait que les dev tiers de plugs doivent s'adapter aux MAJ des DAW et OS (ce qui doit pas toujours être simple quand on développe pour plusieurs plateformes).
Je dis juste que Pro Tools ne DEVRAIT PAS PLANTER s'il rencontre un plug incompatible, grosse nuance.

Bonjour,

Toutes mes infinies excuses pour avoir involontairement tenté de sortir ta phrase du contexte.

Je dois bien reconnaitre qu'il aurait été préférable d'avoir un message d'erreur affichant l'incompatibilité d'un plug-in, plutôt qu'une sortie inopinée sans explication, du style "Memory fault - core dumped" pour les programmes qui violent un segment de mémoire sous Unix.

Malheureusement, je pense que ce n'est pas possible sous Protools, car le code du plug-ins rtas est excécuté par le processus de l'application et pas par un processus fils indépendant.

Un exemple différent : à l'inverse les plug-in flash d'un navigateur internet créent des processus fils. Si l'un d'eux se terminent inopinément, cela n'arrête pas le processus père de l'application qui les a lancé. On peut alors gérer l'erreur et la sortie d'une manière explicative.

Pour des raisons d'optimisation et de rapidité d'excécution des codes exécutables, ce n'est pas le cas dans Protools : le code exécutable du plug-in sera chargé dans la même zone mémoire que celle réservée au processus du programme. Et donc là, le cours des choses est tributaire de la bonne programmation du plug-ins sans aucune vérification d'intégrité possible. C'est pour cela que les instructions de développement en rtas sont hyper-strictes. En cas de violation, le noyau Unix stoppera le processus, sans afficher d'explication précise. On trouvera les explications en analysant le fichier core issu de la procédure d'arrêt d'urgence (kill systéme) du "Memory fault - core dumped", qui reprend la description de la zone mémoire utilisé par le processus au moment de l'instruction d'arrêt du noyau.

Par contre, il serait intéressant de réaliser des processus fils indépendants pour les plug-ins AS (audio suite) qui eux n'ont pas besoin d'être optimisés à l'extrême. Peut-etre une évolution avenir pour Protools.

Je ne sais pas comment fonctionnent les autres stations daw.

Bie. Amicalement.

Ne t'excuse pas Philippe, allons, on discute, et c'est juste un forum, on peut aussi lire en diagonale ça arrive à tout le monde.
Pour ton explication, je ne crois pas que les autres DAW qui testent la compato des plugins au chargement n'utilisent de sandbox ou autre gestion de la mémoire évoluée, et pourtant ça fonctionne. Digital Performer fait ça depuis plusieurs années maintenant, et Logic aussi surement.
Mais là j'avoue que ça me dépasse un peu, de toute façon... Je passe donc mon tour .

Imaginons... C'est dimanche...

Si chaque plug-ins avait son processus fils, cela aurait une conséquence directe double :

- la première serait d'augmenter de manière considérable la stabilité de l'application principale (Protools), elle ne serait plus perturbée par les demandes d'augmentations en mémoire des programmes non-indépendant de plug-ins. Et donc l'optimisation du logiciel serait plus poussée. (ex : le plug-ins Melodyne exploité à l'extrême sur une session de deux heures, ralenti considérablement la session de Protools, et la rend instable, ce ne serait plus le cas).

- la seconde serait de conférer plus d'autonomie aux plug-ins, qui vis-à-vis du noyau UNIX seraient considérés comme de véritables applications actives à part entière, des processus fils de son père. Les processus de plug-ins auraient leur propre mémoire indépendante de fonctionnement, leurs propres fichiers ouverts, sans que Protools n'en soit perturbé ni même informé de ses détails qui ne le concerne pas.

(notons néanmoins que le père reste maître du jeu : la mort du père entraine celle des fils, la gestion des autorisations).

Avantage découlant :

cela serait la porte ouverte, grande ouverte, à la gestion multi-session, c'est-à-dire pouvoir gérer plusieurs sessions actives de Protools en même temps sur le même ordinateur. Le plan de développement serait de créer autant de processus fils que de session, autant de processus petits-fils par plug-ins pour chaque session.

Sous UNIX la communication de données entre processus actifs et non-zombies reste une opération délicate. On a néanmoins trois outils classiques : les segments de mémoire partagée (zone de mémoire partagée entre plusieurs processus autorisés), les sémaphores (indicateur basique) et les sockets (outil de communication de flux de données).

Sans doute pour les taches demandant des flux énormes comme nous en audio, ce serait insuffisant et pas assez optimisé, et engendrerait trop de latence. Cela vaudrait quand même le coup de tenter une telle programmation.

(À l'époque où j'avais écris mon SGBD pour gérer les bases de données de société et de cabinet d'avocat, j'utilisais énormément la gestion multi-processus et les segments de mémoire partagée. Ca me laisse de bons souvenirs de stabilité et d'efficacité).

Bien amicalement.

J'ai pas tout compris, mais j'aime bien l'idée, j'achète !

C'est juste quelques idées que j'aurais pris plaisir à développer il y a 20 ans.

---

Après une petite semaine de travail sur Protools 9.0.5, quelques autres bonnes surprises :

- certains plug-ins RTAS (Relab480, et pour certains le DMM) qui posaient des problèmes de stabilité CPU (beaucoup de crêtes CPU) sont plus droits et plus réguliers (du moins avec la Digi003 comme interface);

- le changement de plug-ins sur une piste sans stopper la lecture d'une session, se passe beaucoup mieux. Il ne semble plus avoir de décrochage ou quelques erreurs DAE avec certains plug-ins au comportement sensible;

- en édition au fil de la lecture (montage d'une émission de radio), quand on faisait des fades sans stopper la lecture, et que l'on reprenait instantanément à un point avant pour écouter le résultat, il y avait un léger temps d'attente et de temps en temps (rarement) une erreur de DAE. Cela est devenu fluide comme un ruisseau. Ce problème a été levé.

Je relève comme les points ci-dessus une série de petits détails, apportant un peu plus de confort dans le travail quotidien. Cette version m'a l'air d'être un bon cru !

Bien amicalement.

Donc les plugs-ins Ircam Flux:: ont été mis a jour (version 1.1.11) ce matin et fonctionnent bien avec la version 9.0.5 de Protools (j'ai testé Verb Sessions).

Merci par la rapidité des modifications.

Bien amicalement.

Oui, une fois faite la mise a jour de la Reverb Flux/Ircam l'installation de PT 9.05 via "l'update install" c'est faite sans problemes et tt semble bien fonctionner, merci Philippe pour ton avis aiguisé .

Vous savez si c'est arrangé pour le RX parceque j'upgraderais bien là, Speakerphone me fait régulièrement planter mon PT ces temps ci...

Dupont a écrit :Vous savez si c'est arrangé pour le RX parceque j'upgraderais bien là, Speakerphone me fait régulièrement planter mon PT ces temps ci...

Il y a une betafix qu'il suffit fde leur demander et qui a l'air de fonctionner.

Ølaf