Thank you for the explanation!

2

(11 replies, posted in Evolution requests)

Rémi wrote:

I've added a "%Pe" variable (path to Siren's executable) which will allow you to do the trick.

Thank you! I am using it now and it seems to work as expected.

I am quite happy with your program now. It takes some time to define what one needs, but that is the expected cost of flexibility.

However, I have programming background myself. Therefore I believe that for many potential users your syntax will be prohibitively complex. Maybe it could help if you would add even more examples in the help and in the favourites in the future.

Regards,
Borut

Stefan wrote:

An leading %e before the drive letter makes no sense.

Hi Stefan, The-XY-scripting-guru. It is nice that we have similar things on our radars! tongue

Well, it does seem to make sense: As an intermediate result for the next expression.

When one wants that the collision logic takes also the extension into account, then (due to somewhat problematic conceipt of Siren scripting, I would say) one has to go that way.

See in Help: Examples > "Rename associated files while renumbering them"

Have a nice First of May!

Regards,
Borut

When using 3.00 beta 2 build 888, then...

This works as expected:

P:\\=%e=Photo\\_Photo\\%dm{"%Y"}\\%dm{"%Y%m"}\\%dm{"%Y_%m%d_"}\\%dm{"%Y-%m-%d_%H%M%S"}%T{"C:\\_PortableProgramFiles\\siren\\abcd.txt",%nc{1,0}}.%e;%fc[1,1,"="]%fc[3,1,"="]

But this does not:

%e=P:\\Photo\\_Photo\\%dm{"%Y"}\\%dm{"%Y%m"}\\%dm{"%Y_%m%d_"}\\%dm{"%Y-%m-%d_%H%M%S"}%T{"C:\\_PortableProgramFiles\\siren\\abcd.txt",%nc{1,0}}.%e;%fc[2,1,"="]

Maybe I am making an error and maybe it is a bug.


BTW, in on line help > Examples, there are two same titles "Rename associated files while renumbering them" at the beginning of the page.

Regards,
Borut

5

(11 replies, posted in Evolution requests)

Regarding B)

Seems to work - thank you for the explanation! One more request:

"C:\\sr_n2a.txt"

I am fond of portable programs and would like to store this small file in siren's directory itself and define its position in a fully portable way. I was looking among base variables and hoping to find a variable that would give me the directory in which siren.exe is located. I was not able to find it. Would it be possible to add such a variable (if it is really not existing already)? Maybe that is not much work?

I would like to use something like this:

P:\\photo\\_Photo\\__TESTdest\\%Xdo{"%Y"}\\%Xdo{"%Y%m"}\\%Xdo{"%Y_%m%d_"}\\%Xdo{"%Y-%m-%d_%H%M%S"}.%le;%pa%b%T{"%PE\\abcd.txt",%nc{1,0}}.%le

Thank you for considering this addition!
Borut

6

(1 replies, posted in Evolution requests)

Most of modern digital cameras can create images and video. So, generally, one should have an expression for *.jpg, another one for *.mov, another one for *.avi and so on. This is OK.

It is possible that what I would find nice to have is already possible with Siren, but I have just not seen it - I do not know. It is the following:

I would like to be able to select all the files in the camera, irrespectively of their extension, and evaluate each file with the expression depending on the extension of theat file. (I know I can do this now by iteratively selecting extension-specific files and applying appropriate expressions.)

So, I was thinking about the concept of an expression set, which would be one level above the expression level, so to speak: Each line in an expression set would provide the file extension(s) and one expression, something like this:

mov,avi: <here an expression for non exif files>
jpg,jpeg: <here an expression for exif files>

Siren could provide for saving and selecting expression set definitions. When evaluating, Siren would look what extension a file has and then apply the appropriate expression from the selected expression set.

Well, this is just an idea, which, I think, could be nice to have.

7

(11 replies, posted in Evolution requests)

Regarding B:
Thank you Rémi, but I have not had time to test this yet. I will write a confirmation, as soon as I find some time to test it.

Regarding C:
I have a question: What happens if there is no name collision between currently evaluated names, and one executes copy (to copy originals to destination places) and there, in the file system, then actually are name collisions? I hope nothing will be overwritten and also hope that some error/problem information will be reported to the user.

(I understand that you will look into this problem after 3.00. I am just asking how it is now, because of the following scenario: Two persons were at the same time with their cameras on the same event and made many shots in the same second. Used expression resolves the names up to the second and resolves also name collisions between currently selected names. Person A saves the image files on the server (expression includes server directories). Person B then saves image files from his/her camera on the same server, using the same expression. What will happen? This could very well be a real world problem, but I have not investigated what will actually happen.)

Thank you for your time. With each day I feel I should donate something smile

I have three wishes in the area of the name collision resolution...

A) I am using %ncs{1}. Is it possible to avoid the underline at the beginning?
B) Is it possible to use something I would call "alpha increment", for example:
    NOW:
    _01    _02   ...    _09    _10    _11  ...

    WISH, for instance %nca{2}:
    aa   ab   ...  az   ba  bb  ...

C) This could be the most difficult to achieve, because it defers from your "philosophy", I think... Currently, I think that "collision" is the collision between the current set of selected calculated names. I think that more correct would perhaps be, if it would be the collision with real files, that exist at calculation time. So, after the first calculation of the new name, to look in the file system if it already exists (and then, if %nc used, recalculate, look again in the file system,...).

I know - this is a major change, but I think it would be better.

Thank you for considering C and helping me to achieve A (or even B), if already possible.

Regards,
Borut

EDIT: C is even more difficult, because I think the logic would need to check against both the file system and other already calculated values and there is no collision only if both cases are OK.

Thank you very much! I have tested it and it seems to work perfectly.

(I have another wish/question, but will use another thread.)

Hello!

I am very new to Siren and am testing beta 300.b1.855 since yesterday. I find it great and am in fact able to achieve what I wanted.

It may be that the following is already possible, but I only do not know how. Although, I do not think so, because it is not about the file renaming, but about the file time stamp manipulation...

I am using Siren to rename and copy Jpg-Files into new directories, based on Exif data. I am not simply moving and renaming files, but copying and renaming files, as I want to be sure that everything is as expected on destination, before I delete the originals.

Since files are - technically - created on destination, their "Created time stamp" bears the time of this operation. I would however very much like their "Created time stamp" to stay the same as that of the original file (i.e. that directly after the copy process the created time stamp be manipulated by Sirene, either by writing the original "Created time stamp", or "Modified time stamp", all as options).

Maybe this would be possible to add, as an option.

Thank you for considering and thank you for your marvellous program!
Borut