Discussion of v6.0 Beta

[Picsel]

Daniel, Peter, Dom

There is a reason and need for this function. The.pte file documents/records the last saved filename\path location to keep track. If the user ever changes the saved filename\path ... the user should be prompted to save because the project file has changed so PTE can properly document the new changes in the filename\path. Im glad Igor keeps all the relative project data in the .pte file ... otherwise our PC registry may have to become the logger of changes.

To Peter, Dom and nobeefstu

thanks for your reply

Dom,

I full agree with your comments that was exactly the reason of my demand to Igor.

Nobeefstu,

when you begin to work on a project, this project has no name except the name by default "project1" given by pte. The normal way to save your project for the first time is to "save as" and to give a specific name and path. This name and path could be registered in .pte file without any inconveniences (even if the user is not aware about that). But if you create an .exe file, the name and the path of the .exe file are suggested by pte to be the same as for the previous .pte file, so if you do not change the name and path there is no need to modify the .pte file and there is no need to prompt the user to save again his project.

Daniel.

[Guest Yachtsman1]

Your explanation of starting a new show is not what I and I assume many others do. The first thing I do is to give the show a name, which clears the slides from whatever show PTE opened in.

Yachtsman1

[thedom]

Maybe a bug, or maybe I do not completely understand 3D transformations.

Strange interaction with 3D transformation and non-linear acceleration.

See attached. Slide 2 no longer rotates in X axis. I would think rotation would be smooth in X axis.

Tom, in addition to Igor's answer, to see the rotation on X axis on slide #2, for rotate parameter, click on "Setting up..." and in the speed options pop-up, click on "separate here" to divide the sections.

This is the way it works now for pan and zoom parameter too.

But in my opinion, the sections should be separated by default (instead of glued by default).

There is a request for this option in the "Ideas and Suggestions for next version" section : http://www.picturestoexe.com/forums/index.php?showtopic=10431

[thedom]

Your explanation of starting a new show is not what I and I assume many others do. The first thing I do is to give the show a name, which clears the slides from whatever show PTE opened in.

Eric, unless I didn't understand Daniel's explanation, that's exactly what he describes :

when you begin to work on a project, this project has no name except the name by default "project1" given by pte. The normal way to save your project for the first time is to "save as" and to give a specific name and path.

[nobeefstu]

Daniel,

To Peter, Dom and nobeefstu

thanks for your reply

Dom,

I full agree with your comments that was exactly the reason of my demand to Igor.

Nobeefstu,

when you begin to work on a project, this project has no name except the name by default "project1" given by pte. The normal way to save your project for the first time is to "save as" and to give a specific name and path. This name and path could be registered in .pte file without any inconveniences (even if the user is not aware about that). But if you create an .exe file, the name and the path of the .exe file are suggested by pte to be the same as for the previous .pte file, so if you do not change the name and path there is no need to modify the .pte file and there is no need to prompt the user to save again his project.

Daniel.

From your comment " so if you do not change the name and path there is no need to modify the .pte file and there is no need to prompt the user to save again his project." ... and my comment ..."If no changes in the filename\path have changed since the last save ... the user should not be prompted to save for changes." . It appears we are in total agreement.

Its my understanding with the Dom's comment "From the user point of view, to create an exe doesn't change HIS project" ... seems to me Dom is saying whenever a user creates a exe of the slideshow the project file has not changed. I disagree ... because it has changed.

From your further discussion ... I believe you state since the project file already has the suggested filename\path, there is no need save the project file again. However the suggested filename\path you mention has not been officially documented in the .pte file to fill the opt_exefn= parameter. The parameter data is only filled after the exe is created and the project saved. So if you save your .pte project file before ever making a exe ... there is no opt_exefn= parameter filled. Are you suggesting the project file should/could be overwritten to save the opt_exefn= parameter without the user being aware ?

---

The other point we agree on is that there is a issue in the Create As function of Beta 20 ... and Beta 21 still has the same issue. My comment:

... it seems whenever Create As is invoked (even if the filename\path is the same) PTE prompts the user to save because the project file has changed. If no changes in the filename\path have changed since the last save ... the user should not be prompted to save for changes.

