HaroldB

Al, I don't recall that ever happening to me. I just ran a test and it worked just fine, too. I am using Cool Edit 2000 1.1 build 2418 -- is that what you are using? I got an email from them. Have you ever used Cool Edit Pro? Does it offer everything the plugins for CoolEdit 2000 offer? Harold

Igor, You are perfectly correct that I could not see any visual difference when I manually shifted everything 20ms. But then I tried the test with shifting everything 50ms. And that seemed almost exactly like the older releases! I think you should increase the factor of 100ms to 150ms, and that will solve this problem. Of course, it may aggravate other shows, and then I'll have to be embarrassed and have to ask you to change it back to 100ms . But I really think that 150ms will do the trick. Thanks for working on this! Harold

Igor, Maybe you should just try without more frequent querying of the CPU, but see if a 120ms adjustment (instead of 100) makes it better? Harold

Igor, I assume that you posted your message about leaving it as in beta 8 before you read my message posted a few minutes earlier . Even the newer version with 100ms is better than beta 8. Harold

Igor, The 100ms fast timer version is better. I think the 50ms version went in the wrong direction -- iow, it made things worse, not better. I don't know what exactly we are measuring here in milliseconds, but could I trouble you to generate a PTE with 120ms? That's the direction I think might solve the problem. The 100ms fast timer version is ALMOST there. Thanks a lot! Harold

Igor, I certainly agree that allowing 500ms after each transition works just fine everywhere. But oftentimes the music "works" better with the slides if one uses a shorter interval. And because we are developing the show on a fast enough machine, we can get away, for example, with 200ms. So we don't even realize that this is a problem at all, and we cut a CD of the finished show. Then somebody takes that CD and puts it into a slower machine. And instead of running, certain slides in the show repeat for a few times. VERY not professional! I think it would be much better if the show could "adjust itself" when running on a slower machine. I greatly appreciate your thinking through if there is a way it could do this. Harold

Igor, Let's see if I can try to explain this so that it makes sense . When you have a show with quick transitions set to music with a quick beat, sometimes you hit the EXACT right spot in the music with the transition. I find that the new beta 8 works just fine for almost all of my slide shows. There is the one I sent you which is just a tiny bit off from where 4.0 was. I imagine that it might be something incredibly small like 10ms or so, which is why I don't it at all "see it" with my other shows. But this show just seems to be oh-so-slightly off in that one or two of those previously "exactly right" transitions are no longer "exactly right". It's possible that the whole show might be off by that 10ms, but for almost all transitions, 10ms is too small to "see". But when doing sharp cuts, sometimes you CAN see it. So it appears that only one or two slides are "off" when really they all are. Beta 8 is good enough that I can live with it. But maybe you can go back and check your calculations just one more time to see if it might not still be off by some tiny bit? It certainly might be me, that I am watching this slide show over and over again while I should be sleeping . Respectfully, Harold

Igor, << Was it glitch in music playback or just slide had not enough time to be calculated and shown? >> The latter. In all the versions of PTE that I have known, if one specifies too short a time between the end of a transition and the beginning of the next slide, the entire presenation "glitches".... typically, the slide keeps on repeating itself a few times. Unfortunately, "too short a time" seems to be hardware-dependent, so what works on a development machine may not work when a CD is distributed. What I'd like to see done in this case is that the next side should just be displayed, shortened by the amount of time that is "missing". IOW, let's say I specified two slides, each with a display time of 1000 milliseconds, and a transition time of 900 milliseconds. Let's assume that it takes 200 milliseconds for the next slide to be calculated and shown. Right now, it gltiches at the second slide becase there are only 100 milliseconds available. What I'd like it to do is simply show the second slide for 900 milliseconds with a transition time of 800 milliseconds. Showing it for 900 milliseconds with a transition of 900 milliseconds would also be OK. Sure, this is not what the show designer specified, but if I have somebody else seeing my show, I'd sure prefer that my transition is off by 100 milliseconds than having the whole show glitch. This is an extremely common problem, as evidenced by the number of questions related to this that we get on this forum. Harold

