Additional Tagging & Reporting Tools

[Tinidazone]

Thanks again for the guidance

This one almost worked, except not to the intention I wanted


Expectation: the "-" should replace the "("
so in the end the result would have been [  Boundaries - DRAMA Remix ]  NOT [ Boundaries DRAMA - Remix]

PS. Only if the title contains Remix this code should work, not if the title contains ( or ). Because there are other songs that contain ( or ) but not the word "remix" and they should not be touched with this Preset

[boroda]

ok, change replace field to

Code

- $2Remix

you can copy this exact string (including all required spaces) by clicking "copy" pictogram on the right.

p.s. you might want to change search field to

Code

\s*\((.*)Remix\)$

and replace field to

Code

 - $1Remix

if you also want to take into account tags like [  Boundaries (Remix) ] , not only [  Boundaries (DRAMA Remix) ].

[Tinidazone]

ok, change replace field to

Code

- $2Remix

you can copy this exact string (including all required spaces) by clicking "copy" pictogram on the right.

Perfect. This one is perfect complete. Thanks 🙏

I am trying to find a way to design an UI for this plugin . to improve the UI (less coding more buttons). I will give a feedback once i have sketched something

[boroda]

i've changed my previous post when you were replying, reread it.

[boroda]

I am trying to find a way to design an UI for this plugin . to improve the UI (less coding more buttons). I will give a feedback once i have sketched something

thanks for this. any good ideas on UI/UX improvement are welcome.

[Tinidazone]

i've changed my previous post when you were replying, reread it.

I had to create another Preseset to understand it - i didn't see what it was supposed to do
But
If it was to help with the Album name -  thanks 🙏I prefer to leave it as it came

[boroda]