This is not correct behaviour comparing to older versions ... because when using the Create As and saving as the same filename\path in the older versions, PTE did not prompt the user to save. The current Beta build version always prompts to save ... whereas older versions only prompt on changes.

[Barry Beckham]

Igor

I wouldn't worry about it, It must be something odd with my machine

Barry

[Picsel]

hello nobeefstu,

Its my understanding with the Dom's comment "From the user point of view, to create an exe doesn't change HIS project" ... seems to me Dom is saying whenever a user creates a exe of the slideshow the project file has not changed. I disagree ... because it has changed.

I really appreciate that .pte file takes records of projects name/path, but from my point of view, perhaps I missed something, there is no need to keep records of name/path for .exe files. In fact the exe files should be considered as the successful results of the project, ending the process, the PTE user will take care of such files without needing PTE help. And following this way I full agree with Dom : the project has not been changed even if you create an "output file" whatever it is : exe file/video file/..... And the main reason for that is that you cannot rework an "output file" with PTE; you can create a new one but you cannot modify or rework an existing one. We can assume that PTE users know perfectly well how to manage their folders and files.

From your further discussion ... I believe you state since the project file already has the suggested filename\path, there is no need save the project file again. However the suggested filename\path you mention has not been officially documented in the .pte file to fill the opt_exefn= parameter. The parameter data is only filled after the exe is created and the project saved. So if you save your .pte project file before ever making a exe ... there is no opt_exefn= parameter filled. Are you suggesting the project file should/could be overwritten to save the opt_exefn= parameter without the user being aware ?

As i said above, from my point of view there is no need to keep records of name/path for .exe files ( or other "output files") inside .pte file and so my suggestion would be that each time the user wants to create an output file, pte can suggest the name/path of the last .pte file which has been saved, but it is the user freedom to keep it or to change it, and if he changes the name or path of the "output file" there is no need to modify the .pte file.

Best regards

Daniel

[Ken Cox]

Well then Daniel can we nominate you to answer all the queries that come along re "where is my exe" ?

ken

[nobeefstu]

Daniel,

We can assume that PTE users know perfectly well how to manage their folders and files.

As i said above, from my point of view there is no need to keep records of name/path for .exe files ( or other "output files") inside .pte file and so my suggestion would be that each time the user wants to create an output file, pte can suggest the name/path of the last .pte file which has been saved, but it is the user freedom to keep it or to change it, and if he changes the name or path of the "output file" there is no need to modify the .pte file.

Best regards

Daniel

I totally understand your proposal. However, there is going to be issues with the suggested and last .pte file which has been saved

The normal workings of PTE uses initially the projectname= parameter value to suggest a filename when saving an exe. The file path is always initially derived from the relative directory the .pte project file is located. So ... the project name and the relative file path is always the suggested filename\path PTE is going to use.

When it comes to your comment :

"pte can suggest the name/path of the last .pte file which has been saved"

Where is PTE going to get the last saved filename\path data from ? If the .pte file documents no record of the saved filename\path data ... PTE is always going to follow the initial procedure of using the project name and the relative file path as its suggestion.

Actually ... I have another program that works in your proposed senario. It only remembers the the last filename\path saved. I absolutely hate it at times because when I build new projects, work with multiple projects in one sitting,or open old ones ... the program always wants to use the same last saved filename\path data for any project I open/save.

Ken makes a valid point. Many users are not so organized and wont remember where and what they saved. The problem will even be experienced by us that open and use project files we made months or even yesrs ago. If PTE isnt allowed to save and remember ... I know I surely wont remember about it from 6 months ago.

If PTE uses the registry instead of the .pte file ... the registry will have a multitude of entries. Then ... when many uses like to do a through clean of their registry especially these days ... all goes the saved data paths.

[fh1805]

I'm surprised that nobody seems to have mentioned this before (but perhaps I missed the discussion).

A child object does not inherit its parents 3D settings.

I've just started dabbling with 3D objects using beta 21. I have set up some coloured rectangles and played around with some simple 3D animation. When I added a child rectangle to one of the existing rectangles and set the child's zoom (main zoom on Animation tab) to 60% I expected to see it in position on its parent and moving with its parent - but it didn't behave that way. Surely such behaviour is the logical behaviour that anyone would expect. I'm talking about the red rectangle in the attached sequence.

