Jump to verse/chorus/bridge

[CardassianScot]

Quite often my worship leader will skip or jump to a verse or chorus that is not in a prearranged order. Now normally, I copy and paste choruses and stuff like that so my operator can just click enter all the way through but if the order gets messed up (sorry changed) then it confuses some of my operators. Yes, I know I can use page up and page down to jump verses but it would be much easier if I could somehow attach verse status or chorus status or bridge status to any given 'verse' and then hit '1' to jump to verse 1 or 'c' to jump to the chorus, rather than having to search for the right bit.

[Christian]

...it would be much easier if I could somehow attach verse status or chorus status or bridge status to any given 'verse' and then hit '1' to jump to verse 1 or 'c' to jump to the chorus, rather than having to search for the right bit.

Mmmm....you mean kind of a similiar thing to how SongPro works?

Does anybody else think they would benefit from such a feature?

Thanks for your suggestion,

Christian.

[webmaster]

Me think that be good toooooooo..

Webmaster

[Tekman]

it would be much easier if I could somehow attach verse status or chorus status or bridge status to any given 'verse' and then hit '1' to jump to verse 1 or 'c' to jump to the chorus, rather than having to search for the right bit.[/quote]

I absolutely agree and we have found that it is much easier if the verses and choruses are in the correct order so that the operator just hits return to move through a particular hymn. There is not sufficient 'thinking time' to do this any other way when hymns are being sung. If we do use ZionWorx to run hymns, then we have to 'tidy' them up first. For a large number of our services we have simply reverted back to using PowerPoint slides with the verses etc in correct order on separate slides, but run these from within ZionWorx. This is partly because various people in our church compile and lead services.

I was going to suggest to Christian something along the same lines as you have. This would have been to 'tag' the repeat verses or choruses so that you could have a printed or handwritten list beside you which told you which verse to go to using the appropriate 'tags'. If there were different choruses or repeat verses in a song, then you could have C1, C2, say and V1,...V5 etc when needed.

If your idea could be implemented, then this would make running hymns with choruses or repeat verses etc so much more easier.

[Tekman]

Does anybody else think they would benefit from such a feature?

Thanks for your suggestion,

Christian.

Hi Christian

Sorry I missed your reply again to this post before adding my comments to what had already been said.

We could certainly benefit from this feature and I think the lack of it is the prime reason why, to-date, we are not making full use of all of ZionWorx's facilities. Hence, all the stuff about compiling 'little' databases within an empty database file at home and then loading these 'subsets' onto our system at church I think if we do any of the aforementioned, then these are really just workarounds.

In other words, it would be great if you could improve the navigation in the songs. I think this would then make a lot of people very

Thank you
The Tekman

[mango]

Now, what would happen if you have a long verse that spans across two slides, which key would you assign to the first slide of that verse and which key to the second slide of that same verse?

[Tekman]

Now, what would happen if you have a long verse that spans across two slides, which key would you assign to the first slide of that verse and which key to the second slide of that same verse?

We currently 'tidy' up our hymns i.e. long verses/choruses we chop-up and/or other verses/choruses where there is musically a 'natural pause, break, inflection etc', then we use that as a 'break-point'. These measures make it both easier for the computer operator and it also makes things easier and more logical for the congregation who are singing the hymns.

If some sort of verse tagging is implemented, then I guess it is going to have to be dynamic, in as much as it will need to be configurable by individual users because of the above mentioned points. I think that to do it any other way would probably cause as many problems as it solved.

As already mentioned, we have found that we cannot use the database of songs 'as supplied'.

I suspect from watching the various posts on this site, that other users have found that they too need to check through the hymns that they are going to use before their services and then 'tidy' them up for easier use.

I rather think that the various 'workarounds', vis-a-vis the songs database that people seem to be striving for, are all attempts in some way to address this crucial aspect of operation.

Anyway, thank you for highlighting this point and spurring me into making a further post on the topic.

Thanks
The Tekman

[CardassianScot]

