xahu34

Peter, Umberto, The fog seems to have lifted, and we can see a common Yorkshire-Bavarian-Italian understanding! Regards, Xaver

Peter, I didn't say that. We referred to different situations. You were talking about keypoint cloning. I considered the situation where you insert a new keypoint (using the button in the animation tab) which is placed between two others having different PZR values (describing a linear animation). In this case the pure keypoint insertion leaves the (linear) animation unchanged, while an additional shift has a side effect on the given animation. Best regards, Xaver

Peter, Sorry, I forgot to say that my observation does not refer to keypoint cloning (which copies the parameters of the cloned point), it only refers to creating a new keypoint at the actual position of the cursor. In this way you can create several keypoints at the same position (transition point), all having (slightly) different PZR parameters. Best regards, Xaver

There is another bad effect with the strange magnetic behaviour described by Peter. If your object is animated, the automatically shifted new keypoint inherits the animation parameters of the position where it has originally been placed. Then the shift causes a modification of the object's animation. Let me repeat one of my earlier suggestions, to provide an input field for manual positioning of the cursor in order to place keypoints without the need of subsequent repositioning (which has side effects on animations). Best regards Xaver Munich

Hello Dave, Would it be possible for you to provide new versions of slides 1 and 2 of your tractor sequences, by replacing stripes 1 to 9 by new ones whose width is enlarged by 1 pixel on the right side? This would mean that all adjacent stripes would have a 1-pixel overlap (see the remark of JPD from above). I just had a look at one of JPD's constructions built with the cale-method. He seems to apply this technique. Best regards, Xaver

Hello Peter, This is a nice example. Some time ago I made a similar experiment by running a panorama via two slides. It is also possible to have a soft start and stop, which is very easy if you program it in a symmetric way. What I did not try so far is the following: Let the moving object run via three or more slides while preserving soft start and stop. If we, the PTE users are honest, we have to admit, that for examples of this kind a slideshow tool providing an unrestricted number of parallel image tracks is much easier to handle. Best regards, Xaver

Hello mfetterhoff, The Quadro series does not seem to be appropriate. You could create an exe-file of your show and see how it will run on a PC ready for gamers. Best regards, Xaver Munich

Hello mfetterhoff, please give us some information on your PC (operating system, RAM, CPU, graphics card, video memory)! Best regards Xaver H. Munich

Hello Dave, If you parquet your screen with butted stripes or rectangles, and want to resize the whole stuff, you can go two ways: 1. You can combine the objects to one single image before resizing. 2. You can resize each object separately before putting everything together. The first way will lead to rather nice results. If you have to go the second way, the effect (thin lines) which you could see, is quite natural. The screen is not a continuum; you have to round positions and sizes. Best regards, Xaver

Lin, I have some doubts about this statement. I would guess that the exe-file includes the media, a playlist (pte-file), and a player, acting in a similar way as the preview, see also here. Best regards, Xaver

Tony, I tried to reproduce the effect of lost images. I programmed a show with two distinct images in different folders, the images having the same name. I tried to create a template and a zip-backup, using versions 5.52 and 5.6b5. In both cases PTE refused to do it, showing a window with an appropriate information. Best regards, Xaver Munich

Hi Dave, I think that Jean-Pierre just presented a simulation of what will happen if you will run a show with images of size 1800x1200 on a 1024x768 screen with ratio 1.5. I generated an exe-file with v.5.6beta5 on my new machine and played it on my old computer with the small monitor. The red line was to be seen; I would have expected the same on 1280x1024, but there it did on occur. Regards, Xaver

No, fullscreen 15:10! The result: No red line on 1280x1024 LCD, red line on 1024x768 CRT. Regards, Xaver

Hello Dave, I changed the davegee project to Fullscreen, and ratio 15:10. I ran the show on my old system with a 1024x768 screen. The red line appeared! PTE seems to resample the image of size 1800x1200 to 1024x683 (as Photoshop and IrfanView do), but seems to generate a screen of 1024x684 in which the resampled image is shown. Regards, Xaver

Hello Jean-Pierre, let me make a final remark on your solution. For me, PTE is a black box. I know its interfaces, how to insert images, how to configure transitions, how to set animation parameters. Furthermore I can look at PTE's output, the preview or an exe-file (I do not use the video stuff). This is what I see, and that's all. I think that your solution would have substantial effects on the internal structure of the PTE software, which is invisible for me as a user. Even if I could look at the design specifications and the source code, this would not help. I am not a software developer with experience in graphics applications. So I do not feel myself in the position to make any substantial remark on your solution. I'm sorry about that, and I would very glad if future versions of PTE would serve your demands. Best regards, Xaver

Peter, let me add an example to my post #61 from above: - Run your project "Frames-Test.pte" from the attachment in your post #40 (this thread) under v.5.5 - Set the zoom values of the white image to "100" (in both cases) - Set the mode for the white image to "Original" (in both cases) This modified project will show the same effect: the two white images again have different sizes; the new show seems visually to be the same as the old one. Thus, the size/position tool achieves a kind of replacement for original mode (surely not in the sense of Jean-Pierre). Best regards, Xaver

