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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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:
Isn't there any ready-made Word-Processor control for Quick-Basic?
Last edit: Christina Lean 2014-05-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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"
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...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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).
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).
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:
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:
Isn't there any ready-made Word-Processor control for Quick-Basic?
Last edit: Christina Lean 2014-05-11
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"
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...
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
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: