Lin Evans

Hi Tom, I misunderstood your sentence, sorry.... The Visisketch idea has uility, but yes, in a narrow sense. It is a very interesting way to "paint" and can be quite realistic especially if you build your own "brushes." This can be done by simply creating the brushes as PNG objects and naming them the same as some of the default brushes. It does take a long time to create some of the sketches/paintings and if you use small brushstrokes, the number of bitmapped files increases exponentially. This makes the file size grow cumbersome. It is a very neat program, but whatever JPD is doing to get around the file size using his own sketch tool is absolutely amazing. I share your and other's enthusiasm and eagerness to hear from him! Best regards, Lin

Hi Jason, Let me add a bit to Eric's comments. HD video is a video of much higher resolution than that which you see on a standard DVD. There are several ways in which you can use HD video. First, you can create a video of MP4 type with h.264 compression. These high resolution videos can be played back on your computer, uploaded to Vimeo or Youtube, played on various devices (iPhone, etc.). The h.264 MPEG 4 four supports much higher resolution. For example you could create a video with 1024p resolution (1920 pixels horizontal by 1024 pixels vertical). You could make one 1600x1200 pixels, etc., or 720p resolution , etc. These higher resolution videos can also be burned to BluRay media via 3rd party software and even to standard DVD media with third party software. To play them back at high resolution on this standard DVD media or on BluRay or HD media then requires the appropriate player. You can't play high definition (HD) shows on a standard DVD player. Standard DVD resolution varies depending on where you live in the world. There are two main "standards" called PAL and NTFS which have slightliy different resolutions and frame rates, but neither are any higher in resolution than SVGA so there are major differences in the appearance of your h.264 MP4 videos when played back on high resolution monitors or televisions and the relatively low resolution standard DVD's. As for the process you now use versus Video Builder, the video engine found in the PTE Deluxe version, there is little difference in the actual video quality assuming each is done in an optimal fashion. The major difference is in convenience and features. You have some pretty powerful menu building features in Vidio Builder which may not be found in your third party software depending on the individual version you use. Also, Video Builder has one of the very fastest rendering engines available if you have hardware (proper video card) to support the hardware rendering feature so the difference in speed of DVD production may be of value to you. Best regards, Lin

Hi Tom, Yes, it will be interesting to see how JPD was able to get this to work so well. As for the second method being too time consuming, I quite agree, although I don't really see it in any way as a "gimmick". In both approaches you are simply displaying sequential frames. The trade-off is that you have no real control over the speed of playback in terms of frames per second in method one but it's easy to implement. With method two you have complete control over playback speed "and" you have complete control over what else is happening simultaneously during display where with method one you are limited to only those frames in the video itself. With method one you can change the timing of the display of each slide, but when you go too slowly then you have very "jerky" motion. With method two you have the ability to slow down the frame rate and still maintain smooth motion because of overlapping opacity blend. Let me give you something to think about. Once you have laboriously created an object sequence by method two, you can speed up things by displaying these same objects with the same keyframes but in a shorter time frame. That is, you can set the slide time to complete the display in let's say 10 seconds, or you could set it to display for 60 seconds. What would then happen with your "movie" portion is that it's like you have a film reel which you can run in slow motion or in fast forward or at normal speed and everything in between. Also consider that once you have programmed a sequence of say "X" number of frames using some generic file names for each frame and saved this sequence, you then have a "template" which you can plug into virtually "any" video sequence you might have by simply decompiling to get individual frames then using a batch renaming algorithm such as found in Irfanview to match the generic file names of your template. If you have fewer frames in your decompiled video that in your template you simply remove the excess frames from the objects list. By doing this you have then complete control over the speed of your video as well as the content. You can program any desired backdrop or simultaneous animation. It's actually a "very" powerful means of displaying a video yet preserving all the other PTE animation benefits while it's running. Of course the down side is, as we have discussed, the labor and time intensive job of creating the individual template. Also there is the issue of memory resources. There is a limit as to how many objects one can have in a show so your "video" will be limited as to how long it can run unless the animation is cyclical such as a demonstration of something which by nature repeats. The solar system comes to mind. Here is a link to one recent demo I programmed this way using about 640 frames - notice that not only does the Earth spin on its axis, but dynamically changes size and position while in rotation around the sun: http://www.learntomakeslideshows.net/template/earthtodom.zip So what you have is by making your "movie" (the earth rotating on its own axis) as a "child" of a controlling parent (transparent rectangle in this template) you have complete control over the placement and size of your video. This dynamic motion and animation is simply not possible with programs which simply "display" a video. For example, this type animation is not possible with Proshow Producer or Proshow Gold even though they allow substantial control over their inserted video. They can move or size the entire video or even use it as a "background" with animation running in front, but they can't "combine" the dynamics of the video as animation as shown in this demo. To do this requires the parent/child relationship. So with PTE we "can" do some pretty impressive things which with the coming new features in PTE are soon going to be even more impressive! Best regards, Lin