regards,

Peter

3D Test.zip

[fh1805]

Further to my post above...

I think I understand what has happened. The parent has had its centre point moved to one edge. I think what is happening is that the child is positioned correctly with its centre point aligned to its parents centre point. Unfortunately, in a 3D space, this causes the child to sit in an offset position.

I've clearly got a lot of learning to do! I can mentally visualize behaviour in 2D, no problem. Visualizing behaviour in 3D is obviously going to require a significant leap in mental dexterity.

regards,

Peter

[fh1805]

A problem (bug ?) with "Transparent to Selection" in beta 21.

I have set up a simple three image object slide as follows:

Main image = ImageA

Independent object image = ImageB

Child of ImageB = ImageC

ImageB is zoomed to 60%

ImageC is zoomed to 60%

The visual effect is of a "stack" of images having all three centre points at the centre of the screen. So far, so good.

I select ImageB in the Objects list, click on its centre-point and drag and ImageB and ImageC move together. Again: so far, so good.

I want to now move the centre-point of ImageB to one corner, so I hold down the Shift key, click on the centre-point handle, and drag. ImageC moves despite the fact that ImageB is still the highlighted object in the objects list. So, I select ImageC and tick the "Transparent to Selection" box on its Common tab. I select ImageB once more and try and move its centre-point to a corner. Once again ImageC moves on its own.

It would seem that the "Transparent to Selection" option of ImageC is being ignored when I do the Shift-click on the centre-point on what I had hoped was the centre-point of ImageB.

regards,

Peter

[Igor]

Peter,

If it possible, please prepare simple project file. Also it would be helpful for me if you could test previous version 5.6 with this demo project. Thanks in advance!

[xahu34]

... A child object does not inherit its parents 3D settings.

I've just started dabbling with 3D objects using beta 21. I have set up some coloured rectangles and played around with some simple 3D animation. When I added a child rectangle to one of the existing rectangles and set the child's zoom (main zoom on Animation tab) to 60% I expected to see it in position on its parent and moving with its parent - but it didn't behave that way. Surely such behaviour is the logical behaviour that anyone would expect. I'm talking about the red rectangle in the attached sequence...

Peter,

Bring the red object into a position inside the yellow one (e.g. center of Image04: -100). Your example shows once more that the given 3D model has its deficiencies. In your example, the bottom image should better cover part of the red image, which does not happen.

Regards,

Xaver

3D_Test-mod1.zip

[fh1805]

Peter,

If it possible, please prepare simple project file. Also it would be helpful for me if you could test previous version 5.6 with this demo project. Thanks in advance!

Igor,

Project file attached. Also a screenshot of what happened when I tried to open this project under v5.6.4 - it wouldn't let me!

I don't know if this is relevant or not, but earlier this morning my PC did a software upgrade to Vista ServicePack2.

regards,

Peter

TransSelBug.zip

[xahu34]

Peter,

Here is another modification of your example. It contains the bottom part twice.

Regards,

Xaver

3D_Test-mod2.zip

[Igor]

Peter,

Thanks, I understand now. This behaviour of the program exists since version 5.0

And related with a fact that child object linked with its parent object via central point. So when you move center point (by Shift+mouse) of a parent we re-calculate Pan X,Y coordinate of the parent object (you can observe it in Animation tab). But we don't change coordinates of child objects. It's a difficult question - should we do this or not?

[uuderzo]

Peter,

Thanks, I understand now. This behaviour of the program exists since version 5.0

And related with a fact that child object linked with its parent object via central point. So when you move center point (by Shift+mouse) of a parent we re-calculate Pan X,Y coordinate of the parent object (you can observe it in Animation tab). But we don't change coordinates of child objects. It's a difficult question - should we do this or not?

From a more technical point of view, I think it's better not, even considering the introduction of new 3D complications.

Greetings... Umberto

[fh1805]

Igor,

Thanks for the reply. I can understand your dilemma. The decision has to be made: what exactly does the child inherit from its parent?

