-
So, with the arrival of MC27 comes my annual considerations about how to handle proper names in MC (especially [Artist] but also [Director], [Composer], [Actors], etc).
* What I'm doing now: Manually "swapping" Firstname Lastname into Lastname, Firstname for many of these fields. For others, like [Director] and [Actors] which are generally auto-filled by metadata lookup, I just suffer with the list being stupid-sorted and generally useless.
* The Dream: Have this happen automatically, so that the tag is stored Firstname Lastname, but (when the value contains a proper name) the swapped version is used and displayed everywhere in MC, especially for sorting.
With the new stuff in the expression language, I'm so very, very close to being able to implement the latter in an extremely clean an efficient manner. But there is one major stumbling block I always hit: Expression Fields are read-only.
So, if I do this, I have to display the original, non-swapped versions in all of my Panes, Columns, and Categories otherwise I can no longer use them to edit these fields. I could do this and sort by the swapped versions, of course, but then the display of my [Artist] and other fields in Panes would look all crazy, and it is difficult in some cases to get MC to sort categories by another field. That's non-ideal, and hence I've never actually implemented The Dream.
To fix this, What I'd Love To Have:
When defining an Expression Field in MC, if you could have two new "boxes" in the UI:
1. Write-To Field: Combobox allowing you to select any other writable field in MC. If blank (the default) then the field is read-only, like now.
2. Expression to Apply to Input: An "expression editor" textbox (disabled when Write-To Field is blank). This would allow you to enter an expression that will be applied to input before the results are written out. For this to work, I think it would need a special field of some kind that would represent the "input" (like [Input] or something similar) so that it could then be used in Expressions.
The idea of #2 is to allow pre-formatting of the data entered to make it match the expected output field format. In other words, since I'm going to be displaying Lastname, Firstname for many of these, I could put something like this in the Expression to Apply box: If([Artist is Proper Name],Unswap([Input]),[Input]) and then the user could enter "Swift, Taylor" (or, more likely, check one of the boxes in the Panes) and it would automatically become "Taylor Swift" when it is written out to [Artist].
This system, or something similar, would be extremely useful in a wide variety of locations throughout MC. There are many places where I use Expressions to "massage" display of field data, where I have to also display the "real field" because I'm otherwise unable to modify that field. Or, worse, where I want to but don't use an Expression to massage the output, because that'll block me from using the thing to enter data, which seems to crimp the power available in the Expression Language and formatting in MC.
I can think of a wide variety of uses for this way-beyond displaying reversed names:
* It would fully unlock the ability to pre-filter and/or format data for display (including fonts, colors, etc) without blocking your ability to edit the underlying data.
* It would enable fancy "data validation" by using the Expression to Apply to block invalid edits to fields, if you got really into it.
* It would make "non-blank" defaults for fields viable (without having to rely on Tag on Import seeing each and every file as it comes into the database).
Thoughts? Would this be a nightmare to implement?
-
The main problem I see with this idea is the danger of creating loops: [FieldA] writing to [FieldB] using an expression that uses the current value of [FieldB]; a change in B would cause A to be recalculated, writing a new value to B, which would trigger A reevaluation again, and so on. Stack overflow, unless MC did all kinds of checks to prevent loops (that's your nightmare scenario because the user could create a loop using any number of fields, A->B->C->D->A ...)
There's a simpler solution, I think:
- for any regular field [Field], add an optional "Display Expression" box (default implicit value is "[Field]")
- when displaying the field value, show the output of the expression
- when editing the field, show/edit the actual written value
Simpler, no chance of loops, no need to point field A to B.
-
I've thought about that over the years, and yes, that's a valid alternative. That would block some of the utility of the tool though, which is why I didn't suggest it.
That would solve the "display something different than what is written" issue. But that's pretty much the only thing it would solve, and it would be extremely troublesome in a variety of places because you wouldn't have the Expression to Apply Before Writing function.
A simple example: How do I check the checkbox in the panes that says "Swift, Taylor" and have it automatically tag it properly as "Taylor Swift"? That's my main goal with the Name Reversing stuff. I use the checkboxes to edit my tags extensively (never type something when you can pick it from a list, because that's how typos happen). Even ignoring that, it would be counter-intuitive for an input field to "change" to something (possibly DRAMATICALLY different) when you go to enter data there, and would make usability difficult. What about when you need to enter completely new data? How would the user know what format to use to enter it? You'd just have to "know" not to type it in matching all the other stuff in the field.
Being able to write out to a different field (with the ability to pre-apply an expression on input) could solve that, and opens up all sorts of other possibilities not enabled by the simpler "massage the display only" method. I listed some in my original post (data validation would be sweet) but here's another: You could auto-set other fields based on input with that expression, by pointing to chains of Expression Fields. This is a dumb, contrived example, but imagine if you could auto-set an [Artist Rating] (star field) down by 1 when you add the 3rd 1-star rated track, or up a notch when you add the 3rd 5-star track? You could do that by chaining input and output to various "display fields".
You're right, of course, that the users could get themselves into trouble if they write to fields which cause a loop. But, honestly, there are tons of places in the Expression Language where you can get yourself into trouble. With Great Power Comes Great Responsibility and all that. I don't think that's necessarily a reason not to implement it in this instance, as you'd have to do some serious mucking about to get yourself into that situation.
-
A simple example: How do I check the checkbox in the panes that says "Swift, Taylor" and have it automatically tag it properly as "Taylor Swift"?
The field actual value would be "Taylor Swift", so it would tag like that. It would be "Swift, Taylor" just when printing the field.
it would be counter-intuitive for an input field to "change" to something (possibly DRAMATICALLY different) when you go to enter data there, and would make usability difficult.
Those are the breaks. I think it much more awkward to have to remember that to change field X, you actually need to edit field Y. And you would still need to have both on screen - the one you want to see, and the one you need to edit.
You could auto-set other fields based on input with that expression, by pointing to chains of Expression Fields.
Update chains are a nightmare, that's not likely to ever be implemented.
With Great Power Comes Great Responsibility and all that.
+1 :)
-
You could also "solve" the looping writes situation in other ways (which might be good even if the user didn't create an infinite loop, just for optimization purposes): Only allow a field to be written-to once by a single input "event".
In other words, when [Artist] gets written in the code, you flip a boolean. If the same input event tries to come through and write to the same field again, the execution stops and the write gets discarded. This would "short circuit" any foolish write-loops simply without the hard-lock.
-
The field actual value would be "Taylor Swift", so it would tag like that. It would be "Swift, Taylor" just when printing the field.
Right, but how does the user know this is what will happen? For reversed names, this is pretty simple and obvious when you're applying an existing tag to a different file.
But what does my wife type into the box when she selects the New Artist checkbox, and how does she know what to put there? If she goes by the values of the other items shown in the list, she'd probably manually type "Swift, Taylor" and then it'd end up displaying as Taylor, Swift or some kind of nonsense and I'd get yelled at.
I don't like getting yelled at. ;D
Also, that assumes the modification to the field is pretty simple in order for it to be intuitive. Many of my "display fields" are compound expressions that combine the values of multiple fields (displaying things different ways depending on the "state" of the file in question). In most cases, these would still make the most sense to keep read-only, but there are other circumstances. Maybe you add a "star" character to favorite artists so that anywhere they display, they show a pretty star. But if the user manually enters the star, you could have your Expression to Apply "filter that out" (or maybe even, if you got super-fancy, set the Favorite Artist status too).
-
WAF is always a consideration ::)
Anyway, it's also tricky to have field X being changed out of the blue without her even touching it. That would have her mumbling around in shock and you would be sleeping on the couch until you fixed that nonsense ;D
-
Those are the breaks. I think it much more awkward to have to remember that to change field X, you actually need to edit field Y. And you would still need to have both on screen - the one you want to see, and the one you need to edit.
I think you misunderstood my original request. That's exactly what I'm trying to avoid. Sure, behind the scenes it would be writing to [Artist] when you edit my [Artist (Display)] expression-field, but for everything you see, it would just look like she was editing a field directly. You wouldn't need to display the real [Artist] field anywhere. I would, in some limited places where it would look nicer, like the Playback Bar and whatnot, but you wouldn't have to show it anywhere.
You'd just edit [Artist (Display)] directly in place, and input your data just like all of the other entries in that field look on screen, and the Expression to Apply would "fix" it before it gets written out to [Artist] behind the scenes.
Update chains are a nightmare, that's not likely to ever be implemented.
If they did what I suggested, you could implement them. Just point your Field to Write to another expression-field, which itself writes elsewhere.
I'm not suggesting you'd do this everywhere, obviously, or go crazy with it, but it could be handy in some limited circumstances to do clever things.
In any case, either option would be better than what we have now. I'm not 100% sure I'd use the Display Expression method to actually solve my Reversed Artist Names issue (though I'd sure-as-heck try it out). If they are able to implement something more like my suggestion, though, I think it could open up possibilities to fix issues we aren't even considering now though!
-
You are entering into the realm of real relational databases which use input scripts and field validation, built into the database itself and not in application code. While MC's "Manage Library fields" functionality provides a little of that capability, a glimpse, the database MC uses isn't relational and doesn't have that capability. That is all written in MC code, not in the database itself. Adding it would be a large project for a flat-file system such as the MC library.
This is better...
There's a simpler solution, I think:
- for any regular field [Field], add an optional "Display Expression" box (default implicit value is "[Field]")
- when displaying the field value, show the output of the expression
- when editing the field, show/edit the actual written value
Simpler, no chance of loops, no need to point field A to B.
... with the addition of an Input Template, which provides a little of the form-based data entry some databases use. The template would simply be text defined against a field in "Manage Library fields".
So the Display Expression is used when the field is just being displayed. i.e. Swift, Taylor
When the field is edited the real underlying data would be shown. i.e. Taylor Swift
When an empty field was edited the input template would be displayed as greyed out text which would disappear when any content was entered into the field. i.e. Firstname Lastname
The Google search entry field is a simple example. The field says "Search Google or type a URL" until you click in it. First image. A better example would be where the text didn't appear until an empty field was clicked on (edited), and remained until some data was entered. There are plenty of those in web form data entry, which is often driven by a database.
Or the Input Template from the fields "Manage Library fields" entry could just be prefilled in the field and highlighted, so any data entry overwrites the content. But there is a danger then of the field being filled with the Input Template text for lots of records. The "Add New Field" function in "Manage Library fields" is an example. Second image.
-
You'd just edit [Artist (Display)] directly in place, and input your data just like all of the other entries in that field look on screen, and the Expression to Apply would "fix" it before it gets written out to [Artist] behind the scenes.
This would require the user to enter 2 expressions on a calculated field A:
- the expression that yields the field's value, usually dependent on the value of B
- the expression that is used to process any input and then write it to field B
These two expressions would need to precisely complement each other so that the system worked seamlessly - and it would be up to the user's proficiency in Expression Language to achieve that. Plus, it wouldn't really work with expressions using more than one field; if the field's output expression is calculated using 3 other fields, but the input expression can only write to one of them... editing the field would immediately break the expected output.
Example:
- Field A output = "[Artist] ([Band])"
- Field A writes to [Artist] (because you would have to choose one linked field)
- how would the Input/validation expression be defined? Editing the field would never be seamless, since any change to the second part (Band) would be lost; the edited value would be written to [Artist] only, potentially messing up the output expression value.
-
I don't understand what you mean at all. Perhaps you're missing my point entirely. You'd define the expression once per field in the Library Fields setup part of Settings. I'd do that when setting up the Expression Field. The "users" would never have to.
The field example I gave [Artist (Display)] was an entire field name, and was just a placeholder (though that's probably what I'd call mine). It could have just as easily been [My Expression Field]. It doesn't matter.
When you edit the field in the Tag Action Window, in-line in the list of files, or in the Panes, you'd just edit them like any other field. Then what you enter would be filtered against the expression defined in settings for that field, and then the result saved to the designated output field.
Which is also, incidentally, why what I'm suggesting does not require any fancy relational database features (though with clever use of Expressions, you could hack some on, like you can now with Expressions). It would just be: (1) calculating expression results (which MC is VERY good at, and does VERY fast) and then (2) saving it to the designated destination field (which is no different from a UI element saving directly to the [Artist] field (or any other "normal" field). What would be actually saved to the output field would just be text, like any other field data.
-
By users I mean you and me, whoever defines the fields.
Maybe I'm misunderstanding. I'm assuming the field [Artist (display)] would be defined as an expression field, with expression = swap([artist]), and then, on top of that, we would link it to [artist] as the write-to field, with a second expression to pre-process the input. Is this correct?
If it is, then my reasoning above applies.
If you mean the field would not be an expression field, but instead a regular field with only that write-to link+expression, then It would mean you could have totally unrelated values in [artist] and [artist (display)], by simply editing the [artist] directly. I don't think this is desired. However, this is what is commonly called a "trigger" in relational DBs, and it can also be useful.
-
You are entering into the realm of real relational databases which use input scripts and field validation, built into the database itself and not in application code. While MC's "Manage Library fields" functionality provides a little of that capability, a glimpse, the database MC uses isn't relational and doesn't have that capability. That is all written in MC code, not in the database itself. Adding it would be a large project for a flat-file system such as the MC library.
I don't think this has anything to do with the underlying storage mechanism and a relational database doesn't have input scripts or validation, it's just a storage engine that may have some programming API built on top.
whether the way MC is implemented makes this easy or not is another Q but it's just a question of constructing a graph of nodes which can operate on values as data passes through it, validate that the resulting graph is not cyclic and you don't have a problem with loops
I'd have thought that usability would be quite bad though without a way to understanding where such graphs exist in your setup & understanding what is going on could be quite challenging for non trivial cases. I mean MC doesn't even have any sort of syntax highlighting, code formatting or autocomplete or any way to publish/share/import fragments that use expressions so adding yet more functionality to the underlying instead of making what is there more accessible seems like the wrong path to me (though more and more excel style expression functionality without any work on other APIs seems like the wrong path full stop to me).
-
@Jim/Matt,
Please check if this feature request is doable/desirable.
[just bumping the thread as I'm aware that it's annoying to the OP when other users derail a feature request with 3rd party discussion ;D]
-
I don't think this has anything to do with the underlying storage mechanism and a relational database doesn't have input scripts or validation
Oracle and Progess have functionality built into the database as part of its definition, and are not part of the application code.
Anyway, noting Zybex's point, I made a suggestion I called an Input Template which seemed to cover Glynor's concern about users not knowing what format to enter data into an empty field. Along with the suggestion of a Display Expression added to Manage Library Fields, as per Zybex's Reply #1, I think there would be a workable solution, without needing to write to a second field, which I think would be problematic from a usability perspective.
-
Well, it seems like all of us are in agreement that the issue does need to be solved in some way. The long and short of it is that the Expression Language provides all the tools needed to manipulate and display data from the Library, but doesn't yet provide a way to cleanly use Expressions while preserving edit-ability of the underlying fields.
To make it simple, I thought I'd briefly summarize the two proposals outlined in this thread:
Display Expression and Input Template
In Tools > Options > Library & Folders > Manage Library Fields, for all standard User Data type fields, provide two new settings:
- Display Expression: Shows a Expression-editing textbox. When blank (the default) the value of the field is displayed, exactly as they work now. When filled with an expression, this value is substituted anywhere the values of the field are displayed (panes, grid-view, Tag AW, etc).
- Input Template: Allows the user to define a tooltip-style "informational" display when the users are editing this field to describe the required input format.
Note: The purpose of the Input Template is to prevent the situation where the user enters the data as it appears for all of the other fields, and receives unexpected results due to the Display Expression transformation.
Writable Calculated Fields
In Tools > Options > Library & Folders > Manage Library Fields, for all standard Calculated Data type fields, provide two new settings:
- Write-To Field: Combobox allowing you to select any other User Data type field in MC. If blank (the default) then the field is read-only, like now. If filled, when the user edits the value of this field, the input is saved to the designated field exactly as it would be for any other standard User Data field.
- Expression to Apply to Input: Shows a Expression-editing textbox (option disabled if Write-To Field is blank). If filled, this expression is applied to any input before that input is saved out to the designated Write-To field. This effectively does the "reverse" of the Input Template option described above. It allows the user to enter data exactly as the other values of the field are shown, but transform the input automatically to the proper "storage format".
Note: The restriction of the Write-To Field combobox to only User Data fields will prevent users from inadvertently creating a loop. Alternatively, (if this is easy with the way MC is currently coded) you could lift that restriction but allow a single "edit operation" to write to a field only once, thereby short-circuiting any loops the user does create. But that's probably dumb.
While (given only these two options) I'd slightly prefer the Writable Calculated Fields version, that's really about minor semantic quibbles. Any solution would be greatly appreciated, and either of these choices would meet my needs (and, I believe the needs of the others who commented here). They're really just two different methods to accomplish the same thing, and JRiver can certainly decide how best to implement it based on the underlying architecture of MC.
-
It is worth noting that I thought of one additional simplification to the Expression to Apply to Input option since I wrote my original responses: I'd originally thought you'd need to define a new, special field for the expression engine to "capture" the user's input (and so allow it to be transformed before output to the designated field). I proposed [Input].
But that isn't needed. You can simply use the calculated field's name for this purpose. So, that gives us these usage examples to solve the "Artist Name-Swapping Issue":
Writable Calculated Fields Version
- Field: Artist Display (custom Calculated Field)
- Expression: If([Artist is Personal Name],Swap([Artist]),[Artist])
- Write-To Field: Artist
- Expression to Apply to Input: If([Artist is Personal Name],Unswap([Artist Display]),[Artist Display])
Display Expression and Input Template Version
- Field: Artist (standard User-Data field)
- Display Expression: If([Artist is Personal Name],Swap([Artist]),[Artist])
- Input Template: I'm not positive what the markup for this would look like, but you could use formatting similar or identical to that used for the Track Info tooltips.
For both versions, [Artist is Personal Name] would be an integer-type field set to Relational: Artist with an Edit Type of Checkbox. You'd check the box if the Artist in question is Taylor Swift and leave it unchecked for "band names" like Pink Floyd.
-
I should note as well, I may have misunderstood RoderickGI's idea for the Input Template function. It is possible that, alternatively, this could operate exactly as my Expression to Apply to Input proposal: where you simply define an expression that is automatically applied to any input entered into the field, rather than explaining to the user what they should enter in the field.
The only downside to that is that you'd lose access to any method to write to the User Data field "directly" (without having this transformation applied). But, I'd live with that.
RoderickGI, if you could clarify that would be great, and if I misunderstood, I'll edit the posts above to reflect it.
-
You understood my suggestion pretty well, only I wouldn't want the Input Template to be a Tooltip, as they take a moment to display, and they don't show in-line, inside the field.
- I would want the Input Template to show when a field was edited.
- The text would be greyed out to indicate that it wasn't editable, as is common practice for forms entry fields.
- When the field that was opened for editing, using F2 or double-clicking, the cursor would be positioned at the beginning of the field. Again, to show that the text is not content, but a template.
- When the user started typing content into the field, the Input Template text would disappear.
- The content would just be text defined in the field definition dialogue, in Manage Library Fields.
My concern with your Writable Calculated Fields solution is that you are using two fields, one for data entry and one for writing the value to. This would cause me issues with Views, as you would need to have one View for data entry and one for day to day use, or you would need both fields in any View you used. I may not be understanding your solution correctly though. But I think I am. Perhaps if you outlined how the functionality would work in Views. My solution uses just one field, which means all data entry and editing is done in the one View, with the one field.
I can think of one potential big advantage with your solution though. If you expanded the concept of the [Artist is Personal Name] to cover the instance of where Artists have three or more names, that could be very useful. So for example, with different Artist names;
For "Taylor Anne Swift" the [Artist is Personal Name] field would be set to 2 (for a zero based field) or 3 for human readability, to indicate that the last name (surname) is Swift, so the swapped version should be "Swift, Taylor Anne".
For "Taylor Swift" the [Artist is Personal Name] field would be set to 1 (for a zero based field) or 2 for human readability, to indicate that the last name (surname) is Swift, so the swapped version should be "Swift, Taylor".
For "Pink Floyd" the [Artist is Personal Name] field would be set to 0, to indicate that the Artist field should not be swapped.
But I would still be concerned with using two fields, and how that would work in Views.
If this could all be done in one field, without the use of a Write-To field, I would be happy for the solution to be implemented. Just re-reading your last post, it seems that still needs an [Artist Display] field in addition to an [Artist] field.
-
My concern with your Writable Calculated Fields solution is that you are using two fields, one for data entry and one for writing the value to. This would cause me issues with Views, as you would need to have one View for data entry and one for day to day use, or you would need both fields in any View you used. I may not be understanding your solution correctly though.
You are absolutely NOT understanding my idea. I think because you're making it more complicated in your mind that necessary. But, to be clear, you would not have to show "both fields" anywhere in MC. You could use exclusively the Calculated Fields in all of your Views. That's the whole idea.
The Calculated Field would work exactly like they do now, except you'd be able to edit values and save to them. If you do save to them, it would save to the field specified as the Write To Field. Like a "write redirect". You could have it save-to a field that isn't shown anywhere in MC at all, nor used for anything at all, and is only defined in Library Fields as a User-Data type field. If you leave the Expression to Apply to Input option empty, then that is absolutely it. You edit your custom-made [Artist Display] Calculated field, and whatever you put in the edit box (in the Tag AW, Panes, inline in the grid, via MCWS, whatever) would save to the field you specify as the Write-To Field.
It might make it easier to forget about all of the Name Swapping stuff, which is making it seem more complicated than it is, and think of a simplified example.
Dumb [Comment Light] Example
Say you have an Expression field that is super dumb, like an indicator light, that tells you if [Comment] contains anything or not. You can do this now, it doesn't require any additions to MC.
Make a Calculated Field in MC called Comment Light and put this expression in it: If(IsEmpty([Comment]),Empty,Not Empty)
Then, if you display this new [Comment Light] field in a View, it would show "Not Empty" for any file that has something in [Comment], and "Empty" for any file that does. Dumb, but simple.
(https://glynor.com/img/screenshots/MC27/Comment_Light-Example.png)
The problem is, when you edit the text in the [Comment Light] field for a file, it doesn't do anything. What you type just gets discarded (and you really should have changed that Edit Type to Cannot be written).
Allowing Edits to [Comment] Through the Dumb [Comment Light] Expression Field
Now say you want to be able to edit that [Comment Light] field and type some crap in there, and have whatever you type in the box go to the [Comment] field. Here you would need the new stuff, but it would be easy. You'd just set the Write-To Field to Comment.
Now, when you have a file that is showing "Empty" in your fancy new [Comment Light] field in a file list view, you could "edit" it and type in "purple" and hit return.
(https://glynor.com/img/screenshots/MC27/Comment_Light-Example-writing.png)
Once you hit return, the text you typed would be saved to [Comment] instead of being thrown away (as it is now). And the value shown onscreen in [Comment Light] would change to "Not Empty" because now [Comment] is no longer Empty. You would not need to have the [Comment] field visible in any way. But, if you opened the Tag Action Window and looked at [Comment] it would contain "purple".
If you're not actively editing the thing, the new functionality does nothing. Everything works exactly like it does now. All of the magic happens when you edit the Calculated Field and then hit Enter.
Controlling What Gets Written Through the Dumb [Comment Light] Expression Field
But, what if you don't want to just write out exactly what the user enters in the edit-box? What if you want to change what they entered into something else? That's what the Expression to Apply to Input box is for. Enter an expression there and then that expression would be evaluated whenever someone makes an edit to the field and then whatever the expression spits out would be written to the Write-To Field. So, continuing the dumb example from above:
Say you want it just like above, but if the file in question happens to be in the Classical Genre, you want the comment that gets written to always be "Mozart Rules". For all other files, you just want it to keep working like described above, but if the Genre is Classical, then only that text can be written out. (I don't know why, it is a dumb example.) So, to accomplish this, you'd just put this expression in the Expression to Apply to Input box: If(IsEqual([Genre],Classical,1),Mozart Rules,[Comment Light])
When you enter something in the box and hit Enter, this expression would be evaluated and its output goes into [Comment] instead of what you typed in the box. So, if [Genre] is "Classical" then it would ignore what you put in the edit box, and always write out Mozart Rules. And, to preserve the original functionality from above, you would "pass through" the input entered by referring to "itself" in the expression.
It would not "go through" and write-out "Mozart Rules" to all of your Classical files. It would only do anything at all if you edited the [Comment Light] field and put something (anything) in there. The two fields would not be tied together in any way (other than that one-way writing behavior). So, you could still tag your Classical files with any comment you want, but you'd have to actually write to the "real" [Comment] field (by opening it up in the Tag AW, for example). You just couldn't do it through the [Comment Light] field you made.
Conclusion
In most real-world cases, of course, the expression that the Calculated Field displays would have some relation to the Write-To field and probably contain it, as it does in my Artist Swapping example from way above. But it wouldn't even have to reference it at all. It would be weird, but you could have a Calculated Field that doesn't even use or display the value stored in the field it writes to at all. So, using the example above, if you set the Write-To field to [Keywords] you could use it to enter Keywords, but the value displayed in [Comment Light] after editing (since it doesn't reference [Keywords] in its expression) would always stay the same. You could also have two (or more) different, completely unrelated Calculated Fields which write to the same User Data field. That's not a problem because it only happens on write, when you hit Enter.
And that really brings up one of the main benefits of this method over the Display Expression suggestion discussed above. My way would be much more flexible. You wouldn't be limited to just displaying that [Artist] in one way. You could have 5 or 6 different Calculated Fields, which show [Artist] in a variety of different ways (maybe formatting it one way for Theater View and a different way for Standard View), but use all of them to allow you to edit the [Artist] field "underneath".
The other way would work, but you'd be limited to a single Display Expression for each particular User-Data field. If you want to make another Calculated Field that uses the values in a User-Data Field to display the contents in a different way, you could, but then you couldn't use those to edit it. You'd only be able to edit the "original", and the "original" would always display with the Display Expression applied. So, that would be another issue. What about when you want to show the original value in your User-Data field, without that expression applied? You wouldn't be able to directly. You'd have to make an expression to point to it, which is silly. And that workaround assumes that the output of the Display Expression would only be used for display, and not actually impact other uses of the User-Data field in the Expression Language. That's not something MC can do now, so it would be entirely new functionality. Without it, the actual stored value in the User Data field would become completely inaccessible.
And, perhaps most importantly, modifying the Calculated Fields to allow writing (instead of modifying the display of User-Data fields with an expression) would not require JRiver to "muck with" the way standard User-Data fields work at all. Which, for architectural reasons I'm guessing, they've often been loathe to do.
Everything would work exactly like it does now, except that when you edit a Calculated Field (which you can do now, if Edit Type isn't set to Cannot be edited) it would actually do something useful, instead of just throwing the edits away.
Again, though, I'm okay with either solution. For the Artist Name Swapping business, they're basically functionally equivalent (I just happen to think the other way is a bit better, more flexible, and a little more elegant).
-
Okay, so now that you (hopefully) understand what I'm proposing, how does it work for the Artist Name Swapping example?
First, you'd want to make two new fields:
[Artist is Personal Name]
(https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-AisPN-Define-small.png)
(Click to embiggen.) (https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-AisPN-Define.png)
[Artist Display]
(https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-Artist_Display-Define-small.png)
(Click to embiggen.) (https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-Artist_Display-Define.png)
Then, you could go through your Library and put all of the Artists back to "normal" and check the boxes for any Artists where the value is a "person's name" rather than a "band name". You could hide the "real" [Artist] field from everywhere (unless you want to use the "raw value" of it somewhere).
(https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-writing-small.png) (https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-writing.png)
I'm showing the "real" [Artist] tag in the Tag AW here so you can see what it really contains in the example (and because I didn't want to screw up my whole Tag AW layout to make the example screenshot), but you wouldn't need to have it displayed anywhere at all, even in the Tag AW. You could just do your edits through the [Artist Display] field instead.
Everything up to now works fine with MC as it is currently. The only issue is that you can't edit values in the [Artist Display] field you made. If you do, they're ignored. If you want to actually be able to modify what shows in the [Artist Display] field, you need to edit the separate [Artist] tag. That stinks.
So, with the new stuff, there'd be two new boxes down below the Calculated Data text box when you're setting up the [Artist Display] Calculated Field. You'd have Write-To Field and Expression to Apply to Input.
- Write-To Field would be a combobox (drop-down picker) where you can choose from any of the existing "regular" Data-Type Fields, and you'd pick [Artist].
- Expression to Apply to Input would be a textbox where you could enter a different expression (just like the the one that is already there, but for input filtering). Here you'd put basically the "opposite" of your original expression (so that you could "de-transform" the entries): If([Artist is Personal Name],Unswap([Artist Display]),[Artist Display])
So that way, if you edit the [Artist Display] field and type something, or choose from the picker (which works now, as shown in my screenshot above) it would save whatever you choose into the [Artist] field. BUT, since you DON'T want to write it out as "Swift, Taylor" it would first apply If([Artist is Personal Name],Unswap([Artist Display]),[Artist Display]). You'd have to make sure to check the box for [Artist is Personal Name] first, but then whatever you enter (or pick) would get saved "un-swapped".
The beauty of this is that most of the time, you wouldn't need to do anything at all. When you first import a track from a new solo artist, you'd just have to check the [Artist is Personal Name] checkbox. But you'd usually leave the text in [Artist] alone (assuming it came in well tagged from whatever place you downloaded it or whatever). Since that [Artist is Personal Name] field is relational, it would be automatically checked for any new files you import, after the first one, with the same [Artist] name going forward (as shown with Taylor Swift in my example above).
Presto, all of your Views would show it reversed, it would sort reversed without having to manually swap anything or do any edits at all.
And, since the default value of [Artist is Personal Name] is unchecked, you wouldn't even need to go through your entire Library and fix the ones you did manually swap before right away. They'd keep displaying right because they'd be treated as "band names" until you fixed them and checked the box.
I'm honestly not as excited to get the [Artist] issue in particular fixed. It is annoying that each time I import new tracks from a solo artists that I downloaded from Amazon or whatever, that I have to manually swap the names on them. But, it is only one-time pain. I just type =Swap([Artist]) into the Artist edit box and it goes where it should.
Where I really want it is all the stuff that gets filled in automatically. Especially [Actors], [Director], [Screenwriter], etc that get filled by TVDB lookup. Those all come in "firstname lastname" style. You could manually swap those too after you import, I suppose. But that's super-annoying, and you'd have to remember to re-do it every time you re-do the lookup (and I do "refresh" mine from time to time because often the metadata available in the databases improves over time).
Lastly, the stuff in your comment about multiple names (3 and 4 names) doesn't make any sense to me at all, because Swap() and Unswap() already work on those. So that was confusing, but... Doesn't really matter. If you wanted to do fancier things with the [Artist is Personal Name] field, you could. Or, maybe you have more than one "setting" for how the [Artist] is handled? Whatever.
-
You just posted while I was writing. I'll post this and read your new post.
Your [Comment Light] example is too simple, and it still has the same concern about having to display two fields in a View.
For example, if I only have the [Comment Light] field in the View, it says Not Empty, and I want to add something to the comment, I need to see the [Comment] field in order to do so. I don't want to just blindly overwrite the field. I may want to just edit it a little, or add something to the end, or whatever. I need to see the field to do that.
I guess if the [Comment Light] field used the expression: If(IsEmpty([Comment]),Empty,[Comment])
Then I could see the Comment before starting an edit. But would the edit give me the text from the [Comment] field as a starting point? I would need that. Checking... Okay, if I currently create a calculated field and edit it, the content of the field is carried into the edit, so I guess that would work.
So looking back at your Artist example, for values in the [Artist] field of "Taylor Swift" or "Pink Floyd":
Writable Calculated Fields Version
- Field: Artist Display (custom Calculated Field)
- Expression: If([Artist is Personal Name],Swap([Artist]),[Artist]) > [Artist Display] would show "Swift, Taylor" or "Pink Floyd"
- Write-To Field: Artist
- Expression to Apply to Input: If([Artist is Personal Name],Unswap([Artist Display]),[Artist Display]) > Then "Taylor Swift" or "Pink Floyd" would be written to the [Artist] field.
Okay, that makes sense. As long as the "Expression to Apply to Input" doesn't result in a loop. As it is writing out to the [Artist] field, then I guess it shouldn't.
Also the "Expression to Apply to Input" would need to write back a value consistent with the original field value format. For example a error such as the expression:
If([Artist is Personal Name],([Artist Display]),Unswap[Artist Display])
Would be a problem, as it would write "Swift, Taylor" or "Pink Floyd" to the [Artist] field instead of "Taylor Swift", which would then be processed by the [Artist Display] expression to become "Swift, Taylor," I think, and each time the [Artist Display] expression was evaluated that would get worse, adding commas.
-
Your [Comment Light] example is too simple, and it still has the same concern about having to display two fields in a View.
How? Explain exactly why you'd ever need to show [Comment] in the View? If you only want to know if [Comment] contains some text, and need to be able to edit [Comment] occasionally, you could just use [Comment Light] in all of your Views everywhere.
For example, if I only have the [Comment Light] field in the View, it says Not Empty, and I want to add something to the comment, I need to see the [Comment] field in order to do so. I don't want to just blindly overwrite the field.
Of course, if you need to see exactly what is currently in the [Comment] field, you'd need to be able to see it. But that's what the Expression to Apply thing is for. You could edit them just as they look in your Calculated Field, and they'd be "right" when they go into their destination.
And there are lots of situations I can think of where I don't care what is currently in the field, but I might want to write to it. I'll provide an example in a separate post.
-
Our posts align.
Well, not on the simple [Comment Light] example. I explained why I would want to see the comment. Because I want to see what I am about to edit. Sure, I could see the "Not Empty" value, and then use the Tag AW to edit it, but that is an extra step, and that wouldn't be true for a more realistic example. As a user I would also need to remember that this is a special calculated field, and so not to just directly edit it if it says "Not Empty".
But I guess I understand your [Artist] example now.
However, in the specific [Artist] example there would be a problem if the [Artist] field held the value "Taylor Swift; The Sweetback Sisters", as one is a personal name and the other is not. As [Artist] is a list type field, that could be a problem. Swap and Unswap will handle List type fields though, so as long as all Artists were either personal names or not, then the example should work fine. I'm not sure how the relational field would handle that situation.
Without testing everything, muy understanding was the Swap and Unswap still fell over with some name formats. In fact, it can't handle "Bary Grant Flowerdale Jr", returning "Jr, Bary Grant Flowerdale". It is similar with any three element name with a suffix. But I guess those are rare and could be handled by exception.
However, a couple of more examples and I think you would have me convinced, even given the concerns above. This would be a power user's tool only, in all likelihood, so caveats are fine.
Oh, I think you updated Reply #19 after I loaded the page. I've skimmed it but haven't thoroughly read it yet... Looks okay. Doesn't change my thoughts. Other activities call, even in Stage 4 lockdown!
-
I have now a field called [Watched] which displays a checkmark when files have been previously fully-played, blank when they've never been played at all, and a percentage when they've been started, but never completed:
(https://glynor.com/img/screenshots/MC27/Watched-Example-Letterkenny-small.png) (https://glynor.com/img/screenshots/MC27/Watched-Example-Letterkenny.png)
It works great. But, one problem is that if I watch an episode of a show in Plex on my iPad, they stay "unchecked" in MC.
But, with this, I could set the Write-To Field to [Number Plays] and the Expression to Apply to: If(IsEqual([Watched],✔)Math([Number Plays] + 1),Math([Number Plays] - 1))
Then, when I "edit" that field, I'd get a dropdown showing a checkmark, blank, and a bunch of percentages (just as I do now):
(https://glynor.com/img/screenshots/MC27/Watched-Example-Editing.png)
I pick the Checkmark, and Number of Plays increments by 1, which causes the [Watched] field to spit out a checkmark anyway, so it looks like I edited it. If I pick any other value, it decreases my number of plays by 1 (which would be handy to "mark as new" the files). Yes, I know I can do this by right-clicking on the files and choosing Library Tools > Mark as Played/Not Played, but it would be much nicer to do it right inline (and we could probably edit these values in Theater View, which would be huge).
I'd probably make mine more complex to make entering a blank value actually set [Number Plays] to zero, and a percentage (any percentage) de-increment the counter like that (or maybe I'd have it ignore these, not sure). But you get the idea, I hope.
Bringing it back around to the [Artist] swapping example, since [Artist Display] displays this:
If([Artist is Personal Name],Swap([Artist]),[Artist])
But when you write to it, it does this (which is NOT the same expression, it is the opposite):
If([Artist is Personal Name],Unswap([Artist Display]),[Artist Display])
Also the "Expression to Apply to Input" would need to write back a value consistent with the original field value format. For example a error such as the expression:
If([Artist is Personal Name],([Artist Display]),Unswap[Artist Display])
Would be a problem, as it would write "Swift, Taylor" or "Pink Floyd" to the [Artist] field instead of "Taylor Swift", which would then be processed by the [Artist Display] expression to become "Swift, Taylor," I think, and each time the [Artist Display] expression was evaluated that would get worse, adding commas.
No it wouldn't. It would UNswap the input when you write to it, so it would convert Swift, Taylor back to Taylor Swift and write that to the [Artist] field.
-
However, in the specific [Artist] example there would be a problem if the [Artist] field held the value "Taylor Swift; The Sweetback Sisters", as one is a personal name and the other is not.
That is correct. That is an issue, but you'd just leave those set to "band mode" (the default) and name-swap them yourself. Which is no worse than what I'm doing now. Just only necessary once in a while.
There's a perfect set of examples in my screenshot above (I picked Taylor Swift on purpose, in fact):
Swift, Taylor;Sheeran, Ed would work just fine (and could have the [Artist is Personal Name] box checked).
Swift, Taylor;Bon Iver would not, so you'd have to actually enter Swift, Taylor in that manually and uncheck the box. Since Swift, Taylor isn't Taylor Swift, and the relational-ness keys on [Artist] and not [Artist Display], the system treats those separately:
(https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-Multi-Type_Artists.png)
Same with things Swap() and Unswap() don't handle well. (Though I have a regex that fixes up some of the Jr., Sr., III, II, etc stuff too, and if you search for old posts here, you can find details, and then you could include that in your system too.)
For anything that isn't "simple" you'd just put them in "band mode" ([Artist is Personal Name] unchecked, which is the default anyway). For my other auto-metadata lookup fields, I'd make override checkboxes (hidden just in the Tag AW for when needed) that would avoid the swapping but which would default the other way. [Director is Special], [Actor is Special], and so on and so forth.
-
No it wouldn't. It would UNswap the input when you write to it, so it would convert Swift, Taylor back to Taylor Swift and write that to the [Artist] field.
I switched around the expression so it would fail. Just a demonstration of what could go wrong.
-
I switched around the expression so it would fail. Just a demonstration of what could go wrong.
Well, sure. If you muck up your expression. But that would be true of lots of the things in MC. If I muck up my expression when I type into the box with =Swap([Artist]) it'll mess up my data too.
But you'd only have to type the "opposite" expression out once. So, you know, be careful. And... I wouldn't do it with a crapload of files until it was well tested (which is part of why I like the system too, because it defaults to "band mode" so I could test with a few files before I converted my whole library over to the new scheme).
-
The Watched example is a good one.
(and we could probably edit these values in Theater View, which would be huge).
Unfortunately last time I checked you still can't select a Checkmark for a field in Theatre View. Though maybe with your custom Watched field, and a list of percentage values in addition to the Checkmark, this wouldn't be the case, as the field doesn't have an Edit Type of "Check"? I haven't looked back at your Watched setup thread to confirm.
-
It does not have an edit type of Check. It usually has an edit type of Cannot be edited. I had to change it for the screenshot.
All of my Calculated Fields do, in fact, except the ones that use Checkmarks and stars. It annoys me that MC can't still show a checkbox or stars or whatever, but not allow editing on it (have the checkbox visible, but disabled).
This could solve that problem too, because if Write-To Field is blank, then the field would be by-definition, read-only, and they could just always disable them in the UI (but still let you pick different Edit Types for display). But if you leave it set to Standard edit type, then it shows all the values available in the dropdown (see my screenshot).
And, if they unlock the Acceptable Values box for Calculated Fields too (like Edit Type is unlocked now), I could make it so that dropdown would only contain a checkmark or an anti-sign, and then my Expression to Apply would look for those to do it's logic.
Which would be even better.
I have LOTS of examples like that. Things where I'd love to use my nice "combined for display" Expression Fields (used all over the place in my Views) to give me toggle or increment up/down types of control.
-
I'm curious as to how it would cope/work with tracks that were performed by Multiple Artists as in:- an individual artist + a group; or more than one individual artists. given there are a multitude of ways those combinations can be input/stored in the database and tags?
In addition how would it cope with artists who frequently use a "Stage Name", i.e. Sting; as the performer but their Proper Name, Gordon Sumner, as composer/song writer?
-
I'm curious as to how it would cope/work with tracks that were performed by Multiple Artists as in:- an individual artist + a group; or more than one individual artists. given there are a multitude of ways those combinations can be input/stored in the database and tags?
In addition how would it cope with artists who frequently use a "Stage Name", i.e. Sting; as the performer but their Proper Name, Gordon Sumner, as composer/song writer?
It wouldn't deal with either one directly. Unchecking [Artist is Personal Name] would be the override, effectively. The way I do that now, for what it is worth, is I add both names as artists. So, right now, for Tom Petty and the Heartbreakers tracks, I have them tagged as:
[Artist]="Tom Petty and the Heartbreakers;Petty, Tom"
I'd leave them that way, and I'd leave [Artist is Personal Name] unchecked.
For [Composer], I'd absolutely use it, just like I described above for [Director], [Actors], etc. All of my composers for my Classical music collection are in with their actual names in "swapped" order now. I'd instead:
1. Make the [Composer is Special] field which would be just like [Artist is Personal Name] but "reversed" in logic.
2. Make [Composer Display] with If([Composer is Special],[Composer],Swap([Composer]))
3. Make Expression to Apply to Input for [Composer Display]: If([Composer is Special],[Composer Display],Unswap([Composer Display]))
4. Fix all of my current [Composer] values by using =Unswap([Composer]) on them (or just control-A and check the [Composer is Special] checkbox on all of them until I felt like doing it).
So, it would work the same as [Artist] but the "default mode" would be reversed. That would be nice because most of my values in [Composer] are personal names. Currently they're manually swapped, so I'd have to un-do that for those, but that wouldn't be too hard because there would be few outliers. And once done, I'd just need the checkbox for your occasional weird name that Swap() and Unswap() puke on for whatever reason.
I'm not sure if this is what you meant, but...
If you want your [Artist Display] to include the Composer, even if those value isn't explicitly included in [Artist], you could certainly do that. My custom [Artist Album (Smart)] field does stuff like that. (I use that because I don't like the behavior of the built in [Artist Album (Auto)] field.)
Your [Artist Display] field Expression could use IsEmpty() to test if [Composer] is blank or not, and if not use ListBuild() to include those values in the display. You wouldn't be able to use it to write to [Composer] because you couldn't pick two different fields in the Write-To Field combobox (and wouldn't want to, because how could it know which goes where). But you could still use it to write to [Artist].
I probably wouldn't do that. I use composers mostly for classical (and some for Jazz). But you could if you want to see all of those values combined in a Pane or a Theater View Category.
Again, all of that stuff you can already do in MC. It just isn't very viable because you can't edit Calculated Fields, and so you are forced to include the "real" [Artist] or [Composer] or [Director] fields in the Tag AW (at least), if you ever want to be able to edit the contents by hand. And you have to include them in panes if you want to use the Pane Checkboxes to tag them (which I do extensively).
-
I should note: I left off &datatype=[list] from all of my [Artist Display] expressions above in basically all of my posts. If you're doing it for real, you'd have to append that.
Including that makes the forum code angry because list makes a list, and I always forget about the [nobbc] tag.
-
Okay, that makes sense. As long as the "Expression to Apply to Input" doesn't result in a loop. As it is writing out to the [Artist] field, then I guess it shouldn't.
Yeah. Bringing up the potential for looping above was a very good point from zybex. I'm glad they (and you) made me think about it more.
Limiting the fields you can choose in the Write-To Field combobox to only Data Type fields is the best solution for that, I think. That does cut out the potential use-case of having "cascading sets" of Calculated Fields to do super-fancy things (like transform the input in multiple ways, depending on conditions).
If it is possible to let us go whole-hog and pick any field we want, including other writeable Calculated Fields, that would be great. I'd take it (and I might do something clever with it someday). But I can't even think of a real world usage for that right now that I'd ever actually want to implement. And they'd have to make darn sure that it can protect itself against a user short circuiting it into an infinite loop with a poorly thought out set of expressions. You could do what I said originally and make it only allow writes to an individual field once per edit, but... That seems like special casing and a bunch of work for an edge-case usage, that maybe nobody will ever use.
So, I'd say just make it so it can only write to "vanilla" fields. That's safe because they can't trigger another write, and so you can't build chains. And it is simpler.
-
Well, not on the simple [Comment Light] example. I explained why I would want to see the comment. Because I want to see what I am about to edit. Sure, I could see the "Not Empty" value, and then use the Tag AW to edit it, but that is an extra step, and that wouldn't be true for a more realistic example. As a user I would also need to remember that this is a special calculated field, and so not to just directly edit it if it says "Not Empty".
You could edit [Comment Light] in-line in a file details listing too.
But, yeah... That's why it was a dumb example. I was just trying to get the point of the system across, without all of the complexity of list data types, swapping names, and the like. You could do that, but it would be stupid to actually do it.
In real-world usages, you'd edit them either by typing something that looks just like the other values in the field (like with [Artist Display]) or you'd pick from the drop-down menu.
-
To make it simple, I thought I'd briefly summarize the two proposals outlined in this thread:
Display Expression and Input Template
In Tools > Options > Library & Folders > Manage Library Fields, for all standard User Data type fields, provide two new settings:
- Display Expression: Shows a Expression-editing textbox. When blank (the default) the value of the field is displayed, exactly as they work now. When filled with an expression, this value is substituted anywhere the values of the field are displayed (panes, grid-view, Tag AW, etc).
- Input Template: Allows the user to define a tooltip-style "informational" display when the users are editing this field to describe the required input format.
Note: The purpose of the Input Template is to prevent the situation where the user enters the data as it appears for all of the other fields, and receives unexpected results due to the Display Expression transformation.
There is no need for an "Input Template" in my suggestion, just the Display Expression. If you mean just some text to be shown as a tooltip/info, that's fine - but it's not a requirement.
Also, the Display Expression would be available on non-calculated fields (user-writable). Calculated fields would still be read-only, there would be no need to make them pseudo-writable as in your proposal.
-
Let me try to formalize both approaches:
Your original idea - WriteRedirect™:
FieldA: normal read/write field
FieldB: calculated field + writeRedirect to FieldA:
read/displayValue = Expression(FieldA, others)
write(value) -> FieldA = InputExpression(value, otherFields)
Simplified idea - DisplayExpression™:
FieldC: read/write field with DisplayExpression
read/displayValue = DisplayExpression(FieldC, otherFields)
write(value) -> FieldC = value
Standard field syntax could be used:
[FieldC] = output of DisplayExpression for FieldC => same as [FieldB] in your idea
[FieldC, 0] = raw value without DisplayExpression => same as [FieldA] in your idea
These ideas are actually equivalent:
- Value of FieldA -> shown via expression of FieldB -> Edits written to FieldA (after massaging with optional InputExpression)
vs
- Value of FieldC -> shown via expression of FieldC -> Edits written to FieldC (optional massaging can also be added - I dislike it)
The difference is only where the "Display Expression" is stored - FieldB is in effect the holder of that expression, and nothing else. The simplified version stores it all on the same FieldC. So the second one is a self-contained/simpler implementation of the same concept, doing away with the need to have 2 expressions for the same field. The rest is eye candy and user assistance - the "input expression" or "tooltip" is in effect a separate concept that can be added to either implementation to help the user when entering data.
For JRiver the implementation is also simpler - they can reuse the existing Field Expression box to enter/store the field's Display Expression.
The need for that InputExpression is problematic in my view, and would not work well in practice, as it requires (as I said above) well balanced expressions that complement each other, and wouldn't really work when the wanted display value is calculated based on multiple input fields.
-
These ideas are actually equivalent:
- Value of FieldA -> shown via expression of FieldB -> Edits written to FieldA (after massaging with optional InputExpression)
vs
- Value of FieldC -> shown via expression of FieldC -> Edits written to FieldC (optional massaging can also be added - I dislike it)
The difference is only where the "Display Expression" is stored - FieldB is in effect the holder of that expression, and nothing else.
They aren't equivalent. I get that you might not care, or it might not matter for your workflow, but without a way to automatically "massage" the input data, I probably wouldn't implement it at all on [Artist]. I'd use your suggestion for my auto-metadata-filled fields, but only those.
Because:
- How would I implement my [Watched] idea with your system described above?
- How would I tag [Artist] on my files using the Panes checkboxes or "dropdown suggestions" in the [Artist] combobox? All of that functionality would become useless. The only way to tag the files would be to manually type values into the box, and even then, you'd have to just "know" that you had to type them opposite of how all the other values look in the field (ignoring all suggestions to the contrary)?
Because of the necessary mechanisms for inputting data into MC. The input data wouldn't match what would be displayed by the field. That way would be "worse" (in my mind) than the perfectly-possible-now method of just showing the Calculated Field in your Views and editing the underlying tags only in the Tag AW. You'd still have to "give up" on ever using those fields where they have a Display Expression in a View to input data (unless you know the "secret method" and type them all by hand).
Maybe I'm not understanding. If you could outline, like I did above, how to solve those issues maybe it would make more sense? I'm interested if there is really a simpler solution where you "unify" the field types. But if so, I'm not seeing how it would work.
Note: I still don't think JRiver is ever going to change how User-Data fields display. I think that probably endangers optimization and caching, and... Fundamentally, they want those to be "simple data storage fields". The point of the Calculated Fields is to serve that role. But, I could be wrong there.
-
It is equivalent. As I mentioned, the Input validation/massage expression can be added to both methods. The only difference is the write-to location: In your suggestion you need a second field, on my suggestion the write-to is the field itself. Everything else is the same.
Your [Watched] example has some problems - what happens when you change the value from 50% to 60%? Your [Number of Plays] gets decreased! Then you change from 60 to 85%, and it again decreases; even if you edit and just enter the same value (70 -> 70), it still reduces the [number of plays] because the expression is still executed.
With plan B you can just have [Watched] be a standard field holding a number from 0 to 100 (percentage), with DisplayExpression = If(IsEqual([Watched],100), ✔, [Watched]%). When you edit the field you can still have the dropdown of values - what it then displays is dependent on the current field value. You can also have another field for [Number of Plays], but that's independent.
As for the [Artist] tagging, all tag suggestions/dropdowns/autocompletes would still work with the DisplayExpression values, while the actual underlying stored value would be the raw value. The concept is simple - anywhere where a name is *displayed* onscreen, it uses the DisplayExpression; but the underlying value to be stored would be the corresponding raw value.
-
Well, I would prefer it all to be done in one field, and to be simpler to understand, but...
Zybex, if I wanted to correct the spelling for an [Artist] field that displayed swapped as "Swift, Tailor", how would I know to enter "Taylor Swift"? That is the level of question that most users would have.
I can think of a simple way, and I'm sure you can too. Just display the raw data when you edit the field. But that doesn't happen in any existing functionality now, so it would require changes to the MC core functionality.
What about in drop-down lists and during Pane editing? You would want both to sort by "Lastname, Firstname", because that is what you see when viewing the data, but if that is the case, how would a user know to enter "Firstname Lastname"?
Also, you would have to read Glynor's whole thread on his custom Watched field to understand why he is suggesting what he is for that example. The [Watched] and [Number Plays] fields are not independent, even in standard MC functionality.
If the issues with using a single field with existing functionality could be resolved, that would be great. But there is some thought required on that. Some detailed thought. Probably by developers who understand the underlying mechanisms used in MC.
-
Zybex, if I wanted to correct the spelling for an [Artist] field that displayed swapped as "Swift, Tailor", how would I know to enter "Taylor Swift"? That is the level of question that most users would have.
I think it is worse than that. You wouldn't be able to use the Panes or combobox drop downs (in a grid-style File Listing View) at all. They just wouldn't work, at least without a substantial re-coding. And typing in the box manually, even if you could see the "original values" wouldn't always be useful.
I think the fact that "Taylor Swift" and "Swift, Taylor" are related terms (easily "mentally" transformable) is confusing the issue. That's why I tried to explain with a simpler example above, but maybe a different simple example would be more clear.
Imagine you want to make a basic enumerated type field where you can choose between three different pre-selected "audience sizes" with a default value of "empty/unset". So, you create an [Audience Size] Integer Field that can contain 0-5. When this shows in Views in MC, you want to display:
0 = blank
1 = tiny
2 = small
3 = medium
4 = large
5 = huge
Since this is an ordered list, it is handy to do it as an integer-based enum like that because you can then do math on it. So, for example, to search against this field you can do [Audience Size]>[2] to find all the files with medium and larger audience sizes. To determine if the audience for file x is "larger than" file y, becomes if (x > y).
So, you write a Display Expression that does IfCase() and spits out tiny, small, medium, large, and huge when appropriate, and you have this field added as a Category in a Panes-style View. You have a brand-new file that just imported, and so [Audience Size] is set to 0 and it is listed under "Unassigned" in the Pane. You select it in the file list, and check the box next to medium in the Pane.
How does it know to assign it as 3?
The expression language is a one-way text transformation language that works on one file at a time. For each file, your IfCase() expression turns the value into "medium", and then the Pane displays that list of values. It doesn't get any integers at all, and doesn't know that the integers exist.
So, when you go back the other way, and try to write to it by checking the checkbox next to "medium" in the panes, how does MC know to write 3 to the field? To know to do this, it would have to be able to run the expression you defined "in reverse" and re-convert medium back into 3. But because the expression language operates on text, they're not all simple 3 = "medium" dictionaries. They can have very complex logic that can't be trivially "auto-reversed".* Even this one would be difficult. What if the text says "MeDiUM"? Should it be case insensitive and reverse it to 3, or case sensitive and error or spit out 0 for unassigned? You can't define the behavior, because there's no way to include the case sensitivity logic in your original expression, because it doesn't "go in that direction".
So, you can't reverse them without the user providing the method. And without being able to reverse them automatically that would totally break the Panes and "dropdown comboboxes (in grid-view and in the Tag AW). To fix it, they'd almost certainly have to dramatically recode the whole system to pass through both "original values" and "displayed values" and keep track of both as "objects" in the panes (which would also likely impact performance).
Beyond that, if you do just give up on the Panes and combobox pre-filled values, and intend to hand-type everything. It still becomes an issue. So, when you edit the field, your suggestion is to have it just effectively "turn off" the Display Expression functionality and let you "see" the underlying data any time you "edit" that field with a keyboard.
Well, continuing my audience size enum example, you select the field in the Tag AW ready to type in your value. It turns off the display expression, and so your currently-blank file shows 0 in the box. What do you type there to make the file turn into "medium"? How do you know to do that?
Sure, you could write some kind of instructional "how-to" that pops up somewhere. But you'd have to type it up when setting up the field (and maintain it as you add additional sizes to your enum), and it could quickly become unwieldy. What, happens when you're using an enum for colors or something, and there are 32 or 64 of them possible?
Obviously, it would be much better if you could just pick "medium" from the drop down, or type "medium" (or "MeDiUM" because your reversing IfCase() is doing IsEquals() in case-insensitive mode) and have it set the value to 2 for you. And bonus, the Panes and comboboxes work again.
Those are all big problems with doing it in a single field at least as I understand it. You'd have to be able to define both a Getter and a separate Setter function (https://docs.microsoft.com/en-us/dotnet/csharp/properties#scenarios) in order to do the transformation both ways.
* The Swap() and Unswap() dilemma is a perfect example: the language doesn't "know" the Swap() and Unswap() are effectively the reverse of each other. So it wouldn't know that when "Swift, Taylor" is coming in "one end" of the expression, how to use Unswap() to turn it into "Taylor Swift" before writing it to the file item in the database.
-
Glynor, you keep misunderstanding a key part of what I'm saying even though I've repeated it a few times. I'm just saying we don't need the "write-to" functionality (it can be done in a single read/write field), but you can still have the InputExpression to process what the user enters. These are two independent features.
The only difference between proposal A and B is where the raw field value is stored - in your case it's in a different field, in my case it's on the same field. Nothing else. Everything else can be done as per your proposal.
Your idea has a field 1 that is read/write, and a field 2 that is read-only. I'm saying we don't need the read-only field to implement your idea.
Edit: To clarify (I hope) - in your proposal, you need a Field2 of type "Calculated", with some ExpressionX, and pointing to a write-to Field1. What I'm saying is that you can simply enter that same ExpressionX as the "DisplayExpression" of Field1. Everything else of your proposal can be added on top of this. DisplayExpression is the Getter, InputExpression is the Setter (better call it SetterExpression)
-
Difficult, isn't it?
I think we (Glynor and myself) have been hung up on the current functionality of Calculated fields.
So Zybex I think what you are saying is that you don't use a calculated field (which is more or less read-only) anymore, but use a new field type that has a "Display Expression" and a "Commit Expression".
So in the Audience size example (because examples work way better for me).
- The raw data held in the [Audience Size] field would be integers from 0 to 5.
- The "Display Expression" would convert that raw data to the text equivalents of those integer values, probably using IfCase() expression. Easy enough.
- Theoretically, the text value would be presented in all Tag AW edits, Panes views, or View columns for in-line editing. Drop-down lists would present the text values.
- When I user does as edit, the "Commit Expression" would reverse the text value selected back to an integer, again probably using an IfCase() expression.
The [Audience Size] field, being an integer, can be used in maths expressions as required, probably using the [Audience Size,0] format. That would be consistent with, for example, the [Date] field, which is a decimal number but has a "Display Expression" hardcoded into MC. The [Date] field actually also has "Commit Expression" hardcoded in MC, as I can enter "25/09/2020" (yes, I know, "09/25/2020" for you Americans) and that will be converted to a decimal number representing that date.
In fact, the [Date] field has a sophisticated "Commit Expression" that lets a user enter just "2020", or "25/09", and it will interpret what the user means, most of the time. The [Audience Size] field "Commit Expression" could handle similar though much simpler data entry, such as accepting either the numerical value or the text value, and still select the correct numerical value to update the field with. That could even be facilitated by having the "Display Expression" output combined values, such as "3 - Medium", rather than just the text value. That would allow fast manual data entry, if that was desireable.
So Glynor, forgetting existing Calculated Field functionality, if we had the ability to set up a user defined "Display Expression" and "Commit Expression" for this new field type, and these fields worked much like the [Date] field does now, would that do everything you want?
My brain hurts too much to go back through the discussion and validate that proposition.
-
So Zybex I think what you are saying is that you don't use a calculated field (which is more or less read-only) anymore, but use a new field type that has a "Display Expression" and a "Commit Expression".
Right, though I think there's no need for a new field Type - just adding optional settings on the existing fields for the Display and Commit expressions (except on Calculated fields - these would remain as-is, read-only). It should work for existing types of string/decimal/percentage/list/etc. The different options for "edit type" might require some thought but should still work, as would the "list of accepted values" for a dropdown.
-
Yeah, I just meant not using the Calculated field functionality, which is currently activated by selecting the radio button.
Correct on the "Edit Type" and list of "Accepted Values". Even the Relational functionality might work, although that would be a corner case! So basically an extension of standard "User Data" type fields.
-
Glynor, you keep misunderstanding a key part of what I'm saying even though I've repeated it a few times. I'm just saying we don't need the "write-to" functionality (it can be done in a single read/write field), but you can still have the InputExpression to process what the user enters. These are two independent features.
The only difference between proposal A and B is where the raw field value is stored - in your case it's in a different field, in my case it's on the same field. Nothing else. Everything else can be done as per your proposal.
I got completely that you intended to eliminate the distinction between User-Data and Calculated Fields. I didn't realize you were suggesting the Setter Expression (as opposed to RoderickGI's suggestion of an instructional display) also be added to the standard fields, but... There is one other important difference, and it would be complicated to work around.
How would you access the underlying (unmodified) field? So, with my silly audience size enum example, when I use it somewhere (in another Expression, in a Pane, in the Tag AW, etc), how do I specify if I want the original raw value or the expression-massaged value? How do I tell it I want to read or write "2" or "medium"? If I'm swapping artist proper names, how do I display "Taylor Swift"? You'd need some new Expression and Search Language functionality (and corollaries throughout the UI) in order to "unify" Calculated Fields and User-Data Fields like that, otherwise you could never access the underlying field value.
With my suggestion, the [Artist] field is still just waiting there, working like it always did, with the value in it, so you don't need any new language features, display features, or the like.
And that's why Object Properties in C-based languages are based on private variables. Because sometimes you don't want to go through the Getter and Setter, and sometimes you do. Sure, you could invent a new mode to the field() command that bypasses (or enables) the Getters and Setters. But you've now just reinvented the wheel.
I think it would be simpler to just keep User-Data Fields as they are now: plain old variables.
And Calculated Fields like they are now: Properties. Only instead of having them be always read-only properties with no setters, you can optionally pick your own user-data field as a "backing variable" and define a Setter.
I don't care what the options are called. But that seems to me to require the least overhaul of the current system in MC, and the least new functionality. Asking for incremental change always wins when you're asking JRiver for something new. Don't fix what isn't broken.
But if they really feel like doing it that way, sure. It would work either way so long as they implement all of the things discussed above and eliminate the distinction between user-data fields (simple variables) and calculated-fields (expression based properties). To me, that's a lot of work for no benefit other than to eliminate a single combobox where you pick your backing field for your Calculated Field.
-
How would you access the underlying (unmodified) field?
This already exists:
[Artist]
[Artist,0]
Also, calculated fields would keep existing just as they are now, no change for them.
As for implementation effort, I have the opposite view - this requires much less effort as it's just simple changes to the field Getter and Setters (which already exist for sure, to handle the many special cases/fields already in MC). Some pseudo-code:
Field::Get(bool rawValue=false)
{ return (rawValue || Field.DisplayExpression == null) ? Field.Value : Evaluate(Field.DisplayExpression); }
Field::Set(string value)
{ Field.Value = (Field.CommitExpression == null) ? value : Evaluate(Field.CommitExpression, value); }
The LinkedField idea is more complex as it requires:
- validation of which fields to show on the LinkedField dropdown
- Setter is now recursive, as the user may have chains of linked fields
- Setter must detect and handle loops, and prevent stack overflow caused by excessively long chains (MC already does this when evaluating expressions)
- deleting a field now needs to check if there's some other field linking to it
- FieldA writing to FieldB may even interfere with the clean/dirty detection of Database files - writing to a field now causes multiple files to be updated, instead of a single one.
- other side effects of these chains will need to be carefully evaluated
-
How would you access the underlying (unmodified) field?
I know I write too much, so things get missed, but I did include that in my Reply #42 (Hey, the Meaning of Life, The Universe, and Everything!)
The [Audience Size] field, being an integer, can be used in maths expressions as required, probably using the [Audience Size,0] format.
Also Glynor, you are still thinking Calculated fields. The Zybex solution isn't a Calculated field, as the value isn't defined by an expression independent of user input. It is a field written based on user input. Those are very different things. User edits aren't thrown away, they are processed by the Commit Expression.
As we know, Display Expressions are used throughout MC, only they are hard coded. My [Date] field example is the most obvious.
Having thought overnight, JRiver may want to flag these fields as different to standard "User Data" type fields, so that MC doesn't have to look to see if the fields have a Custom Display and Commit Expression, just to avoid a potential performance hit. But maybe that isn't even a potential problem.
So, ignoring the technicalities of implementation, my question from last night stands:
So Glynor, forgetting existing Calculated Field functionality, if we had the ability to set up a user defined "Display Expression" and "Commit Expression" for this new field type, and these fields worked much like the [Date] field does now, would that do everything you want?
.
.
.
Okay, one small comment on the Taylor Swift example. When [Artist] is imported from an external source, as is common practice it will be in the format "Taylor Swift". The [Artist] field will need to have a Commit Expression, and the data would be written as "Swift, Taylor". Modifying existing standard fields such as [Artist], which already has a lot of functionality built around it, may be an issue for JRiver. That may not happen, and generally doesn't. The underlying MC database structure hasn't been changed since MC18 I think, which is why Library Backups from MC18 still Restore to MC27. New fields have been implemented as User fields. So, all that could be a stumbling block.
Also, there is potential that the Zybex solution would clash with existing hard coded MC Commit Expressions. Either you would have to drop the hard coded processing and just use the user version, or MC would need to accommodate both, which may not be possible. You could not use this functionality on the [Date] field, for example. There may be other restrictions. Hence, another reason why fields that use Commit Expressions may need to be explicitly identified, and if they can't be, it means that JRiver has decide the field isn't allowed to use them.
-
This already exists:
[Artist]
[Artist,0]
You're totally right. I forgot about that, and that would work. And I finally see what you mean.
- Setter is now recursive, as the user may have chains of linked fields
- Setter must detect and handle loops, and prevent stack overflow caused by excessively long chains (MC already does this when evaluating expressions)
It hardly matters, but FWIW, I removed that from the suggestions earlier by limiting the Write-To Field to only User-Data fields. The building chains idea was a bad one.
But I think we've gotten somewhere in the discussion which wasn't completely clear earlier around the edges of how the entire design could work better. The core of the thing is the Setter function, really, not the Getter. The existing Calculated Data functionality is, effectively, already letting you define a Getter function with an expression. It just can't reference itself (an underlying private variable).
Also, calculated fields would keep existing just as they are now, no change for them.
If this is done, and you convinced me it is better, then it would (IMHO) make more sense to rearrange that section of the Library Manager a bit though. The Disabling\Enabling of the Edit Type and Show a Link Checkbox options is already weird anyway, and this is a good opportunity to clean that up and make it all easier to understand.
I have an idea on that, but I'll put it in a different post to summarize and see if we all agree?
I know I write too much, so things get missed
Yup. I do too, and I get it. But yup, I missed that. Sorry. Realizing that was there already is what made it "click" for me, finally.
-
;D 8)
-
So, with all of this in mind, I think actually describing the change to the UI of the Library Field Manager might be the simplest way to explain the idea fully. And, looking at it closely, I think you can fix a few other organizational issues in there that have crept up over time, without going too crazy and revamping the whole thing (which is good because UI programming is a PITA).
How about this?
_Name_ - Unchanged
_Data_
[✓] User Data - when unchecked, disable indented below and Input Expression.
Data Type [__]
Relational [__]
Acceptable Values [__]
[✓] Save in file tags (when possible)
[✓] Input Expression - when unchecked, disable indented below
[expression editor] - See Note 1
Edit Type [__] - Always enabled.
[✓] Show a Search Link - Always enabled. See Note 2
[✓] Output Expression - when unchecked, disable indented below and enable User Data above.
[expression editor] - See Note 3
_Search_ - Unchanged
Notes:
1: This is the Setter expression, which allows you to transform the user's input before it is saved. This expression is evaluated when the user edits the value, and the result is saved to the User Data variable.
In an Input Expression, if you use square bracket [This Field's Name] notation, it substitutes the input from the user. If you use [This Field's Name,0] notation, then it substitutes the current value of the User Data variable (before the edit).
Since you can only enable this if User Data is also checked, you could put it "under" User Data in the grouping hierarchy. But, doing it this way allows you to get rid of the gigantic Expression: label and that wasted space (http://glynor.com/img/screenshots/MC27/Library_Field_Manager-Wasted_Expression_Label_Space.png). Instead you can expand the width of the expression edit box to nearly the whole width of the panel. Which also probably lets you make them a bit shorter, and so easier to fit the two expression editor boxes in the same overall Library Panel size. And, it'll look nice and symmetrical with the Output Expression box.
2: This is the existing [✓] Show a link checkbox item, which is clumsily named (and it isn't even a checkbox anymore, it is an arrow).
3: This is just the existing Calculated Data expression editor box, exactly as it works now, except you can enable it along with User Data. When you do, the field outputs the output of the expression instead of the User Data value.
If you use square bracket [This Field's Name,0] in the expression then it substitutes the "underlying" User Data value. I'd say that if you use [This Field's Name] notation (without the ,0) then it should just do the same thing. But maybe returns blank? In any case, if [✓] User Data is unchecked (so, the equivalent of a Calculated Data field now), then both substitutions return a blank value.
You can save the space of the giant Expression label here too, and make the box wider (and possibly a bit shorter).
I think that would do it. It would be clean, and allow cleanup of some strange enabling/disabling behavior and hierarchical positioning in the current Library Field Manager. And it is easier to understand than the current setup.
It also isn't a dramatic change in the UI. It would be easy to convert the settings upon upgrade, because the all current Calculated Data expression just become [✓] User Data: unchecked and [✓] Output Expression: checked. Everything else stays the same.
I like it. A lot.
Edits: The forum list formatting was making me crazy. I'm sorry, I'll stop poking at it now.
-
Great, my brainwashing finally worked ;D
I admit I also skimmed some of the longer posts, and while trying to write small/concise explanations for the idea I probably didn't explain it as well as I could. In the end we got to this second page with a consensus, which is nice 8)
I saw that the "Calculated Field" type could be generalized as you did above, but didn't want to say it because I thought it would further complicate the discussion. It's an obvious corollary though, glad you saw it too.
The mockup above is cool! Notes on that:
- "Edit Type" is currently always enabled, but I think it's a bug in the current UI. It makes no sense to have it for Calculated fields. I tried it, and it does allow you to edit the value of a Calculated field... but then nothing happens, the value is just discarded. So this option should be under "User Data" and be enabled/disabled along with the rest.
- I prefer "Display Expression" and "Commit Expression", but Input/Output also works
- "Show a Search Link" could go under the Search section
Other notes and problems:
- Backup/Restore work at the DB level so they should always bypass the expressions and just backup/restore the raw field values;
- same for sidecard export/import
- However, CSV export is ambiguous... we might want to export the Display value or the Raw value, depending on needs/context/field.
- What about when Importing files? The imported tags should be considered Raw values, or should they go through the Commit Expression?
- Conversely, which value should go into an MP3 when tagging it from Field values?
- Same for the File Move&Rename tool, though there we could use the [field, 0] syntax as needed I guess.
I can see other problems with the Setter implementation, but I'll leave those aside for now.
[img width= height=]https://i1.wp.com/blogs.perficientdigital.com/files/2011/07/treecomicbig.jpg[/img]
-
I think the developers would need to fully evaluate all the implications of rearranging the dialogue, but I'd be happy enough if that was done.
Some feedback:
I'm not real happy with the name "Output Expression". I am thinking of the majority of users, and how they would interpret that name. We have been using "Display Expression", or at least I have, because it immediately tells me what this expression does: It defines what is displayed for the field, based on an expression, which implies on the screen. "Output" could mean the output of my data entry. The question is bound to arise, "Which direction is output?" I'm not going to get on my soapbox over the name, but that is my feeling about the currently proposed name.
"Input Expression" is far less of a concern. I used "Commit Expression" because I have a tiny bit of a database background, and Commit to me means something being saved to a database. "Save Expression", as in "What is saved to the Library" might be more meaningful to the majority of users. But I could live with any of those three.
I am not as convinced that the "Output Expression" with the "User Data" flag turned off is exactly the same as the current "Calculated Data" functionality. Your terminology is part of the problem here. I don't really know what you mean by "User Data Value" in Note 3. I think it should mean the current content of the field. But it could be what the user just entered on screen, or it could be what the user put in the field previously.
Regardless, the current "Calculated Data" functionality is, as you have noted, read-only and any data input by the user into a Calculated field is basically ignored and discarded. The contents of such a field is always equal to the result of the expression defining it. As such, it isn't just a manipulation of the data stored in the Library field for display, but is in fact what is stored in the Library field. For a Calculated field called xxx, there is no difference between the value returned using [xxx] and [xxx,0]. The Raw data is always the same as the Display data.
Now, if not having the "User Data" field checked changed the way the "Output Expression" box was used, and it now acted exactly as the current "Calculated Data" functionality, I would be happy with that. Re-using dialogue realestate is a good thing, when functionality is mutually exclusive. However, if the box was used that way, I would like to see the box heading, "Output Expression" or "Display Expression" set to "Calculated Data" until the "User Data" field is checked, to avoid confusion. Or maybe it would be easier to just continue using a radio button for "User Data" and "Calculated Data", and just have the expression entry box collapse when appropriate. Again, a JRiver decision I think.
My main point there is that the "Display Expression" as we have discussed it is not equivalent to the "Calculated Data" functionality as it exists today.
Otherwise, I'm happy. :D Except you kept editing your post as I was reading it Glynor! I had to keep refreshing to be sure nothing changed! 8)
PS: Zybex beat me. It seems we need to discuss "Calculated Data" further. Cool. We are getting there.
My starting point with the export, import and tagging question would be that they always use the raw data. But they would all need to be looked at carefully. Basically, we are just looking at taking raw data and changing how it is displayed, and taking data entry and changing how it is saved. The underlying data should be consistent with external data sharing. Think about the [Date] field as an example, where it is the raw data written to tags, except where there is special code to write that data to different file tags, which may alter it before writing. Usually though that is just reading and writing the raw data to different tag names, rather than changing the data.
PPS: I'm the Business Consultant Zybex. ;)
-
PPS: I'm the Business Consultant Zybex.
I'll get started on the documentation. ;D
-
After thinking more on the "Calculated Data" issue, you might be able to convince me.
I always thought of Calculated fields as holding content, being the calculated value. But maybe they don't, or maybe they don't need to. They are always re-calculated whenever they are accessed, so essentially thinking about it that way, it can be just a Display Expression. As long as the [field name] and [field name,0] functions work correctly, with the field being recalculated for display every time it is referenced, I can see that there would be no real difference.
I guess that depends on how the "Calculated Data" functionality works under the hood now. I don't know what it is doing, whether it is saving a value to the field for use in Views and so on, or recalculating every time.
Zybex, the documentation seems like a fair share of the workload for us. :D
-
I meant Documentation as in the cartoon above ;)
Calculated fields are calculated on access, there's no stored value. Perhaps MC does cache the latest calculated value for performance, but that's an implementation detail. In effect, it's as if there's no stored value.
I don't even think that's the case - try this: add an Expression column with expression="counter()". This just increments the value each time the expression is recomputed. Now... just HOVER the mouse over this expression column, moving it up and down over a few files, or click on some files... and the values change like crazy, indicating that the expression is being recomputed. Highly inefficient, but perhaps there's a reasoning for that that we are not aware of.
Anyway, for all intents and purposes, the traditional "Calculated Field" is the same as just setting the "Display Expression".
-
I meant Documentation as in the cartoon above ;)
Yes, I understood that. No work seems fair to me!
try this: add an Expression column with expression="counter()".
Yes, I was aware of that. But that is an expression column, which could be handled differently to a Calculated field. Let me check something... Okay, a Calculated field works the same way. I set up a field with an expression of Now() and it continuously updates. In fact, it updates on any screen refresh, such as moving a divider, not just on mouse over.
Anyway, for all intents and purposes, the traditional "Calculated Field" is the same as just setting the "Display Expression".
As that does sound like the case, I guess my concerns are satisfied on that point.
I wonder what JRiver thinks of all this?
-
I wonder what JRiver thinks of all this?
[Jim] Hmm, there seems to be some heated discussion around this feature request, doesn't look like everyone agrees. I'll skip this thread.
[Matt] Jeez, so many huge posts! Can't these guys make simple requests??? I'll wait for Jim to say something.
[Yaobing] CTRL+F, "TV"... no hits, I can skip this thread.
[Hendrik] *** users! ... back to Warcraft.
-
I'm not real happy with the name "Output Expression". I am thinking of the majority of users
I didn't finish reading, but I just wanted to make two comments:
1. I don't care very much what names they use.
2. I do think, Display Expression, is particularly bad. Because that is no small part of what it was confusing me all this time. I was hung up on the word "Display".
It isn't just for display. That's why I thought it needed "new functionality" to implement the idea. Because I thought you were saying "apply this expression ONLY when the field is displayed" (in the panes and whatnot), but in other expressions treat it as the Value. So, in a pane, grid-view, etc [Artist] would show as "Swift, Taylor" but in an Expression, it would substitute as "Taylor Swift".
MC can't do that now (output of the field is the output of the field, and a field only has one default output which applies both to display and to expressions). And that would have been very confusing and difficult to use. Because it implies that the expression will only be used "on display", which it can't be (or the whole thing falls down - see basically all of my arguments for this entire thread).
I chose Output Expression because that's what it does: An expression that determines what the field outputs. And it matches nicely with Input Expression, which is an expression that filters the user's input.
Again, though, I'm not that picky. But, based on my own experience here, I think "Display Expression" is a particularly bad name.
-
- "Edit Type" is currently always enabled, but I think it's a bug in the current UI. It makes no sense to have it for Calculated fields.
Sure does. I use it all the time.
Make an expression that outputs 0 or non-zero (usually one, but it doesn't matter, blank or something works too). Set the Edit Type to Check. You have an expression field that outputs a row of checkboxes. Same goes with Five and Ten Stars, Large Value, and List. Clear-Only isn't useful now, but if you could input on Expressions, it would be (so that you could use it like an informational display + reset control).
It is just annoying that the system doesn't "know" they're read-only checkboxes (which is part of what I was complaining about above). But, this would solve that. If you have only Output Expression checked and not User Data (the equivalent of current Calculated Data fields) then you display using the selected Edit Type but always read-only the editors.
You used to not be able to access that setting for Calculated Fields, and they added it back in on purpose (after much complaining by, in no small part, me). That is part of the reason the current Library Field Manager layout is so wonky (same goes with the Search Links thing).
-
- "Show a Search Link" could go under the Search section
Sure. That would work too.
Other notes and problems:
- Backup/Restore work at the DB level so they should always bypass the expressions and just backup/restore the raw field values;
Well, a Library Backup also includes all Field definitions (including current Calculated Fields), Views, and everything else too, so yes, but it would include both.
- same for sidecard export/import
- However, CSV export is ambiguous... we might want to export the Display value or the Raw value, depending on needs/context/field.
- What about when Importing files? The imported tags should be considered Raw values, or should they go through the Commit Expression?
- Conversely, which value should go into an MP3 when tagging it from Field values?
If Save to File Tags is enabled, it should save the raw values to Sidecars and file-tags. That's the "stored data". You don't save current Calculated Fields to tags (that option stays off if User Data isn't enabled) so, that stays the same.
CSV exports should get the final, formatted values, IMHO. That's how it works when you copy/paste to Excel from a view onscreen, and CSV export is the same thing. If you want to export the "raw" User Data values, then you export [Field Name,0].
- What about when Importing files? The imported tags should be considered Raw values, or should they go through the Commit Expression?
My opinion here, but it isn't super-strongly held, is that it should absolutely follow the Input Expression, just as it would when entering User Data "manually". In fact, doing this would make my Tag on Import rules quite a bit simpler, because I could just put the logic for all of the stuff it does now to massage "it's own field" in the Input Expression instead.
Tag on Import wouldn't have to change, mind you. You just wouldn't need to do those kinds of things there.
Nope. All of that is wrong and backwards. You'd NOT want to apply the Input Expression for new file imports, as that would double-convert values like "Taylor Swift" (already in the right format).
Imports ignore Input Expressions (which only apply to user-edits).
- Same for the File Move&Rename tool, though there we could use the [field, 0] syntax as needed I guess.
Definitely use the [,0] notation to access the "raw" User Data values everywhere in MC, including RMCF. I absolutely want to use this for RMCF. That's a big hunk of what I want to accomplish with it, and I want to be able to access both raw User Data (with [,0] and "normal output" via []).
[Field Name] always accesses the formatted Output. [Field Name,0] always accesses the User Data (if enabled). If User Data isn't enabled, then [Field Name,0] outputs blank.*
The only exception would be my two notes, in the expressions used where it refers to itself. There, you can't actually reference the field's own output in the Output expression, as that's a loop, and you need a way to "grab" the user's input for the Input Expression. So, my suggestion for the syntax for these is:
- Input Expression - [Field Name] is user input, and [Field Name,0] is the current User Data value (before the edit).
- Output Expression - [Field Name] and [Field Name,0] are equivalent and both show the User Data value (or blank if User Data is disabled).
For the latter, you could always "force" the author to use [Field Name,0] and have [Field Name] just return blank. But I'd say just make them both do the same thing for simplicity of use.
* Edit: Or you could have [Field Name,0] output the equivalent of [Field Name] if User Data is disabled. I think it might be nice to be able to get "blank" for these in some cases (and more consistent throughout MC), but I don't have a strong opinion here.
-
[Jim] Hmm, there seems to be some heated discussion around this feature request, doesn't look like everyone agrees. I'll skip this thread.
[Matt] Jeez, so many huge posts! Can't these guys make simple requests??? I'll wait for Jim to say something.
[Yaobing] CTRL+F, "TV"... no hits, I can skip this thread.
[Hendrik] *** users! ... back to Warcraft.
I think this is probably fairly accurate.
Once we decide on everything and agree on all of the little edge points (and I think we're very close, if not there now), I intend to start a new thread with our final proposal (and link back to here for the original discussion). Or just poke them and point to a single, definitive post at the end, if we can make one.
-
Make an expression that outputs 0 or non-zero (usually one, but it doesn't matter, blank or something works too). Set the Edit Type to Check. You have an expression field that outputs a row of checkboxes.
Thanks, TIL.
-
I always thought of Calculated fields as holding content, being the calculated value. But maybe they don't, or maybe they don't need to. They are always re-calculated whenever they are accessed,
You were thinking about it wrong. They are not now the way you envisioned it in your mind. There is no data in the database for Calculated Fields (other than the definition of the field). They are calculated when accessed.
Calculated Fields as currently implemented already are the Output Expression we've been discussing. They're identical.
That's why my original idea would have worked. But this is better and cleaner.
-
I actually like the idea you all have come up with. It would definitely be useful in certain situations, and a lot of good thinking has gone into this thread.
I'd be a little trepidatious about really asking for it though. It is a complicated request, that would serve a niche purpose for a limited number of people. The change goes deep. There are many other things that have been needed and ignored for years that would be more beneficial to a larger number of people. Just a couple of examples: making dsp presets work more effectively; and providing better built in support for the multi-track compositions of classical music. There are others of course. Not to mention the D word, which will never happen anyway. If a group of influential individuals is going to come together around a big idea to push for it, I would want it to be something that would provide a big benefit to a lot of people.
I'm just worried about the distraction of resources it would cause. Cost/benefit. I like the idea though, so please don't think I'm denigrating it. Thanks to all of you for the effort you put in on this thread.
-Will
-
I'd be a little trepidatious about really asking for it though. It is a complicated request, that would serve a niche purpose for a limited number of people. The change goes deep.
Not really.
We need three basic things:
1. The Input Expression functionality.
2. Change the Library Field Manager Calculated Data and User Data setups from radio buttons to checkboxes (so that you can check one, the other, or both simultaneously.)
3. The syntactic sugar for [Field Name]. And this only applies to the Input and Output expression definitions, really. The [Field Name] and [Field Name,0] syntax already exists and already does what it does.
The rest of the rearranging of the dialog I put above is all to fix issues which already exist in the setup as things have changed over time and Calculated Fields got access to the Edit Type and Search Link functions.
That's pretty much the beauty of the idea. It doesn't go extremely deep. It is the Input Expression (the Setter functionality) and the ability to enable both Output Expression (aka Calculated Field mode) and User Data at the same time.
Everything else stays exactly the same. All of your existing Field Definitions stay exactly the same (just the radio buttons turn into checkboxes, but unless you go in and fiddle them, they'll be the same as they were).
-
3. The syntactic sugar for [Field Name]. And this only applies to the Input and Output expression definitions, really. The [Field Name] and [Field Name,0] syntax already exists and already does what it does.
It is worth discussing this briefly.
So, the idea would be if you define a field where you check both: [✓] User Data and [✓] Output Expression that you'd use:
[Field Name]: result of Output Expression
[Field Name,0]: value of the stored User Data variable
That's clear, and does exactly what it does now (you just can't actually "check both boxes"). That is the key piece that makes the idea work (hence my "ah-ha moment" earlier).
The only part where it gets clouded is using self-references to the field in your Input and Output Expressions. For the Input Expressions, [Field Name] wouldn't make sense. For the Output Expressions, using [Field Name] also doesn't make sense (it would be a self-referential loop). But that's already the case now (so no change there).
But, you need a way to get input from the user in order to act on it in your Input Expression. So, I figured re-use the otherwise useless [Field Name] notation on the Input Expression to allow you to access the user input. But that's just syntactic sugar.
But, maybe that is confusing the issue? Underneath the covers, it is effectively going to point to a new Input() function, and wrap it in square-bracket [Field Name] notation. You could make it use [Input] notation instead and leave the [Field Name] in input and output expressions alone. The only problem with that is it does introduce a "breaking" change for some people, because if you already have a field called [Input] then you're screwed. And, the only place where you'd ever need the Input() function and its square-bracket version would be in the Input Expression definition.
So, doing the sugar and using the [Field Name] notation to refer to Input() is better, IMHO: It reads better in the expressions, and it doesn't cause that issue.
Thoughts?
-
I think it's fine to reuse the [Field] notation. Something like this:
[Field] [Field,0]
Input Expression: newValue Field.Value
Output Expression: Field.Value Field.Value
Elsewhere: Field.Output() Field.Value
- newValue is the user input being processed for storing
- Field.Value is what is currently stored (raw value)
- Field.Output() is the Output function (or Field.Value if no Output expression is defined)
-
Wer, it's not that complicated to implement as it is now - it's simpler than the initial proposal from Glynor; it's fundamentally just adding a couple of new Field options, tweaking the Field Getter/Setter, and some minor UI design.
In the end it's up to JRiver folks to prioritize their TODO list. Personally, I don't think this feature will rate highly on their queue... but it's worth a shot.
-
I think it's fine to reuse the [Field] notation. Something like this:
[Field] [Field,0]
Input Expression: newValue Field.Value
Output Expression: Field.Value Field.Value
Elsewhere: Field.Output() Field.Value
- newValue is the user input being processed for storing
- Field.Value is what is currently stored (raw value)
- Field.Output() is the Output function (or Field.Value if no Output expression is defined)
Yup. That's exactly what I was thinking.
-
I agree CSV exports and Copy/Paste should be the formatted value, [Field Name], which are the displayed values as a result of the Output Expression. Users would expect the displayed value to be what shows up in a CSV file, or the clipboard.
The Input/Output, Commit/Display Expression naming doesn't matter too much to me, as long as it is properly documented. I was coming from a user perspective, Glynor I think your deep knowledge of MC meant you were thinking of the existing underlying behaviour of MC and terms used to describe it. Zybex is a programmer, so "Yeah, whatever works, I understand it". ;)
The subtle difference that the Display Expression may be used when the field isn't actually displayed wouldn't mean much to most users.
-
Reading and writing tags from/to files needs a little thought, although there may not be an issue.
Consider the [Date] field in MC again. It is a numeric value, but it is written to the "DATE" tag in human-readable format. In fact, MC currently only writes the year to the "DATE" tag, and it isn't the [Year] field, which is a calculated field that formats the [Date] field. It derives from the [Date] field directly, or appears to.
The raw numeric data in the [Date] field is written to another file tag, the "JR_DATE" tag, but only if the [Date] contains a decimal number rather than an integer. i.e. If the [Date] field only contains a year value, then the "JR_DATE" tag isn't written.
On importing a file the human-readable format "DATE" tag is written to the [Date] field, but in numeric format. So while we agree that the Input Expression is bypassed, there is still processing done by existing hard coded rules.
Will this proposal affect the tag mapping in MC?
While I am thinking of the [Year] field, it is an example of some exceptions that occur in MC to the normal rules. It is a calculated field, and as we have said, when a user enters data into a calculated field it is normally ignored and discarded.
However, enter data into the [Year] field and it is validated and saved, and at the same time the [Date] field is updated with the new data. There is some special programming around those two fields. The expression used for [Year] cannot be edited. [Date] is flagged as a User Data field, and that cannot be change. [Year] cannot be flagged as User Data. [Name] is another field that is treated specially.
How will this interact with the new functionality?
What would happen if this functionality allows [Year] to be flagged as User Data, and an Input Expression added to it?
Will some fields be locked so this functionality can't be used with it?
What fields will be locked out of using this functionality?
Will locking out some fields reduce the value of the proposal?
Will this change, or require change, to the definition of USer Fields?
(As I mentioned previously, JRiver has been adding fields as User Fields so that the database didn't need to be changed, which would impact Library Backup compatibility. For example, [HDCD] is a User Field.)
Basically, there is some internal coding around field types which is not visible to the user. More than just Hidden fields.
So, when using the Output Expression, are we assuming that hard coded formating built into MC will still be applied, and that it will be applied after the Output Expression? Or before? If so, are there any other consequences, for any of this proposal?
-
I have expanded your table Zybex. I don't know if the additional information is correct, or agreed, but it is based on posts above. I may have missed something. Comment?
User Data selected User Data unselected
[Field] [Field,0] [Field] [Field,0]
Input Expression: newValue Field.Value N/A N/A
Output Expression: Field.Value Field.Value <blank> <blank>
Elsewhere: Field.Output() Field.Value Field.Output() Field.Value*
- newValue is the user input being processed for storing
- Field.Value is what is currently stored (raw value)
- Field.Output() is the Output Expression (or Field.Value if no Output Expression is defined)
I have asterisk one cell, because currently "Calculated Data" does work differently when [Field Name,0] is used instead of [Field name]. Some formating is applied to [Field name], but is not applied to [Field Name,0]. For example, I have a numeric Calculated field that displays to six decimal places using [Field Name,0], but only to two decimal places using [Field Name].
This may be true for non-calculated fields as well.
Basically, the issue here is that MC currently does some output formatting, and the Output Expression also does output formatting, so it should be decided which happens first. Probably the same issue for Input Expressions. We should make some recommendation.
Raw Data -> existing MC formatting -> Output Expression
User Input -> Input Expression -> existing MC formatting
BTW, I can think of some mathematical and financial examples of where the Field.Output() value would want to be used in the Input Expression. i.e. Store currency value in US$, but enter and display currency value in AU$, and allow incremental user additions. So;
Input Expression would be: (([Field] + input value) * exchange rate).
Output Expression would be: ([Field] / exchange rate)
So the overall expression would be: ((([Field] / exchange rate) + input value) * exchange rate)
A bit contrived, and I don't know if there would be real example in MC data. Just throwing out ideas for consideration, so no roadblocks are left.
-
Your updated chart for Output Expression is definitely wrong. [Field] would not be blank in that case!
Didn’t read the rest yet.
Nevermind. I shouldn't have tried to read it on my phone.
-
Consider the [Date] field in MC again. It is a numeric value, but it is written to the "DATE" tag in human-readable format. In fact, MC currently only writes the year to the "DATE" tag, and it isn't the [Year] field, which is a calculated field that formats the [Date] field. It derives from the [Date] field directly, or appears to.
[Date] like many other built-in fields, has always had special casing, and would be unchanged.
(The other "dates" are internally just expressions that parse out just the Year, or Month, or Day, or whatever, for ease-of-use. But, in any case, any internal fields which are currently grayed out and special cases, would remain as they are.)
Also, it is worth mentioning that your updated chart above (while it appears to be correct), really makes the situation seem more complicated than it is. [Field Name] and [Field Name,0] are already things. They work the way they do now, except for the User Input stuff and the ability to access the User Data variable value.
-
I have asterisk one cell, because currently "Calculated Data" does work differently when [Field Name,0] is used instead of [Field name]. Some formating is applied to [Field name], but is not applied to [Field Name,0]. For example, I have a numeric Calculated field that displays to six decimal places using [Field Name,0], but only to two decimal places using [Field Name].
Correct. The [,0] square-bracket notation option is designed to provide raw values (https://wiki.jriver.com/index.php/Library_Fields#Formatted_and_Raw_Values). [Date,0] shows you the real floating-point date value, for example. Which, makes sense when accessing the User Data variable value. That's why it works, because it already is a "show me the real, underlying value without the formatting" option. The Output Expression is just treated the same way as MC's own internal formatting that it does on fields in this way.
You would "lose" access to the ability to use [Calculated Field,0] to get raw, unformatted data from your expression (if User Data is enabled for that expression). That's easy to work around though, just append &datatype=[string] to your expression, removes the special formatting coming out of expressions too. Or, if you really can't (because it is a number) you can just make a second Read-Only Expression Field (current Calculated Field) and point it to the original value with &datatype=[string], and then use that one anywhere you need the raw, unformatted output from an Expression Field that also has User Data enabled.
Other than that, I don't believe that conflicts with anything, and that is pretty edge-case oriented. It wouldn't, in any case, impact any existing functionality because it would only impact Fields that have both Output Expression AND User Data enabled, which isn't currently possible.
So, really, it could be like this:
User Data selected User Data unselected
[Field] [Field,0] [Field] [Field,0]
Input Expression: newValue Field.Value N/A N/A
Output Expression: Field.Value Field.Value Unchanged Unchanged
Elsewhere: Field.Output() Field.Value Unchanged Unchanged
And, hence, pretty pointless.
Remember, Output Expressions with User Data unselected ARE the current Calculated Data fields. Behavior there doesn't need to change.
I don't actually know what it spits out if you reference a Calculated Field in its own expression. It might spit out Expression Error? I don't know. I could test it, but I don't really care. What it should do there is keep doing whatever it is doing now.
-
It's never pointless to document how something works, or is expected to work, particularly when it isn't obvious, there are several options, and you are making a proposal to someone.
Earlier you were saying a couple of those conditions should output blanks, now you are saying unchanged. Okay, I was summarising the discussion, and asking questions. It would be nice if this worked first time it was implemented.
-
It's never pointless to document how something works, or is expected to work, particularly when it isn't obvious, there are several options, and you are making a proposal to someone.
Earlier you were saying a couple of those conditions should output blanks, now you are saying unchanged. Okay, I was summarising the discussion, and asking questions. It would be nice if this worked first time it was implemented.
Oh, I know. I was working it out in my head now too. I wasn't saying it was pointless that you brought it up! (Far from it.) I was saying, in the end, after realizing that all the things on the right are either (a) impossible with the new system or (b) already exist, that "thinking" about how to change them is pointless. The correct answer is unchanged for everything on the "right side" of the chart.
You can't access the Input Expression box if User Data is unchecked. So, there, the N/A is correct.
For the other ones, which are all currently possible, then you just leave the existing behavior intact.
-
And, I should add further, you brought up an important point I hadn't fully considered. If you make one of these new fields that contains both an Output Expression and a User Data variable, then reusing square-bracket [,0] mode to access the underlying value of the User Data variable, means:
1. For those "new types" of Fields, you wouldn't be able to access the formatted value of the "underlying" User Data variable. Because, I'm assuming throughout all of this, that [Field Name,0] would continue to output the unformatted data from the variable (as it does now for all standard User Data fields).
If you need it formatted, you'd have to wrap it in another Read-Only Expression Field, as discussed above.
2. Likewise, you wouldn't be able to access the unformatted value of the Expression Output itself, as discussed above. However, this doesn't matter because you control the expression itself, so if you don't like what it is outputting, then just change it to output it with better formatting.
Or, if you really need both, one of them is going to have to be wrapped in a separate Read-Only expression field with a different expression, and you won't be able to write to that one. But, again, that's no different than today.
But, all of it only applies to using those new Read/Write Expression Fields. And you control the expressions in this case, so you can do anything you want with them. So, really, hitting that should be very edge-case-y, don't you think?
EDIT: After re-reading this and thinking about it, it is worth leaving here but really... [Field Name,0] really should result in the unformatted data from the Field, and [Field Name] the formatted data. Your Output Expression is, in this case, the formatting.
If you're intentionally trying to get to that underlying value you'd expect it to be the unformatted version. And, more importantly, the unformatted version is "safer" to receive because you can always just re-do the formatting if it is stripped out. You can't always do the reverse easily (think of a Date value).
-
I thought of something else critical, that is worth bringing up again. I mentioned it before but, there is still one last benefit to my original idea that this new one doesn't address.
For this idea to work to solve my original problem (and a few others to boot), you'd have to be able to enable the Output Expression and Input Expression options on the [Artist] field itself, and other stock fields like it.
The Artist field, like many others in MC, is now locked down, and can't be changed. For this idea to work, those fields can still keep Data Type, Relational, Edit Type, and Acceptable Values locked. But Input and Output Expression would have to be unlocked. If not, you'd be able to do it with all of your custom fields, but you couldn't use it to format [Artist] or [Cinematographer] automatically, which would defeat my entire point.
My original idea doesn't require JRiver to let you make any changes at all to the stock fields. A separate, custom field can write into a stock field, but it doesn't actually have to change. And my original idea does all of this other stuff too. So, if JRiver is not willing to allow that, can we agree that some version of my original request would be the best alternative?
-
Yep. That is why I was asking these and other questions.
Will some fields be locked so this functionality can't be used with it?
What fields will be locked out of using this functionality?
Will locking out some fields reduce the value of the proposal?
I was certainly thinking of the [Artist] field and Taylor Swift, even if I didn't include it.
That you would be able to use this functionality on stock fields was implicit to agreeing with this proposal. But even then, there would be some fields that it shouldn't be used with, even if it could be.
If we have to create a new field and can't write back to the original field with all the functionality built around it, the current proposal wouldn't meet your original request. It still might be neat for user-created fields, but less useful.
-
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.
-
So, looking at the above, especially Zybex and RoderickGI and others, do those look like two proposals that would both work equally well if implemented, at JRiver's option?
I can re-write it up if we get general consensus.
-
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.
Do you mean [FieldName]?
The small table above is enough - you might want to add simply that the return value for [FieldName] keeps all existing behavior, except when processing the Input and Output expressions (if defined). [FieldName,0] always returns the field's raw value in all contexts (or "circular reference" error, as it does now, when trying to use it on a pure calculated field to reference itself)
Agreed than locked fields such as [Artist] would need to be semi-unlocked to allow adding Input/Output expressions. Some other critical fields might have to remain locked to prevent users from messing them up.
Your summary of both ideas looks good.
-
Time to throw a few more problems into the discussion ;D
I've mentioned before that I have some reservations about the InputExpression, and I've tried to explain it on the previous page. Let's see if I can explain it better now.
Problem #1 - The Multi-Field Output:
If the OutputExpression for a user-data field references other fields than itself, there's no way to build a corresponding InputExpression that works seamlessly for the user.
Example 1 - normal case
Let's use the [Artist] field example:
- set Output="swap([Artist])"
- set Input="unswap([Artist])"
So "Gaylor Swift" displays as "Swift, Gaylor", and when the user edits it and changes to "Swift, Taylor" the value "Taylor Swift" will be written to the field. All good.
Example 2 - bad case
If the Output expression references other fields than itself, we have a problem. Let's use a contrived example; imagine you want to show the Artist and their country:
- set Output="swap([Artist]) ([Country])"
- set Input= ??
The Output expression will display like "Swift, Taylor (US)".
The problem here is that the InputExpression cannot write back to [Country], only to [Artist]. So you might define an Input expression that removes the (US) part and unswaps the name to get "Taylor Swift" back; however, any edit to the Country part is lost, which kind of breaks the magic:
- if the user edits "Swift, Gaylor (US)" and changes to "Swift, Taylor (US)", the Input Expression can store the correct artist name, it works fine;
- if the user edits "Swift, Taylor (AU)" and changes to "Swift, Taylor (US)" ... nothing happens, the field will still display "Swift, Taylor (AU)" as the [country] cannot be changed by the Input Expression of [Artist].
This behavior might be weird to the user, who will not easily understand why some edits work and others don't. WAF is the problem here!
Note that this problem exists in both proposals.
One solution is to prevent using other fields except itself on the OutputExpression of user-data fields. To do that the user would need to use regular Computed fields without Input expression (not editable, read only). Another, more radical, is to do away with the InputExpression completely and just show the actual/raw field value when editing starts (I know you dislike this).
-
Problem #2 - The Debug Method:
Another issue with InputExpression is ... the debugging of it until you get it right. Who here can get an Expression Language expression right on the first try?
While playing with the InputExpression to get the desired results, each time it runs it will overwrite the underlying field content. If the expression isn't right on the first try it will mess up the saved value and the user will have to manually fix it before trying again with a new/fixed expression.
This is annoying.
Worse, you might enter an InputExpression that appears to work just fine, but does not in fact cover all edge cases. Then you start using the field and in some cases it might be corrupting data when the user edits the field value. If the user doesn't notice this corruption immediately he might end up with lots of corrupt data that will need manual fixing, or even a backup restore. Even if the user notices it immediately he might become suspicious of the feature and will want to check all his data for possible corruption.
This is annoying and dangerous.
These are usability/reliability issues that make using this feature very cumbersome and even dangerous if you're not an expert.
-
Problem #3 - The Input Bypass:
Lastly, another usability problem: on a field with an InputExpression defined, how can the user edit the raw value directly?
By definition, any edit to the field would go through the InputExpression. But if the user wants to enter some raw data (either individually or via a multiple-file/field Paste), he needs an easy way to bypass the InputExpression. This is not so much an issue with the LinkedField idea as the user can just go and edit the back-end field directly, but it would be nice to be able to do so directly on the new editable field which holds the InputExpression.
Suggestion:
- When editing a field, press ENTER or click somewhere else to finish the edit (as usual) -> InputExpression is triggered
- Press CTRL+ENTER to finish the edit and write the value directly without processing -> InputExpression is bypassed
-
Yep, the proposal summaries look fine for both.
Problem #1, Example 2: I can't think of any practical way to solve that. I can think of at least one fancy programmatic way to update just the main field (re-read the field, parse the Output Expression to only include the functions affecting the main field, the Input Expression only handles that main field), but I don't think that would fly.
Problem #2: Yes, it could be a can of worms. Library Backups, regularly. Maybe users only get access to this functionality with special licence conditions, for expert users. Sorry, no better ideas just now.
Problem #3: Your suggestions sound fine.
-
The problem here is that the InputExpression cannot write back to [Country], only to [Artist]. So you might define an Input expression that removes the (US) part and unswaps the name to get "Taylor Swift" back; however, any edit to the Country part is lost, which kind of breaks the magic
Correct, and yes, if you merge multiple fields into a single output, you'd have to pick only one value that can be written. My [Watched] expression above is a similar example. That would apply to the Unified User Data and Calculated Fields example too, as you noted.
Again, not really an "issue" because you control the expressions. I think it is fine. Just design your system well.
The perfect does not have to be the enemy of the good. There are lots of things like this in MC's expression design.
-
Problem #2 - The Debug Method:
Another issue with InputExpression is ... the debugging of it until you get it right. Who here can get an Expression Language expression right on the first try?
This would be equally true of both systems, and of all data entry done with =Expression. I think that was your point, but I don't see how it is any different than stuff we've had for years.
Yes, if you're writing to field values with an expression, you should be careful. I wouldn't mass tag my entire Library with anything until it was thoroughly tested.
But that also applies to mass tagging them with the =Expression editing method. So... As Roderick said, make Library Backups (which it does automatically now, thank god) and test.
-
Problem #3 - The Input Bypass:
Lastly, another usability problem: on a field with an InputExpression defined, how can the user edit the raw value directly?
Unnecessary. And that's why that idea still has merit (I think you missed this important point). You just edit the Data Storage Field directly. The real field is still there and is still accessible like it always was. While the Calculated Field can write to the Data Storage Field, this does not block you from writing/reading to/from the Data Storage Field yourself directly.
So, for the Artist Name Swapping example, while the system does not require you to display the "real" [Artist] field in order to edit it anywhere, the real [Artist] field is still sitting there and can be used like it always was, directly, whenever you want.
That is the one advantage the Writable Calculated Fields example has over the Unified approach. It doesn't touch the original fields. They're "regular" like they always were, and so no special syntax is required. Want the formatted value? Use [Artist Display]. Want the original unformatted value? Use [Artist]. You can write to either one, in the format that seems appropriate and then both change.
-
The real field is still there and is still accessible like it always was.
I'm raising issues for both proposals - #1 and #2 are common to both, #3 is exclusive to the unified approach.
-
I'm raising issues for both proposals - #1 and #2 are common to both, #3 is exclusive to the unified approach.
Yep. I got it, I was just making it clear for other readers. But #3 isn't an issue. Or I don't understand what you mean.
You don't need any special syntax or controls to bypass the Input Expression, because if you want to bypass the Input Expression, you can open up the Tag AW and edit the "original" field.
You can't do it through the Calculated Field. But that's... By design. It does what it does, and if you don't want it to do what it does, then don't use it.
-
I mean that on the unified approach, if you set up a field with an Input Expression you also need a way to write a raw value directly to the field, without any massaging by the Input Expression. I was suggesting CTRL+ENTER.
There is no "original field" in this case. It doesn't link to any other field.
Edit: Are you saying that the Tag panel should display the raw value instead of the OutputExpression() value? I fully disagree there, if there's an Output+Input expression pair defined, then the Output-processed value is the one to be displayed pretty much everywhere. Hence the need for a workaround.
-
I mean that on the unified approach, if you set up a field with an Input Expression you also need a way to write a raw value directly to the field, without any massaging by the Input Expression. I was suggesting CTRL+ENTER.
There is no "original field" in this case. It doesn't link to any other field.
OOOOOOH. Sokath, his eyes uncovered. #3 is specific to the Unified Approach. Which you wrote, I think twice, and I read it backwards both times.
You're right.
So, that's another big knock on the Unified approach that I'd forgotten in my excitement over [Field Name,0] yesterday. In addition to the requirement for the [Field Name,0] syntactic sugar to access the unmodified field for reading, you need something to let you access the un-modified field for writing.
Makes me think Writable Calculated Fields is overall better again:
- Less syntactic sugar required.
- Doesn't require JRiver to unlock stock fields.
- Provides easy-to-use access to the underlying storage fields directly.
I think your proposal for the solution is fine, but... It feels like it needs a lot of special casing, which is (1) harder to use and (2) more work for JRiver to implement, and so less likely we'll get anything.
-
Both of them are finicky solutions, frankly, likely requiring more code changes than we can perceive. They will have limited audience, not many people would play with this feature. I think the chances of it getting implemented are very slim. Remember that the only added gain relative to what MC already does, is the ability to edit computed fields; but... one can already edit the base fields directly, so in the end it sounds like a lot or work just to create an editing shortcut.
-
Out of the blue, here's an alternate idea to allow editing of Computed fields (let's call it "Smart Tag Editor" for reference):
- keep field definition as-is, no change required at all
- when user edits a computed field, MC looks at the expression for that field, extracts the names of all Fields used in the expression (following expression chains if needed), and pops up a mini-tag editor JUST with the fields that make up that Computed field.
- the mini-editor has a cell for each field, and may show underneath what the Computed expression will output in real-time as the edits are being made.
- Optionally, a new checkbox could be added the the Computed field definition to enable it: "[_] enable editing of related fields"
That's it. They could probably reuse the existing Tag AW for this.
-
A decent idea, but:
(1) That wouldn't help with tagging in the Pane Checkboxes (or it would be very clumsy). Enabling that is a core design-focus of my original idea. For me, and my (now 15-year long) workflow, it wouldn't help at all.
(2) That sounds like more implementation work than my Writable Calculated Fields or the Unified approaches (we can't know for sure, but it would be inventing a whole new GUI editing function of some kind, if possibly small-scale).
-
A decent idea, but:
(1) That wouldn't help with tagging in the Pane Checkboxes (or it would be very clumsy). Enabling that is a core design-focus of my original idea. For me, and my (now 15-year long) workflow, it wouldn't help at all.
(2) That sounds like more implementation work than my Writable Calculated Fields or the Unified approaches (we can't know for sure, but it would be inventing a whole new GUI editing function of some kind, if possibly small-scale).
Creating a new window/panel is a couple hours work... contrary to the other 2 ideas, this would be a self-contained feature, wouldn't impact anything else. And it could reuse the existing TagAW code/look.
Pane checkboxes, are you referring to this example (https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-writing-small.png) you gave? If so, it would work the same... you can have the [artist is a person] field/column, and the [Artist-Display] would use it to compute the displayed name. When editing the [Artist-Display] field, one of the related fields that would show up is the [artist is a person]. You could even select multiple files and popup the Smart editor for the [Artist-Display] - it would show <varies> where needed.
Not sure I understand correctly though.
-
EDIT: Read my next post before you read this one.
Now I'm confused. I thought you were talking about that as an add-on for the Unified Approach. And you wouldn't be able to use the Pane Checkboxes to tag those underlying fields.
Eg: If it was based on writing to [Field Name,0] which is what I was thinking initially, then you could make a "plain [Artist]" pane, if you wanted one. But you can't, because then that expression wouldn't be writable. And you couldn't point more than one expression pane at the same field and have them both be writable.
Are you instead talking about an extension to the Writable Calculated Fields idea? Because, again, you don't need anything fancy to write to the underlying fields with that idea. If you want to write to the underlying fields directly (and bypass the Input Expression) you can: Just add [Artist] to your Tag AW. In fact, it is already there. Just don't hide it.
My concern over the implementation time is about:
Out of the blue, here's an alternate idea to allow editing of Computed fields (let's call it "Smart Tag Editor" for reference):
MC looks at the expression for that field, extracts the names of all Fields used in the expression (following expression chains if needed), and pops up a mini-tag editor JUST with the fields that make up that Computed field.
That seems terrifying. It might not be easy to follow some of my expression chains, filtering in and out all of the fields. Here's one of them I use as a Pane in all of my music views:
Regex(NoArticles(ListItem([Artist],0)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4))If(IsEmpty(ListItem([Artist],1)),,;Regex(NoArticles(ListItem([Artist],1)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],2)),,;Regex(NoArticles(ListItem([Artist],2)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],3)),,;Regex(NoArticles(ListItem([Artist],3)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],4)),,;Regex(NoArticles(ListItem([Artist],4)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],5)),,;Regex(NoArticles(ListItem([Artist],5)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],6)),,;Regex(NoArticles(ListItem([Artist],6)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],7)),,;Regex(NoArticles(ListItem([Artist],7)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],8)),,;Regex(NoArticles(ListItem([Artist],8)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))If(IsEmpty(ListItem([Artist],9)),,;Regex(NoArticles(ListItem([Artist],9)), /#([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(And(IsEmpty([R1]),IsEmpty([R2])),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2],3)FixCase([R3],4)))&DataType=[list]
Now, that particular one would stay read-only and wouldn't need the editor at all. But, it has Regex replacements (which look like square bracket notation), and has to operate on multiple ListItems. Possible certainly. That one wouldn't really be that hard (the answer is only [Artist]). But a couple hours to make and validate all of that across the entire scope of the Expression Language?
I never like to assign a time estimate to code I can't see. It is hard enough (often nearly impossible) estimating timeframes on code you CAN see. But that still seems like more work than my original idea. Which is self contained.
But, that's not for us to decide. I do just want to keep the proposal as simple and as "bare necessities" oriented as is necessary. And that seems like a bigger ask than a rearrangement of the Library Field Manager and adding in Input Expressions (which is, as discussed, effectively just adding a Setter to an existing system that already works in the proper way).
I could be wrong, of course. But, I don't see how it is that complicated.
-
Pane checkboxes, are you referring to this example (https://glynor.com/img/screenshots/MC27/Artist_Swapping-Example-writing-small.png) you gave?
Oh, and no, that is not a picture of the Pane checkboxes. These are:
(http://glynor.com/img/screenshots/MC27/Category_Pane-Direct_Editing.png)
(http://glynor.com/img/screenshots/MC27/Category_Pane-Checkboxes-Enabled.png)
I almost never tag anything in the Tag AW or in the file listing grid. Probably 95% of things I manually edit, I edit there.
That's what I'm trying to accomplish. I want to be able to use my [Artist Display] expression which will spit out the list of artists in Name-Swapped order, and to be able to check the little boxes next to "Swift, Taylor" (or control click it to add her) and have it write out "Taylor Swift" to the [Artist] field for the selected files.
If I can make the [Artist] field itself show the values (stored in the database as "Taylor Swift") as "Swift, Taylor" in those panes, and let me tick the boxes next to them to assign the track with [Artist]="Taylor Swift" (with the optional holding-control to add her to the list instead). Then it would work that way just as well for me. If it doesn't solve that issue, though, it doesn't solve my problem.
I'm not sure how that is overall relevant to your idea, but that's what I'm trying to do, and from that comment I quoted, I'm not sure you use those.
-
Sigh. We keep confusing each other.
I meant this as a totally separate idea to address your original concern - that a computed field is not editable. This would allow editing all fields used in the expression for a given Calculated field in one go. You would be able to have calculated fields on your view, displaying whatever you like, and when you click on them to Edit, it would popup this new UI with the related fields.
That seems terrifying. It might not be easy to follow some of my expression chains, filtering in and out all of the fields.
Actually, it's trivial. I can build you the recursive function for this in 10 lines of code. The 2h estimate is for the UI Form, bells and whistles.
Here's a c# version I just wrote - the regex expression might require some test and tweaking, but this is basically it:
List<Field> getFieldList(string expression)
{
List<Field> fields = new List<Field>();
var names = Regex.Matches(expression, @"(?!/)(\[.+?\])").Select(m=>m.groups[2].value).ToList();
foreach (var name in names)
{ var Field = GetField(name);
if (Field != null && Field.Type != FieldType.Calculated)
fields.Add(Field);
else if (Field != null && Field.Type == FieldType.Calculated)
fields.AddRange(getFieldList(Field.Expression));
}
return fields;
}
-
Sigh. We keep confusing each other.
Yep.
I meant this as a totally separate idea to address your original concern - that a computed field is not editable. This would allow editing all fields used in the expression for a given Calculated field in one go. You would be able to have calculated fields on your view, displaying whatever you like, and when you click on them to Edit, it would popup this new UI with the related fields.
I don't want that. I would turn it off if it was there.
-
Public service - your expression above can now be simplified to this:
ListMix(Regex(NoArticles([L1]), /#^([0-9]{0,2})([a-zA-Z]?)([a-zA-Z]?)#/,-1)IfElse(IsEmpty([R1][R2]),/(other/),!IsEmpty([R1]),0-9\[R1],1,[R2]\FixCase([R2][R3])),,[Artist])&DataType=[list]
-
Yeah. It is old, and I hadn't gotten around to messing with ListMix() yet. Thanks! I'll muck with it later.
To be clear, I'm not saying the idea is terrible. I think it could be cool, if limited only to the Tag AW. Having those things popping up in the File List Grid View would be bad, which is why I'd want to turn it off (but maybe you meant only in the Tag AW). And that kind of thing would not be usable in the Panes (or if it was, it'd break the usability of them - the whole idea is that I can fix typos and "categorize" things without introducing new typos with a single-click).
So, not core to this discussion, and I'm worried enough about getting the core idea done.
That's all.
PS. And I've spent two hours trying to get button elements and text to align correctly in a GUI editor. ;) :P
-
Could you maybe try to explain what still concerns you about the Writable Calculated Fields idea, implementation wise?
It seems extremely straightforward to me:
- Some GUI messing about in the Library Field Manager panel. But that really needs to be done anyway.
- Adding a Setter function for Calculated Fields. This is literally just the Expression engine, which already exists.
- Let you pick what "variable" (another standard User Data field) will be used to store the results.
The rest of it is already there. You already CAN edit them, they just don't save.
-
Gotta love the ListMix() function. :D
I'm mostly just sitting back reading now, concerned that we keep hitting special cases and problems to solve, rather than refining the proposal to a workable solution.
But thinking about Taylor Swift, and re-reading the first post, I'm wondering if that particular requirement can be met with a simpler solution. That is, don't try to build a universal solution that would be all sorts of goodness in other areas. Just address the Pane Tagging issue of "Swift, Taylor", while maintaining "Taylor Swift" in the fields, and supporting field edits.
What about a pure Display Expression on normal fields?
- "Swift, Taylor" is shown everywhere when the [Artist] field is displayed.
- Sorting would be done using the displayed value, "Swift, Taylor".
- The stored value is always "Taylor Swift".
- When the field is edited anywhere, the underlying data "Taylor Swift" is shown, and the value is edited in that format.
- Panes show "Swift, Taylor" and allow clicking the box next to her to set her as the [Artist], or Ctrl-Clicking to add her to the [Artist] field, and "Taylor Swift" would be added.
- Calculated fields could not use the function. They are read-only anyway and can be formatted as required using their expressions.
- The Display Expression can be added to any User Data field, including all stock fields, as any editing is always using the original format and not the displayed format. So [Director], [Composer], [Actors] would be good candidates.
- The Display Expression would be processed after any internal processing that currently exists in MC, so theoretically it could even be added to the [Date] field. Though that may have interesting results. But it wouldn't change the underlying data, so would be safe.
- Any use of [Artist] or [Artist,0] in expressions would work exactly as they do now, using the underlying data, plus any current hard coded processing in MC. The Display Expression would only be processed for display, and sorting, not in expressions.
- The Display Expression can be turned on and off in the (new and improved ;)) Manage Library Fields dialogue via a checkbox, without losing the expression, so users could see the unmodified format easily. Mostly for expression development and debugging.
There is precedence in the way the [Date] field is handled now, allowing many formats of data entry, but storing only the decimal day value.
There is also precedence in Theatre View view definitions where an expression defines what is to be included in the View, and another can define what is to be displayed. No edits there, but a similar concept.
Go ahead. Shoot me down. Be gentle. ;D
-
You still have to be able to edit the [Artist] field in the Library Manager in order to turn on the Display Expression. The whole reason we wrapped back around is that this might be over a red line for JRiver.
They have reasons they keep some of those fields locked down.
Rather than thinking about something new entirely, what is actually wrong with the most recent version of the Writable Calculated Fields?
I say this because, I think we've investigated the Unified Field Types idea pretty thoroughly. I'm NOT saying that idea is totally out. But IF it is out, then your new idea would be out too. The idea now is to investigate Writable Calculated Fields as an alternative if JRiver says "nope, [Artist] stays locked".
-
I don't think my new idea would be out because of the red line, as it never writes to the fields in any way other than how it is done now. It's purely display and sort.
I haven't applied myself to reconsidering the Writable Calculated Fields yet, as I need to take a break from this for a bit, and come back fresh.
-
I don't think my new idea would be out because of the red line, as it never writes to the fields in any way other than how it is done now. It's purely display and sort.
I think the red line could be all of the checkboxes about [Artist] (and other stock fields) stay grayed out. So you wouldn't be able to turn on your Display Expression on [Artist].
That may very well be wrong. But, if they are willing to let you apply an Output expression, and build in all of that other functionality, then the Unified Fields Theory holds, I think.
I think Writable Calculated Fields is the best alternative. It is flexible, doesn't require any core changes, and very limited GUI-impact. But, I could be missing something. I was originally, with the looping issue, for sure.
-
Roderick, your idea is what I proposed on post #2 of this thread :)
Eventually it evolved to the grand "Unified Field Theory" that has vexed the likes of Einstein and Stephen Hawking ;D
-
Glynor, the Linked fields has been vetted and ironed out, so I agree it's ready for presentation. I think the implementation likely has to consider more ramifications than we see here, and is not as trivial as you see it. Breaking the Field object encapsulation is likely to have consequences on the implementation.
Regardless, we have no visibility into that, so only JR folks can take it from here.
-
Roderick, your idea is what I proposed on post #2 of this thread :)
Yeah I know. I should have said "What about going back to a pure Display Expression on normal fields?
But I covered the issues we have seen along our journey. At least as I remembered them.
So, a proposal to JRiver. See what happens.