OAK : Gérer plusieurs timelines "Objets" à la fois

[jean-claude]

Très étonné d'être la vedette de ce fil. Restons modeste.

Merci à Charlie et à Gérard pour le bref historique. Merci aussi à tous pour vous encouragements.

je pense avoir détecté et corrigé l'erreur signalée par Charlie et Eric (grâce au fichier qu'il m'a envoyé)

Nouvelle version OAK 1.0.1c

- essentiellement correction de ce bug (à confirmer)
- détection disque absent à l'ouverture d'un fichier image
- corrections documentation

Je laisse le soin à Charlie de mettre le lien proprement avec le bouton <télecharger> car je n'y arrive pas.

[Charlie]

Je l'ai ajouté en pièce jointe dans le premier message de ce fil...

Encore merci Jean-Claude pour cet outil formidable...

Reste plus à l'ami Igor qu'à l'inclure dans PTE directement ou comme plug-in... Gérard en dira peut-être un peu plus

[eric]

Jean-Claude, je teste dès que possible ta nouvelle version.
Les bugs aléatoires sont vraiment casse pied à résoudre.

[GuyR]

Merci Jean-Claude.

[jean-claude]

Reste plus à l'ami Igor qu'à l'inclure dans PTE directement ou comme plug-in...

Plugin. Ce n'est pas un véritable plugin (je viens d'apprendre le mot français: greffon) car à part la passerelle du presse-papier il n'y a aucun lien entre les 2 programmes.

Ceci dit, IGOR aurait la possibilité de prévoir une interface ouverte aux programmes extérieurs plus facile à décoder que sa structure arborescente actuelle et ses paramètres parfois énigmatiques, directement accessible par messages inter-programmes ou DLL, et suffisamment documentée.

OAK est un exemple qui pourrait en profiter mais aussi le dernier développement avec les courbes de Bézier et certainement d'autres.

Quant à inclure OAK dans PTE, c'est pratiquement impossible. 24000 lignes dont les 2/3 de code. En plus avec deux langages différents.

[Etienne H]

Félicitations et un grand merci pour cet utilitaire aux fonctions tant espérées dans le PTE !
Espérons qu'Igor ouvrira rapidement une fenêtre permettant aux programmeurs de talent dont tu fais partie avec quelques autres de proposer des modules adaptables directement dans le PTE et non plus en tant que programmes séparés.
De plus, un dialogue entre Igor et vous permettrait une évolution bénéfique plus rapide de notre PTE bien aimé.

[eric]

Jean-Claude, j'ai "torturé" la nouvelle version avec le même fichier que je t'avais fait parvenir sans pouvoir la mettre en défaut.

[Jean-Cyprien]

Ne croyez pas que j'aie voulu snober le travail de Jean-Claude, mais je n'arrive plus à courir deux lièvres à la fois, et je voulais finaliser un premier jus de mon tuto sur les courbes de Bézier, qui commence à devenir l'Arlésienne...

On en reparlera, mais je peux déjà remercier Jean-Claude de nous offrir si gentiment le fruit de son travail.

[Michel.pn76]

Bonjour et, avec un peu de retard... merci à Jean-Claude pour l'excellent travail qu'il offre à tous. C'est vrai qu'à l'origine ça manque cette possibilité de déplacer une série de points-clés. Et il y a bien plus que ça dans ce programme.

J'ai lu attentivement le pdf. Une toute petite remarque. Comme toi, j'ai été confronté au problème du point-clé situé juste à la fin de la transition précédente. Dans ce cas, effectivement on n'a pas dans les propriétés du point-clé sa position temporelle dans son descriptif puisqu'alors on a toujours Time=0. Cependant s'il existe un autre point-clé un peu plus loin (non situé à une position particulière) il est possible de calculer simplement la position du premier point-clé même avec son Time=0. Et comme ton programme se justifie lorsqu'il y a plusieurs points-clés... ça devrait le faire !

Autre toute petite remarque : quelque chose n'est pas mis à jour lorsqu'on colle l'objet changé dans pte. Néanmoins, il suffit de déplacer très légèrement un point-clé dans l'objet collé pour que pte fasse lui-même cette mise à jour. Donc on ne remarque rien, tout se passe bien.

Si tu le désires, plus d'infos par la suite parce que là... je vais manger...

Merci encore pour ton OAK.

[Michel.pn76]

Bon... voici la suite.
Cas du premier point-clé à problème :
object KeyPoint1:KeyPoint
Time=0
Origin=PrevEffectEnd
Opacity=100

