Some designing of PSALM Increment One
Slightly overdue (I mean overdue in going onto this blog), here's some of the more interesting design work done for the first increment of PSALM.
First, the component/module relationships. Please be aware that this is not in any kind of standard notation, but is actually just a tidied representation of what I have written be hand in my grand A4 pad of joy. The key should at the top-right should explain the crazy colour scheme. The arrows give a basic idea of relationships. So, for example, the GUI (which is circular in the diagram for no real reason other than most operations run through it) calls the DB (database) Bridge component. The little arrows under some of the components just highlight some of the more important functions or sub-components.
I have named these 'components' because they won't necessarily constitute modules. If anything, each block is more like a 'part' of the program. So the external XML database is included on the diagram, as is the Setlist object class. I will also point out at this stage that this design is just a starting point that is likely to need refinement. This first increment is about getting something built that will be functional to stimulate further thought and then work.
Next, we have a plan for the layout of the XML database:
<songlist>
<song title="..." writer="..." date="..." basekey="..." capokey="..." ...>
<verse no="..."> | <chorus> | <prechorus> | <bridge> | <tag>
Lyrics go here, [C] chords go in sqaure brackets [Em]
[D/F#] Sometimes chords mig[G]ht be in awkward places. [C] [G]
</verse> | </chorus> | </prechorus> | </bridge> | </tag>
</song>
...insert more songs here!
</songlist>
Hopefully that gives you an idea. Additional imformation can be stored in the song tag, such as theme, quick reference or songbook information. This is not so important for this increment of the program.
For a better example, take a look at this code snippet: songs-nocopyright.xml. You may find it simpler to view this file in a text editor by saving it first rather loading it directly in your browser.
Again, this is just an example, which won't necessarily be used exactly like this in the final implementation.
17 Nov 2007 16:00
| 
Tags: Design Increment One Psalm XML
| 
Comments (3)
| 
Report a problem
Loading…
Steve Rumsby
Some comments on the file format:Out of curiosity, why choose XML as the DB format?
17 Nov 2007, 20:39
This is still very much a work in progress. I agree that as some of those attributes in the song tag could have multiple attributes, it will be better to give them their own tags. Alternative titles, songbooks and themes (however I come to implement them) will all probably end up with their own tags.
The ‘standard order’ for songs will be pretty much how the song is laid out in the xml.
i.e. :
< verse no=”1”>...< /verse>
< prechorus>...< /prechorus>
< chorus>...< /chorus>
< verse no=”2”>...< /verse>
< tag>...< /tag>
I realise that XML isnt supposed to take much notice of the order – well, I guess this is a special version of XML then :-) The idea of XML is that it can be extended to do things how you want, which is what I’m doing! I could put numbers in each tag:
< verse order=”1”>...< prechorus order=”2,5”>...< chorus order=”3,6,8”>...< verse order=”4”>...< tag order=”7”>
or something like that, but don’t really see it to be necessary. Maybe as another improvement in the future, but I can’t let my project include everything or it would go on forever :-)
I want to ensure the whole song is displayed on the screen together in the PSALM interface anyway because scrolling is very difficult to do while playing a guitar! If the program was to be integrated with things like projection software that need an order, this functionality could be added. For the moment I want to just focus on having something concrete that can have lots of extras such as this added in.
Good point about the words & music being different people by the way. I shall see what I can do with that, and how it would be used in my program. :-)
As for why XML… well the ‘real’ reason is that in setting up mySQL in my computer I got locked out because it wanted a password that I never set! After quite a lot of effort trying to fix that, I stopped to think ‘why am i using SQL?’. If I was having so much trouble setting up a SQL server, its quite likely that the average user of my software would too. The song structure/database seems to lend itself to a hierarchical system quite well, and I don’t really need all the ‘extras’ of a full DBMS. A simple, portable text file database like XML would be simpler to use/edit directly if necessary. It would be quite straightforward to use it to convert songs for SongPro or other common programs used in the church context. I know XML quite well too so feel comfortable with it whilst being able to do file input/output in java which I (frustratingly) haven’t done in my course before.
Hmm, that was quite a lengthy reply. Well, Steve, I hope it answers your question, and to anyone else reading this, that it further clarifies things for you.
17 Nov 2007, 22:08
Steve Rumsby
What about songs with unusual chorus placement? V1 V2 C V3 C, for example. Things can get even more confusing with bridges and multiple choruses, sometimes with the same words but different music. I’d expect musicians to want the exact order of everything in front of them.
The reason I asked about XML is that I’ve done something like this before. By the time you’ve put in themes, keys, bible references and other stuff, you’ve got something really useful for planning as well as during playing. But doing all those lookups isn’t fun without a proper DB to help you out!
19 Nov 2007, 11:57
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.