Function to reverse Filter

Hello

I would like to propose two things:

1] A feature of reversing the filter search, by clicking on an icon

If one uses a short expression like

title HAS "ABC"

it's easy to reverse the search by writing

NOT title HAS "ABC"

But when you have something like

$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 1

then without a proper knowledge you will be lost in that code

I am aware of that it may be near to impossible, to write into the code of Mp3tag all the ready-to-use-negatives, or whatever you ma call it. Or that some expressions may even not it's negatives at all. But there could be a very simple workaround. Because Mp3tag could act like this:
a] users puts the expression in the filter
b] users clicks the button
c] Mp3tag creates a temporary file with all the loaded files
d] Mp3tag creates a temporary file with all the loaded files visible at the given moment with the filter working
e] Mp3tag compares both files and displays only the files not present on the second list

And an even more advenced feature would allow the search within the search [create another reverse list from first reverse list]. And also would make it possible to save a search under for example number from 1 to 10, do that the user could quick and easily compare different searches done at his files. [History of searches is not handy like that]

This idea came to me near the end of this topic: Filter reverse

2] It would be much easier to write and read in the filter field all those complicated codes like the aforementioned one

$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 1

with different colors in it; just like you can see codes in this forum

[I've put the code i CODEBOX, but the colors / formatting didn't show up; just the code as ordinary text in the box itself, as you can see]

This was implemented in earlier versions of Mp3tag, but has been changed, and I do not miss it.

The proper knowledge is laid down in the Mp3tag help manual, and even more special refinements are buried here in the Forum.

For your example ...
"$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 1
... the inversion is ...
NOT "$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 1
... or ...
"$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 0

DD.20150226.0855.CET

As soon as you enter the world of true expressions like
%_filename_ext% HAS "jpg" AND NOT %_filename% HAS Cover AND NOT %_filename% IS folder
it is not clear, what a filter-inverter would do. Invert the first, second or third expression? Or all?
Probably all.
Having such a powerful query language at hand will enable you to pinpoint more or less any set of data.
Actually, the option to search through a set of records would not be necessary if you expand the filter expression with the search term.
This has the discrete charme that you do not have to hop through a lengthy list but you see at one glance (at the bottom in the status bar) how many hits you would have got.
It is a different concept to e.g. searches in word processing but once you get the hang of it you will see the benefits.

Every additional click or keyborad stroke is just... another click or stroke

Now that a different file creation was reworked

can my idea somehow be built utilizing the mechanisms of those [upgraded Library] processes?


But come to think of it: if Library back then was using a temporary file - then why cannot there be such temporary file created when a search is done? And then used quickly for an immediate reverse search?

I don't understand.

What does

help to do

?
A "reverse search" would still be a new process and require just as much effort and resources as the first one.
And to get this straight: filtering is not searching.
Filtering presents a list of items that match the current filter criteria.
A search hops from hit to hit (and depending on the program you do not know how many hits there are still to come and how many you already visited).

This comes down to this:

Right now

you filter > you wait > you see something [or nothing] on the list files

And at this point a file could be created. And with such file you press a button and see the opposite- all that was hidden from you, thus hiding everything that was shown to you when the filtering expression was chewed bythe Mp3tag [sometimes you will see everything]


Of course if files are then somehow manipulated then it starts to break down. But such break down are [unfortunately] achievable also by other means

I still don't understand what the contents and purpose of a "file" should be. I only see a list.
The only button I can press in the context of the filter is F3 to toggle it - and if it switches off the filter, I see the complete list of loaded files again.
Perhaps you explain how you think the filtering works, where you see the creation of a file and where the "reverse" information should come from.

And all this please suitable also for collections that include more than 100,000 files and also for filter expressions that feature not only a single criterion but several like

because that is what the current implementation already does.

Is it really so hard to understand?


Here is a breakdown of the proposed process:

1] There are 10 000 files

2] User loads up them to Mp3tag

