In the
18.0.207 thread, I wrote:
I think I'm seeing a bug when selecting a value in a pane column, when the column values are derived from global variables. First, here's a link to the movie that shows the problem:
https://www.dropbox.com/s/kv9gmv2885mddya/possible%20bug.mp4
Here is how the view is created:
Set rules for file display below. These just initialize two variables to 0, and then later increment either of the variables depending upon the value of the field [Custom]:
[=save(0,exc_[Artist])1]=1 [=save(0,inc_[Artist])1]=1 [=if(isequal([Custom],EXCLUDE), save(math(1 + load(exc_[Artist])),exc_[Artist]), save(math(1 + load(inc_[Artist])),inc_[Artist]))1]=1
The library has two calculated user fields which are defined as:
_v_exc: load(exc_[Artist])
_v_inc: load(inc_[Artist])
The movie shows these in the file list column. It is clear that clicking on them selects the files that produced the cell value. So this works.
The movie also shows that the view has a calculated field - this pane column's expression demonstrates the problem:
math( [_v_exc] & [_v_inc] )
The calculated values are correct - the pane shows both values 0 and 1, as expected, since some of the 90 files have the EXCLUDE keyword in Custom.
However, notice how clicking on either value produces the wrong file list - its all files or no files.
To which Matt replied:
MrC, you're in uncharted territory.
When you pick '1' in your AND expression pane, it's effectively saying "show files that match these two searches":
Code:
[=save(0,exc_[Artist])1]=1 [=save(0,inc_[Artist])1]=1 [=if(isequal([Custom],EXCLUDE), save(math(1 + load(exc_[Artist])),exc_[Artist]), save(math(1 + load(inc_[Artist])),inc_[Artist]))1]=1 [Media Type]=[Video]
[=math( [_v_exc] & [_v_inc] )]=[1]
The search compiler combines searches, sorts token ordering, etc. to help performance. It's not really designed have dependencies that require a deterministic evaluation ordering, which only arise when there are save and load calls.
It's possible we could make the compiler smarter for cases like this.
However, I'm not thrilled with packing up the global variable store like this as it seems like a complex solution. Is there some construct that would allow the same functionality without using variables like that? Feel free to start a thread.
I understand the explanation, and had previous suggested to others that this is how MC might be working. I realize these hack techniques are working by a fortuitous side effect, which has surpassed the limits by trying to impose a deterministic evaluation order. So that's cool. And I entirely agree, the current hacked solutions are far too complex and JRiver probably should spend no time trying to make this work.
Here's my assessment of the desired functionality:
- a way to deterministically evaluate an expression sequence across the list of files
Generally the technique is employed for performing some math/counting, or for string manipulation.
A more straightforward method to accomplish this (removing the gross side effect employed now) would require an ordering to MC's operations with a new intermediate stage:
1) Filter Stage: Set rules for file display (and Search) to filter the list of files
2) New: Post-filter Iteration Stage: Iterates over these resulting files evaluating an expression sequence
3) Display Stage: Presents the generated tokens based on view configuration
Stage (2) would require a loop as such:
Foreach expression
Foreach file
evaluate expression
This order is require so that values can be initialized across all files, and then subsequent calculations performed:
a = 0 (for all files)
a += 1 (for all files)
There are cases when an expression only needs to be run once (e.g. number_of_tracks = 0), and cases where it needs to run for every file (number_of_albums_per_artist). Performance optimizations could be done by providing two evaluation sections or lists:
1. Run Once:
Evaluate run-once expressions
2. Run Always
Foreach run-always expression
Foreach file
evaluate expression
Allowing things like this (non-MC pseudo-code):
1. Run Once:
1a. n_tracks = 0
2. Run Always
2a. n_albums_[artist] = 0 (for each file)
2b. n_albums_[artist]++ (for each file)
Clearly item selection in the view would have to restart the sequence of operations (which MC essentially seems to do already). Selection seems tantamount to filtering via Search.
I have no idea how much impact this has on MC code. But folks want to count things, and aggregate cross-file data. And these folks seem willing to accept a performance penalty for such capabilities.