[KHS]

Which ChordPro metadata fields are supported upon import? I don't seem to be able to get these:

{year: 1992} to feed the Years field
{artist: Bob Slow} to feed the Artist field
{lyricist: Jo Blow} to feed the Lyricist field (name changed from "Custom Group")

{title: } and {album: } seem to work

Update: some work but only if I delete the song entirely rather than using "swap file" to bring in edited versions of the .cho file

Alternatively, is there some way to use a .CSV to import a .CHO file so that the same MSP fields that I can import when using a .PDF could apply to my .CHO files?

Thanks.

[Zubersoft]

See page 103 of the manual for the supported fields: https://www.zubersoft.com/mobilesheets/M...etsPro.pdf

"year" and "artist" are supported. If you want to populate the custom group field, you have to use {meta customgroup: Jo Blow}. Due to the fact that the custom group name is an open text field where you can enter any value and I rely on tokenizing with spaces, I don't allow the custom group name to be used in the chord pro directive as it could break my parsing logic. I also support {meta: customgroup Jo Blow} so I can't rely on the colon being listed after the custom group name (and if it's not a single word with no spaces I wouldn't know where the value started).

You can't use a CSV file with a chord pro file.

Mike

[KHS]

Just curious: is there some reason why the name of the Custom Group has to be spelled and spaced differently for .CHO file import and .CSV file import?
Based on my experience, .CSV files have to call it "Custom Groups" or it won't work, but .CHO files have to call it {meta customgroup} or it won't work. Is "customgroup" an official ChordPro thing that can't be made consistent with your .CSV import group names?

One more: does the number of text file lines taken up with all the {} directives and such affect the resulting layout? I think I've figured out that blank lines in the .CHO file DO affect that layout, so I'm just wondering whether metadata lines are ignored for page spacing or treated like blank lines. If the latter, are they allowed to be shoved together on the same line of the .CHO file?

Thanks again for all your help and for a great program.

- Kevin

[KHS]

One more problem I just discovered. I have not found a way to code the .CHO file in such a way that multiple artists or multiple years properly import. If I use one meta for each, only the first one imports. If I use one meta for both with a | between them, they populate as one (with the |) and not as 2 separate artists or years.

[sciurius]

Is "customgroup" an official ChordPro thing

No, but meta items must be single names. Otherwise it would not be possible to distinguish meta "foo" having value "bar boo" and meta "foo bar" having value "boo". Both would be written the same way:

Code:

{meta: foo bar boo}

A future version of the ChordPro specification may introduce quote handling.

One more: does the number of text file lines taken up with all the {} directives and such affect the resulting layout? I think I've figured out that blank lines in the .CHO file DO affect that layout,

That is correct.

so I'm just wondering whether metadata lines are ignored for page spacing or treated like blank lines.

Lines that contain a directive (that should be alone on the line) should be ignored w.r.t. formatting.

If the latter, are they allowed to be shoved together on the same line of the .CHO file?

No, but as I wrote above, this would not be necessary.

[Zubersoft]

It all seems to work for me. I just imported this:

Code:

{title: Test}
{year: 1985}
{year: 2003}
{meta customgroup test1}
{meta customgroup test2}

The new song had multiple years listed and multiple custom group entries. This does only get picked up when you first import though - I don't make changes to the library metadata if you edit the file and it gets parsed again.

As Johan specified, CSV uses the plural form because it accepts multiple values in the column, but the .cho only supports one value per meta directive. 

Mike

[KHS]

It all seems to work for me. I just imported this:

Code:

{title: Test}
{year: 1985}
{year: 2003}
{meta customgroup test1}
{meta customgroup test2}

The new song had multiple years listed and multiple custom group entries. This does only get picked up when you first import though - I don't make changes to the library metadata if you edit the file and it gets parsed again.

As Johan specified, CSV uses the plural form because it accepts multiple values in the column, but the .cho only supports one value per meta directive. 

Mike

