Without an open source music OCR package, your best option is still to make PDFs of rare Chinese full scores, and allow end-users to typeset parts etc. I am sure they will be more than happy to help us. Moreover we can enlist help from the Mutopia technical team. But after that I would like to work closely on integrating these services into IMSLP. Yagan: I am busy for the next two months (my PhD work). So I strongly believe that we should set up Lilypond and MusicXML submission and compiiling system on our website. Moreover, think about the visually-impaired musicians! A MusicXML file or a Lilupond file would potentially allow a compiler with Braille plugin to generate Braille files in a fly (rather than retysetting in Braille) Of course the generated PDF file is also part of our archive. Therefore in terms for long-term archival, Lilypond is still suitable. Moreover we still store the initially-compiled PDF file. It will still compile by future lilypond compilers if it can compile now. Lilypond format is backward compartible, as a new version of lilypond come out, you may want to maintain the code to make use of the newest feature. works by Xian Xinghai) to get parts score and transposition.įor processing Lilypond zip files, why can't we just lift the system setup off Lilypond (for compiling and setup? I am sure they only use open source software / script which we can use directly. This would exclude most early Chinese Symphonic works which I intend to re-tyset (e.g. A document must be published before 1923, PD in US, Commnonwealth and Europe before it can be uploaded. Mutopia is good for Lilypond, but its admission criteria are much stricter than IMSLP. The functionality of MusicXML is quite limited. Also Lilypond is much more human-readable and editable than MusicXML. In terms of functionality, Lilypond is far superior than MusicXML. In this way, the source file can be adapted by others for their own need with minimal cost.īut the Lilypond compiler is open source and available to any systems (just download it) Proprietary formats (such as overture, sib, finale) should remain unaccepted because they have closed format, and they can be converted to the *open* format MusicXML. This would allow source to be uploaded yet will not incur extra human overhead. Then the human examiner will examine the PDF output as usual. If compile fails or if zip file contains non-text files, reject immediately. After specifying format of the source file on the submission screen, the server automatically opens the zip file and runs the makefile. We can also stipulate a specific file structure for the zip file and the compile script (makefile). However if each source file is uploaded individually, this would certainly clutter the page very quickly because in Lilypond, a file may include other files (like source code in a computer program) and each PDF file may be generated from multiple source file (a source file may also contribute to multiple PDF files.įor typeset score (with *open* format - Lilypond and MusicXML only), we should set up a compiler on the server which automatically reads and unzips a zip file and compile PDF from the source file (like what Mutopia does). produce different transpositions or printing in braille etc) If the user typeset a work and uploaded its PDF, it would also be a very good idea to upload the lilypond / MusicXML source (an *open-standard* typesetting language) so that files can be modified / recompiled in the future as needed (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |