aplman

I don't know how to move an item to a different sub-forum. Nor do I know how to bring a specific post to Igor's attention. Any help will be appreciated. Ken T (aplman)

Would it be worthwhile to have a "colour picker" option (accessible via right-click) in all parts of PTE, and an option in colour dialogs to insert the "picked' colour? Ken T (aplman)

Ken, my initial post was to point out a flaw in the present system, which could be fixed in a few milliseconds of programming time. Perhaps I exaggerate a little, but sometimes one must exaggerate to make a point! Ken T (aplman)

Hi Stu! Thank you for your comment. I appreciate your suggestion for a workaround. This might be an example of the need for separate Forum sections ... separating requests for help from reports of bugs and design shortcomings. I thought this case was in the latter category, so I expected to be communicating directly with the wonderful Igor and his team. I have indeed found my own way around the problem -- editing the .pte (text) file. However, my reason for posting was to alert Igor and his team to the problem. I can think of several reasons in support of having an editable field for the destination folder. But while we don't have that luxury, then the PTE software needs to insert the necessary backslash. Regards ... Ken T (aplman)

Further discovery: When I choose a folder for the optimized video clip by browsing the folder hierarchy, PTE puts the chosen folder path name in the edit field, but it won't allow me to type in the trailing backslash. aplman (Ken T)

New project, single slide with a .MOV file. Try to preview. PTE suggests optimizing, I agree. I don't want "Same folder", so I choose another. The new folder field needs to have a trailing backslash inserted. I found the optimized .AVI file was in E:\xxx\folderfilename, rather than E:\xxx\folder\filename. Should be the easiest fix ever? Thank you! aplman (Ken T)

Sorry! Sloppy research on my part! Nevertheless, I still see a need for an option to see the File List "Unsorted". That was there until a few versions ago, and it must be a trivial matter to restore the option. Please Igor! Ken T (aplman)

Hi Dave! Thank you for your response to my post. I should have made it clear that I was asking for the date and time as recorded in the image file's Exif information. I believe it usually goes by the name of DateTimeOriginal. That is much more useful than the file's timestamp, which reflects the last operation on the file. I appreciate your hints on other ways, but having to rename files is often not desirable. Best Wishes ... Ken T (aplman)

I don't think so - I believe the F3 key toggles full screen display of the slide list, without any effect on the order. By the way, my original post seems to have acquired an inappropriate sub-title - please ignore! Ken T (aplman)

I wish to suggest a feature that would greatly facilitate the sorting of slides in the Slide List. I would like to be able to highlight a consecutive group of slides, and collapse them into a single "box" in the Slide List (perhaps via a right-click option). That would preserve the order within the box (of a group that has been carefully sequenced), and allow the box to be moved around, just like a single slide. A right-click option on the box would expand the box contents and restore the display of individual slides. I would be happy to leave it to Igor to decide such matters as: how to give a name to a box how to show a box in thumbnail view and in table view whether boxes would be preserved during a save whether nesting of boxes could be allowed - I would use that feature if it were available. Igor, thank you for considering this request. Ken T (aplman)

I still lament the removal of the "Unsorted" option for the display of the File List. I use PTE for shows of my travels. I find arranging slides into a meaningful sequence is more difficult, more tedious, than it used to be. Here's why. I have various ways of sorting image files into a desired sequence (outside of PTE), and I can then drop those image files into a newly created folder on a FAT32 drive, where the directory entries remain in the right sequence. I used to be able to have PTE's File List present those files in "Unsorted" order. It was then a trivial matter to drop them (all, or a batch) into the Slide List in the desired order. Since it must surely be a very small programming task to restore the "Unsorted" option, may we PLEASE have it restored? Grateful thanks ... Ken T (aplman)

May I request please that we be given an option to display, in the File List, the date/time the picture was taken, rather than the last modification date/time of the picture file? That would be much more useful in sorting out images, especially in travel shows. Ken T (aplman)