3] User uses Filter box with some complex expression; it takes a noticeable amount of time to see the
list narrowed down

4] With this new function: a file is created. It breaks those 100 00 files into two groups: those who are shown with this expression and those who are not. It does not even to be a file- this two lists can be stored in RAM [I suppose]

5] With this new function: user clicks an icon and sees the other group, hiding the files that were shown when the expression was entered

6] With this new function: user clicks and icon and once again sees the list narrowed down by the expression


Is it really so hard to imagine? And to see that without that new function, step 5 would require [in case of complex expressions] a time consuming writing down a whole new code, prone to errors? Or would require joggling with playlists- which first would have to saved as files and then time after time loaded up?

What?
You replace a "1" with a "0" as you know from this post

You add a NOT or remove it. If adding or removing 3 letters is error prone ...

You still have not answered what the "reverse" filter should be of a (more) complex filter, here is the example for the 3rd time:

Also an added button to "reverse" the filter would make it more difficult to interpret the result: If you enter a "NOT" and simultaneously have activated the "reverse" function, it works like the "positive" - easy to overlook and definitly not a "filter upgrade".
And as you are a friend of a straightforward to be used user interface I think you would agree that this double negation would be a throwback.

Ah yes,

I don't know how many files you treat. For my collection the library alone has some 3.4 GB.
So after filtering I would have two files which at least sum up to 3.4 GB? And loading this file would then speed up things....
I seriously doubt that. And

is not really feasible for the 32-bit application Mp3tag that can address a maximum of 4GB.
Putting it all together means for me that your suggestion is a valid suggestion but it is no real improvement of the handling and hits fairly soon other boundaries that render the new feature useless.

Well, that might be true for even complex ones where you have at the end IS with 0 or 1

But

in case of
(((GENRE MATCHES "●D\d+") AND NOT (GENRE MATCHES "●\d+")) OR (NOT (GENRE MATCHES "●(D\d+)") AND (GENRE MATCHES "●(2|T)")) OR (NOT (GENRE MATCHES "●D\d+") AND (GENRE MATCHES "●T")) OR ((GENRE MATCHES "●D\d+") AND (GENRE MATCHES "●2") AND NOT (GENRE MATCHES "●T")) OR ((GENRE MATCHES "●D\d+") AND (GENRE MATCHES "●T") AND NOT (GENRE MATCHES "●2"))) OR (NOT (GENRE MATCHES "●D\d+") AND NOT (GENRE MATCHES "●2") AND NOT (GENRE MATCHES "●2") AND (GENRE MATCHES "●\D+$"))
would be put where exactly?

And that where in that specific example is not important here; I do not need that information or knowledge how to do it for that code right now. The issue is: the time it will take the user to chew through something like this is more that a single click of a button. And most of the users will not indulge themselves in such tasks, as most users are not skilled programmers

I have no covers in my files so I cannot test this, so to know exactly what it does

But I can give an answer like this: as not every filtering expression returns data [files being visible on the list], a reverse button could not always work

And I think I need to emphasize: not a reverse button where reverse means manipulating the filtering code but reverse button where reverse means showing the other portion of files currently loaded up to Mp3tag


How does Mp3tag works when a filtering expression is entered: files that do not succumb to that expression are removed? No, they are still present. So what would be the problem in:
1] Adding a temporary number to each file when it is loaded to Mp3tag?
2] Mp3tag taking notice of which numbers [i.e. files] are shown when filtering expression is entered?
3] Mp3tag showing all of the other numbers [files] when a reverse button is pressed, hiding at the same time the ones from the first group?

I admit: it is easy in for example FreeCommander to overlook that a Quick Filter is showing filtered items; which is something of a equivalent to Filter Box in Mp3tag. And that is why I configured it there to show me the whole main window [a Panel] in red- so that I will be impossible not to notice this special mode being turned on

If the Filtering Box would gain a red contour you would still not see it? Or if the black text on white space be switched to black on white? [Yes, I know: this would also require new more updates / options]