Jim, I did not meant to suggest that Igor build in an adjustment for CoolEdit. That adjustment came up in a discussion of a sample file he sent me, where we seemed to be off by .025 seconds.... and that made me think of the CoolEdit addition of .027 seconds. It was about the sample sound file, not about PTE. So we are all on the same wavelength. Harold

Igor, Great work! The new beta now works perfectly for every presentation but this one. On this particular very demanding presentation, it seems to be just the TINIEST bit off when compared with 4.00, needing a tiny bit more of push in the direction you pushed it in to create this beta. I don't know what you changed to get it this good. But if you shifted it 70ms, I'd suggest trying an extra 7ms shift. Similarly if you shifted it 200ms, I might try an extra 15 or 20ms. To me, it's actually "acceptable" the way it is now, even for this presentation. But I think it may need just the slightest tweka to be totally perfect. Great work! I watched a number of my presentations with this new beta, and I noticed that one presentation that used to play flawlessly now "glitches" in one place because of the transition/duration time problem that we've talked about in the past. Apparently, 4.10 is just a tiny bit more demanding, and that makes this particular presentation now "glitch" where it used to work before. This is not a problem, since I can decrease the transition time by 200ms without any problem in this presentation, but I just wanted to say that it would be good if you could fix the "glitch" problem related to transition times versus durations once and for all. Maybe in 4.2 ? Harold

Oleg, I did actually intend to do screen copies of some of your screens. But doing that is much more tedious than having a pause ability in PTE . Thanks! Harold

Igor, I sent you the music file with details via email. In CoolEdit, I discovered that each time I save an MP3 file, it adds .027 seconds of silence to the beginning of the file. Is it possible that the Nero program you spoke of does the same thing and you saved it once more than you thought you saved it? Try opening the current file in Nero and look at the waveforms. Is silence at 4.183 or 4.208? When I create a soundtrack for PTE, I build the soundtrack and then save it in CoolEdit. Then I open it again (now looking at the file with the extra .027 seconds) and use those timings to input to PTE. Up till now, it has worked perfectly. BTW, I keep track of exactly what I have done in CoolEdit to build the sound file, and if I need to recreate it, I always do it from scratch again. In addition to only needing to figure in one .027 silence at the beginning of the file, this also ensures a sound file of the best quality. Harold

Sam, <nodding> Yes.... that's about what it seems to be off for me, too. Harold

I figured if my email was taking more than an hour and a half, I'd bore everybody else and just post it here: Igor, The "special version" *is* better, but still not quite right. I opened the music file that you sent me in CoolEdit, and it shows the silence beginning at 4.208 seconds. You named the file "silence_at_4-183" -- does that mean that the silence is supposed to be at 4.183 seconds? The difference is .025 seconds, but my tests indicate that my show is off substantially more than that. What I can do, if you want, is email you the music (it's 3883K) and the piece of the PTE file that shows the timings in my show. You can then put in thirty or so pictures of your own choosing, and you can see the difference very clearly when you look carefully at slide 28. The other slides in this segment are also slightly off, but it seems easier to see in slide 28, where even the little preview box in the synch window is visibly off. Does your email allow you to get something that big? Harold

Igor, I sent you an email describing my test results. Better, but still not quite there. And Jim, thanks. I was actually wondering about your bumble bee show, but if I recall correctly, thatis not synched. Harold