Hi Tom, Having access to these temp files allows one to bypass the need to decompile the AVI file to get the individual frames to make the animated show. How these are then used becomes the next issue. To my knowledge, there are really only two "basic" ways to use individual frames to create an animated sequence which duplicates the "effect" of a video in PTE. 1. Place individual frames as separate slides then sequence them at a rapid rate to create the animation. 2. Place individual frames as separate "objects" within a single slide then turn each object on and off via opacity at carefully spaced keyframes. Strengths and weaknesses of the above. The #1 metod, separate slides, let's you play the sequence back but is extremely limited in that you can do little else except see the sequence as if you were playing back a video. You can't have moving backgrounds, you can't have other objects in motion simultaneously, but it is rather easy to set up and it works fairly well but not nearly as smoothly as #2. The other down side with PTE is that any sequence set to faster than about 100ms will drop frames as long as you have the animation engine operational. This method actually worked better with 4.x and earlier versions where sequences as fast as 10ms would generally not drop too many frames and would create a very smooth video appearance. So the strengths of #1 are easy setup, minimal fuss and fair response. The weakness is loss of slideshow flexibility and having to deal with realistically slower frame rates and less smooth playback. Number 2 method of sequencing as objects works really well as far as smoothness goes (there are "tricks" to help make this so), and it is extremely flexible because you can have other objects in animation simultaneously with moving backgrounds, etc. Depending on how you set up the timings, you can have many neat things in your show during the playback of that single slide. The downsides of #2 are serious though. First, it may take hours or days to program the thousands of keyframes which sequentially turn on and off individual objects (slide frames). In the process you must save and exit PTE possibly hundreds of times to keep from crashing. PTE keeps an internal log to allow the undo and redo process. When there are hundreds of objects, this quickly exhausts memory which isn't returned until you leave the program and re-open. Just saving doesn't help. So the strength of #2 is extreme flexibility, smooth playback and versatility while the weakness is that it's very time consuming to program. This brings us to the value of what JPD is developing which is, by all intention, a much "better" way to approach the issue. As an aside, I just created a sequenced PTE show using David's "Le Mans" car, a sketch which is significantly less detailed than the one JPD did in his example. JPD's show was 19 megabytes. The bitmapped files from David's Visisketch Pro Bitmap folder created a PTE show of over 500 megabytes. Perhaps it would be possible to make these smaller by making a smaller than 640x480 image size, but we still have a "huge" difference in file size for a similar type slideshow. I guess my point is that JPD is on to something really neat which may allow PTE users to do some great sketch animations with much smaller resource load than using Visisketch Pro output. Best regards, Lin

Hi Steev, I understand now - I couldn't quite make sense of what you were trying to achieve from the original sample. Yes, it seems that there must have been a change in programming formula math between 5.7.2 beta and 5.7.3 beta - perhaps Igor can look at this and it will help with diagnosis. Best regards, Lin

Hi Tom, Let's start a new thread so we don't get off-track. If you will, copy your post above to a new title and start a new post and we can continue with discussing how to implement Visisketch output in PTE. Best regards Lin

Hi Tom, Just some observations. I too have used Visisketch Pro but I believe what JPD is doing is significantly different in numerous ways. There are superficial similarities, but the essence, I believe, is quite different. First, Visisketch creates an AVI video file, and as you say the file size is quite large. Then it works on a flat palette limited to 640x480 pixels (at least in my version). Of course it would be "possible" to decompile these individual frames, use them as objects but only with a tremendous amount of effort and time. What JPD does is all in extremely smooth executable format and of quite compact size (only about 19 megabytes or so), the palette is 3D and in an artistic perspective rather than lying flat as with Visisketch, and he overlays images and remove them, something not currently possible with a video file. The brush is "dipped" numerous times for different colors and the result is nothing short of spectacular for PTE. Perhaps in the near future JPD can reveal how he was able to accomplish this. Visisketch Pro provides a way to construct a sketch, painting or both and create a really nice AVI, but what JPD is doing is, I believe, quite different. Best regards, Lin

