Sujet [NEWS] eaReckon BloXpander passe à la version 1.0.2
- 43 réponses
- 6 participants
- 7 037 vues
- 6 followers
Afficher le premier post
Le comportement des potentiomètres est normal dans ton cas. Ceci correspond bien au protocole Mackie à condition que ces potentiomètres soient "sans fin" (on devrait pouvoir les touner dans un sens à l'infini) - Est-ce le cas sur ton Motif?
Il existe un MIDI learn dans BloXpander pour le mode "Basic Control" mais pas pour le mode "MC Control" (qui correspond à un mapping MIDI fixé par un standard).
Cependant, la fonctionnalité "Plugin Control" de BloXpander a été pensée pour fonctionner dans les deux modes de manière quasi similaire (sélection des paramètres, appel du plugin, 8 boutons + 8 potentiomètres pour tout gérer).
Voici quelques détails techniques supplémentaires à propos du protocole Mackie.
Tout est prévu dans ce protocole pour un fonctionnement bilatéral. Le controleur envoie des infos mais il est aussi censé en recevoir. En gros, l'appareil ou le logiciel qui reçoit ces infos est responsable de la gestion des valeurs. Par exemple, lorsque tu bouges un des 8 controleurs rotatifs, le hôte reçoit une information de mouvement (à gauche ou à droite, de telle amplitude) et ajoute ou soustrait une valeur à la valeur en cours. Le résultat est alors envoyé au controleur qui met à jour la représentation visuelle de cette valeur (une série de LEDs autour du bouton, en général). Le controleur n'est pas censé "stocker" la valeur en cours.
Voici un exemple concret:
Imaginons qu'un paramètre (du hôte) ait une plage de valeurs définie de 0 à 100. La valeur en cours est 50.
Si l'on bouge doucement le V-Pot à gauche, le controleur envoie une information de mouvement ("à gauche", amplitude 1).
Le hôte interprète alors cette donnée. "J'étais à 50, j'enlève 1 - je suis maintenant à 49 et j'en informe le controleur en lui envoyant un message, sachant que le controleur à une plage de donnée de 0 à 127. Produit en croix et hop: 49 * 127 / 100 = 62 -> Tiens controleur, on en est à 62 maintenant".
Le controleur recevant ce message met à jour la série de LEDs pour que ça corresponde à 62 sur 127.
Le controleur ne cherche pas à comprendre ce qu'il se passe ici. On pourrait très bien lui envoyer 127 tout le temps pour qu'il soit à fond quelque soit le mouvement. On pourrait aussi lui faire danser le disco pour que les LEDs s'animent en fonction du niveau des basses dans le hôte
En fait, si le hôte n'envoie pas d'info, les LEDs d'un V-Pot de changent pas d'état même si ce même V-Pot est tourné dans tous les sens. Le V-Pot et ces LEDs ne sont pas physiquement liés et ne communiquent pas entre eux.
Pour des faders motorisés, c'est le même principe, sauf que la valeur reçue par le hôte représente, pour le coup, la position du fader. En bref, le fader bouge, le hôte reçoit des valeurs qu'il doit renvoyer au controleur pour que ce même fader reste en place. Si le fader bouge sans information en retour de la part du hôte, ce même fader retrouvera bien souvent sa position précédente (sur un BCF2000, par exemple). Aussi, pour plus de précision, le fader envoie des messages de type Pitch Bend qui ont l'avantage d'être codés sur 14 bits (au lieu de 8 pour un message de type CC).
Le controleur compatible Mackie, il est soumis... il obéit tout le temps et n'a aucun esprit d'initiative. Mais dans notre cas, c'est très pratique et moralement acceptable
Par exemple, lorsque BloXpander charge une scène et qu'un controleur Mackie est connecté, BXP envoie un tas d'infos au controleur pour que celui-ci soit dans un état qui représente la configuration en cours (les faders sont placés au bon endroit, les LEDs des V-Pots aussi, l'afficheur LCD affiche les numéros des pistes controllées, etc...). Pour un ingénieur FOH ou le membre d'un groupe qui fait office de FOH pendant qu'il joue de son intrument (chapeau!), c'est vraiment le bonheur
A propos du MIDI... et conclusion:
Un message MIDI est codé sur 3 octets:
1er octet: Type de message (note, cc, pitch bend, ...) + Canal MIDI
2e octet: Valeur 1 (numéro de note, numéro de CC, bits les plus significatifs du pitch bend, ...)
3e octet: Valeur 2 (vélocité, valeur de CC, bits les moins significatifs du pitch bend). Cette valeur est parfois non utilisée (par exemple, dans le cas d'un "All Notes Off" )
Un controleur "classique" n'envoie bien souvent que des messages de type CC (continuous controller). La valeur 1 du message MIDI permet d'identifier la cible et la valeur 2 permet de lui attribuer une valeur (de 0 à 127).
Dans ce cas, le controleur est "le chef". Peu importe l'état de la valeur cible, celle-ci devra être mise à jour en fonction de ce qu'elle reçoit. Malgré quelques supercheries possibles, un total recall n'est pas possible sur ce genre de controleur.
Sur un controleur compatible Mackie, mis à part les switchs, rien n'est standard... mais très bien pensé.
1. Comme tu l'as remarqué, les V-Pots utilisent bien des CC mais la Valeur 2 définit le sens et l'amplitude d'un mouvement (par exemple, Valeur2 = 0 signifie "le controleur a bougé à droite un tout petit peu" tandis que Valeur2 = 65 signifie qu'il a bougé à gauche... un tout petit peu!). Il faut donc que le hôte soit prévu pour répondre à ce genre de choses, sinon, les V-Pots ne sont pas exploitables.
2. Les faders envoient des messages de type Pitch Bend. Si tu convertis un tel message en CC par le biais d'un mapper MIDI, il est fort possible que ce dernier change le 1er Octet en $Bx (au lieu de $Ex), fixe le deuxième octet sur un numéro de CC au choix et utilise la valeur 2 du pitch bend pour définir la valeur du CC. Cependant, la valeur 2 d'un message pitch bend contient les bits les moins significatifs et voilà surement pourquoi tu obtiens un tel résultat en mappant tes faders.
En très bref...
Dans le contexte de BloXpander, en mode MCP, il n'est pas prévu de pouvoir controler les paramètres des plugins avec autre chose que les V-Pots. Les faders sont réservés à la gestion des volumes de sortie (et donc ignorés lorsqu'un plugin est sous contrôle). Ceci est volontaire et permet d'éviter une certaine confusion mais ça implique quelques limites.
Si tes V-Pots ne fonctionnent pas correctement, et en particulier s'ils "collent" un peu quand tu passes de 0 à plus haut, je penses pouvoir modifier quelque chose de mon côté pour éviter le problème (je ne promets rien mais je crois que c'est possible).
Anonyme
7206
lucienz
557
Posteur·euse AFfolé·e
Anonyme
7206
PFozz
300
Posteur·euse AFfamé·e
Citation de lucienz :
le problème des potentiomètre, c'est que contrairement aux faders, il ne donnent pas leur position, mais le sens du déplacement.
Du coup, si des infos midi sont ratées, la position du potentiomètre ne correspond plus?
Mais le problème principal vient de la course qui fait que je talonne déjà en passant de midi à 14h.
Le comportement des potentiomètres est normal dans ton cas. Ceci correspond bien au protocole Mackie à condition que ces potentiomètres soient "sans fin" (on devrait pouvoir les touner dans un sens à l'infini) - Est-ce le cas sur ton Motif?
Citation de lucienz :
Une suggestion pour BloXpander:
Lorsque l'on active CTR pour piloter le plugin, le mode apprentissage devrait être possible.
Actuellement BloxPander se connecte au plugin d'une façon qui ne permet pas le mode apprentissage (Learn).
Une deuxième suggestion:
Ajouter un mode apprentissage pour régler le problème de course.
Il existe un MIDI learn dans BloXpander pour le mode "Basic Control" mais pas pour le mode "MC Control" (qui correspond à un mapping MIDI fixé par un standard).
Cependant, la fonctionnalité "Plugin Control" de BloXpander a été pensée pour fonctionner dans les deux modes de manière quasi similaire (sélection des paramètres, appel du plugin, 8 boutons + 8 potentiomètres pour tout gérer).
Voici quelques détails techniques supplémentaires à propos du protocole Mackie.
Tout est prévu dans ce protocole pour un fonctionnement bilatéral. Le controleur envoie des infos mais il est aussi censé en recevoir. En gros, l'appareil ou le logiciel qui reçoit ces infos est responsable de la gestion des valeurs. Par exemple, lorsque tu bouges un des 8 controleurs rotatifs, le hôte reçoit une information de mouvement (à gauche ou à droite, de telle amplitude) et ajoute ou soustrait une valeur à la valeur en cours. Le résultat est alors envoyé au controleur qui met à jour la représentation visuelle de cette valeur (une série de LEDs autour du bouton, en général). Le controleur n'est pas censé "stocker" la valeur en cours.
Voici un exemple concret:
Imaginons qu'un paramètre (du hôte) ait une plage de valeurs définie de 0 à 100. La valeur en cours est 50.
Si l'on bouge doucement le V-Pot à gauche, le controleur envoie une information de mouvement ("à gauche", amplitude 1).
Le hôte interprète alors cette donnée. "J'étais à 50, j'enlève 1 - je suis maintenant à 49 et j'en informe le controleur en lui envoyant un message, sachant que le controleur à une plage de donnée de 0 à 127. Produit en croix et hop: 49 * 127 / 100 = 62 -> Tiens controleur, on en est à 62 maintenant".
Le controleur recevant ce message met à jour la série de LEDs pour que ça corresponde à 62 sur 127.
Le controleur ne cherche pas à comprendre ce qu'il se passe ici. On pourrait très bien lui envoyer 127 tout le temps pour qu'il soit à fond quelque soit le mouvement. On pourrait aussi lui faire danser le disco pour que les LEDs s'animent en fonction du niveau des basses dans le hôte
En fait, si le hôte n'envoie pas d'info, les LEDs d'un V-Pot de changent pas d'état même si ce même V-Pot est tourné dans tous les sens. Le V-Pot et ces LEDs ne sont pas physiquement liés et ne communiquent pas entre eux.Pour des faders motorisés, c'est le même principe, sauf que la valeur reçue par le hôte représente, pour le coup, la position du fader. En bref, le fader bouge, le hôte reçoit des valeurs qu'il doit renvoyer au controleur pour que ce même fader reste en place. Si le fader bouge sans information en retour de la part du hôte, ce même fader retrouvera bien souvent sa position précédente (sur un BCF2000, par exemple). Aussi, pour plus de précision, le fader envoie des messages de type Pitch Bend qui ont l'avantage d'être codés sur 14 bits (au lieu de 8 pour un message de type CC).
Le controleur compatible Mackie, il est soumis... il obéit tout le temps et n'a aucun esprit d'initiative. Mais dans notre cas, c'est très pratique et moralement acceptable
Par exemple, lorsque BloXpander charge une scène et qu'un controleur Mackie est connecté, BXP envoie un tas d'infos au controleur pour que celui-ci soit dans un état qui représente la configuration en cours (les faders sont placés au bon endroit, les LEDs des V-Pots aussi, l'afficheur LCD affiche les numéros des pistes controllées, etc...). Pour un ingénieur FOH ou le membre d'un groupe qui fait office de FOH pendant qu'il joue de son intrument (chapeau!), c'est vraiment le bonheur
A propos du MIDI... et conclusion:
Un message MIDI est codé sur 3 octets:
1er octet: Type de message (note, cc, pitch bend, ...) + Canal MIDI
2e octet: Valeur 1 (numéro de note, numéro de CC, bits les plus significatifs du pitch bend, ...)
3e octet: Valeur 2 (vélocité, valeur de CC, bits les moins significatifs du pitch bend). Cette valeur est parfois non utilisée (par exemple, dans le cas d'un "All Notes Off" )
Un controleur "classique" n'envoie bien souvent que des messages de type CC (continuous controller). La valeur 1 du message MIDI permet d'identifier la cible et la valeur 2 permet de lui attribuer une valeur (de 0 à 127).
Dans ce cas, le controleur est "le chef". Peu importe l'état de la valeur cible, celle-ci devra être mise à jour en fonction de ce qu'elle reçoit. Malgré quelques supercheries possibles, un total recall n'est pas possible sur ce genre de controleur.
Sur un controleur compatible Mackie, mis à part les switchs, rien n'est standard... mais très bien pensé.
1. Comme tu l'as remarqué, les V-Pots utilisent bien des CC mais la Valeur 2 définit le sens et l'amplitude d'un mouvement (par exemple, Valeur2 = 0 signifie "le controleur a bougé à droite un tout petit peu" tandis que Valeur2 = 65 signifie qu'il a bougé à gauche... un tout petit peu!). Il faut donc que le hôte soit prévu pour répondre à ce genre de choses, sinon, les V-Pots ne sont pas exploitables.
2. Les faders envoient des messages de type Pitch Bend. Si tu convertis un tel message en CC par le biais d'un mapper MIDI, il est fort possible que ce dernier change le 1er Octet en $Bx (au lieu de $Ex), fixe le deuxième octet sur un numéro de CC au choix et utilise la valeur 2 du pitch bend pour définir la valeur du CC. Cependant, la valeur 2 d'un message pitch bend contient les bits les moins significatifs et voilà surement pourquoi tu obtiens un tel résultat en mappant tes faders.
En très bref...
Dans le contexte de BloXpander, en mode MCP, il n'est pas prévu de pouvoir controler les paramètres des plugins avec autre chose que les V-Pots. Les faders sont réservés à la gestion des volumes de sortie (et donc ignorés lorsqu'un plugin est sous contrôle). Ceci est volontaire et permet d'éviter une certaine confusion mais ça implique quelques limites.
Si tes V-Pots ne fonctionnent pas correctement, et en particulier s'ils "collent" un peu quand tu passes de 0 à plus haut, je penses pouvoir modifier quelque chose de mon côté pour éviter le problème (je ne promets rien mais je crois que c'est possible).
[ Dernière édition du message le 06/07/2012 à 08:57:40 ]
PFozz
300
Posteur·euse AFfamé·e
Anonyme
7206
PFozz
300
Posteur·euse AFfamé·e
Anonyme
7206
PFozz
300
Posteur·euse AFfamé·e
Bonjour Lylo,
Merci pour ton message.
Veux-tu dire un menu déroulant directement dans le cadre accueillant l'interface du plugin (en plus de l'accès par clic droit sur le slot d'insert)?
Je n'ai pas reçu à ce jour de retour évoquant un plantage aléatoire (sans raison particulière) et en tout cas pas en plein concert. J'ai bien sûr eu quelques retours de clients qui évoquaient des problèmes particuliers (liés à un plugin tiers, une interface audio ou une configuration spécifique) mais la plupart ont été résolus.
Je fais en général de mon mieux pour que les produits tiers fonctionnent avec BloXpander (un paquet de "workarounds" spécifiques à certains plugins sont d'ailleurs implémentés).
En fait, la stabilité ne dépendant pas uniquement de BloXpander, les utilisateurs qui travaillent dans un contexte à l'enjeu très important ont bien souvent deux laptops dédiés à BloXpander (l'un d'entre eux étant toujours prêt juste au cas où).
Je ne peux pas citer de noms, mais certains utilisateurs (des ingénieurs FOH, en général) utilisent BloXpander pour des spectacles de très grosse ampleur. Ceux-ci semblent satisfaits de la stabilité du logiciel, semble-t-il
Cependant, étant donné le nombre de produits tiers pris en charge par BloXpander (OS, interface audio, plugins), il m'est impossible d'offrir une garantie quelconque à propos de la stabilité d'un système entier. Par exemple, si une interface audio n'est pas stable, BloXpander ne pourra rien y faire.
A bientot,
Philippe
Merci pour ton message.
Citation :
Que penses-tu de ce clic droit dans la fenêtre pour obtenir les presets ?
Veux-tu dire un menu déroulant directement dans le cadre accueillant l'interface du plugin (en plus de l'accès par clic droit sur le slot d'insert)?
Citation :
Rien de spécial d'un point de vu retour clients concernant la stabilité et la robustesse du soft en utilisation sur scène ?
Je n'ai pas reçu à ce jour de retour évoquant un plantage aléatoire (sans raison particulière) et en tout cas pas en plein concert. J'ai bien sûr eu quelques retours de clients qui évoquaient des problèmes particuliers (liés à un plugin tiers, une interface audio ou une configuration spécifique) mais la plupart ont été résolus.
Je fais en général de mon mieux pour que les produits tiers fonctionnent avec BloXpander (un paquet de "workarounds" spécifiques à certains plugins sont d'ailleurs implémentés).
En fait, la stabilité ne dépendant pas uniquement de BloXpander, les utilisateurs qui travaillent dans un contexte à l'enjeu très important ont bien souvent deux laptops dédiés à BloXpander (l'un d'entre eux étant toujours prêt juste au cas où).
Je ne peux pas citer de noms, mais certains utilisateurs (des ingénieurs FOH, en général) utilisent BloXpander pour des spectacles de très grosse ampleur. Ceux-ci semblent satisfaits de la stabilité du logiciel, semble-t-il
Cependant, étant donné le nombre de produits tiers pris en charge par BloXpander (OS, interface audio, plugins), il m'est impossible d'offrir une garantie quelconque à propos de la stabilité d'un système entier. Par exemple, si une interface audio n'est pas stable, BloXpander ne pourra rien y faire.
A bientot,
Philippe
Anonyme
7206
- < Liste des sujets
- Charte