Avec Time=0 et Origin=PrevEffectEnd on ne peut pas déterminer le temps de ce point-clé.
Mais vers le début du fichier de l'objet (vers les lignes 20...) on trouve ceci :
PanSpeed=11;2500;5729;6350;6971;7937;8627;9386;10628;11387;12146;12971;1;0;10;0;1;0;1;
RotateSpeed=11;2500;5729;6350;6971;7937;8627;9386;10628;11387;12146;12971;1;0;10;0;1;0;1;
ZoomSpeed=11;2500;5729;6350;6971;7937;8627;9386;10628;11387;12146;12971;1;0;10;0;1;0;1;

On a ici des renseignements précieux :
- on sait immédiatement que cet objet a 11 points-clés
- on connaît la position temporelle de tous ces points-clés depuis le début du diaporama (pas depuis le début de la vue).

Il suffit de prendre le second point-clé dont la position début de diaporama est à 5729, de regarder ce qui est indiqué dans les renseignements du point-clé :
object KeyPoint2:KeyPoint
Time=4729
Origin=SlideBegin

décalage de temps entre ces 2 indications : 5729-4729 = 1000.
On applique le même décalage au premier point-clé : 2500-1000=1500 ce qui veut dire que le premier point-clé est à 1500 du début de la vue, ce qui donne par la même occasion la valeur de la transition qui précède.

Ma seconde remarque concerne le fait que lorsque ton logiciel fait le décalage des points, il ne met pas à jour les 3 lignes PanSpeed, RotateSpeed et ZoomSpeed : ce sont les valeurs d'origine qui restent. Ce n'est pas important dans le sens où pte rectifie à la première action de l'utilisateur.

Mais pour mon programme (BezierPTE) où j'ajoute des points-clés (en nombre parfois important) PTE me faisait une erreur si je ne mettais pas à jour ces 3 lignes. C'est pourquoi j'ai dû étudier ça et que je peux te donner maintenant cette information .

Enfin, pour ton programme, ceci reste anecdotique puisqu'il fonctionne bien comme ça !

Bonne soirée
Michel

[Igor]

Dear Jean-Claude,

I'm very impressed by your work! It's a very professional tool which will be useful for all AV enthusiasts. I learn functions of the OAK program now.

We will try implement features of the OAK editor to future version 8.0 (after 7.5). In v8.0 we will rework the Objects and animation editor.

Also I hope that after v7.5 we will release new versions more frequently (every 6 months).

P.S. I visited France and Luxembourg several days ago and I love your country! Paris, Reims, Amiens and Chartres have beautiful cathedrals.

Igor Kokarev,
WnSoft

Cher Jean-Claude

Je suis très impressionné par votre travail! C'est un outil très professionnel qui sera utile pour tous les amateurs de diaporamas. Maintenant j'apprends les fonctions du programme OAK .

Nous allons essayer de mettre en œuvre les fonctionnalités de l'éditeur OAK dans une future version 8.0 (après 7,5). Dans la v8.0 nous allons retravailler l'éditeur O&A.

Aussi j'espère que, après la v7.5, nous publierons de nouvelles versions plus fréquemment (tous les 6 mois).
PS : J'ai visité la France et le Luxembourg il ya quelques jours et j'aime beaucoup votre pays! Paris, Reims, Amiens et Chartres ont de magnifiques cathédrales.
Igor

[jean-claude]

Igor, thank you for appreciating this software derived from the model dating 4 years ago.

This is great news to hear that version 8 will incorporate these features.
But I also hope that the module A & O will display the audio waveform as is done in the main window. It would be a great additional improvement.

Today these features are really necessary for authors who want to fully utilize the flexibility of objects.

Meanwhile, to release 7.5 if you could include in the copy made in the clipboard the slide duration
and the effects duration, it will permit to OAK to be more precise.

Jean-Claude Sénéchal

------------------------------

Merci Igor pour avoir apprécié ce logiciel dérivé de la maquette datant d'il y a 4 ans.

C'est une grande nouvelle d'apprendre que la version 8 intégrera ces fonctionnalités.
Mais j'espère aussi que le module A&O permettra d'afficher les formes d'onde sonore comme cela se fait dans la fenêtre principale. Ce serait un grand plus.

Aujourd'hui ces fonctionnalités sont vraiment nécessaires aux auteurs qui veulent utiliser pleinement la souplesse qu'apporte le concept des objets.

En attendant, pour la version 7.5, si pouviez inclure dans la copie faite dans le presse-papier
la durée de la vue et celle des effets, cela permettrai à OAK d'être encore plus précis.

Jean-Claude Sénéchal

[Charlie]

Que voila deux excellentes nouvelles, la première étant l'intervention directe d'Igor sur nos forums comme il l'a promis et la seconde l'annonce de la prise en charge de cet outil indispensable lors de conceptions évoluées...
Merci Igor et surtout merci Jean-Claude

[jean-claude]