See if this is what you are looking for: http://www.learntomakeslideshows.net/endev...onChange584.zip If it is correct, the problem is that you have accidentally clicked on the small box between the zoom (Horiz and Vert) which makes your animation non-linear in circularity resulting in asymmetrical opposing objects. Check your numbers against my numbers to see where I made changes. Best regards, Lin

Hi Douglas, We are trying to recover JPD's thread. I deleted the entire thread by accident rather than just the annoying last spam post. It's one of the problems with the way the forum software is designed. The moderator has to use great care or these accidents happen. Ken has a backup archive (posted above) and JPD has been notified as well as Igor. We are waiting to see whether Igor can recall the thread before "posting" the "Printable" archive version which has all the responses and by whom, but doesn't show the incredible number (over 2500) of "hits" that JPD's original post had. This is one of the reasons why we would like to see changes to forum software to prevent spammers from being able to easily post. Moderators try to use extreme care but late at night we get tired and sometimes click on the wrong "action" which removes the entire thread rather than just deleting the offending post. I will try to do better in the future and hopefully Igor may be able to recover the original. Best regards, Lin

Hi Igor, Congratulations to Wnsoft for the best Presentation Slideshow product available! It was the best in 1999 and still is in my opinion!! Best regards, Lin

Hi Dan, It doesn't work exactly like that. The way it works is you create a menu which has buttons. Each button represents a slide number. This works very well as long as you don't have an excessive number of slides to jump to. Some time ago I created an example of this. The easiest way is to place your "jump to" menu as the last slide. You may place a blank slide before this "last slide" so you can manually stop the show before the last slide shows. On each slide you may place an invisible button which you can click on - or even just program a mouse click on each slide to pull up the "jump to" menu. Then you simply click on the appropriate number on the "go to" menu and that slide is immediately selected and displayed. Being able to enter a number via the keyboard would be nice, but the program isn't designed to be interactive in that way. The practical limit as to how many slides you can jump to via the menu is determined more or less by the memory resources available on the system you use to build the menu. Each "button" on the menu is a separate object. As you are programming, PTE has to keep track of each command so you can "undo" and "redo" if you make an error. This begins to impact the memory after about 20 or 30 objects so when you are building your "Jump To" menu it would be wise to save, completely exit PTE and reopen after about 20 objects to avoid a crash. Unfortunately, there is no way around this, however, PTE can handle hundreds if not thousands of objects. I have made shows with as many as 1000 objects and the shows run fine but making them can become tedious. Of course the "practical" consideration of having a single menu with say 100 objects becomes problematic for space considerations. Also remember that if you do this should you add or delete a slide, you will have a "sequence" issue because the slide you add will appropriate the sequence number which is represented by the position of that slide. This will then push the slide after into the next available slot number. So if you had a particular slide as number 10 and the total was 20 slides and you added a slide at position 9, now nine becomes 10, 10 becomes 11.......20 becomes 21. Best regards, Lin Later: I made you a test show using this approach. Open the linked PTE zipped file in Beta 5.7 (it won't open in 5.6.4). Here is how it was done. The "Go To Slide Menu" was created with 30 buttons. Each button is programmed to go to the slide number written on the button. I called the slide numbers to be displayed at the top center of each slide so you can check the accuracy of the program - that is you can see which slide number is called by the menu. I removed the "Pause" button from the Navigation Bar because it is no longer needed. The show is set to do nothing unless a mouse click is detected. You can use the navigation bar to go forward a slide, backward or go to "home" (first slide). If you click the left mouse button anywhere on the slide "except" on one of the Navigation Bar Icons, the "Go To Slide Menu" will appear. You can then click any number on the Menu and that slide will appear. Each slide was set to respond to a mouse click by going to slide 30. Slide 30 is the Menu. Just before the menu for slide 29 I placed a blank so if you are simply navigating by the Navigation Bar the show would effectively "end" at slide 29. Press ESC to exit the show. Try compiling this to an executable with Beta 5.7 and you will see how it works or just use the "Preview" feature. Study how the buttons are programmed, etc., to get a feel for how to do this for your own shows. http://www.learntomakeslideshows.net/sample/testshow.zip and the executable zip for those who don't yet use the beta. http://www.learntomakeslideshows.net/sample/testshowexe.zip Lin