Many thanks to you and to Johan! Is it possible that you could offer the user a choice upon "file swap" or re-import (at least with .CHO files) to have the library metadata edited thereby? At least the metadata that's accepted from .CHO files?  That would make the process of fine-tuning .CHO files a lot less frustrating.

[KHS]

It all seems to work for me. I just imported this:

Code:

{title: Test}
{year: 1985}
{year: 2003}
{meta customgroup test1}
{meta customgroup test2}

The new song had multiple years listed and multiple custom group entries. This does only get picked up when you first import though - I don't make changes to the library metadata if you edit the file and it gets parsed again.

As Johan specified, CSV uses the plural form because it accepts multiple values in the column, but the .cho only supports one value per meta directive. 

Mike

Many thanks to you and to Johan! Is it possible that you could offer the user a choice upon "file swap" or re-import (at least with .CHO files) to have the library metadata edited thereby? At least the metadata that's accepted from .CHO files?  That would make the process of fine-tuning .CHO files a lot less frustrating.

Additionally, upon Import of a .CHO file, the editable fields are first shown, but what is NOT shown is how they'd be populated from the metadata in the .CHO file. Is there a good reason why that data is not shown in a situation where user input is invited without the user being aware of what will be inputted automatically?

[Zubersoft]

That would require a different implementation from what is in place. I would need to parse out all the metadata from the file before importing it to display that, but what happens if you import both a .cho and a .pdf? Or two .cho files? The metadata fields give you a way to specify what additional metadata will be assigned to each song that is created. It wouldn't make sense to show the metadata parsed out from the .cho file when that wouldn't apply to the other files that are being imported. So I would either have to only allow a single .cho file to be imported at a time (which users certainly wouldn't like), or I would have to come up with a different UI where you could specify for each individual file you've selected, what metadata will be applied to it. I'm not even sure what that would look like off the top of my head, because some users import hundreds of files at once this way, so you'd have to provide an easy-to-use and meaningful way for them to apply metadata to any one of those files, but also still provide a way to specify metadata for every song that is created.

As far as updating existing metadata when a .cho file is imported, what is the correct way to handle this? Do I rename existing metadata fields (this is more complex as I have to compare what the song is using to what is in the file, but how will I correctly match up the fields especially if multiple values are specified)? Do I just add new ones? If I add new ones, do I remove the song tied to the .cho from the old metadata groups and add it to the new? What happens to the old fields if you don't want them anymore? Do I force users to have to cleanup old metadata if they happen to edit the file? It doesn't seem to me like there is a very clean way to handle this...

Mike

[KHS]

That would require a different implementation from what is in place. I would need to parse out all the metadata from the file before importing it to display that, but what happens if you import both a .cho and a .pdf? Or two .cho files? The metadata fields give you a way to specify what additional metadata will be assigned to each song that is created. It wouldn't make sense to show the metadata parsed out from the .cho file when that wouldn't apply to the other files that are being imported. So I would either have to only allow a single .cho file to be imported at a time (which users certainly wouldn't like), or I would have to come up with a different UI where you could specify for each individual file you've selected, what metadata will be applied to it. I'm not even sure what that would look like off the top of my head, because some users import hundreds of files at once this way, so you'd have to provide an easy-to-use and meaningful way for them to apply metadata to any one of those files, but also still provide a way to specify metadata for every song that is created.

As far as updating existing metadata when a .cho file is imported, what is the correct way to handle this? Do I rename existing metadata fields (this is more complex as I have to compare what the song is using to what is in the file, but how will I correctly match up the fields especially if multiple values are specified)? Do I just add new ones? If I add new ones, do I remove the song tied to the .cho from the old metadata groups and add it to the new? What happens to the old fields if you don't want them anymore? Do I force users to have to cleanup old metadata if they happen to edit the file? It doesn't seem to me like there is a very clean way to handle this...

Mike

Thanks, Mike. I wasn't even thinking about mass importation. Your questions are great ones and I'm not smart enough to answer them without thinking about it for awhile!