Feature Request: Sheet Music / PDF support

edited November -1 in Development



It would be nice if one could use/project sheet mucis files (Musescore, Sibbelius, Finale, etc) and/or PDFs for the band, choir, orchestra, etc. Something similar to "The Paperless Hymnal" (http://www.paperlesshymnal.com/CN/index.html)




  • mmjmmj
    edited March 2012

    Hello DJBoer,

    these features are already requested. PDF support for the presentations plugin was once implemented, but lies idle since long time as there were some problems with packaging it into the Windows installer. But it is not unlikely, that these problems can be resolved when someone looks in it once again.

    The support for musical score notation is requested as well. But it has a low priority, as it is expected to require a lot of work while there is low demand and no developer has some personal priority on this point. This, of cause, might change. For example in case that CCLI SongSelect starts to provide score sheets in a apropriate format, so that such a feature can be easily used by a many users.

  • edited March 2012

    The beta version of the new Song Select site allows downloads of all the music in PDF as does the already in production mobile song select site.

  • mmjmmj
    edited April 2012

    Hmm, I don't find other PDF sources than already available on the old portal. This ones are layouted for sheet music. What would be reeded are slides, which are designed to show over a digital projector. Otherwise the text is too small for this purpose.

    According to PDF btw: I've looked a bit arround. I think the best soultion would be to use MuPDF libraries. Beside tha fact, that they are ultra fast and highest quality they should be easy to package and they support XPS documents as well. I looked into it, and I think I can provide some python bindings. The only limitation is, that the API is not yet stabile, and I've still some troubles with creating shared libs. I've talked to the devs and I think it makes sense to wait a bit until v1.0 is out, and shared lib building is provided bu MuPDF guys.

  • mmj mupdf has the disadvantage of not commonly being built for OS X or Linux.  Ghostscript a relation of mupdf has the habit of being provided out box for more platforms.

    Both are from the same group of developers.   Both support PDF and XPS.   The major difference is Ghostscript is not designed todo the direct output.   So PDF to Image then display with ghostscript.  With mupdf go direct to display.

    Ghostscript is also mature with fairly much stable ABI.    So from my eyes support Ghostscript for now.
  • I'd recommend that mupdf should used for all platforms. A quick search on google shows that mupdf is included in the lastest versions of the big linux-distributions. On Mac OS X it would (like windows) be necessary to include a mupdf-lib in the OpenLP install.
    If just one solutions could be used for all platforms it would lessen the maintaince burden, which should not be underestimated, especially not in an open source project like this.
    Is anybody actually working actively on PDF support at the moment? Otherwise I'll might have a look at it...
  • tgc its the there be dragons clause.   http://www.mupdf.com/

    Windows version is built by the mupdf team so building for windows should not be too gremlin packed since they commonly build and runs.  One head ache mingw is not build for on Windows.   Linux has package maintainers to share workload with so not too bad.   In fact if we are lucky on Windows and Linux using the built versions should be possible at times.

    OS X is where the large possible teeth are.   Not commonly build by the upstream I should have put.

    http://en.wikipedia.org/wiki/MuPDF   tgc it gets a worry when you cannot find upstream build or common downstream builds for a wanted platform.

    tgc I have been trying to find some time myself to look at it.  But currently no mainline developer is working on it last developer I know did this https://code.launchpad.net/~j-corwin/openlp/pdf  this is using poppler-qt4 .  There is a good chance that j-corwin source be usable for mupdf support.   This is why I have been digging into the platform support sides.

    tgc this is a big problem with MuPDF the source code in theory should support OS X.   Poppler-qt4 code should also in theory support OS X and Windows as well as Linux.  The true fact building Poppler-qt4 you find out it support is not that great for OS X and Windows because its not regularlly built for those platforms.

    The fact MuPDF has not been built for OS X commonly the size hiding issues we don't know.  Ok this is 1 better than Poppler-qt4 that is not regularlly build for Windows or OS X and has teeth ready to consume hours fixing regressions.   MuPDF could be the same.

    tgc I don't have a OS X machine to test MuPDF on to find out what its OS X quality is like.

    Linux could have some issues due to not commonly being provided by upstream but there will have a team of people to assist with any of those issues(package maintainers).  So not a major fear or worry.

    OS X is one of those things.   OS X low developer count market so low amount of assistance if you find that you are by yourself get ready for hell.

    Ghostscript is required by particular printer driver makers on OS X.    Yes going Ghostscript on OS X we are not alone.   Even going imagemagick on OS X we are not alone.

    If openlp only supported Linux and Windows I would by like you mupdf would be the go for it because it workable for those platform.

    Its the OS X that forced me to look Ghostscript.   Particularly Ghostscript callable as a executable to turn PDF into images.

    Really I would at this stage temped to support both Mupdf and Ghostscript.  Mupdf will give some thing better like possible animations in pdf that the Ghostscript path cannot provide.   But if we run into hell with Mupdf for some reason and it just will not work at least we are not left without the functionality completely.

    Its like webkit and vlc for playing back videos.  In theory we only need 1.   But having both saves tail when one fails.

    tgc yes I want PDF functionality.   I don't want to be stuck with not able to merge again due to lack of platform support.

    If someone could test build Mupdf on OS X or show where someone is building it for OS X commonly would allow me to cross off a issue with it and be more confident that its good enough to make it.
  • I have a solution that uses jpeg files. pdf is too slow. It goes like this:

    Step 1: add Formatting tag: go to settings, select "configure formatting tags, then click on "new" then Under description give it a description I called it "music",  then under tag call it:  sm    (for sheet music), under start HTML type:   <      under end HTML type:   >  
    then save that.

    Step 2. in your custom folder (in the stages folder) you should have a file called "print.html" make another copy of that and call it piano.html
    Now you need to edit it in an editor and add the following line in the <style> section:
    #sheetmusic { width: 90%; }
    then save that file.

    Step 3: You need to edit any other display files, like stage.html in your custom folder by adding the following line in the <style> section, so as not to display the sheet music:
    #sheetmusic { width: 0%; }

    Step 4:  Open your sheet music pdf in gimp editor crop it to just the first verse and export it as a .jpg (give it a meaningful name with no spaces in the file name e.g.This Is The Day Verse 1 can be saved as thisisthedayv1)  do that separately for each verse and chorus etc.
    Now, the only place you can save these .jpg files where they work, is in the custom folder, with the .html files.

    Step 5: In OpenLP edit your song. So for the example I used "This Is The Day" edit the first verse and add the following to the first line (at the start of the verse):

    {sm}img id=sheetmusic src=thisisthedayv1.jpg{/sm}

    (note: the src is the same file name as the jpg that you created, don't add " marks, OpenLP does that automatically).

    Step 6: repeat step 4 and 5 for each verse/chorus/bridge etc.

    Now, if you have OpenLP running, and you open that location in your browser like you do for your stage view, then it should work,

    e.g. localhost:4316/stage/custom/piano.html

  • It is also possible to display the whole score for the sheet music, if you save it as a .jpg file in the custom folder, along with the html files. Then, in the service editor in OpenLp right-click on the song, select "note" and type the following <img src="thisistheday.jpg" > obviously you use your relevant file name. The down side of using this method, is that it isn't saved that way in the data base, because notes don't get saved with the song, they only get saved with the service. so you would have to do that each time for each song for every service. It would be great if we could display comments, then we could just add the link in the comments. and sve it with the song. but it isn't possible yet.

  • I think the big issue with this one, it is a little like my current project, which is porting from MS Access, there are tools to do this, but they are not Python supported tools.  This requires a "bridge" program that goes from the tools C support to Python.  That works well enough on Linux and MAC as they have a native C compiler.  The oddball of the group is Windows as there is no C compiler installed by default.  This means your setup.py needs to have a windows version pre-compiled and then be smart enough to use this, but to simply call the C compiler for Linux and Mac.  

    The other issue, some of these tools, are not generic enough to run on Mac.  
Sign In or Register to comment.