Hi Mike, Not exactly a "style editor" but one of our forum members "Stu Rands" (nobeefstu) has created a PTE reporter which gives the variables in an easily read format. The essence is that the .pte file contains a data set which holds all the variables as you have programmed them with the PTE software. This set of variables is used at the time of Preview or Creation of your slideshow and it contains all the variables such as timings, zooms, rotations, pans, opacities, colors, shadows, fonts requested, keyframes, etc., etc., which are vital to the creation of the slideshow. Sometimes, when a user wants to make changes to a show which affect multiple slides and they don't want to have to go to each slide to individually make these changes, they instead alter the PTE file itself with a text editor. However, this can be quite dangerous so if you attempt this be sure you are working on a duplicate backup instead of the original pte file. Of course when a PTE file is edited and saved, the save must be non-formatting such as an ASCII file. Most of what you will need to do in the majority of cases can more easily and safely be done with PTE itself especially until you really understand the internals well. The best way to understand how PTE works in terms of the file layout is to study the PTE file itself. That's best done by simply duplicating it under a different name and studying the duplicate so no harm might be done by accident. Do a forum search for "nobeefstu" and look for his download link for his "Project Reporter" which displays the variables in an easy to read format. Best regards, Lin

Hi Mike, On "Project Options" "Main Tab" put a check beside "Wait for a Key Press or Mouse Click to show next slide." This will make your show a "manual" advance, retreat, pause, etc.,show. Lin

Let me address a couple of your questions. First, you can use the very good freeware audio editor Audacity to do just about anything you need to do in the way of audio mix, etc. Download it here: http://audacity.sourceforge.net/download/ Yes you would need to customize each slide or the audio to match with your voice over. You won't be able to use Navigation buttons on an MP4 show because you are working essentially with a "dumb" device in contrast to your computer which is a relatively "smart" device. With an executable file, you have the ability to pause, go forward, go backward, etc., because the code allows "on the fly" creation of your show beginning wherever your programming via menus and navigation allow. With a video file you have very limited abilities to do anything not allowed via the play device. The reason it takes much more time to create a video (mp4, avi, mpeg II, etc.) is because "each" and every frame must be created and "stored" for the differences in animation, etc. So if you have, for example, a zoom into an image followed by a zoom out, at least 30 frames consisting of separate images must be created and saved for each one second of display time. When an executable file is created, it only contains the first frame and "instructions" to the computer to create successive frames "on the fly" and it creates double and more the frames in "most" videos. For example the "typical" PTE executable with animation will have 60 plus frames per second. You "can" create video with up to 60 frames per second as well, but the normal is "29.97 fps" for USA and 25 fps for PAL countries. These frames created on the fly by the computer are not saved or stored, only played as they are created. The above is also the reason that "most" MP4 creations are much larger in terms of storage than an executable file which produces the same or much better quality. Best regards, Lin

Hi Ron, No, it's not.... Best regards, Lin

Hi Dom, Both are perfectly smooth on my systems. The "only" difference which I can see is that the 5.7b2 version has for me the same issue with the last slide. On the 5.6.4 version all slides display properly. On the 5.7b2 version the last slide just quickly "flashes" after extended black. It actually flashes so quickly that it's impossible to read the text - just a flash orange color, etc. However, if I press the space bar "anywhere" during the show to stop the show on a slide, the last slide displays normally. Something is not quite right about the beta yet. Best regards, Lin

Hi Eric, Sorry for not being clear. What I wanted to get across (I assumed you would be buying an LCD monitor) is that not "all" LCD monitors are created equal in that "some" are much more amenable to correct gamma range and calibration. Others can't be calibrated at all. Also, some will "probably" give you ghosting while others will not. Price is another can of worms. You don't necessarily have to pay an arm and leg, but you do need to "not buy" the run-of-the-mill LCD monitor if you want to be able to "accurately" edit your images for color intensity, hue, etc., and if you want accurate representation of what most other will see on your slideshows. We really "can't" edit animated "images" as such in the relevant sense. We edit still images and with PTE can then animate these edited images as necessary or desired. Ask Dave what his monitor cost because that model is, I believe, the same one theDom uses and it is a very good one for both editing and for playing back stills as well as animations. Bottom line is you won't get a decent LCD monitor for less than about $400 USD and probably it will cost more. Best regards, Lin

