More > JRiver Media Center 20 for Windows

Examples of the new LOAD and SAVE functions?

<< < (6/7) > >>

MrHaugen:

--- Quote from: mark_h on April 26, 2012, 08:15:23 am ---Next challenge - calculate an album average rating...

--- End quote ---

Oh yea. I've been looking for that for a long time. Would save me a lot of trouble manually add album ratings. This is also connected to things like counters for episodes for series, and how many of them that is left who is not watched. This would be perfect to have in the Info pane for TV Shows. Then you would not have to relay so much on views. As I think I've understood, this cross media file counters is not possible today right?

vagskal:

--- Quote from: MrC on April 27, 2012, 01:37:04 am ---Probably the field/GV is not evaluated until necessary.  You can test for it in the Set Rules for File Display.  That will cause an evaluation.

--- End quote ---

Thanks! Just setting the rules for file display to this works (at least until Matt sees the opportunity to optimize the evaluation engine even further...):
([Field A]=[] or -[Field A]=[])

MrC:
Linking to mark_h's new thread on Calculating Album Average Rating using variables:

   http://yabb.jriver.com/interact/index.php?topic=71790.0

vagskal:
I just wanted to share this discovery of how clever the expression engine is.

The variable name can in fact include functions, since the expression engine recognizes them without any escapement. At first I messed with variable names like varComposerBorn[Composer]ListItem([Composer],0), but later discovered that the expression engine accepts/understands this varComposerBornListItem([Composer],0). And now I can also have fields relational to the "Primary" composer (or the "primary"/first item in any other list type field)!

Sorry if this was obvious to everyone else.

MrC:
Now all we need is self-modifying code.

This is going to bite someone, somehow, someway...

Typically in a language, keywords are isolated and identified by various parsing tokens.  But in MC, the language is looser, and parsing uses the longest match to identify keywords, with function-identification keyed by parenthesis.  Once a pair of parens is identified, the parse tracks backwards to look for functions.  The parsing is context-aware.  So,

   varComposerBornListItem()

gets parsed into:

   varComposerBornListItem()

and the varComposerBorn is just text.  But if you or some user use something like:

  varAlbumReplaceListItem()

anticipating the current behavior, and JRiver adds a new function:

  ReplaceListItem()

guess what happens?

I believe the /# #/ escapements introduced when Regex() was added provide a means to prevent this (but I'm not certain of this, esp. with recent w/inlining changes), and makes the intent clearer:

   varComposerBorn/##/ListItem()

Navigation

[0] Message Index

[#] Next page

[*] Previous page