Re: [Mutopia-discuss] review of GalileiV/saltarello
On 12/15/12 at 11:14am, Felix Janda wrote: On 12/11/12 at 09:31pm, Federico Bruni wrote: - The mutopiacomposer header field needs to be fixed for old scores You mean it must be equal to the directory? composer = GalileiV Yes. You can/should also check with datafiles/composers.dat. See also the technical section at: http://www.mutopiaproject.org/contribute.html Sorry, you should leave the composer field as it was and only change the mutopiacomposer field. (The composer field is what will be seen on the pdf whereas mutopiacomposer is for example used to list pieces by composer on the mutopia page.) Felix ___ Mutopia-discuss mailing list Mutopia-discuss@mutopiaproject.org http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
[Mutopia-discuss] On the header parsing
Hi,
just some thoughts on the current header parsing of Mutopia's software
motivated by (not wanting to install java and) the thought that lilypond's
language is so complex that parsing it should be left to lilypond itself.
I noticed that lilypond has (since at least version 2.8.0) a --header
option which could be used to retrieve header fields from the file,
thereby letting lilypond do the parsing for us. Compared to the manual
parsing this of course takes longer, especially since it seems that one
has to compile the piece in order to get the header information, on the
other hand one does not need to care where the header is placed in the
file, whether there are multiple headers or variables are used inside
the headers.
In addition to retrieving header fields the Mutopia software also inserts a
lastupdated field, a footer and a tagline to the header. So lilypond's --header
option is not enough to stop the need of manually parsing the files. But one
could put these fields into a separate header at the end of the files. In this
way they take precendence over fields of the original header while keeping it
intact.
Maybe going a bit further one could strip the (new) files in the git repository
from the (automatically generated) lastupdated, footer and tagline fields and
add a new field like mutopiaId (I hope that the name is self-explanatory). When
preparing the files for the server one adds the lastupdated field, the footer
field with something like
footer=\markup{\concat{Mutopia- \lastupdated - \mutopiaId}}
and the tagline in a separate header to the end of each file. One advantage of
this would be that if a update/correction of a piece sent via git is ok, it
wouldn't have to be modified at all. For new pieces just the mutopiaId field
needs to be set. Disadvantages would be the fact that there are now two versions
of the files floating around and I'm not sure about legal matters: For a piece
contributed in terms of a CC license then the only hint about this license in
the files in the git repository would be the copyright field. Is that enough to
comply with the license?
I think that it wouldn't be too difficult to implement it, even in shell by
tweaking and extending the current scripts. I haven't tried so, though. A bit
of thought would need to be spent on the best way of how to handle multiple-ly
pieces.
Any more thoughts on this?
Regards,
Felix
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
Re: [Mutopia-discuss] On the header parsing
On 01/07/13 at 05:24pm, Glen Larsen wrote: Very cool, David. Felix, I knew you'd want something like this made out of that: Simple python wrapper for this scheme code https://gist.github.com/4480245 Yeah, I think it still needs some processing. IMO, The header fields should be checked for their validity and the remaining fields written to a preliminary (incomplete) .rdf-file. (They are only required for the .rdf aren't they?) Your wrapper looks like a good start. From reading David's mail I realised that header fields can also contain newlines, which could mess up parsing. I'd replace those with nulls in the scheme and change them back with the python. (If there are nulls in header fields this will go wrong, but I don't really see an application for having nulls in header fields.) So varying David's command line a bit lilypond -e '(set! print-book-with-defaults (lambda (parser book) (module-for-each (lambda (sym var) (if (markup? (variable-ref var)) (format #t ~a=~a~% sym (string-map (lambda (c) (if (eq? c #\newline) #\nul c)) (markup-string (variable-ref var)) (ly:book-header book' file.ly replaces newlines by nulls and prints header fields literally without escaping characters. (Otherwise the nulls would be displayed as \x00.) Python's xml.sax.saxutils.escape looks useful for producing the .rdf format. Felix PS: Is supporting multiple files really necessary for the script? If there is a multiple file piece the relevant fields should be equal for any of the files (which are not only for inclusion in other files). Ok, one could compare the output for the different files and check whether that's really true; this doesn't seem to be worth the time, though. Raising this issue is probably also not worth the time, since it doesn't seem to make the script much more complicated and doesn't do any harm at all... ___ Mutopia-discuss mailing list Mutopia-discuss@mutopiaproject.org http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
Re: [Mutopia-discuss] On the header parsing
On 01/09/13 at 10:54am, David Kastrup wrote: Felix Janda felix.ja...@posteo.de writes: Do you have a (rough) estimate for what's the earliest lilypond version which works with this command line? Huh. Several functions are only available with commit eab591fe423ef0eeb03d8bbedf7d43185d2fbc74 Author: Reinhold Kainhofer reinh...@kainhofer.com Date: Mon Dec 27 15:49:30 2010 +0100 Print out header fields as PDF metadata; Add simple markup-string function -) Create DOCINFO pdfmark, with the metadata fields extracted from the \header block -) Add scheme function markup-string that extracts and returns only the string part of a markup. As all header fields are possibly markups, we need to call this function on the header fields and use only the string representation (formatting and possibly some information lost!) as metadata. This function is very simply (for all known text markup functions, it extracts the text and ignores the formatting, all other markup functions are entirely ignored), so it might not work perfectly for complex markups. -) Add possibility to override a header field with the same name, but a pdf prefix, to force a particular metadata string, which is not displayed in the pdf. E.g. if the \header block contains pdftitle = Title for pdf file then that pdftitle header field will be used for the document title in the PDF metadata instead of the title header field. so that would be version 2.13.48. Thanks, markup-string is quite useful. Felix ___ Mutopia-discuss mailing list Mutopia-discuss@mutopiaproject.org http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
Re: [Mutopia-discuss] Three voice up stems
Use
\relative c' {
{ c2 } \\ \\ { e2 } \\ \\ { g2 }
}
By default the odd numbered voices have their stems up and the even numbered
voices have their stems down. They are shifted more and more as the number
increases. In the example I'm only using voices 1, 3 and 5 so that all beams
go up.
Alternatively you can do it more explicitely like this:
\relative c' {
\stemUp
c2 \new Voice {\shiftOn e2} \new Voice {\shiftOnn g2}
}
It's a good idea to have a look at the Multiple voices section in the
Notation manual.
Felix
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
Re: [Mutopia-discuss] git advice: remove a merge
git reset --hard should be able to fix up your master. Then make new topic branches and git-cherry-pick your work into them. Then make new pull-requests and close the old ones. (Can you really not do this yourself? If not you could still add a comment to the pull-request.) Felix ___ Mutopia-discuss mailing list Mutopia-discuss@mutopiaproject.org http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
