More > JRiver Media Center 20 for Windows

Examples of the new LOAD and SAVE functions?

<< < (2/7) > >>

mark_h:

--- Quote from: MrC on April 25, 2012, 12:28:13 pm ---FYI: here is mark_h's thread.  I think the thread assumes an ordered execution, updating of smartlists, and variable assignment:

  1) run smartlist
  2) grab some field from single entry in that list
  3) assign it to a GV
  4) run another smartlist based upon this GV

There's probably a more direct route to solving this particular case.

--- End quote ---

Yes, that's exactly what I want to do.  There are loads of things I'd like to do but require such functionality.

It'd be great if the contents of the save() variable were available to ANY expression once save()'d

rick.ca:

--- Quote ---It'd be great if the contents of the save() variable were available to ANY expression once save()'d
--- End quote ---

+1

Would there be in any harm in saving variables to the Library so they can be, in effect, permanent? I suppose there would have to be an accompanying tool (in Options?) for cleaning up messes: Clear saved variables. And maybe a List saved variables for troubleshooting. :-\

MrC:
One can almost think about the various File Locations as being a specialized case of this.  And calculated Fields w/static values.  Maybe this could be extended and generalized.

I use an [fCoverArt] field for cover art base directory for inside expressions so I don't have to hard code paths.  But it feels wrong to be a per-record field, when really it is a global var like File Location settings.

Matt:
Next build:
Changed: Expression variables used with Load(...) and Save(...) are global, and valid for the run of the program.

However, I reserve the right to back-track on the first sign of trouble.

The change is trivial, but I don't love it for two reasons:
1) The expression compiler can't optimize variables like it can constants since they can change every run (and since they're global, there's some overhead for locking).
2) Sharing a global variable space is not a reliable thing to do in a highly threaded environment like Media Center (for example, someone browsing with Gizmo could clobber variables that you're using while browsing locally -- it won't crash, but the results will be undefined)



--- Quote from: MrC on April 25, 2012, 02:32:32 pm ---I use an [fCoverArt] field for cover art base directory for inside expressions so I don't have to hard code paths.  But it feels wrong to be a per-record field, when really it is a global var like File Location settings.

--- End quote ---

I agree it's weird, but it isn't storing anything per-record.  And it has the advantage that the expression compiler knows it's static.

I suppose a list of constants would be more elegant.

rick.ca:
Obviously variables can be set by any expression that needs them, but I was thinking it might be more convenient if they could be set more like 'environment variables'—so certain constants are always available to any expression. I still haven't decided what I might use this for, but this is what I came up with...

Navigation

[0] Message Index

[#] Next page

[*] Previous page