that preset can be applied to any tag which values can be [  Boundaries (Remix) ] OR [  Boundaries (DRAMA Remix) ], e.g. to album name, and will ignore tag values (won't change tags), which don't have either of these patterns.

[Messiaen]

Just discovered an odd bug from the stock Transliterate to ASCII preset.  If the preset is applied to the following title (note the unicode quotation marks and the unicode hyphen character):

Grave, ma non troppo tratto (“Muß es sein ”) – Allegro (“Es muß sein !”)

the returned title becomes:

Grave, ma non troppo tratto ("Muss es sein " – Allegro (“Es muß sein !”))

The first text ("Muss es sein " is converted (up to and including the closing quotation mark) as expected, but the following close-parenthesis is somehow transferred to the end of the text, and none of the other characters are transliterated.

It appears the $TransliterateToAscii() function via the plugin is not at fault - it returns the expected result, so it appears AT&RT's parsing might be the culprit.  I don't usually use this preset, so I don't know what other text (if any) might trigger it, I just noticed this as a fluke, and saw it was reproducible.

[boroda]

Just discovered an odd bug from the stock Transliterate to ASCII preset.  If the preset is applied to the following title (note the unicode quotation marks and the unicode hyphen character):

Grave, ma non troppo tratto (“Muß es sein ”) – Allegro (“Es muß sein !”)

the returned title becomes:

Grave, ma non troppo tratto ("Muss es sein " – Allegro (“Es muß sein !”))

thanks a lot for this notification. have forgotten to change this preset, when had introduced new \@eval[[]] behavior:

i've fixed another \@eval[[]] bug related to tag values containing quotes. Now, if you want to pass a string to a virtual tag function as is, you must put it in DOUBLE quotes, e.g.

\@eval[[$IsNull(""$1"",,NULL,,$1)]]

instead of

\@eval[[$IsNull("$1",,NULL,,$1)]].

the updated preset (nothing else is changed):

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file

[Messiaen]

Thanks.  Now I'm kicking myself for not checking the preset myself - I thought to check the function, just not the preset itself.  So much for the thin veneer of cleverness in my disguise. 

If I may, a suggestion to mull over... I know it may be too much trouble to implement, given AT&RT "targeted nature" towards presets working on specific tags, but in MB 's <Ctrl-R> search/replace, the first tag in the list to choose from is "Any Field", and I've found that to be extremely useful recently.  Obviously, ASR presets can be made to reference many tags in one preset, but it still requires one to anticipate which fields are most likely.

For certain kinds of presets such as the clean-up type (like replacing multiple spaces with single space or whitespace trimming, etc), this sort of any-field thing is ideal.  However, I haven't thought it through enough to know if it's got broader appeal than just that (admittedly useful) example.

What do you think?

(And I must thank Hiccup for his most recent suggestion about changing the "Some presets have changed" behavior - just in the last week alone I must have breezily clicked though that modal enough times to make even the pope doubt his faith.  Why wasn't it suggested years ago?  A Godsend.)

[boroda]

in MB 's <Ctrl-R> search/replace, the first tag in the list to choose from is "Any Field", and I've found that to be extremely useful recently.  Obviously, ASR presets can be made to reference many tags in one preset, but it still requires one to anticipate which fields are most likely.
...
What do you think?

well, it's possible, but it's not so easy, because it will require not only to iterate through all writable tags, but also to force the destination tag to be always the same as the source tag, and only if the source (pseudo)tag is set to <any tag>. UI behavior must be changed for this too.

i'm not sure if this functionality is really needed in the context of ASR (considering that it's already supported by mb native search & replace). maybe it's worth to wait for responses of other users?

Why wasn't it suggested years ago?

maybe, because this dialog (even in its initial form) has been implemented recently?  

[hiccup]

… And I must thank Hiccup for his most recent suggestion about changing the "Some presets have changed" behavior - just in the last week alone I must have breezily clicked though that modal enough times to make even the pope doubt his faith.  Why wasn't it suggested years ago?  A Godsend.)

Good to hear I'm not the only one that appreciates these small (slightly OCD) improvements implemented by boroda.

@boroda:
When using 'Import ASR preset', presets that have the (previous) .xml extension are not shown, nor can be imported in this way.
Is it intentional that you can now only import presets that have the newer asr-preset.xml extension?

[boroda]

@hiccup
yes, i've recently completely removed the support for old format presets. because old presets have been actually very differently implemented, and they have been converted to new format by special function.

@Messiaen
i've added support for <ALL TAGS> pseudo-tag, but it's now experimental. you will need to copy exiting presets(s) and switch types one/more of <tag #> pseudo-tags from "writable" to "writable+<all tags>" in preset editor. you won't be able to select <ALL TAGS> pseudo-tag directly in preset editor, i.e. you won't be able to create preset/copy of preset, which will be defaulted to <ALL TAGS> (for safety reasons). but you will be able to select <ALL TAGS> in <tag #> field in ASR main window.

https://www.mediafire.com/file/r51stg5alaxwmup/mb_TagTools_beta.zip/file

[Messiaen]

...but it's now experimental...

That's the understatement of the century.  It's beginning to dawn on me just how dangerous this option actually is - if combined with auto-organizing it's capable of completely decimating whole albums and sending them in pieces to the four corners of the kingdom.  As such, while it's still experimental, I'd make it harder for people to actually use it, like maybe half-disabling the "apply" button for now and just allowing previews.  It does seem that setting a hotkey to one does not actually apply the results, though the status-bar says it was applied - this may be unintentional, but it's good for safety.  Same caveat would apply to auto-applying - not sure if it works or not, but might be wise to disable that too, just in case.

The "Always preserve these tag values" list is invaluable, to be sure.  If you decide to keep this <All Tags> option permanently, there might need to be a similar list where it's "only apply to" instead, as sometimes the "all" in "all tags" is a bit too many.  

Also, unrelated observation, in the description for "Always preserve" it says to separate the values with ";;" but using two semi-colons actually breaks the list (as in only the first item is preserved, the rest are applied).  It only works as described when using a single semi-colon to separate the list.  You might change that label.

And as Boroda didn't make this clear above, I'll say it: As a warning to anyone else experimenting with this, I can't underscore enough just how unintentionally destructive a command it can be by it's very nature.  Do not mess around with it on part of your living library - for now, only apply it to albums/songs you have no need for.

I shall experiment more, obviously.  I had a few crashes at first, so it's not entirely stable (but I guess you know that).  I didn't want to report the error logs until I can actually reproduce the steps necessary to reliably crash it again.

Thanks for your efforts.  (The idea seemed harmless enough originally... I'm rethinking that a bit now.)

[boroda]

That's the understatement of the century.  It took a little while for me to interpret your description above (not a criticism of your English at all), once I figured out all the qualifications, it makes sense - however, (and read this as a joke, please) "I won't be asking you to give a general lecture on lamda-expressions in the near future".  

actually, i would be very thankful if you rephrased my warning in very clear way in natural english, because this is very important.

like maybe half-disabling the "apply" button completely for now and just allowing previews.  It does seem that setting a hotkey to one does not actually apply the results, though the status-bar says it was applied - this may be unintentional, but it's good for safety.  Same caveat would apply to auto-applying - not sure if it works or not, but might be wise to disable that too, just in case.

that's what i was thinking about yesterday. i'm going to completely disable auto-applying of such presets, explicitly disable hotkeys for them, and disable applying of them without explicitly generating preview at first.