I wonder whether the "Ideas and suggestions" sub-forum will achieve useful ends, if poor Igor has to read through all these posts. Might it be useful for the forum to separate the actual suggestions from all the (relevant and irrelevant) ensuing discussions? Ken T. (APLman)

If I may make several points ... (1) No amount of auto-saving will help, if the final save is erased. (2) Frequent backups with scheduled backup software will give the opportunity of restoring the ".pte" file as it was at various stages (I'm assuming the development has taken place over days or weeks). (3) It's not just about PTE. With any software where you are progressing adding to your own personal effort over time (word processing, spreadsheet, picture collection) your source file (the one you are progressively creating) needs to be backed up regularly. (4) As for PTE, perhaps it's essential that the program reminds new users that the ".pte" file is the source document, the definition of the project. If it is erased, further development is more or less impossible. By way of comparison, for example, if one has a Word document and "prints" it to a pdf file, that's not "converting". That is generating a by-product, but the original Word document needs to be preserved. Apologies to anyone who finds this obvious, but I am trying to assist the orginal poster. I am only submitting this because I am surprised nobody else did so. Ken T (APLman)

This sounds like a case for Right-Click. Ken T (APLman)

Looks great to me too! Ken T (APLman)

Hi Peter! Glad you're still there to notice my plea! Ken T.

Thanks Dave. Not tried it yet -- according to the web site, it's not up there yet! Ken T.

As far back as February 2010, I went through a lot of pain coming to an understanding of keyframe scaling. I put forward a suggestion as to how I would like to see it work, but apparently my long dissertation struck a chord only with Peter (fh1805). I have resubmitted it today, hoping to get more interest. There's just one complication -- the abominable KFSD concept has been introduced meanwhile, and led to much confusion. The two subjects are horribly interlinked. Please see "Scaling of keyframes/keypoints" in "Ideas and Suggestions" Ken T (APLman)

Hello Igor NS FRIENDS ... SUGGESTIONS RE ANIMATION IN PTE This suggestion was put forward in February 2010. It received a very enthusiastic response from Peter (fh1805), but not a comment from anyone else. If I have not explained my thoughts well, then I should re-work the item. Trouble is, it will be even longer than now! = = = = = I am now using PTE 7.5 (was 6.02 back then). I think PTE is a wonderful program, and in general the animation features are implemented brilliantly. However, I gather from some recent discussion on the forum (both then and now) that some users do not find those features as exciting as I do. I have only one complaint, and that concerns the way keypoints are relocated when the duration of a slide is changed. Here are my suggestions as to how things might be enhanced. Specification of Keypoint Location I note that keypoint objects in a PTE file have their locations defined by the Origin= parameter and the Time= parameter. Origin can be SlideBegin, PrevEffectEnd, NextEffectBegin or SlideEnd (Let us call those the four “special points”). Time is a number of millseconds relative to the specified Origin. For keypoints that do not lie at one of those special points, the PTE user interface appears always to generate a time relative to SlideBegin. However, I have successfully edited PTE files to have keypoint locations specified relative to the other special points, and both positive and negative time values appear to work. However, if I subsequently move the keypoint (in Objects and Animation), its Origin reverts to SlideBegin (with the Time value suitably adjusted). The present behaviour has some unfortunate effects. For example: (1) if a slide’s duration is reduced, and “Scale keypoints” is unchecked, keypoints that were within the main viewing time of the slide (between transitions) can end up in the next transition; (2) if a slide’s duration is increased or reduced, and if “Scale keypoints” is checked, keypoints that were placed at PrevEffectEnd or NextEffectBegin are no longer located at those special points; (3) keypoints can get out of sequence, when those at the special points remain there, while others move past them. I suggest a change to the PTE program could free us users from these problems. It would be better if each keypoint had its Origin set to the nearest one of the four special keypoints, and its Time value as a positive or negative offset from its Origin. This should apply both to the initial creation of the keypoint, and to its new position after a move. This way, we would get the following benefits: (1) keypoints that are placed at one of the four special points would remain there, (2) keypoints that are supposed to be within a transition would remain within that transition, (3) keypoints that are supposed to be between the transitions would remain there. All these are true whether “Scale keypoints” is in effect or not. Scale Keypoints It remains useful to keep the option “Scale Keypoints”. Scaling should be applied within the range of adjacent special points, not across the whole range from SlideBegin to SlideEnd. In other words, scaling should apply to keypoints within a transition when the transition duration changes. Keypoints between PrevEffectEnd and NextEffectBegin should be scaled within that range only. If the user wants to adjust the duration of a slide, by extending or reducing the main viewing time (between transitions), but wants to keep the timing of the animations near the start and near the end, then Scale Keypoints would be unchecked. If the aim is to adjust the duration of a slide and the animations within the main viewing time, then Scale Keypoints would be checked. In neither case is any animation within a transition affected. On the other hand, if there is animation within a transition, then its keypoints should be adjusted when the transition duration is changed. This would have no effect on animation within the main view time. Potential Problems A reduction in slide duration, without keypoint scaling, could cause keypoints to “collide” or cross over in the centre. This should provoke a message to the user, with the option to cancel the change or drop the keypoints. Removing a transition should cause any keypoints within the transition to be dropped. Possible extensions It might be worthwhile to allow a right-click option on keypoints to enable them to be “anchored” to any one of the four special points. Different colours could be used to give visual feedback. It might be beneficial to have one more special point: Centre - Half way between PrevEffectEnd and NextEffectBegin. Thank you, Igor, for giving this your consideration. If anyone else has read this far, I say THANK YOU! APLman (Ken Travers) - Moss Vale NSW Australia

Hello Igor ... Thank you so much for 7.5 - a wonderful job! Just one small matter re the User Guide. On page 37, under "Scale Keypoints", the third image seems to be the same as the second - it does not reflect the scaling. Regards ... Ken T (APLman)

Without wishing to reply to any particular message in this conversation, I would like to offer my thoughts. I write as a professional software developer of fifty years experience -- even more than Igor's, I suppose. I beg you all to be sympathetic of Igor's challenge. No matter what the application, any program that has to deal with unpredictable amounts of data has varying requirements of memory space. Whether it is an algorithmic computation involving large multi-dimentional arrays (my particular field), a graphical process on many image files, or any other kind of manipulation of large amounts of data, there is a limit to what can be processed. It is not a simple matter to judge, once the user's requirements are known, how much memory will be needed to perform the process. It's not usually possible to tell the user "You have too many images" or "You have too many formulas in your spreadsheet", or "You have mathematical expressions too deeply nested", or whatever, the fact remains, there is not enough memnory to accomplish what you want the computer to do. The response that most software will give is "Not enough memnory", "Not enough resources", or something similar. It's quite simple ... you're pushing the limits, and you need to back off a bit. A 64-bit version of PTE would probably overcome the immediate problem. However, we can be sure that, in a 64-bit world, some users will still push the boundaries and probably eventually be disappointed. It's best, in my view, to accept that there are limitations (which cannot be explicitly specified), and do your best to work within those limitations. Please (Igor and others) ... Do tell me if I'm wrong. Ken T (APLman)

Dave, please forgive me - I haven't done your exact test yet - but I think you and readers of your post will find this interesting. I have a Sony Bravia TV and a Sony Blu-Ray player (connected by HDMI). I have several PTE-produced MP4 files on a USB stick. When I play them with the stick in my TV, I lose some image through the "TV Safe Zone" effect. When the same USB stick is played in my Blu-Ray player, there is no loss of image on the TV. I suspect the answer to your question is going to be more complicated than you expect! Ken T (APLman)

Yes, Peter, I agree -- potentially very useful, and easy enough for Igor and team, I'm sure! Ken T.

With a general "Preferences" page coming in 7.5, perhaps we should hope to see the default font included there. Ken T.