This version of preview works much better. The preview and the run of the EXE are now virtually indistinguishable. But (see below) they both still have a definite problem. Yes, it does have other transitions before this show segment. However, the problem occurs when this show segment is previewed from the middle with no prior transitions, too. I'm running Win/ME on a 1mh Pentimum 3, and the pictures are all 1024x768 resolution, compressed so that they have an average file size of between 100-200K. I've spent a bunch more time with this and I am really convinced that this is not a CPU problem, at least not in the sense that CPU is at 100% and unavailable. Using the 7b beta, the small preview picture in the synch window is also off, although much closer to 4.00. However, both the preview and the EXE are off by quite a bit more. I used Wintop to watch CPU for execution of the 4.00 EXE. It seems to run in 8 threads. There seems to be a main thread that gets the bulk of the CPU, and another thread that gets about 1.82-2.5% of the CPU. Two other threads get some very small amounts of CPU. I then used Wintop to watch CPU for execution with the 4.10 7b beta EXE. It seems to run in 4 threads. Again, there seems to be a main thread that gets the bulk of the CPU, and another thread that gets 3.5-4.2% of the CPU. The two other threads get less than 1% of the CPU each. I'm assuming that it's the music thread that had doubled in CPU use. But notice that even though it has doubled, it is still quite small in CPU consumption. More importantly, the TOTAL CPU is almost always less than 50%. To me this seems to mean that this is not a CPU problem, because there is CPU available to execute instructions that is not being used. Also, if it were a CPU problem, I would expect the slide after a really short transition to be the worst. In my example, slide 27 is 84K and is on the timeline at 44.839 seconds. Slide 28 is 185K, and is on the timeline at 45.774 seconds. Surely, that should be no problem, yet slide 28 appears noticeably "late" during the show, EVEN in the small preview box in the synch window. I think the reason that this problem might be more noticeable in this show is that there are a lot of rapid transitions set to very beat-y music. So if PTE is off by some very small fraction of a second, it would be much more noticeable than in a more typical show. I then did a test which I think conclusively proves that this is not a CPU problem. In the synch window, I adjusted slide 28 to come in 200 milliseconds earlier on the timeline -- and it worked just fine both in the small box and in full-screen preview mode!! If it were a CPU problem, adjusting it earlier shouldn't have helped, right? What I get is exactly the same show playing differently on 4.0 versus 4.1, and I can adjust the timeline in 4.1 so that it plays the way 4.0 plays without adjustment. That shouldn't happen! So I think that there is SOME sort of problem with the new PTE synching to music. It's off by a little, but that "little" is very noticeable in beat-y music with lots of transitions. Harold

Igor, I hope you've seen Oleg's wonderful tutorial on creating PTE backgrounds on Beechbrook. If you try to follow that tutorial, you'll see that it's pretty hard because there is no way to pause and resume a PTE show once it's running. Of course, we'd like to also be able to restart PTE execution from a differen point once it is paused . But giving us at least the ability to pause and resume a show would be a Really Good First Step, and might not be too hard for you to implement . Respectfully, Harold

Igor, First, a general comment and then the results for the tests you asked for. 1) Shouldn't the total amount of "work" done on the system not change meaningfully between 4.0 and 4.1? IOW, whatever technique PTE used to play the music in 4.0, shouldn't that ALSO take CPU? 2) The best way I can describe the results of the tests you asked me to do is to say -- interestingly -- that the results were not completely reproducible. In general, it feels that this presentation is running "close to the edge" in 4.10, and it works better some times better than other times. In 4.0, in contrast, every transition was hit at exactly the right time. Given that, here are my subjective feelings. The most reproducible timings are when I watch the presentation in the small preview window. Whether I use a WAV file or an MP3 file, the presentation is almost perfectly reliable. Next most good is the WAV file running from a standalone EXE. Next most good is the MP3 file running from a standalone EXE. In fact, I wouls judge this as "acceptable", although 4.0 is definitely better. Next most good is a WAV file running from PTE preview. Worst is an MP3 running from PTE preview. You know from the past that I am a big believer that old PTE shows should be able to execute unchanged with newer versions of PTE. The Wintop monitoring indicates that this is not a CPU problem. Perhaps this is some kind of scheduling problem, in the way that the music and display threads (I assume that they are separate threads) are interfacing? Harold