Hi Eric, There are two considerations which at first blush may seem to be of equal importance, but in reality are not. In terms of "practical" application, I find that I can edit my highest resolution images with precision and absolute accuracy on a crt monitor at 1024 x 768 resolution. I don't believe having higher resolution (larger pixel matrix) settings are really all that necessary or useful in terms of editing. However, for folks our age, having higher resolution screen settings can adversely affect our ability to read text, etc. So for display purposes of slideshows, higher resolution monitors are very nice but for edits and such are not necessary. The issue with LCD monitors is that there exists a wide disparity in their abilities to accurately display nuances of color and therefore accurate calibration. Further, the refresh rates are highly variable and this means potential ghosting of objects should you have rapid movement of objects of contrasting color with the background. Recently I submitted a little test slidshow which may be of value to you when purchasing a new display. Various forum members tried this brief show on a variety of different equipment and the results were interesting. For example, many if not most of those who were using LCD displays saw ghosting as the disc rotated against the dark backdrop. Those using crt monitors saw little, if any. On the other hand on the LCD monitor theDom was using (not generally found in the US, but probably available in the UK) there was no ghosting and the disc was sharply defined at all times. So what you might want to consider is not only the usability for editing but also the probability of ghosting or not on a specific LCD display. Here's a link if you care to put this little show on a USB media stick and take it with you to test a display before purchase. http://www.learntomakeslideshows.net/sample/3Dsimulation.zip Best regards, Lin

Hi Guys (Jeff, Barry), I think something else must be going on. The show runs butter smooth on the two systems I've tried it on which are configured as follows: 1. Gateway with Pentium 4 running at 3.0 GHz with 2 gig of RAM, Direct x 9.06 and an nVidia 8600 GT (over-clocked) with 512 Meg video RAM. The display is 1280x1024 32 bit. 2. Dell Inspiron with Core 2 Duo running at 2.33 GHz with 4 gig of RAM, Direct x 9.06 and an nVidia 8800GT with 512 Meg RAM. The display is 1024x768 32 bit. The second system I would expect to be able to run about anything smoothly, but the first one has less resources than your computer Barry and about the same video card except being overclocked which really shouldn't make that much difference. I'm wondering about available system resources or possibly something running in the background? We have had these kind of problems in the past where seemingly there are sufficient resources yet something runs fine on one system but not on another. I will try this at 1600x1200 and see how it works and get back. Both systems using Windows XP Home Edition. Which operating systems are you using where you have the stutter or "jitter"? Lin Just tested it on the 8800GT at 1600 x 1200 and was still butter smooth. I can't run the LCD monitor on the gateway at any higher resolution than the 1280 x1024 because it's maxed out there. I'm guessing the issue may be related to how the OS uses resources rather than resources themselves. It would be interesting to get others to respond and see if we could find some "pattern" to the issue. There is one strange thing though. If I let the slideshow run without touching the spacebar to pause it, the last slide which says "animation by theDom" just flashes on screen for a picosecond. If I press the spacebar any time within the slideshow, then the last slide stays on screen for the normal duration. I'm assuming Dom is using 5.7 beta 2 and I noticed a bug with it which I emailed Igor about. In my quickie slideshow where I duplicated the images and text from the Denver Post Blog about D-Day, the first slide takes forever (maybe 10 seconds) to show in the executable, yet pops right up in the Preview. AFAIK, the Preview creates a temp exe file so something is different. Also, when the exe file is created, it is twice the size of the exe reported before creation. I'm suspicious that the issue with the "jitter" could somehow be associated with this beta rather than a true problem with either the resources or show.

Hi Dom, Exceptional! I love it! Lin

Just for the record. There is no problem with PTE's Video Builder - there are thousands of people using it very successfully. If your file size is 2/3 smaller with Roxio, then the quality will also be considerably less. High compression means less video quality. The data doesn't magically shrink when using a different product. This may also be a clue as to the area of the problem you were experiencing with Video Builder. You said you were unable to burn a DVD with PTE then said that using Roxio took half the time. If you couldn't make a DVD with PTE then you really don't have a legitimate comparison. I don't know exactly what the problem may have been, but Video Builder is incredibly fast at creating DVD's compared to my other burning software including my Roxio Creator Ultimate 2009. As Stu mentioned, Video Builder uses hardware acceleration and hardware rendering so if your video card isn't up to the task this may be part of the issue and requires turning off hardware acceleration. It's difficult to say what the problem may have been, but since there are multitudes who are not having problems, it's safe to say that it was something unique to your set-up or settings. The best way to approach this is to use rewritable DVD's until the problem is found. Best regards, Lin

What you want to do is something which has been suggested by theDom in the past and that involves "selecting" multiple keyframes and "moving" them in unison. What the Scale Keyframes feature does is increase the time for the slide and all objects by your chosen time (one second - in this case) but spread that one second evenly among the keyframes so that the relative relationship between keyframes is maintained but increased proportionally to its specific "share" of the one second increase. If there were a way to select and "lock" the keyframes, then insert a specific amount of time "before" or perhaps after the locked keyframes so they move together and maintain their current absolute time relationships then it would do as you wish. As it is, you would have to move multiple keyframes. Best regards, Lin