Messages

1

Plugins / Re: Additional Tagging & Reporting Tools

« on: March 03, 2024, 05:17:56 PM »

well, another try:

And there we go - now all the scrollbars are working/appearing as advertised.  

Thank you.

2

Plugins / Re: Additional Tagging & Reporting Tools

« on: March 03, 2024, 11:47:04 AM »

@Messiaen, what Windows version do you use? also, please check the scroll bars in LR (you'll need to create several dummy/empty presets to see scroll bars).

Oops, yeah, LR seems to suffer this problem too - I just didn't have enough presets to see it.

Standard boring Win10.  (And, just for the record, the issue persists in the version you just uploaded above whilst I was typing.)

3

Plugins / Re: Additional Tagging & Reporting Tools

« on: March 03, 2024, 08:44:18 AM »

please recheck this issue using new version.

BTW, what did you mean by 'most' (except for those doubled scroll bars in ASR)?

Nope, scrollbar issue remains - strange that all the other scrollbars are fine, it's (as far as I have seen) just the main ASR one that's bugged.  Tried switching in and out of "use skin colours", even other skins, but no change.  (I just used the word 'most' because I hadn't tested for all of them at that time - I haven't seen any others in ALR either.)

4

Plugins / Re: Additional Tagging & Reporting Tools

« on: March 02, 2024, 06:41:20 PM »

3. scroll bars are now skinned.

Well, most of the scroll-bars are skinned - the main ASR one seems to have 2 scrollbars now...


And I might add that this last package doesn't seem to contain the usual folder of ASR Presets (for those who may be downloading it for the first time...)

5

Plugins / Re: Additional Tagging & Reporting Tools

« on: January 21, 2024, 07:17:08 AM »

...but all must be working as earlier.

Appears to be fixed on initial testing.  Thanks.

6

Bug Reports / Re: Offset default pointer (dis)placement in modals with "Skin Window Borders"

« on: January 20, 2024, 05:49:02 PM »

You are not crazy Messiaen, this is definitely an existing bug...

Thanks for the confirmation.

To be honest I have been using the same portable install (updated as it goes) for a few years now, so it isn't impossible that something could have become corrupted - as such I spent an hour this afternoon completely rebuilding my setup without using any of my old settings or files.  And... the results were exactly the same.  I'm as sure as I can be that user-settings/plugins aren't a contributing factor, as this is also extant in a default vanilla install.

Thanks again.

7

Plugins / Re: Additional Tagging & Reporting Tools

« on: January 20, 2024, 05:36:55 PM »

Hello. I'm having some trouble with certain keys (backspace, spacebar, arrows, maybe more) not working, while also triggering MB actions in the background.

could you be more specific? i don't understand what you mean.

I have seen this too - it's directly related to the hotkeys the user sets within Preferences -> Hotkeys.  For some reason the plugin window is not "insulated" from them, and MB takes the keystroke despite not having direct focus.

For example, were you to set the spacebar as the hotkey for Playback -> Play/Pause (as many media players do), if the ASR window is open and you are trying to type into a field (say <Custom Text 1> for example), every time you hit <Space> MB grabs the message and starts/pauses the music - but no <Space> character can be entered into the field, since the keystroke is gone.

The only way around it is to disable the keys you want from being hotkeys, so common ones such as <Left>, <Right>, <Back>, etc. can't be used, unless you want to have a lot of trouble in ASR windows.

I reported this once, but you got sidetracked onto other things so it was never looked into, or you couldn't reproduce it for some reason.  Try the above example (of spacebar) and you'll see what I mean.

8

Bug Reports / Re: Offset default pointer (dis)placement in modals with "Skin Window Borders"

« on: January 19, 2024, 10:33:58 PM »

Well, that's odd.  I could of course post a screenshot but it would only show the mouse pointer correctly centered horizontally over the default button, but appearing (consistently) vertically 32 pixels above where it's supposed to be - so there's not much to see.

As I said, this happens for all skins when "Skin Windows Borders" is selected, except the "Windows Theme" which disables that item anyway.  If I manually untick the menu item, everything works fine.

I did try to search for similar complaints, but nothing turned up.  It's not a new problem - I had it on an old Win7 machine, but considering I just re-installed (from scratch) Win10 a couple of weeks ago, it's not a system problem.  I just assumed that most people untick the windows "Mouse Properties -> Pointer Options -> Auto-move pointer to default button in a dialog box" option for some reason.

I have no software running which effects the mouse (default drivers), nor anything which manipulates windows rendering itself (such as Window Blinds, etc.)  I use a single monitor, with DPI at %125.  I originally thought this could somehow be a DPI issue, but it's not - same behaviour at %100.

Just for laughs I just tried nuking my MB settings file (and .bak) but it makes no difference.

Moving the main-menu and/or the command-buttons toolbar in and out of the caption bar makes no difference.  It can't possibly be a coincidence that the vertical offset is exactly the height of the caption bar.

This is absolutely consistent: for example, clicking Tools -> Convert Format the window opens and the pointer moves to above (but not ON) the Proceed button.  If, however, I click on Tools -> Tagging -> Search and Replace the pointer moves to where it's supposed to be, perfectly centered on the Close button.

All that being said, if no one else can reproduce this issue, then I guess it's somehow a local problem, but I don't understand how it could only effect a single programme (MusicBee), and no others, and only when the borders are skinned.

 

I guess I'll just live with it - it's not exactly a huge problem, but it is a strange one.

9

Bug Reports / Offset default pointer (dis)placement in modals with "Skin Window Borders"

« on: January 19, 2024, 02:46:33 PM »

Not sure if this has been mentioned before (there seem to be more posts about skins on this forum than any other topic), but when the borders are set to be skinned, some (not all) popup modal windows place the default mouse position exactly 32 pixels above the default button position, so the mouse pointer is no longer on the button itself.

None-too-curiously, it turns out the header-bar is - wait for it - 32 pixels high.  

This applies to the windows for:

Tools -> Convert Format
Tools -> Tagging Tools -> Renumber Tracks
Tools -> Artwork Downloader
etc...

Strangely, this does not happen for things like Tools -> Tagging Tools -> Search/Replace or even the main MB Options window.

So, for example, what would ordinarily be a simple two-click action like using a toolbar button to convert tracks (once to open the window and again to accept the default settings), means the mouse must be physically moved down before being able to click the Proceed button.

Occurs for all skins. If the "Skin Window Borders" option is unticked, the default mouse positioning acts as expected.

10

Plugins / Re: Additional Tagging & Reporting Tools

« on: December 30, 2023, 07:14:07 AM »

i don't see this issue in the last uploaded plugin version...

You can't see "Incude" instead of "Include"?  It's there whether skinning is on or not...



The rest of the changes are all great at first glance.  Many thanks.

11

Plugins / Re: Additional Tagging & Reporting Tools

« on: December 29, 2023, 07:19:35 PM »

ok, i'll separate the options "use MB font" & "use skin colors".

Thanks.

...isn't it scrollable for you?

It is scrollable, it's just that in one of the more recent updates, the "Ok" button was contained within the scrolling area, and while a bit unorthodox, it worked.  With the last version however, the scrolling only shows up to the "Unit of Billions..." option - if there's supposed to be options/buttons below that one, they aren't displayed, that's why I asked if you removed it.

12

Plugins / Re: Additional Tagging & Reporting Tools

« on: December 28, 2023, 06:20:51 PM »

Plugin uses MusicBee font & skin colors by default now

Long absence ("Real-Life-Stuff"), but some time to play now.

I'm not so sure that coupling the plugin to MB's custom font size is working quite right when DPI is 125%.  Using Win10, if the "default" Segoe UI 9pt is used, all is well, however, increasing that font even by 1 point causes problems.  Segoe UI 10pt (at 125% it actually becomes 10.2), the ASR window expands to below the taskbar, so the "preview" section is mostly cut off.  Worse, the preset editing window extends similarly, so that the "Step 5" controls are completely inaccessible.

Maybe only tie it to any custom font up to 9pt but decouple it for anything over that (if DPI > 100)?  At least the font/skin option can still be turned off for now, so it defaults back to 9pt, albeit with the sickly white default skin colours.

Also, was the "Ok" button intentionally removed from the plugin configuration (Options -> Plugins...)?  Hitting <Enter> seems to apply settings, so it's no great loss, but a dialog with no "Ok" button is just weird...

And, in that same window, in the "result filtering" options section, in the English translation the word "Include" is missing the 'l' letter, on all three lines.

Thanks for your continuing efforts.

13

Plugins / Re: Additional Tagging & Reporting Tools

« on: July 21, 2023, 08:31:07 PM »

...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.)

14

Plugins / Re: Additional Tagging & Reporting Tools

« on: July 19, 2023, 11:14:45 PM »

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.)

15

Plugins / Re: Additional Tagging & Reporting Tools

« on: July 19, 2023, 08:17:25 PM »

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.