réactions à la news Le Rack Performer d'Abeem en version 1.0
- 7 réponses
- 4 participants
- 693 vues
- 4 followers
Banshee in Avalon
27934
Administrateur·trice du site
Membre depuis 17 ans
Sujet de la discussion Posté le 08/01/2014 à 11:50:21Le Rack Performer d'Abeem en version 1.0
L’hôte logiciel pour plug-ins, Rack Performer, a atteint sa version finale 1.0, c’est ce qu’annonce Abeem Live Technologies.
Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Eloquent
4217
Squatteur·euse d’AF
Membre depuis 15 ans
2 Posté le 08/01/2014 à 17:52:46
Pas mal, au fait qu'est ce que ça donne de connecter des plugins.. Qu'est est la différence entre ça et les mettre a la suite de l'autre dans son séquenceur?
www.wsproaudio.com
Anonyme
3 Posté le 11/01/2014 à 16:43:58
Pitêt une réduction de la latence (sujet à l'ordre du jour) en raison d'une gestion interne (donc certainement plus directe) du transport des données entre les éléments avec pour résultat une durée plus courte des traitements. C'est du workflow (de la gestion de flux de données).
Ne connaissant pas du tout le produit je ne sais pas... mais j'imagine que ce point (le transport des données entre éléments) a du faire partie des éléments essentiels du cahier des charges de façon à être un avantage très sérieux comparé à la connexion classique entre éléments se faisant systématiquement par le host (ou le daw).
On doit pouvoir imaginer ça comme un bus interne (et avec un protocole de communication optimisé), donc nécessairement plus économique en ressources qu'un bus externe générique.
Ne connaissant pas du tout le produit je ne sais pas... mais j'imagine que ce point (le transport des données entre éléments) a du faire partie des éléments essentiels du cahier des charges de façon à être un avantage très sérieux comparé à la connexion classique entre éléments se faisant systématiquement par le host (ou le daw).
On doit pouvoir imaginer ça comme un bus interne (et avec un protocole de communication optimisé), donc nécessairement plus économique en ressources qu'un bus externe générique.
[ Dernière édition du message le 11/01/2014 à 16:45:11 ]
jeff 7 adore.
2755
Squatteur·euse d’AF
Membre depuis 16 ans
4 Posté le 11/01/2014 à 19:11:17
aaah bon!!! coool!,ils ont l'air sérieux et pleins d'idées!(les gens de chez Abeem.)
[ Dernière édition du message le 11/01/2014 à 19:13:37 ]
Eloquent
4217
Squatteur·euse d’AF
Membre depuis 15 ans
5 Posté le 11/01/2014 à 22:48:53
La latence est propre au plugin, non?
www.wsproaudio.com
Anonyme
6 Posté le 12/01/2014 à 18:00:29
Citation de Eloquent :
La latence est propre au plugin, non?
La latence d'une source (un clavier par exemple) ou d'un plugin c'est le temps passé entre l'entrée et la sortie.
Dans un enchaînement de plugins en série les latences s'additionnent. La latence globale est la latence cumulée de tous les plugins traversés les uns après les autres, depuis la source jusqu'à la destination finale (ma phrase comporte trois pléonasmes mais elle est plus claire ainsi).
Mais attention, dans un système électronique il faut aussi compter le temps passé dans les composants qui sont hors des plugins mais qui font partie de la chaîne. C'est le cas des bus de données, des câbles, etc. La transmission de données entre deux éléments (l'un en sortie l'autre en entrée) se fait par un dialogue entre les deux éléments ("Attention, je vais t'envoyer une donnée", "Attends, je suis pas prêt", "Ok, j'attends", "Ayé je suis prêt", "Ok, je t'envoie la donnée", "Hop!" (c'est la donnée qui passe dans les tuyaux), "Ah, merde, j'ai raté une partie de la donnée à cause d'un parasite dans la ligne", "Rhaaa, bon je te la renvoie dès que t'es prêt", "Attends je vide mon tampon de réception", "Ok j'attends... Bon, ça vient ???", "Ayé ch'u prêt", "Ok, je t'envoie la donnée", "Hop!" (c'est la donnée qui passe dans les tuyaux), "Ah cette fois-ci j'ai tout bien reçu, merci", "Ok, dis-moi quand t'es prêt pour la donnée suivante", etc.). J'écris ça de façon imagée mais c'est exactement ce qui se passe. Ca s'appelle un protocole de transmission. Les parasites électroniques, les problèmes de synchronisation entre éléments, les temps d'attente à poireauter pendant que l'autre élément se met en situation d'être prêt pour la donnée suivante, etc. eh ben ce sont des causes importantes de latence qui sont fortement négligés et qui ont pourtant une part non négligeable (voire catastrophique quand le système est franchement mal peaufiné) dans la latence globale surtout quand l'élément expéditeur de la donnée et l'élément destinataire de la donnée font partie d'ensembles (logiciels ou matériels, peu importe) différents assemblés pour les besoins de la cause. C'est la raison pour laquelle il existe ces protocoles. Parce que si ces protocoles sont une cause incontournable de latence, ils ont pourtant une utilité indispensable : celle de garantir que l'intégralité des données sera reçue par le destinataire. Il faut donc une bonne qualité non seulement des plugins mais aussi de l'ensemble du contexte.
La latence d'un système, c'est donc la latence cumulée :
- du mode de saisie : clavier MIDI musical, clavier alphanumérique de l'ordinateur, émulateur logiciel de clavier à l'écran, enregistrement audio capté par un micro en temps réel, entrée guitare, enregistrement audio chargé depuis un disque dur (on néglige trop l'importance de la vitesse du disque dur, de la décompression du format de réception, etc. qui entrent eux aussi en ligne de compte).
- de chacun des éléments matériels et logiciels traversés les uns après les autres.
- du temps passé par le processeur à faire autre chose qui n'a rien à voir avec le traitement du son musical. La plupart du temps les éléments logiciels doivent partager le même processeur, sans compter que ce processeur est aussi occupé à d'innombrables autres choses (ne serait-ce que la gestion des innombrables tâches permanentes du système d'exploitation, l'écoute du port d'entrée de vos données, etc.). Or le coeur d'un processeur informatique ne peut faire qu'une seule chose à la fois. Donc il distribue une partie de son temps à toutes les tâches logicielles. En plus il ne fait jamais une tâche en une seule fois, il fractionne toutes les tâches par petites unités de n fractions de secondes qu'il exécute à tour de rôle. Il donne ainsi l'impression d'exécuter toutes les tâches en même temps alors que ce sont en réalité des petits bouts exécutés les uns après les autres à tour de rôle en tournant (c'est un peu comme quand on joue au "Jeu des 1000 Bornes"). Et quand une tâche est enfin terminée elle est retirée du cercle des tâches tout comme le joueur des 1000 Bornes qui a terminé ses 1000 bornes a fini sa partie laissant les autres joueurs continuer leur partie jusqu'à ce que tout le monde ait enfin fini. Le processeur fait ainsi pour absolument toutes les tâches afin de ne pénaliser personne, tout le monde ayant ainsi l'impression de travailler en même temps. Et lorsqu'un petit bout de tâche n'est pas en cours de traitement (parce que ce n'est pas son tour) par ce coeur de processeur, eh ben c'est comme un joueur qui attend son tour au Jeu des 1000 Bornes... il est mis en attente, c'est tout, et ne peut donc rien faire puisque c'est en réalité ce coeur de processeur qui fait quasiment tout. Il n'y a que quelques très rares exceptions qui sont certains éléments électroniques ayant leur propre unité de traitement personnelle (et donc qui jouent au Solitaire dans leur coin), ce sont en général les cartes graphiques et certaines cartes AN/NA (les convertisseurs analogiques/numériques - numériques/analogiques). Pour résumer tout cela : les tâches d'un coeur de microrocesseur sont découpées en tous petits morceaux exécutés les uns après les autres, mais de surcroît à tour de rôle. C'est la raison pour laquelle la plupart des microprocesseurs des ordinateurs ont désormais au moins deux coeurs et non plus un seul comme autrefois... ça permet à ces deux coeurs de se partager les tâches. Cela a de multiples avantages.
- et enfin le troisième élément important mais hélas profondément négligé dans la latence, c'est tout le câblage (physique ou logiciel) de transmission des données entre les éléments. Et qui dit transmission de données dit automatiquement risque d'éventuels problèmes de transmission donc nécessité d'un protocole dans le dialogue pour garantir l'intégralité des données lorsque ces données peuvent être renvoyées (c'est un des intérêts du numérique sur l'analogique).
[ Dernière édition du message le 12/01/2014 à 20:23:15 ]
Eloquent
4217
Squatteur·euse d’AF
Membre depuis 15 ans
7 Posté le 13/01/2014 à 18:55:24
C'est bien d'expliquer... Mais ca répond pas a la question....................
www.wsproaudio.com
Anonyme
8 Posté le 13/01/2014 à 19:36:46
Citation de Eloquent :
C'est bien d'expliquer... Mais ca répond pas a la question....................
Alors la question n'a pas été posée de façon claire. On peut la comprendre de plusieurs façons et probablement que la mienne n'était pas la bonne.
Dans ce sujet actuel itiDav commence un petit cours en plusieurs parties sur la latence dans lequel il explique ce qui dans les plugins provoque de la latence. Je me contente simplement d'ajouter deux autres raisons très importantes elles aussi mais qu'on oublie trop souvent : d'une part la communication entre les éléments (matériels et/ou logiciels) d'une chaîne de production du son, et d'autre part le temps effarant que passe le processeur à faire des tas de choses inutiles pour ce qu'on est en train de faire, d'autant plus inutiles qu'on peut parfaitement s'en passer le temps où on travaille sur notre musique. Rien qu'avec ces trois aspects complémentaires on comprend quels sont les sources les plus importantes de la latence dans les plugins ET dans l'environnement autour des plugins. Et je pourrais ajouter encore une quatrième source de latence bigrement importante : l'antivirus, qu'on pourrait parfaitement désactiver pendant qu'on fait de la production musicale si on prend la peine de se déconnecter totalement du web (et du réseau en général), cet antivirus qui pris ainsi fait partie des tâches inutiles citées ci-dessus. Il faut évidemment ne pas oublier de le réactiver dès qu'on se reconnecte au réseau.
Donc maintenant, après cela... qu'entends-tu en ce cas par "La latence est-elle propre au plugin" ? Détaille un peu plus ce que tu appelles "propre au plugin". Un plugin c'est un ensemble de traitements qui ont été codés et dont les boutons mis à la disposition de l'utilisateur permettent l'usage et les réglages de ces traitements de façon à se comporter suivant les désirs de l'utilisateur. Bref, un plugin c'est un ensemble de traitements. Et comme itiDav l'a indiqué dès sa première partie et comme je le redis aussi dans ma réponse ci-dessus, ce qui génère des latences ce sont des traitements (que ce soit les traitement internes aux plugins comme les transmissions entre plugins... ces transmissions étant elles-mêmes des traitements). Il est donc clair que chaque traitement génère de façon incontournable une latence puisque tout traitement demande un temps d'exécution. Que ce soit dans le plugin ou hors du plugin il y a nécessairement des temps d'exécution, et ces temps d'exécution sont toujours nécessairement supérieurs à zéro. Et la latence totale c'est l'addition de toutes ces latences les unes derrières les autres ainsi que les latences générées par les autres tâches du processeur. Donc puisque chaque plugin a des traitements différents (ou des traitements semblables mais codés différemment) il est évident que chaque plugin génère une latence qui lui est propre. Tout comme le temps que tu mets à exécuter toi-même une tâche manuelle (monter un meuble par exemple) est propre à toi alors qu'une autre personne à qui on demandera d'effectuer rigoureusement la même tâche mettra évidemment un temps différent en fonction de sa dextérité, de ses méthodes, de ses acquis en matière de bricolage, de son caractère, etc.
Chaque plugin est un ensemble de codes informatiques de traitements de données. La façon dont ces traitements ont été programmés a une importance sur la latence, de même que l'environnement informatique logiciel et l'environnement matériel (même les câbles et les connecteurs sont des générateurs de latence qui sont fonction de leur qualité et de leur optimisation puisqu'ils sont générateurs de parasites et autres problèmes permanents qui nécessitent eux aussi des protocoles de dialogue). C'est tout. Je vois mal ce que peut vouloir dire d'autre "la latence est-elle propre au plugin ?"...
Sinon peut-être que itiDav donnera une autre réponse à ta question dans la seconde partie qu'il a prévue de présenter après la première partie. Sa présentation de la première partie est excellente et je pense qu'il ne niera pas, tout comme Los Teignos, ce que j'apporte humblement comme réponse à ta question (humblement mais tout de même sur la base d'une formation professionnelle en électronique numérique et de plus de trente ans de pratique, j'ai entre autres travaillé dans des laboratoires de microbiologie à la conception d'instruments d'analyse de haute précision pour la bioinformatique, c'est à dire le séquencement ADN, mais bon c'est pas par fierté que je te le dis mais c'est pour que tu saches simplement que je ne te réponds pas de façon vague en matière d'acquisition et de traitement de données).
[ Dernière édition du message le 13/01/2014 à 20:32:45 ]
- < Liste des sujets
- Charte