Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

Pane checkboxes, are you referring to this example you gave?

Oh, and no, that is not a picture of the Pane checkboxes. These are:



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.

[zybex]

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;
}

[glynor]

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.

[zybex]

Public service - your expression above can now be simplified to this:

Code: [Select]

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]

[glynor]

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. 

[glynor]

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.

[RoderickGI]

Gotta love the ListMix() function. 

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. 

[glynor]

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".

[RoderickGI]

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.

[glynor]

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.

[zybex]

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 

[zybex]

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.

[RoderickGI]

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.