Hello Peter, I cannot see anything unreasonable in your sequence. It behaves as it should do. Maybe that a new user not having my personal mathematical background will have other feelings, at least at first sight. But this cannot be avoided, provided that we will not cancel the size/position tool (I actually like it). So, the situation is, as it is now; we cannot change it! I think that the size/position tool has been made for users who think in pixels, and who want to embed child objects into their parents in terms of pixels, although the internal representation of the embedding functions may now be based exclusively on percents (who really knows what happens inside of PTE?). Again: The size/position tool is just a new tool which helps pixel oriented users to get rid of some calculations. We have the same situation as ever, provided that (in the past) we did not use original mode. A new user should perhaps avoid the size/position tool. If you look for the white image (of your example) in the animation tab at the zoom values (6.400% and 50.000%) it should be pretty clear why the white image is of different size in the two slides. So let me claim: The concept provided by WnSoft may not be satisfactory for JPD and his friends who heavily used original mode (I'm really sorry about that), but the concept itself seems to be sound and consistent. What I do not like very much is the fact, that the relationship between child and parent typically is project dependent, but not for top level objects. Here the parent is the screen which is system dependent, see my remark here. The size/position tool itself needs to be endowed with a good documentation! I do not feel myself in the position to answer in general the question if PTE is an intuitive product. For me, it is! Best regards, Xaver

Peter, for each child object there are two sizes in the game: One size is its own absolute size (for a frame it is the one given in the Properties tab). The second size (size/position window) refers to the embedding of the child into the context of its parent. The latter size depends on the embedding mode (fit or cover), the scaling, and of course of the absolute size of the parent. If the width of the parent would count in millions, the same would hold for the child's entry in the size/position window. If you enter the absolute pixel values of the child into the size/position window you will obtain an embedding which can be regarded as a replacement for the original mode of version 5.5. This is what I already tried to indicate in post #16 of this thread. Best regards, Xaver

Igor, Peter, It is my impression that each of you has his own interpretation of the Size/Position tool, and these two views seem to be contradictory. Igor, I think that it would be helpful for some users if you would publish a short specification, in particular how the size parameters in the tool have to be interpreted. Best regards, Xaver Munich

Hello Dave, what I wanted to say is that 5.5 really had different representations (for "original mode" oin one side, and for the other modes) inside the project (pte) file, indicated by the values "absolute" and "percent" for a particular attribute. So it seems to reasonable that both modi were treated differently inside the software, maybe (I can only try to guess) in the way how child objects were embedded into their parents. In 5.6 you can program this embedding via the user interface (size/position window), and of course you do it in absolute terms (pixel coordinates). But your absolute inputs will not be stored in the pte-file. They will be translated into percent values for scaling and positioning. If the difference between original mode and the other modes were only a matter of the user interface the whole discussion here would not have taken place. Best regards, Xaver

Peter, This is not a bug. In the Size/position window each object is described relative to the size of its parent, a very simple logic! A top level frame of size 10000x8000 which fills the monitor (1280x1024) has size parameters 1280 and 1024, while the frame's child (independent from its own size, provided it has the same aspect ratio) inherits the parameters 10000 and 8000 in 100 percent view. Regards, Xaver

Igor, Just a question: What happens to the converted exe-files when playing them on monitors of different seizes? Do they really behave in the same way as the old ones containing original mode images? I would be surprised if they did. Best regards, Xaver Munich

Dave, your observations do not contradict with mine. In order to check my assertion, you should use a text editor and examine and compare pte-files generated with versions 5.5 and 5.6 using a text editor. Study the attributes of images having original mode (version 5,5). These images are marked as "absolute", a value which does not seem to exist in 5.6. Best regards, Xaver

Dave, I think that you can use the frame method (I proposed it to Jean-Pierre a couple of days ago in a PM) in order to do similar adjustments as they can be done with the cale method. A major difference in my eyes seems to be that 5.5 with original mode places objects pixel oriented, while 5.6 internally seems to be completely percentage oriented. The size/position window only seems to be a tool for avoiding calculations (from pixels to percentages). I had a look at a project file created with 5.6: It did not contain the pixel coordinates which I typed into that window, but only the corresponding percentage information. The images all have position mode "percent", I think that position mode "absolute" does no longer exist. Best regards, Xaver Munich

Hi, I tested the two exe-files without noticing any stuttering (AMD 64X2, 2GB RAM, Nvidia 8500GT 256MB, Win XP SP3). I use a FujitsuSiemens monitor (1280x1024) with a Samsung S-PVA panel. With this monitor I never had any problems with zoom and pans, while (in the past) using a Canon Realis SX50 projector I often had synchronization problems while running the same shows and using the same resolutions. Regards, Xaver Munich