Author Topic: Additional Tagging & Reporting Tools  (Read 917196 times)

boroda

  • Sr. Member
  • ****
  • Posts: 4595
Ah, ok, that explains it - my mistake, I didn't expect that.  I imagine you'll get a lot of confused users by this method, no matter how simplistically you try explaining the difference between an applied logical conjunction and disjunction.  Sometimes rigorous logic is not a good thing when dealing with... people.  ;)
yes, it may be hard to explain the difference between conjunction vs disjunction a person with no mathematical background.

It's also the opposite of how the previous multi-checkbox filtering worked.  
no, filters always worked this way.

Most people would "expect" a cummulative system (i.e., all filters selected == no filters selected, regardless of logical "conflicts").
maybe, but cumulative system makes almost no sense for preset filtering (imho).

-------------

i've changed ALR UI/UX to make it more consistent and logical in respect to preset creating, saving new preset, saving (updating) existing preset, and deleting preset. also, it behaves more similar to ASR now.

also, i've changed coloring algorithms for ASR/ALR again.

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file
Last Edit: January 31, 2023, 02:19:31 PM by boroda

Messiaen

  • Jr. Member
  • **
  • Posts: 103
no, filters always worked this way.
Sometimes I wonder about my brain... I just checked the version from last week, and (obviously) you're right.  Pay me no mind; I wasn't testing with my regular collection of presets before, so I didn't have enough of the varying types to see the distinction.  I need a holiday.

i've changed ALR UI/UX to make it more consistent and logical in respect to preset creating, saving new preset, saving (updating) existing preset, and deleting preset. also, it behaves more similar to ASR now.
Much improved.  The only small thing I can see (in ALR) is that checking/unchecking a preset's "Apply on Startup" status doesn't seem to count as a "changed setting" as far as closing the window is concerned.  Not a big deal - almost all of mine only ever need to be run once, so I bind them to hotkeys using the ASR bridge anyway.  However, since now checking an ASR preset's Auto-Apply status seems to result in extra Bells-&-Whistles (I'm assuming to draw extra attention to it?), that's a behavioural mismatch.

Messiaen

  • Jr. Member
  • **
  • Posts: 103
Oh, and for simplicity, you might shorten the ALR "Calculate ticked presets at startup..." to just say "Apply ticked presets to custom tags on startup" (and roughly the same for the "every 100 changes" option), leaving out the whole "calculate" and "aggregated functions" phrasing.

While the word "aggregated" is technically more accurate to describe what a preset is, it's a rather uncommon word in English, except in mathematical-set theory, and/or geology classes, so it would only serve to confuse people.  Once someone has created a working preset, the rest is reasonably self-explanatory (I would think?).
Last Edit: January 31, 2023, 05:59:59 PM by Messiaen


boroda

  • Sr. Member
  • ****
  • Posts: 4595
The only small thing I can see (in ALR) is that checking/unchecking a preset's "Apply on Startup" status doesn't seem to count as a "changed setting" as far as closing the window is concerned.

it's intentional. preset list is blocked (and presets can't be ticked/unticked) if ALR detects any modification until you click "save preset" or "undo changes".

btw. i've renamed the button "discard changes" to "undo changes". the meaning is the same, but i guess that new wording is better.

Oh, and for simplicity, you might shorten the ALR "Calculate ticked presets at startup..." to just say "Apply ticked presets to custom tags on startup" (and roughly the same for the "every 100 changes" option), leaving out the whole "calculate" and "aggregated functions" phrasing.

you are right, my phrasing was too sophisticated and confusing for most users. i've renamed these labels.

---

i've changed ASR filters tool tips to make it more clear that all filters are applied simultaneously, if several filters are checked.

now preset combo box displays the text "(Mixed filters)" instead of empty field, if several filters are checked.

---

i guess that all necessary UI/UX updates are done now. still waiting @phred for suggestions on updated readme. then i'll change readme files in plugin .zip, 1st post on this topic, and add-on page.

---

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

phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9299
i guess that all necessary UI/UX updates are done now. still waiting @phred for suggestions on updated readme. then i'll change readme files in plugin .zip, 1st post on this topic, and add-on page.
@boroda- do you have the last revision I did? If so, can you PM it to me? Or post it here, if you wish. If you don't have it, can you get me the last one -you- did?

I'll have some time towards the end of the week to look it over, ask you questions, and get it done.

Thanks.
Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

Messiaen

  • Jr. Member
  • **
  • Posts: 103
preset list is blocked (and presets can't be ticked/unticked) if ALR detects any modification until you click "save preset" or "undo changes".
Unless you tick/untick ALR presets before you do any edits to them.  Just open the window, tick one or more (it takes two clicks), then close the window.  The "changes" are saved automatically, but there's no indication that a change happened.  This is not especially important, but I point it out as an inconsistency.

boroda

  • Sr. Member
  • ****
  • Posts: 4595
preset list is blocked (and presets can't be ticked/unticked) if ALR detects any modification until you click "save preset" or "undo changes".
Unless you tick/untick ALR presets before you do any edits to them.  Just open the window, tick one or more (it takes two clicks), then close the window.  The "changes" are saved automatically, but there's no indication that a change happened.  This is not especially important, but I point it out as an inconsistency.
you are right. at the moment, there is only one variable to store "some modifications are made" state, which blocks the preset list. i simply could add another variable "preset checked states are changed".

boroda

  • Sr. Member
  • ****
  • Posts: 4595
i guess that all necessary UI/UX updates are done now. still waiting @phred for suggestions on updated readme. then i'll change readme files in plugin .zip, 1st post on this topic, and add-on page.
@boroda- do you have the last revision I did? If so, can you PM it to me? Or post it here, if you wish. If you don't have it, can you get me the last one -you- did?

I'll have some time towards the end of the week to look it over, ask you questions, and get it done.

Thanks.
i think, no. the latest readme version i have is very old. here what i have now:

https://www.mediafire.com/file/xw1y91qr66id89r/README_FIRST%2521.txt/file

but ASR behavior have been changed since the time this readme version have been written. here is the current ASR behavior, which is different from described in readme:

----

process of preset installing is changed: "install new" will always silently update all (customized or not, but only if there are new versions of installed presets, or new presets have been added to plugin zip since presets have been installed/updated last time) predefined presets, always preserving all customizations. 'install all' will ask the user (ask, only if some presets are customized) if he wants to reinstall all unchanged and update all modified by plugin developer presets resetting all customizations, or preserving all customizations. 'install all' will always install presets not existing among working presets (i.e. new or previously deleted by user presets), and always reinstall/update all not customized presets.

reinstallation of unchanged presets (only when performing 'install all' command) may be useful if some working predefined presets (not presets located in "plugins\asr presets" folder - "local preset repository" - i'm, actually, not sure how these presets must be named) are somehow damaged (or if user wants to reset all customizations).

----

this warning must be inserted to readme:

Be careful to not ACCIDENTALLY tick some "Advanced Search & Replace" preset(s) for AUTOMATIC APPLYING!  there will be a reddish (color near to red) warning message at the top of ASR window, if you have any ASR presets ticked for auto-applying.

----

i think that the following explanation (but very shortened and simplified) must be mentioned in readme:

user preset (no matter how it has been created - from scratch or by copying predefined preset) doesn't relate anymore to any other (e.g. predefined) preset. user has full control over user preset, can completely change (edit) it, and user preset will never be affected by any deletion/(re)installation/updating of predefined presets.

customized preset is always a tiny modification (only allowed by me modification) of predefined preset (and only predefined preset) made by user. it's not a new copy of preset, and it's still predefined preset. user can reset all customizations of all predefined presets by clicking "install all" button, and clicking "yes" in the following confirmation dialog.

----

all the text i've written above is just a draft. it's not suitable for final readme.

so, could you (and maybe @hiccup and @Messiaen) make the whole readme as much simple and clear for not advanced users as it possible?

and, of course, the big problem personally for me is that the english readme text must "sound" naturally for natives (without using awkward and uncommon words/phrases).

phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9299
Thanks boroda.

I've got what I need to get started. I should have something for your review Friday or Saturday, if not before.
Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

boroda

  • Sr. Member
  • ****
  • Posts: 4595
i've merged ALR and LR commands into one LR command. united LR command code is almost written from scratch. new LR code must be much more efficient and fast. new LR window looks/behaves more similar to ASR window.

$ALR(<URL>,function_id) virtual tag function is renamed to $LR(<URL>,function_id).

@hiccup, please update your cheatsheet.

BE CAREFUL! YOU WILL LOSE ALL ALR/LR PRESETS ON PLUGIN UPDATE AND MUST RECREATE THEM.

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

boroda

  • Sr. Member
  • ****
  • Posts: 4595
i've added a download link to the latest plugin .zip at the top of the 1st post of this topic, and at the top of the add-on page.

boroda

  • Sr. Member
  • ****
  • Posts: 4595
forgot to mention: new LR command allows assigning hotkeys to LR presets. hotkey can apply a preset to the entire library or to selected tracks only.

Messiaen

  • Jr. Member
  • **
  • Posts: 103
BE CAREFUL! YOU WILL LOSE ALL ALR/LR PRESETS ON PLUGIN UPDATE AND MUST RECREATE THEM.
Thanks for that. <Heavy, smothering, doom-laden sarcasm>

I don't seem to be able to assign $LR ID's to custom presets.  The text field accepts input, I click the "Assign" button next to it, and Save the preset - except when I reopen the ALR window and click on the preset to edit it, the ID text-field is empty, so it doesn't stick.  And obviously trying to execute the $LR function results in the curiously helpful "Incorrect $LR() ID!" being assigned to the custom tag instead.

And I'm sure we discussed this before, but why do those Assign/Unassign buttons even exist?  Logic suggests that if there's text in the field when the preset is saved, it should be considered assigned, and likewise, if the field is blank, then the ID is considered unassigned when saved.  (Also, if you insist on keeping those buttons, their current tooltips still include that deprecated "Aggregated Function" text.)

<Superficial comments>
Why are the default preset names in all capital letters?  Weird.  Also, since the listview only really allows 6 presets to be displayed (before needing to scroll down), it's awkward that the default ones take up 4 of those slots - I can't even override the sort order (like I can with ASR presets) by prefixing a "_" to my custom preset names.
</Superficial comments>

boroda

  • Sr. Member
  • ****
  • Posts: 4595
BE CAREFUL! YOU WILL LOSE ALL ALR/LR PRESETS ON PLUGIN UPDATE AND MUST RECREATE THEM.
Thanks for that. <Heavy, smothering, doom-laden sarcasm>

hmm, i didn't think that somebody has more than a couple of custom presets, so haven't implemented preset migration mechanism. sorry.

I don't seem to be able to assign $LR ID's to custom presets.  The text field accepts input, I click the "Assign" button next to it, and Save the preset - except when I reopen the ALR window and click on the preset to edit it, the ID text-field is empty, so it doesn't stick.  And obviously trying to execute the $LR function results in the curiously helpful "Incorrect $LR() ID!" being assigned to the custom tag instead.

there was a blunder related to saved function id loading to LR GUI. i've fixed it. but ids are saved as they should, and $LR function is working fine on my machine. though i'd uploaded the plugin several times during last night, maybe i've already fixed this bug. in any case, download the latest version.

And I'm sure we discussed this before, but why do those Assign/Unassign buttons even exist?  Logic suggests that if there's text in the field when the preset is saved, it should be considered assigned, and likewise, if the field is blank, then the ID is considered unassigned when saved.  (Also, if you insist on keeping those buttons, their current tooltips still include that deprecated "Aggregated Function" text.)

"clear id" button was always in place. i had a good reason for adding "assign id" button during ALR/LR merging, but at the moment i agree that it's residual. i'll remove it.

Why are the default preset names in all capital letters?  Weird.  Also, since the listview only really allows 6 presets to be displayed (before needing to scroll down), it's awkward that the default ones take up 4 of those slots - I can't even override the sort order (like I can with ASR presets) by prefixing a "_" to my custom preset names.

i'll enlarge vertical size of preset list.