[DTownSMR]

I don't know if this is technically a bug (I'm 99.9% sure it used to work) or needs to be a feature request or simply a SUE (Stupid User Error)...

When I import chordPro files with a key directive tag the song's field data does not contain the key although the field data does contain info for other specified directives.


***Update*** - not sure what made me check but...the software I use to generate my chordPro files uses an abbreviation for key of just "k:...". That's what is not getting recognized. If I spell key out it works. (although I'm pretty sure it used to work I guess this make it a feature request :-) )

[itsme]

{key: is not part of standard ChordPro. It is one of those extensions that might be implemented slightly different. If your other app also works correctly with {key: instead of {k: I would propose to use that. 
It's up to Mike if he wants to add support for {k:

[sciurius]

The upcoming ChordPro standard (fwiw) will contain the "key" directive but not the abbreviation "k".
In general, please do not use abbreviations if not neccessary. You type the keyword in. Once. In a file. Using a convenient editor. Is it really important to save two keystrokes?

[DTownSMR]

The upcoming ChordPro standard (fwiw) will contain the "key" directive but not the abbreviation "k".
In general, please do not use abbreviations if not neccessary. You type the keyword in. Once. In a file. Using a convenient editor. Is it really important to save two keystrokes?

I'm actually not typing it in. I use a program to convert screen scrapes. I highlight the key, and press "Key" in the sidebar and it formats the data as a chordPro directive. That program uses abbreviations and is out of my control.

IMHO removing abbreviations, whose use seems to be pretty widespread, will not benefit the standard.

[DTownSMR]

v1.3.1 update -

Now with the v1.3.1 release MSP crashes if the file contains a {k:...} directive. However, it does work with a {key:...} directive.

[sciurius]

I'm actually not typing it in. I use a program to convert screen scrapes. I highlight the key, and press "Key" in the sidebar and it formats the data as a chordPro directive.

Correction: "as a custom, ChordPro-style, directive."

IMHO removing abbreviations, whose use seems to be pretty widespread, will not benefit the standard

The current standard does not have the "key" directive, nor any abbreviation for it. It's a new directive.

The reason I encourage the use of full keywords is that abbreviations quickly become confusing. For example, {artist:...} and {album:...} are clear, but what is {a:...} ?

Anyway, ChordPro is an advisory standard, everyone is free to implement it the way she sees fit. But I think we all benefit from trying to stick as close to the standard as possible, or convenient.

That program uses abbreviations and is out of my control.

Have you considered contacting the author?

[DTownSMR]

I've re-worked this several times because I thought it might be taken as being argumentative, which I'm not trying to be. However, I'm not sure how well I did.     If you think it still does read that way, I'll apologize in advance because that's not my intent. I'm merely trying to convey a different POV. 

I'm actually not typing it in. I use a program to convert screen scrapes. I highlight the key, and press "Key" in the sidebar and it formats the data as a chordPro directive.

Correction: "as a custom, ChordPro-style, directive."

IMHO removing abbreviations, whose use seems to be pretty widespread, will not benefit the standard

The current standard does not have the "key" directive, nor any abbreviation for it. It's a new directive.

How far behind the standard is from the implementations and/or if and when it's going to catch up isn't really my concern. From my POV if the software I use to convert to chordPro format and all the software we use to display it on our iPads and Android tablets all have the same "custom, ChordPro-style, directive.", it's just a chordPro directive to me (however technically inaccurate that may be...today).

btw, many (if not all) of the implementations of readers that I've come across that support custom directives have also followed the standard and supported abbreviations for those custom directives.

The reason I encourage the use of full keywords is that abbreviations quickly become confusing. For example, {artist:...} and {album:...} are clear, but what is {a:...} ?

That's exactly the point of a standard. Would be to state what "a:..." means.

I would agree that full keywords is desirable for human readability but that's not my use case and I'm not even sure human readability should be a primary goal. Ideally, the chord chart would have no markup and the software would just be able to process it like we humans can. Since the markup is there so a computer can understand and they're not confused by abbreviations I'm not sure why it's a concern. Granted folks new to hand crafting chordPro directives will find human readable form useful but after 10 or so files they'll be very thankful for abbreviations. And if they're generated some other way there's no reason to care. Am I missing a use case?

My use case: I use a program to convert screen scrapped text to chordPro format at which time what it looks like is irrelevant and never again read by a human. From that point on it's only computer software parsing it to display and I'm pretty sure they won't get confused by abbreviations.  

Anyway, ChordPro is an advisory standard, everyone is free to implement it the way she sees fit. But I think we all benefit from trying to stick as close to the standard as possible, or convenient.

Certainly standards are only successful (i.e. a "standard) when they are followed however I think you'll actually find the reverse to be true when it comes to standards. The more restrictive or unaccommodating they are, the less they are embraced and/or followed. At least that's been my experience. And yes, I do realize "restrictive & unaccommodating" are VERY subjective but a reality none the less that we have to deal with.  

That program uses abbreviations and is out of my control.

Have you considered contacting the author?

Sure, and he's been very accommodating and I'm sure he will so again.

I also believe that when I initially switched to chordPro format MSP supported an abbreviation for key. I know for sure it didn't crash as it started to do when I started this thread. And although I can't go back and test it out now to know for sure, I do know that the current behavior is different enough that I believe I would have noticed that the key abbreviation wasn't working. As a software developer I consider this a regression bug (if I'm correct of course LOL). Moreover, it has the potential for future failure if I ever have to re-import those files again. They'll either crash MSP or silently fail...both are bad options over something as trivial as support for abbreviations.

Plus, I think the standard should be consistent. It started with supporting abbreviations, folks writing implementations also use abbreviations for both generation & consumption, and IMHO the standard should also support them in the future even for new features. I do understand that could cause potential conflicts where custom directives become official standard directive and different implementations may have used different abbreviations (like {a:...}). Hopefully those conflicts, or at least a majority of them, could be detected and handled by using letters in those abbreviations.

For what it's worth...YMMV

[sciurius]

Jon Postel's robustness principle (a generally accepted design guideline for software) reads: "Be conservative in what you send, be liberal in what you accept".
Any program is completely free in accepting directives, abbreviations, whatever. Any program is completely free to accept "k" as an alternative way to specify the key of the song. But the ChordPro standard only defines "key". So programs are encouraged to use "key", but are free to accept "k" as well if they feel so. Do not think too easily that generated data is not meant for humans. Historic mistakes include PostScript, Forth, and XML.

That's exactly the point of a standard. Would be to state what "a:..." means.

Even if the standard did define a meaning, would you know it? At all times, without looking it up?
For example, I often use a id3 tagging tool that uses command line options -a for album and -A for artist. Or the other way around. Each time I have to lookup what means what.
On the other hand, the unabbreviated options are --artist and --album. Clear and unambiguous.
You lose nothing by generating unabbreviated keywords, but you may gain a lot.

[Zubersoft]

I need to test again, but I don't believe a {k: ...} will crash MobileSheetsPro with the latest version. I'm not even sure that was really the problem before, as none of the crash reports had anything to do with that. There were other problems that were introduced that may have been related.

If it's useful to you for me to support {k:...} I don't have a problem adding support for that. It's really easy for me to do. The same goes for any other abbreviations.

Mike

[sciurius]

If it's useful ... to support {k:...} I don't have a problem adding support for that. It's really easy for me to do.  The same goes for any other abbreviations.

Please do. I think this will be advantageous for some users, while others won't be impacted negatively.
From rereading the thread I don't see other abbreviations than "k" for "key" being discussed here.

[DTownSMR]

Jon Postel's robustness principle (a generally accepted design guideline for software) reads: "Be conservative in what you send, be liberal in what you accept".

Words to code by!  

Any program is completely free in accepting directives, abbreviations, whatever. Any program is completely free to accept "k" as an alternative way to specify the key of the song. But the ChordPro standard only defines "key". So programs are encouraged to use "key", but are free to accept "k" as well if they feel so. Do not think too easily that generated data is not meant for humans. Historic mistakes include PostScript, Forth, and XML.

Agreed, there very well maybe use cases where human readability is a concern. Are they the predominant/most frequent ones?!? I don't know. But what I do know (or at least think I know   ) is that the standard would be best served by being as specific as possible. Harkens back to your Jon Postel quote. The more specific the standard is the less likely that implementations will be incompatible.

That's exactly the point of a standard. Would be to state what "a:..." means.

Even if the standard did define a meaning, would you know it? At all times, without looking it up?
For example, I often use a id3 tagging tool that uses command line options -a for album and -A for artist. Or the other way around. Each time I have to lookup what means what.
On the other hand, the unabbreviated options are --artist and --album. Clear and unambiguous.
You lose nothing by generating unabbreviated keywords, but you may gain a lot.

I'm not suggesting that you do away with non-abbreviated directives so that someone that doesn't know has to look everything up. Merely that keeping the standard consistent by offering standard abbreviations across the board would benefit the standard and the community of users. You could (and probably should) still highlight that the recommended practice is to use non-abbreviated directives and state the reasons to avoid using abbreviations.

I did spend a little bit of time Googling & looking at some implementations. Of the ones I found, most that offer custom directives generally offer an abbreviation as well. My guess is since the standard has opened that can of worms (so to speak), it's become a general practice with implementers. Again, YMMV.