Al, In this presentation segment, I am using only cuts (IOW, no gray bars). I've never had problems with that before, and that's why I'm bringing it up as a "problem" with 4.10. Harold

Igor, The small intervals are due to the slides following the beat of the fairly beat-y music. I ran the WINTOP performance monitor to see what was doing with CPU time, and while WINTOP is obviously not a precise measuring instrument, it seems to be fairly clear that this is not a CPU time problem. Interestingly also, the slideshow seems to repeatedly go out of synch NOT at the slides with the shortest durations. WINTOP reports four additional threads when running a preview from PTE. Of those four threads, there seems to be one running consistently at about 3.5% of the CPU (I assume that's the music?), so that doesn't seem like it would be detracting significantly. The thread that consumes most of the CPU time seems to peak at about 50% of the CPU during this sequence, which would seem to indicate that this is not a CPU problem. Could it possibly be a program bug? It happens very consistently. My processor is a 1MH Pentium 3 running Win/ME, so it really shouldn't be very slow at running PTE presentations. (FWIW, the only time PTE takes almost the whole CPU is when it does fades.) Harold

I don't even know what beta 6 DOES, but when I tried to download beta 5, I got beta 6a. My problem with it is that it shows certain slideshows differently than 4.0 did. Specifically, the following slideshow segment acts differently... it's as if putting up a new slide with no transition takes (relatively) significantly longer under 4.10 than under 4.0 and therefore the presentation is markedly different for any presentation where lots of slides are put up in very quick succession to work with the beat of quick music. ------------------------------ opt_synchpos18=39950 opt_synchpos19=40654 opt_synchpos20=41345 opt_synchpos21=42258 opt_synchpos22=43121 opt_synchpos23=43969 opt_synchpos24=44221 opt_synchpos25=44444 opt_synchpos26=44839 opt_synchpos27=45774 opt_synchpos28=46594 opt_synchpos29=47449 opt_synchpos30=47658 opt_synchpos31=47874 opt_synchpos32=48312 opt_synchpos33=49149 opt_synchpos34=49997 opt_synchpos35=50830 opt_synchpos36=51043 opt_synchpos37=51266 opt_synchpos38=51683 opt_synchpos39=52552 opt_synchpos40=53391 opt_synchpos41=54212 opt_synchpos42=54629 opt_synchpos43=56360 -------------------------------------------------- Harold

Igor, My feeling is that five or seven thumbnails would not be useful. I currently use Microsoft's Photo Editor as a "poor man's light table". I open as many pictures as it will let me open at one time and then just move them around until I get them in the order I want. Being able to zoom in on a picture or minimize a picture is valuable, too. It sounds to me like five or seven thumbnails would be a step backward. I'd vote for either doing it right or focusing on other things. For the record, my number one suggestion now is to change the PTE slideshow display processing so that transitions that are too tight don't cause glitches when the slide show is run. And my number two suggestion is to allow us to change the transition type and duration from the synch window. And my number three suggestion is to allow simple animations a la PowerPoint. Harold

I wanted to second Al's suggestion that this problem be cured once and for all by the PTE run-time engine. I think it's very important to do it, Igor -- see how often it comes up here as a problem! Harold

Granot, I thought your Effects show on Beechbrook was very clever. Have you ever tried these techniques in a synched show, where the current PTE is apparently less tolerant of coding a two second duration with a two second transition? Igor, Is there any chance of us soon getting these kinds of effects in PTE in a simpler way than Granot's method of animation by creating all the frames? I thought his work was really good, but that performance would be better if these kinds of effects were native to PTE. After all, Powerpoint had had the ability to "fly in" text or pictures for years now. Harold

Works perfectly on my Win/2000/Pro system, run straight out of the zip file. It's a very good show, IMO!! It very clearly communicates your daughter's happiness. Harold