<lyrics> Structure Suggestion

Larry Rix
2014-03-03
2014-05-05
  • Larry Rix
    Larry Rix
    2014-03-03

    Consider changing the <lyrics> tag specification to have more structured parts, such as:

    <lyrics>
         <verse number=1>
            <line number=1>
                <chord>G</chord>
                <phrase>And can be that</phrase>
                <chord>Am/C</chord>
                <phrase>I</phrase>
                <chord>D</chord>
                <phrase>should</phrase>
                <chord>G</chord>
                <phrase>gain,|an</phrase>
                <chord>C</chord>
                <phrase>in-</phrase>
                <chord>D</chord>
                <phrase>terest</phrase>
                <chord>G</chord>
                <phrase>in my</phrase>
                <chord>D</chord>
                <phrase>Sa-</phrase>
                <chord>A</chord>
                <phrase>avior's</phrase>
                <chord>D</chord>
                <phrase>blood?</phrase>
            </line>
            <line number=2>
                ...
            </line>
        </verse>
        <verse number=2>
            ...
        </verse>
        <chorus number=1>
            <line number=1>
                ...
            </line>
        </chorus>
    </lyrics>

    This does have the standard problem with many XML specifications, in that it is quite "tag-wordy" or "tag-verbose". What would be preferable would be a JSON equivalent.

    Use-Case: This suggestion solves a use case where one wishes to query attributes about the lyrical structure of a song without using any form of text parsing or writing a lex/yacc "mini-language" parser (which might be fun, interesting, and powerful!).

    Furthermore, the specification would allow for lyrical presentation without the need for using evenly-kerned fonts; opening the way for a very controlled presentation of the lyric text together with complex phrasing and chord structures in a specialized editor, which would know how to map the lyrics into a display space quite precisely.

    The suggestion also makes quantification of the lyrics easier to perform specific queries about the structure and content of the lyrics. Thus, one could ask quite complex questions, such as: "What songs have chord structure of G-Am-D in the start of their line #1?" <-- not claiming this is a complex question, nor that it is not perhaps answerable from the existing lyric data structure.

    One can easily see that given simplistic parsing that the same complex queries can be made and answered. So, the second point is not as strong as the first.

    Finally, how does the existing lyric format play together with sheet music scoring? It might be a simple matter (especially if one chose JSON instead of XML as the overall specification) to introduce needed data in the lyric structure to facilitate complex scoring to sheet music and even simple application to MIDI (given bpm, time-signatures, and so on).

     
    • Christina Lean
      Christina Lean
      2014-04-20

      Yes, I so much want an improved lyrics editor, a bit like what this other free worship software offers.
      Actually, the OpenSong lyrics editor is a real pain to use, furthermore when chords are involved:
      When typing song lyrics, I have to type a blank at the start of every lyrics line (or OpenSong adds one automatically), and a dot at the start of every chord line.
      And what about having a wysiwyg editor where chords move around with the character where they belong to?
      Another much needed feature: display chords to the audience.

      So please make typing lyrics and chords easier.

      Here is an example of what I would expect:

      Lyrics

      Note the chords on top of the lyrics, in a purple color, as superscripts, and they move along with the text when you edit it.

      And this is the corresponding slide:

      Slide

      Isn't there any ready-made Word-Processor control for Quick-Basic?

       
      Last edit: Christina Lean 2014-05-11
  • Ed Palmer
    Ed Palmer
    2014-03-07

    Larry,

    I've given a lot of thought to making a better representation of the song within OpenSong. Your representation is one good alternative that I had not considered. I'd like to be able to better represent not only chords and lyrics, but extend the encoding to support formatting as well, because an often-asked request (after "when's the next release?" and video support) is to add some sort of bold/italics/column capability to permit things like call-and-response, alternative text, or just staying within OpenSong instead of having to punch out to Powerpoint or another program to get that.

    Your example actually highlights one of the things I have struggled with. If a word is split into two different text elements, how do we search on it? In your example, you split both "interest" and "Savior"

    <chord>C</chord>
    <phrase>in-</phrase>
    <chord>D</chord>
    <phrase>terest</phrase>
    

    Something has to be done special to make sure that a search for "interest" will find this block. (Of course, we have that problem in the current representation, so this would not be a regression.)

    Thanks for your thoughts, and for your interest in improving OpenSong. I wish I could tell you exactly when something like this might get added into the program, but as has been pointed out frequently by myself and others, we all have far too little time to accomplish what we want to do on OpenSong. However, I'm doing a research project in XML and XSLT at the moment, so I'm hoping that some of what I uncover in that project will "spill over" to OpenSong.

    Peace...

     
  • SvA
    SvA
    2014-05-04

    I actually find the current editor, given the capabilities of the program, the easiest and most WYSIWYG approach I can think of. More fancy stuff is needed only when proportional or non equally sized fonts start to get supported.

    You need to tell the editor in some way, whether you are entering chords or lyrics. whether you do this with a character in the first column or with some function somewhere - I prefer the former. It's faster to enter and easier to check.

    I usually enter the lyrics first, without the blank in the first column, then save the song and OpenSong adds the blanks. Then I proceed to enter the chords. With the current system, I can just type them away, adding blanks as required. With a system as proposed by Larry, or maybe as ChordPro, you need to move the cursor to the place you want your next chord to be. Again, I prefer the former.

    The only drawback is, as you said, if you change anything in the lyrics, the chords don't move along. But this is not so much related to the way the lyrics are stored in the file, but could be handled by the editor by adding some logic to it, probably much more lightweight than if using an entirely different format for storage than for display.

    I think the people who defined the OpenLyrics format did a pretty good job, although they left out lyrics text formatting (probably on purpose, because it adds great inflexibility to the lyrics presentation engine).

    Also their use of <br/> tags is nonsense in my opinion, as is the line breaks in the formatting of Larry's example. XML, by default, contrary to html, preserves white space, including line breaks. As a general rule, if you have running text, you should be able to just remove XML elements, with or without the text that element encloses, depending on the nature or the element, and what remains is a proper running text.

    When it comes to searching lyrics, therefore, an XML format with inline chords does not provide much trouble. Just delete all the chord elements and you're good to go. You don't even need a marker for dashes anymore (the current _) because it would go where the chord is inserted. Actually, on second thought, there needs to be a text marker for this, because typically you will want to split words at syllables but chords may be anywhere.

    Concerning the chord elements, it is probably better to add the chord as attribut, nor as encompased text. that way you can more easyly cater even for diffenrent chord schemes, such as C, D, E and do, re, mi, and also have capo-chords, modulations, and who knows what.

    One use case comes to mind, though, when I wished the lyrics/chords part of OpenSong was more XML like: I tried to convert the songs to Songsheet Generator-format in order to get prettier print outs, with or without the chords as needed at the moment; things that actually need improvement from within OS.

     
    Last edit: SvA 2014-05-04
    • Oon-Ee Ng
      Oon-Ee Ng
      2014-05-05

      I actually wrote some bare-bones python code which converts from
      OpenSong format to ChordPro.... works pretty well as far as I can
      tell, using it for my church currently.

      On Mon, May 5, 2014 at 1:55 AM, SvA sva-de@users.sf.net wrote:

      I actually find the current editor, given the capabilities of the program,
      the easiest and most WYSIWYG approach I can think of. More fancy stuff is
      needed only when proportional or non equally sized fonts start to get
      supported.

      You need to tell the editor in some way, whether you are entering chords or
      lyrics. whether you do this with a character in the first column or with
      some function somewhere - I prefer the former. It's faster to enter and
      easier to check.

      I usually enter the lyrics first, without the blank in the first column,
      then save the song and OpenSong adds the blanks. Then I proceed to enter the
      chords. With the current system, I can just type them away, adding blanks as
      required. With a system as proposed by Larry, or maybe as ChordPro, you need
      to move the cursor to the place you want your next chord to be. Again, I
      prefer the former.

      The only drawback is, as you said, if you change anything in the lyrics, the
      chords don't move along. But this is not so much related to the way the
      lyrics are stored in the file, but could be handled by the editor by adding
      some logic to it, probably much more lightweight than if using an entirely
      different format for storage than for display.

      I think the people who defined the OpenLyrics format did a pretty good job,
      although they left out lyrics text formatting (probably on purpose, because
      it adds great inflexibility to the lyrics presentation engine).

      Also their use of
      tags is nonsense in my opinion, as is the formatting of Larry's example.
      XML, by default, contrary to html, preserves white space, including line
      breaks.

      When it comes to searching lyrics, an XML format with inline chords does not
      provide much trouble. Just delete all the chord elements (including the
      element's text if used (OpenLyrics specifies the chord as attribut, which,
      by extension, coud cater even for diffenrent chord schemes, such as C, D, E
      and do, re, mi, and also allows to have capo-chords, modulations, and who
      knows what)) and you're good to go. You don't even need a marker for dashes
      anymore (the current _) because it would go where the chord is inserted.
      Actually, on second thought, there needs to be a text marker for this,
      because typically you will want to split words at syllables but chords may
      be anywhere.

      One use case comes to mind though, when I wished the lyrics/chords part of
      OpenSong was more XML like: I tried to convert the songs to Songsheet
      Generator-format in order to get prettier prints with or without the chords
      as needed at the moment (things that actually need improvement from within
      OS).


      <lyrics> Structure Suggestion


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/opensong/discussion/373378/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/