Hi all,
I've been given a task to write a program that can display words for music up on a projector screen. Simple enough you might think....Think again.
The program needs something similar to the presenter view in powerpoint and only displays 2 lines at a time on the display monitor/screen/projector.
(For a bit of background we have 2 very large projector screens at our church which has video of the people at the front as well as the words to songs across the top.)
Being an amature programmer I need some help. Firstly how do i store all this information???
Lets look at a typical song
Verse 1
Line 1
Line 2
Line 3
Verse 2
Line 1
Line 2
Line 3
Chorus
Line 1
Line 2
Line 3
What is the best way to store this text in the database so that I can display the entire song or just two lines at a time?? Or maybe I'd like to just get verse 1 or the chorus??
The first thing that came to mind was XML but storing XML in a database seems like a bad idea. What it might look like is:
<song>
<title>Title</title>
<verse number="1">lines</verse>
<verse number="2">lines</verse>
<chorus>lines</chorus>
</song>
I also thought about tackling this problem relationally but that seems....unrealistic.
My last thought is just doing something like this:
Database has Title, number, composer, etc in other database fields. The song text would look like this:
[Verse]Verse 1[/Verse]
[Block]
Line 1
Line 2
[/Block]
[Block]
Line 3
Line 4
[/Block]
[Verse]Verse 2[/Verse]
...
[Chorus]Chorus[/Chorus]
...
Is this a good idea, bad idea...I'm just struggling to find a way that I can store the information ie. the words, with some meta data that describes what is a verse and chorus and which lines go together on the screen.
-
-
This looks a lot like YAML.
-
Have you looked at WinAmp and its various lyrics plugins? Since you're synch'ing to music anyway.
-
Could you use PowerPoint? It should allow you to specify timings for each slide.
-
This is my opinion: use a relational database like MySQL or some kung-fu like Bamboo.Prelevance if you're not going to be storing a lot of information.
First off, store the lyrics in chunks: break them up into versuses and choruses.
Next, relate each chunk with a time-index: the time to start and the time to stop showing that particular chunk on your presentation machine.
[Verse]
(blah blah blah)
[Verse]
(Hour/Minute/Second)
00.00.00 00.00.32 Verse1
00.00.33 00.00.36 Verse2
00.00.37 00.00.43 Chorus
...
Kinda like that, I think. -
Ahh...lucky for me I don't need to include timings. An operator will click on the lines of the songs that they need displayed on the screen.
The layout of the program I have clear in my mind and I will definately be using MSDE for the database. The only thing I am having trouble with is what format to store the data in.
There really is no 'good' way to store it is there?
-
Jachin wrote:
Ahh...lucky for me I don't need to include timings. An operator will click on the lines of the songs that they need displayed on the screen.
The layout of the program I have clear in my mind and I will definately be using MSDE for the database. The only thing I am having trouble with is what format to store the data in.
There really is no 'good' way to store it is there?
I'd say that this depnds on what you are doing to the display.
example: overlay with video using hardware?
just the text from the computer?
are you drawing the text with fonts?
one example:
store as html and use that to draw.
or
store as .rtf from word and use that to draw
or store as xml and use xslt to draw
or
custom drawing app -- custom format.
and what ui does the user have to enter the songs with and how can they format the text??
seems like that needs to be part of the thing... -
Currently the text is simply ouput to a textbox on the second display which is a full screen form that is completely black. The vision mixing equipment is able to do the rest.
Is storing XML or HTML in a database a good idea??
In the initial stage I'd insert all the songs and format them manuall until a suitable GUI could be designed.
All I'm really after is a good method to store the information.
Is storing XML in a database ok? Or my initial idea of the [verse] tags ok?
The program should be able to grab 2 lines of the song at a time and display them in a optionbox. This allows the operator to select the 2 lines for display.
So basically i just need to load the song into an arrayList and make sure it is split in all the right places. My first version was based on a plain text file that had '&' characters at the end of every 2 lines. It would read the file in, split on the '&' and there was my ArrayList for the OptionBox.
The problem with that is that there is no provision for 'metadata' like verse 1, verse2 chorus and copyright info. I don't know, maybe I am complicating this too much. -
Over-engineering? I'd just go for a straight-up text file.
-
I thought about that, but they also need this stuff to be accessible via the web. I thought it may be easier to have it in a database.
-
how many songs max?
10?
100?
1000?
10000?
unless you have a need to hanlde a lot of songs
(more than 1,000 say)
I'd say just use xml for the whole app.
why?
simple, expandable, easy to push to the web, easy to read in text editors and so on...
idea of how to setup:
create a main folder on the server: /MusicDB/
then create folders for each letter A-Z
then in the main filder plan on having 1-10 xml and xslt files to manage the rest of the data
and a few .aspx files for the web page view
and a webservice to connect other clients.
one xml would have song title, description,location of details.
in the folder holding the song have 1 xml file per song.
store the song details, comments, notes, credits, and whatever.
for the display app call the ws to get the sond and show it.
you can have a ws to let a winforms client edit the song.
you can have pages to read the songs and format them for printing etc...
xslt can help format the xml for pages and printing.
depending on where you are best one xample is xslt could scan the songs and build indexes for table of content, directory, and other stuff.
if later you needed to you could move to a db.
but for even 10,000 songs a folder tree and xml souhld work well. -
Jachin wrote:Is storing XML or HTML in a database a good idea??
Sure. If you want people to be able to find a song by typing in a line or two of the lyrics, then you could use full-text indexing.
Since your data is canonical, you could store multiple copies of it in different places.
-
I think I may just go with a database that contains XML for the songstext and stores the title and composer in other fields to make it easy to search. Thankyou everyone for your valuable input.
-
Good luck. I imagine the toughest part is the UI, not the backend storage.Jachin wrote:I think I may just go with a database that contains XML for the songstext and stores the title and composer in other fields to make it easy to search. Thankyou everyone for your valuable input.
-
Well almost a year from when I started this little project it still has not really gone anywhere. I am still grappling with how I can store this information in a way that will be simple yet contain all the information necessary to display the data correctly.
I am now leaning away from the idea of XML in a database as many people have told me this is not a good idea. The thought of 100s of xml files doesn't sound all that good either.
Anyone got any more bright ideas? -
If using a database, I'd probably do something like this (I thought on it for less than five minutes, so it's probably not the best of ideas).
Song (id, name, artist, maybe some other fields)
SongSection(songid, order, type, lines)
A section is chorus, verse, bridge (type indicates which), lines are all the lines in that section (just use a TEXT field), split it on line breaks when you only want to display two lines at a time.
So an example song would have a row in Song like this:
1, Still Loving You, The Scorpions
And several rows in SongSection like this:
1, 1, Verse, Time, it needs time\r\nTo win back your love again\r\nI will be there, I will be there etc.
1, 2, Chorus, If we'd go again\r\nAll the way from the start etc.
This is based on the fact that you said that you also wanted to be able to get just the first chorus or whatever, otherwise I'd probably not bother with splitting up the song at all. -
Another way to go would be to store each song in a flat-text file. Separate screenfuls of text with an extra blank line
This is the first line of the song, yeah yeah
This is the second line of the song, yeah yeah
Those two lines showed together, yeah yeah
These two lines also show together, yeah yeah
Finding a song given a lyric is a simple "find files containing..." search in Explorer
You could store metadata (author, etc.) in the files or encode it in the folder structure, depending on taste
-
Thanks for your comments, it is much appreciated.
Sven Groot wrote:
Song (id, name, artist, maybe some other fields)
SongSection(songid, order, type, lines)
A section is chorus, verse, bridge (type indicates which), lines are all the lines in that section (just use a TEXT field), split it on line breaks when you only want to display two lines at a time.
So an example song would have a row in Song like this:
1, Still Loving You, The Scorpions
And several rows in SongSection like this:
1, 1, Verse, Time, it needs time\r\nTo win back your love again\r\nI will be there, I will be there etc.
1, 2, Chorus, If we'd go again\r\nAll the way from the start etc.
I have a couple of issues with this approach:
-Isn't it bad to to store information like 'order' in a database.
-The program has to display 2 lines in a black bar at the top of a projector screen. If you just break on every second \r\n then you run into problems if you get a long line that wraps to become two lines.
It really is a difficult problem to solve. Thinking ouside the box would it be a better idea to just store the song text, title, author, etc in one table then store, 'metadata' in another table??
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.