Suggestion: Add an "OR" operator to FIELDS input of actions

It is my impression that to apply a set of rules in actions to more than one tag field, one has to create multiply actions sets or use _TAG. However and often, _TAG is too indiscriminate and affects tags that should not be changed.

Scenario:
You have a series of 10+ rules to apply to ARTIST but want to apply the identical set to ALBUMARTIST, TITLE, COMPOSER, BAND, COMPOSER, LYRICIST and their ~SORTs but not touch all other tag fields.

Instead of…
[#13]
T=4
F=ARTIST
1=(^\\s+|\\s+$)
2=
3=0

There would be…
[#13]
T=4
F=ARTIST|ARTISTSORT|TITLE|TITLESORT|…
1=(^\\s+|\\s+$)
2=
3=0

  • Note: This example is only for illustrative purposes.

Florian,
An alternative approach (or maybe in addition) is to provide the means to lock some field ids from being edit when the _TAG is used. This might be easier and quicker to implement.

Thanks.

I think that the example you gave could be dealt with the idea given in this thread:
/t/9138/1

Other than this concrete application of trimming I can hardly think of actions that deal with so many fields or have to be limited to a set of fields (e.g. replacing Umlauts and things).
The trimming probably does not work on filenames if you have composed the old filename with bits and pieces from now trimmed fields. The additional spaces will probably remain inside the string.

Thanks for the input, Ohrenkino. However, I think you may have misunderstood the "feature suggestion."

To reiterate, the suggestion for development is to add operators to the "fields" input of actions. At least, an "OR" would be good, represented by a pipe/bar. You would be surprised how complexed the use of actions can be. It just depends on your needs.

Nonetheless, Florian should have a similar function in the code as _TAG does something similar (enumerate the used field ids > run regex or other functions on those until n=0). Add to that, read the input and separate field ids at the pipes, then run the functions on each until n=0.

What are the advantages you might ask. Well, if a user needs to tweak a process, they would only edit one action as opposed to many similar ones. Therefore, one point of failure.

The link you provided appears to be about reg-exp.

I think it should be an "AND".

If you look at a tag (see picture)


then you do not have to know anything about the field name but simply treat everything in inverted commas.

The example was about trimming more or less all fields without the need to name them all.
See also the $trim() function.


I am sorry Ohrenkino, this post was moved from development to the general discussion section of the forum. There might me a very tiny chance I mis-posted. We humans are error prone. This was not a plea for assistance, per se. Unless, there do exist some novel method/approach to apply one action to many user selected fields … in one go.

Your response suggest that you did not understand the issue fully.

Any boolean operation is appropriate: OR or AND is relative to how the process is written. 1) Find in "A OR B OR C and do X" or 2) Pool "A AND B AND C then do X." That is minutia. Just looking for the ability to apply to multiple field ids in one shot. All or one at a time, is stark.

Florian, please consider the value of the proposition. Thanks.

This is what I understood:
You tried to apply an action of the same type with the same parameters to a number of fields.
You found that creating action after action for a different field but with the same action parameters is (too) tedious.
The idea I understood was the option to enter more than one field in the field selector.
So far so good.

The example you gave to illustrate the necessity was about reducing the number of space characters in more or less all fields.

For this specific problem there is a solution documented in the link I included in one of my earlier posts. You could use that solution straight away without any delay until the suggested feature is implemented.
The unanswered question is still: if there is a (different than the suggested) solution (for the problem in your example to reduce the number of space characters in fields) do you still need the suggested feature, and if: please tell us the yet unsolved problem.
This would help to consider the value of the proposition.

I tried to save you some time in stating that this was not a plea for assistance. You have re-stated my request somewhat fairly. It's the … therefore leap that is in error, I think.

  1. Please note: The example is only that; it is used for illustration only. There is no "problem" with trimming. The Mp3tag provides more than one approach for that. Cool? Cool. Let's bury this.

  2. The suggestion for "development" is to add the ability to apply Mp3tag actions to "more than one user-selected fields" by extending the field input to accept some boolean matching—OR and NOT. Mp3tag already does so with "Remove fields" action which uses the ";" delimiter to match either-or fields.

Or, as I recently added, to globally protect/lock user selected frames from being processed by the _TAG. _TAG should come with a warning when frames are being edited.

Thanks Ohrenkino. Your responses are appreciated. Be well.