Yep. That is why I was asking these and other questions.
I missed that when you said it earlier, but it is an important point. If we were given the option between:
- My original Writable Calculated Fields idea, and...
- The Unify Calculated and User Data Fields proposal outlined above, except that: you can only use it with user-created custom fields and not stock ones
Then I'd take Writable Calculated Fields in a heartbeat.
Because I can't just switch away from those stock fields: I want my files to actually be usable in other applications (the [Artist] tag needs to be set properly so that other applications can see it), and I want to apply it to all of the "personal name" auto-metadata filled fields (like Director, Cinematographer, Actors, etc). Those are my core "designs" and Writable Calculated Fields do not suffer from that restriction.
With that, I think we're back to two proposals:
1. Unify Calculated and User Data field types, as outlined above.
This has two potential issues:
* It requires a little bit of syntactic sugar with the [Field Name,0] notation stuff, which has one edge case when using the new functions.
* It requires that it be possible to apply this change (optionally) to [Artist], [Album], [Actors], [Director], [Composer], and similar built-in stock fields.
But, I do like how easy to understand this idea is, and it does simplify the overall quantity of fields you'd need to create to accomplish some tasks.
2. Writable Calculated Fields. If the second of the two points above fails to meet JRiver's requirements, then this would do all of the same things, and would avoid both of those issues.
It requires no special syntax other than a reference to the User's input in the Input Expression. And you can just use your Write-To User Data field directly when you need to access the raw value (so no mucking with [Field Name,0] required). The major downside is that it requires you to define two fields (a custom Calculated Field, which then writes to a standard User Data Field) instead of one.
Writable Calculated Fields Mock Library Field Manager Implementation:
_Name_ - Unchanged
_Data_
[•] User Data - See Note 1. Radio button (like now)
Data Type [__]
Relational [__]
[✓] Save in file tags (when possible)
[•] Calculated Data - See Note 1. Radio button (like now)
Output Expression - cannot be disabled.
[expression editor] - See Note 2.
[✓] Input Expression - when unchecked, disable indented below
[expression editor] - See Note 3.
Data Storage Field [___] - See Note 4.
Edit Type [__] - Always enabled.
Acceptable Values [__] - Always enabled if User Input is allowed.
_Search_
[✓] Show a Search Link - Always enabled. - Same as above, but I moved it here this time.
(Section otherwise unchanged.)Notes:1. User Data and Calculated Data: These work
exactly as they do now, only the "always available" options are moved out of the "User Data grouping".
2. Output Expression: This is the
exact same thing as the current Calculated Data Expression box, just relabeled Output Expression. Cannot be disabled.
3. Input Expression: This is identical to what was described above. Enter an expression here which is evaluated on any write to the Calculated Field, the results of which are saved to the Data Storage Field. Square-bracket notation [My Field Name] (or alternatively Input() or [Input]) expands to user's input data when the expression is evaluated.
By default when Input Expression is enabled, but left blank, the user-entered data is passed through to the Data Storage Field unmodified (alternatively, you could just pre-fill [My Field Name] in the expression box, which would also probably serve as a handy tutorial tool for users).
If Input Expression is unchecked, then Calculated Fields work
exactly as they do now.*
4. Data Storage Field: This allows you to select a single User Data type field from a drop-down combobox. Other Calculated Fields cannot be selected (preventing loops). The selected field will be transparently used for storage any time data is saved to the Calculated Field, after the input is filtered through the Input Expression (if provided).
* But, one other little thing: If Input Expression is unchecked, please "Read-Only" the star-editors, checkboxes, and whatnot if Edit Type is set to Check, 5-Stars, 10-stars, etc (to be clear, do not disable these options in Edit Type, just make the checkboxes that show up in the Views read-only). I love that we can have a checkbox-style Calculated Field, but it stinks that you can click it and check the box when it is read-only.