Ce que FDX sert à échanger, et ce qu’il perd

Ce que FDX assume dans SlateX est un échange de structure de scénario : épisodes, scènes, titres de scène, marques jour/nuit, nombre de pages, éléments de texte et couleurs de révision peuvent entrer dans ce chemin ; les plans, les fiches de prise, les jours de tournage, les paramètres de caméra et l’état de plateau laissés par le tournage ne font pas partie des objets que cette importation crée. Autrement dit, FDX peut apporter la structure du scénario, mais « importation réussie » ne veut pas dire « le projet de tournage est déjà construit », et ne veut pas davantage dire que tout revient mot pour mot après un aller-retour.

Ici, FDX est un support d’échange de la structure du scénario, et non un conteneur des résultats du tournage.

Ce que l’importation crée réellement

Le chemin d’importation actuel de SlateX ne crée que trois familles d’objets métier : les épisodes, les scènes et les éléments de scénario. Les plans ne sont pas créés avec l’importation, pas plus que les fiches de prise, les jours de tournage ou les paramètres de caméra. Les préréglages d’équipe de production tels que le groupe, le réalisateur ou le directeur de la photographie ne sont pas non plus créés par cette importation et restent une question manuelle à part.

Cette frontière décide directement à quelles questions FDX peut répondre. Il convient pour découper un scénario en scènes et en structure de texte lisibles, afin que les enregistrements ultérieurs aient une base de scénario ; il ne convient pas pour le décrire comme « une fois importé, le plan de tournage et les enregistrements de plateau sont prêts ». Qu’une structure existe dit seulement que la structure du scénario est entrée dans le projet. Ce que l’importation crée, et ce qu’elle ne crée pas, est détaillé dans « Ce que l’importation du scénario crée, et ce qu’elle ne crée pas ».

Ce qui précède le premier titre de scène lisible ne forme pas de texte de scène

L’analyse actuelle prend le titre de scène lisible comme point de départ de la création des scènes. Un paragraphe situé avant le premier titre de scène lisible n’a aucune scène déjà existante auquel se rattacher, et n’entre donc pas dans le texte des scènes après importation. Des contenus apparentés aux entrées d’ouverture tombent hors de cette frontière.

Si le texte du titre de scène est vide lui-même, la scène correspondante n’est pas créée non plus. Il ne faut pas y lire une quelconque « intention » du produit ; la formulation exacte est celle-ci : l’étape qui crée les scènes exige un texte de titre de scène disponible, et, quand cette condition de support manque, aucun objet de scène n’a où s’écrire.

« Analyse réussie » peut aussi ne donner aucune scène

Il reste un cas facile à mal lire : un FDX bien construit duquel aucune scène n’est lisible — l’app explique alors sur place qu’aucune scène n’a pu être lue dans ce fichier et l’écran de sélection de scènes ne s’ouvre pas ; ce qui est vraiment facile à manquer, c’est la lecture partielle des scènes : dans ce cas l’écran s’ouvre comme d’habitude et la liste compte moins de scènes que le fichier source.

Cela veut dire que « le fichier a été analysé avec succès » et « du contenu a été importé » forment deux contrôles différents. Le premier dit seulement que le fichier a pu être lu ; le second demande encore de voir si des scènes apparaissent réellement dans la liste de sélection, et si des éléments de scénario existent sous elles.

Un état d’importation qui dit succès ne veut pas dire que des scènes sont déjà entrées dans le projet ; on regarde d’abord la structure réellement créée.

Plusieurs réécritures certaines se produisent à l’aller-retour

Un aller-retour montre plusieurs changements déterministes. Quand une scène venue à l’origine d’un FDX est réécrite, le titre écrit peut ajouter le titre et l’information jour/nuit à un titre qui contient déjà ces éléments. Le point est ajouté sous condition : un titre qui en a déjà un reste inchangé, et un titre sans point en reçoit un seul, de sorte qu’un aller-retour ne produit pas de forme double comme INT...

Le résumé n’est pas symétrique non plus. Les informations de résumé peuvent être lues, mais la réécriture du projet n’emporte pas le même résumé, et une importation ultérieure peut remplacer le résumé de la scène par le premier paragraphe du corps. Quand le nombre de pages vaut zéro, aucun attribut de longueur n’est écrit ; à la relecture de ce fichier, la longueur absente retombe sur 1/8 de page. L’état de tournage n’est pas conservé non plus par cet échange de structure ; une réimportation ramène à l’état « non tournée ».

Ces observations proviennent des résultats d’importation et d’exportation de SlateX lui-même. Elles ne prouvent pas comment se comportera un autre logiciel de scénarisation. La seule formulation autorisée vers l’extérieur est plus étroite : un aller-retour ne garantit pas une fidélité mot pour mot.

Quelles informations de tournage ne sont pas du tout dans cet échange

Les plans, les fiches de prise, les jours de tournage, les paramètres de caméra, le timecode, la notation et les chemins de médias ne font pas partie du périmètre que le FDX actuel peut porter. Le chemin d’importation ne crée pas ces objets, et l’exportation ne glisse pas ces enregistrements de plateau dans la structure du scénario.

Ainsi, quand une information ne revient pas, la bonne question est « cette couche a-t-elle un champ ou un objet capable de la porter », et non un motif inventé à la place du produit pour expliquer « pourquoi elle serait perdue ». L’absence ne doit pas être décrite comme une décision intentionnelle de perdre l’information quand le fait vérifié est simplement qu’aucun champ ne la porte.

Un aller-retour non fidèle ne veut pas dire que le fichier est inutile

FDX reste adapté à l’échange de la structure du scénario. Il peut apporter dans SlateX des structures telles que les scènes, les titres de scène, le jour/nuit, le nombre de pages et les éléments de texte, et peut aussi réécrire dans un fichier la structure de scénario du projet courant. Seulement, cet échange doit être compris aujourd’hui comme une livraison de structure, et non comme une boucle de brouillon que l’on éditerait dans les deux sens sans qu’aucun caractère ne change.

Si le destinataire veut continuer à s’en servir, il vérifie la structure réellement présente dans le fichier, et ne tient pas « cela s’ouvre » ou « cela se réimporte » pour une preuve de fidélité du contenu.

FAQ

L’importation d’un FDX crée-t-elle automatiquement les plans et les fiches de prise ?

Non. L’importation actuelle ne crée que les épisodes, les scènes et les éléments de scénario, et ne crée ni plans, ni fiches de prise, ni jours de tournage, ni paramètres de caméra.

Une analyse réussie veut-elle dire que des scènes ont été importées ?

Pas forcément. Quand aucune scène n’est lisible, l’app explique sur place qu’aucune scène n’a pu être lue et n’ouvre pas l’écran de sélection de scènes ; quand seule une partie est lue, la sélection s’ouvre comme d’habitude, donc il faut aussi vérifier le nombre de scènes réellement créées.

Un aller-retour FDX conserve-t-il les titres de scène mot pour mot ?

On ne peut pas le garantir ainsi. Après un aller-retour, on peut observer des réécritures comme l’empilement du titre et du jour/nuit ou le remplacement du résumé, et la seule formulation publiable reste « un aller-retour ne garantit pas une fidélité mot pour mot » ; on se fie aux différences constatées sur le fichier qu’on a en main avant et après l’aller-retour.

Pourquoi certaines informations de tournage ne reviennent-elles pas par FDX ?

Parce que l’échange FDX actuel n’a ni objet ni champ pour les porter. C’est une frontière de portage, pas une affirmation sur l’intention du produit.

Axiom One LLC — SlateX