Print

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

[edojan]

For some time I have been using the Artist field to store the names of the participating artists as well as the instruments they played. 
Current examples of values in the [Artist] field:

Sample track 1 / [artist]:  Keith Jarrett (piano);Gary Peacock (bass);Jack DeJohnette (drums)
Sample track 2 / [artist]: Chet Baker (trumpet);Johnny Griffin (tenor sax);Al Haig (piano);Paul Chambers (bass);Philly Joe Jones (drums)
Sample track 3 / [artist]: Chet Baker (trumpet, flugelhorn);Jim Hall (guitar);Hubert Laws (flute);Gary King (electric bass);Steve Gadd (drums);Sammy Figueroa (percussion)

Note 1: The artist names are separated by semicolons and the instruments played are in brackets.
Note 2:  In case an artist plays multiple instruments (e.g. In track 3 Chet Baker plays both trumpet and flugelhorn) a comma is used to separate the instruments.

I assume that I  would need to store parsed values from [Artist] in a custom made field - e.g.  [1_Instruments] to look like this:

Sample track 1 / [1_Instruments]: Piano;Bass;Drums
Sample track 2 / [1_Instruments]: Trumpet;Tenor sax;Piano;Bass;Drums
Sample track 3 / [1_Instruments]: Trumpet;Flugelhorn;Guitar;Flute;Electric bass;Drums;Percussion

Then I could easily create the Instrument View which would group Artists by Instrument. The end result would then look like this:
   
Key Instruments
   Bass
      Gary Peacock
      Paul Chambers
   Drums
      Jack DeJohnette
      Philly Joe Jones
      Steve Gadd
  Electric bass
        Gary King
   Flugelhorn
      Chet Baker
   Flute
      Hubert Laws
   Guitar
      Jim Hall
   Percussion
      Sammy Figueroa
   Piano
      Keith Jarrett
   Tenor Sax
      Johnny Griffin
   Trumpet
      Chet Baker
   
So I have proceeded to create a custom field  [1_Instrument] with calculated data type. This is where  I would appreciate your help with the expression that would:
   1. Parse instrument names from the Artist field and store them in semicolon delimited format
   2. In case of an artist plays multiple instruments (e.g. In track 3 Chet Baker plays both trumpet and flugelhorn) both trumpet and flugelhorn should be included (also separated by semicolon)
   3. The first letter of the instrument name should be capitalized
   4. I have untagged albums. As I add artist / instrument metadata to the [artist] field will the [1_Instrument] field become automatically updated?

Thanks!
Ed

[wer]

Happy New Year!

You're looking to do something rather advanced, and it's going to take a certain amount of work and testing. The testing effort would be complicated for anyone that doesn't have your data, with all the instrument information filled out, in the variety and permutations that exist in your database, as they would have to enter a bunch of data. How you're storing that data is unusual.

I'm not going to embark on this and do all this for you, sorry, but I will offer you some tips so you can help yourself.

First, you're going to need to use the Regex() function in the Expression language, which implements Regular Expressions. That will be necessary to parse your instrument data. So you'd better study how that works. You will also need to cast the data type of your results as a list, so study the "Data types" section at the bottom of the article as well.  https://wiki.jriver.com/index.php/Expression_Language
If you get into trouble with details, there are a few other people here on the forum who would be capable of helping with the regex.
Learn about Regular Expressions here: https://www.regular-expressions.info/

I would also strongly urge you to abandon your novel misuse of the [Artist] field, and store your instrument and performer/instrument data in the [Instrument] and [Soloists] fields. (Or you could create new fields).  It would not be difficult to copy the information over to new fields, and then sanitize the [Artist] field. The Artist field is intended to store names, and only invariant names. By cluttering the Artist field with extraneous variable non-name data, other aspects of MC will not work as expected. With your current scheme, someone who plays two different instruments will be regarded by MC as two different artists. I will not debate this or hear any defense, or further try to persuade you, on this point. You can take my word that what you are doing is deleterious and will ultimately hinder you, or not.

Regarding your question on capitalization, the expression language has a function just for this: FixCase().

Regarding your untagged albums and automatic updates, what you will want to do is create a new field, of type Calculated Data.
See this article: https://wiki.jriver.com/index.php/Library_Fields
This Calculated Data field will use the Regex() expression to automatically parse out the instrument data from the Soloists or Instrument fields (or Artist, if you unfortunately decide to leave it there). It's this calculated data field that you will then reference in your views, and the field will automatically update itself any time you make a metadata change.

I hope this helps.... Good luck.

[zybex]

Your [Instruments] field could look like this:

Code: [Select]