Would a workable solution be to allow the user to choose which aspects are inherited? Perhaps a new Project Options tab called Object Properties, with a series of tick boxes under the heading Child inherits from parent to set the project defaults and extra fields on the O&A Properties stab to allow override at the individual object level:

Child inherits from parent:

Pan

Zoom

Rotate

Centre

Opacity

I realise that implementing this amount of flexibility in the code will be a major rewrite for the team, but I think the result would be to add an additional level of flexibility for the more advanced user that could make animation even simpler and certainly more logical than at present in some of the more complex situations.

regards,

Peter

[fh1805]

RE post 272

Sorry folks, my brain was not in gear. Of course, it is entirely reasonable that PTE should stop me opening a v6 project file in v5.6.4. I'm not old enough to be having senior moments but that was a king-sized one come early!

In mitigation, I had been hopping around between v5.6.4 and v6b21 so much I had lost track of which release I was in and what I was trying to confirm. Added to which I have been driving two PCs at once today as both my desktop and laptop have applied major software upgrades.

I guess my brain just hit the "information overload" condition.

regards,

Peter

[xahu34]

.. Of course, it is entirely reasonable that PTE should stop me opening a v6 project file in v5.6.4 ....

Peter,

I agree with your statement; but there should be a warning if you open a v5-project with PTE v6, and try to save it. If you do it, you will no longer be in the position to open your v5-project with PTE v5.

Regards,

Xaver

[xahu34]

... Would a workable solution be to allow the user to choose which aspects are inherited? Perhaps a new Project Options tab called Object Properties, with a series of tick boxes under the heading Child inherits from parent to set the project defaults and extra fields on the O&A Properties tab to allow override at the individual object level ...

Peter,

We had a very similar discussion some time ago. Regarding the fact that the parent/child mechanism allows tree like structures of arbitrary depth (similar to a file system, here with the screen as common root), I have to say that my mathematically shaped head starts to ache.

Regards,

xaver

[fh1805]

...but there should be a warning if you open a v5-project with PTE v6, and try to save it...

Xaver,

I agree. This would be useful warning to receive.

Igor,

If an effect of the File Save is going to be to change the PTE version number, why not issue a warning message box: "You will not be able to open this project in an older version of PTE. Do you wish to continue with the save? Yes|Cancel"

regards,

Peter

[fh1805]

We had a very similar discussion some time ago. Regarding the fact that the parent/child mechanism allows tree like structures of arbitrary depth (similar to a file system, here with the screen as common root), I have to say that my mathematically shaped head starts to ache.

Xaver,

I know, we've been here before! But consider my little test project. I would like to be able to build up a "super-object" (comprising many individual objects) and then apply the motion to the entire "super-object". Conceptually all I should need to do is animate the top-level parent and all the children should follow in proper order.

But it seems to me in the current implementation of 3D objects that I will, potentially, have to animate every single object independently. That is not how my mind visualizes the motion.

Perhaps I am expecting too much - and what I would like can be delivered only with a true 3D-graphical package. Unfortunately I have become so used to Igor's team of wizards delivering the impossible I've come to expect it.

regards,

Peter

[Lin Evans]

Hi Peter,

Actually, that's quite possible - see my most recent demo of "Critter Cube" which is a six sided cube created and animated entirely within PTE. The complete animation of the cube is controlled from a single frame. It's definitely not necessary to animate individual components though it is quite possible to do so. The strength of the PTE approach is that you have both inheritance from the parent as well as individual child animation possible - it makes many of my sequences possible.

You just need to spend a little more time working with the new features to fully understand them. Look at some of JPD's animations for some inspiration - they are done in a similar way.

Best regards,

Lin

Xaver,

I know, we've been here before! But consider my little test project. I would like to be able to build up a "super-object" (comprising many individual objects) and then apply the motion to the entire "super-object". Conceptually all I should need to do is animate the top-level parent and all the children should follow in proper order.

But it seems to me in the current implementation of 3D objects that I will, potentially, have to animate every single object independently. That is not how my mind visualizes the motion.

Perhaps I am expecting too much - and what I would like can be delivered only with a true 3D-graphical package. Unfortunately I have become so used to Igor's team of wizards delivering the impossible I've come to expect it.

regards,

Peter