Now, what would happen if you have a long verse that spans across two slides, which key would you assign to the first slide of that verse and which key to the second slide of that same verse?

I would just assign a key to the first part of each verse. If I only needed to go to the second part of the song I could then use Page Down, or if my operater was a bit unsure he could just press 'Enter' till they got to the right bit but it would still be quicker if they could jump directly to the correct verse.

[Christian]

Hi folks,

I think what we're grappling with here is the difference between 3 types of information: raw data (i.e. the song lyrics), formatting data, and meta data which describes the meaning of the raw data (e.g. defines it as a 'verse' or 'chorus').

What I've been trying to do from the start with ZionWorx (and this is also where I think some other song display software packages have missed the mark a bit) is to achieve a separation between these different types of information. In my mind, this separation of data is key in making software usable and flexible.

The plan behind v2.0 was to have a database of raw song data which anyone can use in its original state, without having to make any tweaks to it. This, combined with the Service List which stores separate 'formatting' data should provide a totally flexible system. For example, if you change font size or image margins, then the required word-wrapping and screen breaks are all dynamically recalculated from the original raw data. I think this is ultimately what makes ZionWorx a powerful yet simple tool...

What we're talking about adding now is the song 'metadata' - the extra information that describes what some lines in a song mean (i.e. verse, chorus) and also the order in which they are most likely to be used e.g. verse 1, chorus, verse 2, chorus, bridge etc. This information could be added using some kind of tag markup within the raw song data itself. But I'd also suggest that the feature should be:

1. Totally optional - a song should not be forced to contain such information.
2. Non-restrictive - if you want to deviate from a prescribed running order, then you can, without being penalised for it.

Getting back to the point of the original post (sorry CardassianScot!) there could also be a selection of keyboard shortcuts which could provide navigation to the next/previous song 'section' in the running order, and also some 'quick-jump' keys which could display, for example, the 'chorus' or 'verse 3' instantly...

Please feel free to comment (or argue)!

[Tekman]

But I'd also suggest that the feature should be:

1. Totally optional - a song should not be forced to contain such information.
2. Non-restrictive - if you want to deviate from a prescribed running order, then you can, without being penalised for it.

Getting back to the point of the original post (sorry CardassianScot!) there could also be a selection of keyboard shortcuts which could provide navigation to the next/previous song 'section' in the running order, and also some 'quick-jump' keys which could display, for example, the 'chorus' or 'verse 3' instantly...

Please feel free to comment (or argue)!

Hi Christian

You lost me a bit with your definitions of different sorts of data but I did perceive that you have nevertheless discovered what people would like to have in ZionWorx.

Certainly the Songs Database is a very valuable resource and without it, ZionWorx would not be an attractive solution for worship presentation and I thank you very much for providing a complete, and largely workable solution.

I absolutely agree with your summation of what is required in terms of moving/jumping from verses to choruses etc.

I had envisioned some sort of flexible 'tagging' of the verses/choruses (data) but I hesistated in being too prescriptive because I realise that someone has got to program this into the system and make sure that it is a 'robust' solution through thorough testing.

If you can implement the features as outlined in the above quote, then I reckon ZionWorx will then truly surpass the excellent job that it is already doing

Good Luck and thank you for taking onboard the problem that I think everyone is wrestling with in various ways.

Regards
Tekman

PS
Do you have sufficient beta testers?

[CardassianScot]

Christian,

Yup your last post was basically what I had mind. Rather than the rather rigid way Song Pro handles things I was basically hoping for some aditional tag which could be applied to sections of a song but if you just want to paste the song lyrics in and run with that you could.

I have just come back from a youth holiday where I was in charge of the techincal stuff (in contrast to usual job of pastor) and I did appreciate the ability just to copy and paste a song straight in, as for at least one service we just went on and on and started bringing up new songs that I didn't have in the database. However, I then had to really keep on the ball when I had to jump backwards and forwards to keep choruses and verses straight and got it wrong at least once or twice. Ah well, I'm sure it made the young people who usually run our system at church feel better .

[mango]

I totally agree with Christian's point of separating raw, formatting and meta data. As far as I understand, Christian is not in favour of storing the formatting data in the database, formatting (and layout) is done automatically when the user chooses which font, font size, etc, etc while doing up the service list, only raw and meta data are stored in the database.

I can perceive a limitation to this, what if a user doesn't like the layout applied by the formatting rules? For example, if I had the following raw and meta data stored in database (meta data enclosed by '<' and '>'):

<section name="Verse 1">
Did you feel the mountains tremble?
Did you hear the oceans roar,
When the people rose to sing of
Jesus Christ, the risen One?
</section>

and let's say the margins I apply to this song is such that the first 3 lines are on one slide and the last line is on its own on the next slide. I might not like this layout, I 'd prefer two lines on each slide if I can't put all four on one. Not to worry, I know how to fix it, so I make changes in the database:

<section name="Verse 1">
Did you feel the mountains tremble?
Did you hear the oceans roar,
</section>
<section name="Verse 1 (con't)">
When the people rose to sing of
Jesus Christ, the risen One?
</section>

Essentially, what I had just done was I subtlly stored my own layout (formatting data) and at the same time, corrupted the meta data - there is now one extra section to the song with an unusual name "Verse 1 (con't)".

This is just one instance, I can forsee that users will demand power features to make some words of a particular song italics/bold, and these are purely formatting issues.

I guess my point is (after all those babbling ) that you'd probably end up needing to store some formatting data in the database to avoid users tweaking (and breaking) the meta data. The idea of storing formatting data should also carry the two points you made about meta data, that it should be optional and can be ignored. I know this is ugly, and the sad thing is most users won't understand the complexity behind it all

[webmaster]

I would have gone for simple tags say

<1> for v1</1>
<2> for v2</1>

I don't know why you have a problem really.

if verse goes over a slide then you press enter ?

We try our best in our church to get the text to fit on one slide but have it large enough for people to see..

I have never had to change the data supplied by Christian (SOF)

And I imported the whole Salvation Army Song book that works fine too..

I place the chorus between each verse so an operator just has to press enter but I mainly operate the system and this is fine..

Considering service plans used to take 30 to 40mins to create the ppt's i wanted.

now it takes all of 5mins.

anyway

<v1>1st slide part of verse 1</v1> this would work if you put a continuation
<v1>2nd slide part of verse 1</v1>

so to get 2nd part of slide 1 you would press 1 then enter and 1 again and enter maybe....

<v2></v2>
<v3></v3>

[mango]

Just to clarify, my last post was not about how to assign a key to a slide, and I don't think assigning key is a big issue. The big issue lies with how to cleanly separate raw, formatting and meta data. By placing chorus between each verse, you have just done the classic thing of mixing all raw, formatting and meta data together. Really, from a purist point of view, the song does not have a chorus that repeats after each verse, it has only one chorus and it is entirely up to the worship leader of a particular Sunday which order he wants to sing it.

I don't think it's impossible to achieve a clean separation of the three data, just needs a lot of thoughts. Hope this makes sense.

[webmaster]

But it works...

So why worry.

And thats why zionworx is so good if we do it this way anyone can press the enter key if they need to go back to a verse which is not very often they can do that too.

I would like more features but this one maybe is too complecated and if it is not implemented well then it could make the software non user freindly.

KISS is a word I use Keep it simple stupid.

It works and my soloution to the problem may make the database file bigger but my database holds all of SOF 1,2,3 and 890 Salvation army songs plus another 30 out of a salvation army worship book (about 3000 songs)and it holds up very well it is also very quick at searching and in the end we do not need to mess around with the database, only If I the operator and master have added songs I will then backup the old DB files and then install the new one very simple and clean.

Sometines i will use the import utility from a clean database file of machine at home this works well too.

I would like to know why this feature is really needed as being a user I would never really need this feature.

We use about 10 songs a service.

Regards