FixCase(ListClean(replace(regex([Artist],/#\((.+?)\)#/,-2),/,,;),1))
Regarding question 4: yes, the expression is calculated in realtime, so each time you change an Artist value, the expression output also changes.

I agree with Wer in that you should keep the [Artist] field clean. You can get just the names like this:

Code: [Select]

ListClean(regex([Artist],/#(?:^|;)(.+?)[\(;$]#/,-2),1)
You can use this expression to fix the [Artist] field - you must first copy the current value to some other field, and then use this expression to cleanup [Artist]. Make a DB backup first!

I don't think these 2 are enough to do what you want though... these will separate the instruments so that you can use it as a Tree level, however you still need some other expression to get just the names of the artists playing that instrument - without that, all artists would be shown under each instrument.

[edojan]

wer and zybex: - thanks for your input!
wer:
I will follow your advice to declutter the Artist field of personnel / instrument information moving the info to a newly created field "Personnel"

zybex:
I used your code

Code: [Select]

FixCase(ListClean(replace(regex([Artist],/#\((.+?)\)#/,-2),/,,;),1))
in the custom field [1_Instrument] but for whatever reason the program seems to be treating it as a string rather than a semicolon-delimited list.
The views created with [1_Instrument] lump the artists in a single string as follows:

[edojan]

The problem can be partially fixed by creating a second custom field [2_Instrument] this time using  "User Data" option with "List (semicolon delimited)" as the Data Type and manually repopulating the field using
=[1_instrument]

The view based on [2_instrument] properly lists all the instruments but, as you mentioned in you post, under a selected instrument it lists all artists from the track rather than only the ones playing that specific instrument. Here is the screenshot:

[wer]

The problem you are experiencing with Zybex's code, where the value is interpreted as a simple string, is what I mentioned to you in my post, regarding data type casting. I suggest you re-read that and the section of the wiki I pointed out to you, and utilize the appropriate type cast modifier:

Code: [Select]

&datatype=[list]

[edojan]

Thanks wer. I have scanned the wiki on data type casting.
Adding at the end of zybex's expression did the trick. Just needed square brackets around "list" and then it worked.

Code: [Select]

FixCase(ListClean(replace(regex([Personnel],/#\((.+?)\)#/,-2),/,,;),1))&datatype=[list]

Now as mentioned above I am trying to make the program list only trumpet players under "trumpet" rather than the entire band. I wonder if this can be fixed by altering the code further? The task is well beyond my abilities as I am not very technical (I just like poking around)
If not, what is a better way of accomplishing the same? Maybe I am trying to reinvent the wheel and there is a better / easier way to group artists by instruments played?

[wer]

MC has a lot of flexibility, but using it is something akin to being a frontier homesteader and being confronted with the challenge of building your own cabin. Those who know carpentry have nicer houses. Those who don't can try to get someone to build for them, or develop their own skills, or learn to live within their means.   I try to encourage people to develop their skills. Teach a man to fish and all that.  So yes you're having challenges by attempting something "beyond your abilities" as you say, but you can learn if you stick with it.  But you've set your sights on something difficult.

What you're wondering about is not a problem with the code per se (although it might need to be modified), it's the way you've defined your view or the data underlying it.  Show the view configuration, along with the details of each category and what you have in the fields referenced by that category, especially, the category underneath the one that gives you the instruments (trumpet/trombone/tenor sax).

I can guess that fundamentally the issue is that your view at that category is configured to show "Personnel". And there's more than a trumpet player on a track that has trumpet in it.

The way your data is structured has to be conducive to how you want to display it.

[edojan]

What you're wondering about is not a problem with the code per se (although it might need to be modified), it's the way you've defined your view or the data underlying it.  Show the view configuration, along with the details of each category and what you have in the fields referenced by that category, especially, the category underneath the one that gives you the instruments (trumpet/trombone/tenor sax).

I can guess that fundamentally the issue is that your view at that category is configured to show "Personnel". And there's more than a trumpet player on a track that has trumpet in it.

The way your data is structured has to be conducive to how you want to display it.

wer, thanks for your help. As per your advice I have moved the artist / instrument mapping to the custom [personnel] field and cleaned up the [artist] field leaving only the artist names separated by semicolons.

@zibex
Thanks for your code to clean up the artist field - it worked great!

The current structure is as follows:

[edojan]

The custom [instrumentz] field are populated from the [personnel] field:

[edojan]

And this is the [personnel] field:

[edojan]

Finally, here is the details on the Instruments view. As you can see it correctly lists the instruments but includes all artists from the track rather than those playing the instrument in question (e.g. see the expanded flugelhorn section)

[edojan]

I am not sure if there is a better way of structuring the data. I don't see any other way to relate artists with the instruments played in the context of a given track.

[wer]

That's the expected behavior.

I suspect you misunderstand what you're doing in the tree. You think you're selecting an instrument, which is associated with players of that instrument. But you're not. MC is selecting TRACKS.

Each time you traverse a level in the view, MC does a select on the tracks in the database

Here's what you and MC are actually doing:
1. Select all tracks. Show the list of instruments that appear on those tracks.
2. Select all tracks featuring flugelhorn. Show the list of people that appear on those tracks.

You're telling it to show all Personnel on the tracks, and the way your data is organized, Personnel contains more than just flugelhorn players.

[edojan]

So how do I fix this to get the desired outcome? I understand why it is doing what it does given the current settings. What I don't understand is how to make it do the thing that I want.

[zybex]

I don't think MC can do that (unless Wer proves me wrong . The second grouping level under the Instrument would need to group files based both on [personnel] AND the value of the parent node (instrument); it would have to be defined by an Expression like:

ListGrep([Personnel],[value_of_the_parent_node])&DataType=[ List ]

AFAIK, that's not supported by MC - there's no variable that we can reference that contains the value of the parent node.
I tested using Save() on the parent node definition to save the name of the node/instrument into a global variable, but it does not work; it saves the full [Instruments] field, not just the current one on the tree.

You can try posting a feature request for a special [ParentNode] or [NodePath] variable. Depending on how MC builds the trees internally, this might be trivial to do or extremely complex.

[Dawgincontrol]

If you go to Audio>files and type the instrument wanted into the search bar, what happens?

Just thinking the search function may somehow help you.

[wer]

I was thinking about this previously, and I had arrived at the same obstacle Zybex just described.  I also considered how this might be done with Global Variables, but again, the lack of context-awareness was a problem, in addition to a lack of facility for controlled iteration. I also considered the search language, but again, it is not context aware.

The issue is that you don't want to filter on a field, you want to filter on the partial contents of a filtered field. So when you get to the next category down, the question becomes filter on what?  The choices made in the tree (the context) are not exposed to the Expression Language. There's no way for the expression language to know you selected flugelhorn, and so the next expression down cannot be configured to filter just for flugelhorn.

To do this right, you would want a two-way associative relationship between elements of two lists (partial fields) and MC does not provide for that. Or you need a relational database for people, and MC does not provide for that either.

This is similar to the desires of opera lovers: Show me all the Vocal Ranges. Now show me all the Contralto singers. Now show me all the operas this one appeared in.  They solve this problem by creating fields for the vocal ranges and the singers in them.  But there are a fixed number of vocal ranges, and thus a small and finite number of fields to be manually created.  You would need fields for every possible instrument and the players of them. That's a lot of manual fields, so I don't consider it viable.

There's also a challenge with implementing a solution to the context-awareness problem. Variables in MC (so far) are global. But remember, you can expand multiple nodes in the tree at once (and have multiple trees, due to tabs); so the same variable would have to have different contents at every point in the tree.  This sort of scoping is in contrast to how variables are now implemented, and there's nothing like it in the expression language currently.

Filtering that next expansion is problematic, due to limitations in the expression language and how your data is structured.

[zybex]

There's also a challenge with implementing a solution to the context-awareness problem. Variables in MC (so far) are global. But remember, you can expand multiple nodes in the tree at once (and have multiple trees, due to tabs); so the same variable would have to have different contents at every point in the tree.  This sort of scoping is in contrast to how variables are now implemented, and there's nothing like it in the expression language currently.

Like I said, it can be trivial or extremely hard to do, depending on how MC code is structured. Only Matt can tell us. Matt, if you're reading, this would be a nice feature

The trivial case would be:
- When MC needs to build one of the levels of the tree, it's calling some function to do the grouping/filtering
- This functions takes A) the List of Files from the level above; and B) the filter/group definition for this level
- The function applies the filter B) to the collection A) and returns the filtered collection to display on this sublevel
- The change would only require a 3rd argument to this hypothetical function: C) The name (or full path) of the parent node on the tree
- The function could then simply replace [ParentNode] with that value (or [ParentPath]) when processing Expressions.

It doesn't matter that there are multiple trees/views/levels open at the same time. Each time MC needs to compute which nodes to display at any level, it needs to do this group/filtering call; so all it needs for this new feature is that extra arg.

[edojan]

Thanks zybex for your analysis. Matt and other devs: would you please chime in to assess the difficulty level. This would be a great enhancement!

[edojan]

Matt, have you had a chance to read this?

[edojan]

Matt and other devs: it would be a shame if all the good analysis by zybex and wer go unnoticed. If you could review and provide your comments on the relative ease or difficulty of implementing this enhancement. I would then create a feature request if needed. Thanks !

[JimH]

We read.  We don't always write.

[edojan]

Jim, thanks for your response. I wonder if you could comment on the ease of implementation of this change so that you could prioritize and retain the benefits of the good analysis done by the members.

[edojan]

Please add to the list of requested features. The functionality would significantly enhance the capability to much better organize the content

[edojan]

Am I the only one who wants the capability to see his jazz collection to be sortable by instruments played?