Mais vers le début du fichier de l'objet (vers les lignes 20...)

merci Michel pour ton appréciaition sur OAK et toutes ces précisions. Effectivement je n'avais pas trop exploré ces lignes.

On peut en effet en déduire la durée de l'effet et celle de la vue mais uniquement si des points-clés sont précisément positionnés sur ces frontières ce qui n'est pas la règle générale.

Je n'est donc pas implémenté de traitement particulier et laissé le soin à l'utilisateur de préciser ces valeurs si cela a une importance mais dans la plupart des cas cela ne joue en rien sur la modification des points-clés à condition que la durée de la vue aille suffisamment au delà du dernier point-clé. C'est pour cela que par défaut j'attribue une durée de vue allant 2 secondes plus loin que ce dernier point-clé.

Ce serait quand-même plus simple que Igor donne expressément ces durées ce que je viens de lui demander dans mon derneir message. A mon avis c'est une modification de programme extrèmement mineure.

Ps: je n'ai pas encore eu l'occasion de te féliciter pour ton programme créant des courbes de Bézier. C'est un plus certain pour les animations de PTE. On pourrait sans doute aussi s'en servir pour tracer des itinéraires. J'ai constaté que tu utilises le même outil que moi à savoir Pascal et Delphi.

[Michel.pn76]

Bonjour,

Jean-Claude, merci pour ton appréciation concernant mon programme. C'est vrai que j'utilise Delphi 7, considéré maintenant comme obsolète (il existe des versions plus récentes chez celui qui a repris l'affaire). Pourtant c'était une version très aboutie de Delphi et ça fonctionne toujours très bien, même avec les dernières versions de Windows... moyennant quelques précautions. Mais qu'il est loin le temps où j'avais cassé ma tire-lire pour m'acheter une calculatrice programmable HP67... ça coûtait la peau des fesses (surtout au regard de mon compte en banque de l'époque !). Puis la programmation sur Oric : quelqu'un avait créé un "assembleur" sur 2 k octets : génial... oui, je dis bien 2000 octets, il n'y avait pas d'étiquettes, tout en hexadécimal, mais ça fonctionnait bien. Et puis... bon, là, je m'égare...

Revenons un peu à ton programme fort intéressant : tu as raison, on ne peut calculer que dans certains cas la durée de la transition précédente et, comme toi, j'aurais bien aimé que ces informations se trouvent dans l'objet lui-même. D'ailleurs, j'aurais aussi apprécié qu'on puisse copier dans le presse-papier une vue complète. J'adhère donc à ta demande auprès d'Igor.

Il est normal que tu ne te sois pas intéressé aux lignes dont je parle puisque ton programme fonctionne bien comme ça. D'ailleurs, pte fait la même chose que toi si on veut copier l'objet d'une vue dans une autre vue : au départ ces lignes restent inchangées mais à la moindre intervention de l'utilisateur tout est mis à jour. Pour mon programme, il fallait que je trouve pourquoi pte m'envoyait une erreur quand je multipliais le nombre de points-clés. La réponse était dans ces trois lignes. Et tu peux voir qu'en mettant un grand nombre de points-clés ces lignes prennent une taille impressionnante !

Mais c'est un vrai bonheur que le fichier pte soit un fichier texte sur lequel on peut intervenir : pte digère pas mal de choses, ce qui permet de créer d'excellents trucs comme tu viens de le faire.

Bonne journée à tous,

Michel

[Papysurfer]

Bonjour,

Mais qu'il est loin le temps où j'avais cassé ma tire-lire pour m'acheter une calculatrice programmable HP67... ça coûtait la peau des fesses (surtout au regard de mon compte en banque de l'époque !). Puis la programmation sur Oric : quelqu'un avait créé un "assembleur" sur 2 k octets : génial... oui, je dis bien 2000 octets, il n'y avait pas d'étiquettes, tout en hexadécimal, mais ça fonctionnait bien. Et puis... bon, là, je m'égare...

Michel

Et encore, n'as-tu pas connu le bon vieux temps du ZX81, cette bidouille plein de câbles et fils partout sur lequel il fallait les dix doigts d'une main + les dix doigts de pied et le nez si on voulait taper cetains caractères ou atteindre certaines fonctions !!!?? Ca c'était le bon temps...!!!!!!

Amitiés,
Jean-Luc.

[Michel.pn76]

Si si, Papysurfer, je me souviens du ZX81 mais je ne l'ai pas possédé.
Je crois qu'il faisait ses calculs lors du retour balayage de la télé... donc vraiment lent. Si on voulait l'accélérer on lui disait de laisser tomber l'affichage et alors plus rien sur la télé jusqu'à ce qu'il ait fini de faire ses calculs.
L'Oric était nettement plus performant !!! Il avait le même processeur que les premiers Apple !

