Transitions and Effects

[aplman]

The introduction of video into PTE has led to changes in the handling of Slide Duration . Ensuing discussions have brought to light a few difficulties, some of which relate to Transitions. I understand Igor is still wrestling with ideas.

I would like to put forward the following idea concerning Effects and Transitions.

Transitions generally may not have any relationship with a particular slide - they simply provide a visually appealing way of progressing between two slides, and have as much connection with the second slide as with the first.

On the other hand, sometimes a particular slide needs a particular incoming effect, and/or a particular outgoing effect. Some slides may need both incoming and outgoing effects. For example, we may want to introduce a new subsection of a show by unrolling a "curtain" with title or description, and after the appropriate interval, rolling it up again. These effects need to be kept with that particular slide, if any movement, reordering or copying takes place.

I suggest that the Customize Slide dialog, which currently has Main and Effect pages, could have additional pages for Incoming Effect and Outgoing Effect. Any effect specified in those pages should be attached to that slide, and should go with the slide when it is moved. Effects specified in this way should take precedence over any transition before or after the slide.

My own preference for the display in the Slide List would be for transitions (in the current sense) to be shown between slides, rather than above the incoming slide.

I have not thought this through in the case of video slides - I leave that to Igor and team.

[AnKo]

Hi APLman

I agree with you that it will be very usefull when we can get our hands on the transitions better then we can today. To me the transitions are part of the slide.

See this threat I once started:

You suggest that it would be handy to choose a start and end transition effect as an option. But is the end transition not always the start transition of the next slide?

The discussion of the slide duration, somewhere else on the forum, is to complicated for me. And I do not use video. However, I would suggest that the slide duration is the time between the start of the slide, INCLUDING that part of incomming transition effect, and the start of the next slide, INCLUDING the part of the outgoing transition effect.

Too me this sounds logic as I make very often use of those grey areas on the timeline in O&A window.

Kind regards,

André

[xahu34]

I would like to argue that we should leave the situation as it is, in particular, because it is simple. Assume the situation where we had (following your proposal) a slide with both, an incoming and an outgoing effect. What should be the incoming effect of the subsequent slide, and what should happen to it if the "double featured" predecessor is going to be moved? In my view, we do not have incoming and outgoing effects, at all. We only have transitions between slides (object containers), and each transition can only be specified once. The present situation, where each slide defines the transition with its predecessor isn't that bad

Regards,

Xaver

[aplman]

I would like to argue that we should leave the situation as it is, in particular, because it is simple. The present situation, where each slide defines the transition with its predecessor isn't that bad

Xaver

The present situation isn't too bad for one simple reason - that's how PTE has always been up till now, and we have got used to it. However, a recent post by Igor himself shows that he would rather find a better way.

In my view, we do not have incoming and outgoing effects, at all. We only have transitions between slides (object containers), and each transition can only be specified once.

Xaver

I agree completely. That's what we have now. I am suggesting that we SHOULD have the possibility of incoming and outgoing effects, as well as transitions.

Assume the situation where we had (following your proposal) a slide with both, an incoming and an outgoing effect. What should be the incoming effect of the subsequent slide, and what should happen to it if the "double featured" predecessor is going to be moved?

Xaver

My idea is that effects attached to a slide would take precedence over a transition between slides.

The whole idea of one or both effects being attached to a slide is that they would be moved with the slide.

Any transition between two slides that happens to be suppressed because a slide-attached effect takes precedence, would still be there in the specification ... just not visible in the showing. If the slide with the attached features was moved, the old transition would become effective again. (That's just one possible way it could be implemented - I am confident Igor and team will find the right solution, usable and probably elegant as well!)

Ken T (APLman)

[fh1805]

Ken,

I'm afraid that, at present, I disagree with your suggestion. The transitions (or effects) at each side of a slide are, in a well-designed and well-built sequence, chosen to work in conjunction with the adjacent images. If you choose to move the slide, the adjacent images will now be different and, consequently, the choice of transition (effect) and its duration may (probably will) need to be amended. I fail to see any value in carrying the old transitions along with the slide. And, in any case, setting a different transition is not exactly time-consuming.

Could it be, perhaps, that you are trying to "polish" your show too early in the workflow? Setting transition types and durations is one of the last things I do when building a sequence. The bulk of the build is done using simple fade in/out set at 1.5 seconds. Only when I feel reasonably happy with the order of the images and the basic synchronisation to the music or voice-over do I set about refining the transitions.

regards,

Peter

[davegee]

The current system allows for setting keyframes (and therefore animations) within the incoming and outgoing transition periods.

This allows for overlapping PZR effects and less static transitions.

If this facilty were removed then the functionality of the software would be diminished and not improved.

DG

[aplman]

The current system allows for setting keyframes (and therefore animations) within the incoming and outgoing transition periods.

This allows for overlapping PZR effects and less static transitions.

If this facilty were removed then the functionality of the software would be diminished and not improved.

DG

With my suggestion, there would be no need whatever for that facility to be removed. I'm sure the WnSoft programmers could see to that.

Ken T (APLman)

[davegee]

Ken,

I have read your suggestion a couple of times and I can see what you are putting forward.

As long as the O&A dialogue would still show the incoming and outgoing transitions durations (gray strips) I would be happy.

What you are talking about is a method of "locking" particular transitions and their parameters to a slide in the event that it is moved etc?

DG

[xahu34]

... The whole idea of one or both effects being attached to a slide is that they would be moved with the slide.

Any transition between two slides that happens to be suppressed because a slide-attached effect takes precedence, would still be there in the specification ... just not visible in the showing. If the slide with the attached features was moved, the old transition would become effective again ...

I don't think that this feature would be used very often, and in rare cases where it might be useful, the present concept provides easy workarounds. So, I would not recommend to develop this feature. We should keep in mind that PTE has single track of hybrid objects (called slides). At any particular point of time, only one slide is alive, or there is a transition from one slide to the next one. Thus, in my opinion, the present programming concept is an adequate one. There are other AV tools like Wings Platinum and m.objects which offer parallel image/object tracks; and for this presentation concept, incoming and outgoing effects of objects are quite reasonable.

Regards,

Xaver