I see white box: I know I see what the code in the filter says
I see red [or whatever indication]: I know I see the opposite of what the code in the filter says

I do not use Library function so I am unable to speak of it from experience. But from what you are saying I understand that it creates large files - that would make my proposed option inconvenient to be used i combination with it

I have now under 15 000 files. The 100 000 number was chosen by me because it takes Mp3tag longer to apply any filtering code to it than to e.g. 10 000 files- so that it would be seen as larger advantage to be able to just click the reverse option than to write down the opposite code. And may I remind you, when Auto-apply is turned on, when you write down then the filtering already happens- and so to prevent it, the user would have to turn it off. And that is just another of those little annoying things

But do you see a similarity here? I have a relatively low number of files- so I do not really have to turn off the Auto-apply. But if I were to have 150 000 files then by default I would most likely run my Mp3tag with the Auto-apply being turned off. And so my proposed option might not be for every user / set o files - but it would be the user who would decide if to use it. Just like it is now in case of the Auto-apply

Now that is a vital information, that shows even to no programmers like me what would have to be done first in order to make such option valid for larger sets of files

And so on that basis alone I can concur with conclusion that my proposition

but not as much as useless but incapable of working as intended

Your answer contained at least on question that I would like to answer

Answer: around the whole expression: NOT (...expression)
This has the discrete charme that it does not need a red box or something to point out that "what you see is not what have entered" and as you say

That should be enough.

In respect to the numbers I have some questions:
What is the criterion of numbering them?
The loading order?
The current sorting order?
What happens if you sort that list by a different criterion?
Do the numbers cling to the original file or do they stay in the list position?
What happens when you press the "reverse button" to files that have been editted so that they do not match the "positive" filter any more but should belong to the "reverse" list?
Will the "reverse" list be updated with editted files?
What is the purpose of the numbers anyway?
Should I memorize the numbers so that I know which file was in which list?
Should I scan through lengthy lists to see where there is a gap?

Or to come back to the already existing functions:
It is already today an easy task to modify a filter to get the reverse result.
The current filter function works with simple and with complex expressions and (together with the library) works also for collections with more than 100,000 files.
The current filter function is fast esp. together with the library and gives more or less immediate feedback what the applied filter does.

The moment a file is loaded up it should gain a number- and that is it

If you somehow sort them out, the sort order would hold out- just like it does now whenever you enter anything into Filter box; does it not?

And if you in Mp3tag delete or remove a file temporarily numbered 125- then it is simply removed from that temporary list. And then when you add a new one- then it becomes [e.g.] "file #10001" and not "file #125 but new" [or it could indeed take the now missing number - but that is for the programmer to decide what would work better]

When you go back from using reverse to normal- the filter expression is then either applied once more [which could take time, which would be a downside] or the positive [normal] files are shown from the memory / list- and that choice behavior could be configurable as well [just like in case of Auto-apply option being turned on / off]. That second option would of course show then also the missing files- so it would misinform the user

But such ghost / blank files already are capable of existing in Mp3tag. Here is a proof:

Reverse would always be created when filtering expression would be entered or changed. With 100 000 files it will take time- so some kind of progress bar indicating that would make it possible for the use to see if the reverse is ready to be pushed. Or instead of progress bar a simple grayed out Reverse button turning green [or whatever other color / form]] would tell the same thing

Do you memorize the FILENAMEs of what you drag and drop to Mp3tag in order to be able to filter them later on?

Purpose of number? To id them. So that the Mp3tag would now that file #567 was not shown when filtering expression was entered- which would automatically mean that when the reverse option is activated, file 567 is to be shown. [And to avoid another question] When another expression would be entered, that file would still have this number. And if this time it would show in the normal mode, then it would be not as much as removed from the list- but the list would be created from scratch- is it not what now is happening: you change expression in the Filter box thus you change the outcome shown in the main window. The difference is that now a list [be it for positives or negatives] is not created in a form of file