On reconnaît bien ici les plus jeunes..........
Malgré tout, ce n'est pas si vieux, l'évolution a été très rapide... on dira plutôt ça

[vilara]

Je viens de faire joujou avec ce super programme (merci Jean Claude). Une petite suggestion : lorsqu'on déplace un point clé on voit s'afficher dans le tableau des points clé, le positionnement....bien....pour plus de précision, serait-il possible d'entrer dans ce tableau une valeur numérique qui se répercuterait sur le positionnement de ce point?

[cg37]

Je viens de faire joujou avec ce super programme (merci Jean Claude). Une petite suggestion : lorsqu'on déplace un point clé on voit s'afficher dans le tableau des points clé, le positionnement....bien....pour plus de précision, serait-il possible d'entrer dans ce tableau une valeur numérique qui se répercuterait sur le positionnement de ce point?

+ + + + +

[jean-claude]

Pour répondre à Vilara, et CG37, je pense effectivement pouvoir faire cette modif. Mais faut-il raisonner en valeur absolue, ou en valeur relative (c.a.d. ajouter/retrancher quelques millisecondes)
On ne pourra pas directement modifier dans la case elle-même (elle contient 2 valeurs de nature différente) mais dans la barre supérieure où ces valeurs seront dupliquées (cas valeur absolue) dès que l'on clique sur une case.

Un autre aménagement m'est aussi venu à l'esprit. Parfois on veut introduire un certain délai à partir d'un endroit donné (où l'inverse, le raccourcir). On peut le faire en sélectionnant tous les points-clés qui se touvent derrière et en les déplacant simultanément
Pour faire plus simple je vais ajouter une entrée au menu des marqueurs: - sélectionner tous les points-clés de droite.

Pour Michel, Delphi et Delphi 7 sont loins d'être obsolètes. Delphi est en 4ème position des outils de développement dans le monde professionnel (derrière Java, C++, C#) Parmi tous les Delphi Delphi 7 reste aussi une valeur sûre notamment grâce son aide contextuelle que les autres n'ont pas. Les nouvelles versions orientées WEB et Bases de données conviennent certes mieux à l'informatique d'aujourd'hui.


Jean-Claude

Ps: je n'ai pas eu la possibilité de répondre avant à cause de ma migration de la région parisienne vers la Bretagne où il pleut abondamment auourd'hui.

souvenirs, souvenirs, mon premier ordinateur
- salle climatisée de 200M²
- mémoire centrale de 10 000 caractères de 10 bits
- langage assembleur symbolique
- pas de disque, 6 dérouleurs de bandes magnétiques
- lecteur, perforateur de cartes perforées, 1 imprimante
- pour les développeurs: une seule compilation et un seul essai par jour. D'où l'interet de faire soi-même l'essai virtuel auparavant en se relisant plusieurs fois. Aussi prenant qu'un SUDOKU.

année 1963.

[vilara]

Merci Jean-Claude d'envisager de prendre en compte nos demandes. En ce qui me concerne, je pense que la modification devrait se faire en valeur absolue.
Ce soir à notre club photo nous avons appris à manipuler ce programme et il nous est venu à l'idée une autre suggestion. Je trouve logique que certains réglages se fassent dans "Options" (car souvent on ne les règle pas à chaque utilisation) par contre, le coefficeint d'expansion/compression devrait pouvoir se régler dès que l'on clique sur expansion (ou compression) dans une fenêtre spécifique qui s'ouvrirait alors.
Est-ce possible?

[jean-claude]

Très bonne suggestion. D'ailleurs je suis preneur de toute suggestion car ne réalisant moi-même pratiquement aucun diaporama, certains aménagements possibles et souhaitables m'échappent.

Demander le coefficient de compression à chaque opération nécessiterait l'ouverture d'une fenêtre additionnelle donc ce serait un peu lourd. Je vais faire autrement. J'ajouterais la saisie du coefficent en haut dans la barre après les saisies des durées, donc toujours visible (pour savoir où on en est) et ajustable selon les besoins.

[vilara]

Parfait, merci Jean Claude

[vilara]

Je ne sais quelle fausse manip j'ai pu faire, mais je ne peux plus utiliser OAK. A chaque tentative de lancement j'ai le message "Division par zero en virgule flottante" et si j'essaie de passer outre ce message, OAK s'ouvre mais sans les objets et sans possibilité de faire quoi que ce soit.
J'ai désinstallé OAK et réinstallé à plusieurs reprises sans succés.
Que faire?

[Pti Robert]

Aller a Saint Jacques de Compostelle faire un vœux pieux!!!
Gaffe a la contrepèterie!!!