Export to XML
Dear LilyPond users, I used to post questions on the LilyPond forums few years back when it was possible to post and edit messages directly online (on nabble.com if I recall correctly). But since it was closed, I didn't take the time to subscribe to the mailing list and haven't try that way. I somehow managed to find answers to my questions myself, but today I would need some advice. I used to be an intense Finale then Sibelius user and I learnt LilyPond back in 2017. Since then, it is my only tool to engrave my scores and I have moved progressively my workflow on Linux. Hence I cannot (and doesn't want) to go back on those proprietary software and it also changed my use of LilyPond (I replaced frescobaldi by vim, I use a lot of separate folders for each projects and program some Makefiles to link everything smoothly, ...). I received some good news recently. A big music publisher (Schott Music Group), is interested in publishing some of my compositions I made for my piano students and it should be released in a near future. I engraved my score with great care, and as I said, using a Makefile and some unix architecture for that particular project. However, as you might guess, they want to engrave it with their own editorial chart and within their music software (I am not sure of which one they are using yet). I proposed to send them my LilyPond files but I have been confirmed yesterday that they cannot process those... They told me an XML file might help them though. I looked if it was possible to export in XML but I read the result was bad and LilyPond wasn't made for that task... So here's my question: what would you suggest I could do to export my scores and help them prepare the album? Thanks for the advices!
Re: Export to XML
Dear all, Thank you for your comments about that situation. I tried what Jean suggested : 1) The XML export in Frescobaldi did work but the result was very unsatisfactory. I even tried to simplify as much as I could (erased all tweaks, custom commands, fingerings) and only kept the music notes. But still, the result when imported in Finale (2014) was terrible (some voices were displaced!). 2) I tried the OpenLilylib package. I wasn't familiar with that tool and had to struggle a bit with the installation. But still, with the export-example.ly seen in the manual, I get this error message: | GNU LilyPond 2.22.2 | Traitement de « export-example.ly » | Analyse... | | oll-core: library infrastructure successfully loaded. | Interprétation en cours de la musique... | init exportHumdrum: "export-example.krn" | init Staff 1 | init Voice 1/1 (1) | init Voice 1/2 (2) | init Staff 2 | init Voice 1/ (3) | init Voice 2/ (1) | init Voice 2/mel (2)/home/remy/.config/lilypond/openlilylib/lilypond-export/api.scm:278:48: In expression (ly:grob-properties grob): | /home/remy/.config/lilypond/openlilylib/lilypond-export/api.scm:278:48: Unbound variable: ly:grob-properties And I only get the PDF as an output. I don't know what I missed here? 3) I tried in the same old Finale version to import my PDF and I have to admit the result was for now the most satisfactory... I am pretty convinced now that Schott uses Sibelius as I read those fonts in some PDF examples they put online (maybe this will be of interest for some of you): | SchottMusicSibeliusStandard | SchottMusicSibeliusText | CenturySchoolbook-Bold | TimesNewRoman | OpusText | OpusFiguredBassStd | LinotypeSyntaxCom-Regular 4) I don't know if the fact I could not provide a workable file for them would be a deal breaker... I hope not as I "imagined" the work of a publishing company to be able to engrave from scratch any score... I could also mimic their own house styling in LilyPond, but I would be very surprised they ask for that and agree with Andrew, something would be wrong if so. So if I can't export in XML, my best bet would be for them to typeset from scratch, or to import the PDF in their own software and see if that can provide a good initial base... 5) To answer Andrew about the copyright and financial deal, I haven't received a concrete proposal yet and cannot say how it would appear. I know the incomes won't be very substantial, but still I see that as on opportunity to reach more people. But I would be curious to know what you meant by self-publishing? I, for sure, like to buy my scores on paper and that is an aspect I like in those old publishing companies... 6) Last point: I made some month ago, a short presentation and introduction to LilyPond for my colleagues in my music institution. Beyond the fact it was quite a challenge to try and convince them of the utility to take some time and learn that great tool, I received that question I couldn't answer at the time: is it possible to import or export in XML? I haven't have a use for that kind of feature until now, and I don't know how the commercial softwares handle that, but still, wouldn't that be a great argument to convince the people to go for it? Final thought, I don't know how Urs did manage to convince publishers about LilyPond and what responses he got (I would be curious though), but I am pretty sure that kind of limitation in importing/exporting in XML would be nowdays a dealbreaker for publishing companies, don't you agree?
Re: Export to XML
> A MusicXML export integrated into LilyPond has been discussed repeatedly, > and everybody agrees that it is desirable, but it has not been implemented > so far because, well, it's quite easier said than done. In a free (libre) > / open source project, the only way to be sure something will get done > is to do it yourself. I didn't want to sound like complaining! I understand it should be a lot of work to provide. I wasn't sure it was not implemented for technical or ethical reasons.
Re: bookpart without pagebreak?
> Dear community,
> I would like to know how the pagebreak could be avoided between the two
> "movements" in the below quoted snippet:
It is because bookparts automatically do this behaviour. To make separate
movements fit into the same page, you have to do \score block instead.
\version "2.22.0"
MusicI = \relative c' {c4 d e f g1 }
MusicII = \relative g' { \time 2/4 g4 e8 f g4 e c1 }
\bookpart {
\header {
title = "My great Work"
composer ="Stefan Thomas"
}
\score {
\new Staff \MusicI
\header {
piece = "First Movement"
}
}
\score {
\new Staff \MusicII
\header {
piece = "Second Movement"
}
}
}
Key Signature Bug in 2.24.0
Hi all,
I just discovered this huge bug in the recent release of 2.24.0 which
wasn't in the previous version. Placement of key signatures on multiple
staves with transposed instrument behaves very poorly. Consider this
example :
\version "2.24.0"
music = \relative c' {
\key es\major
c d e f
\key c\major
c d e f
\key as\major
c d e f
\key bes\major
c d e f
}
\new StaffGroup <<
\transpose c a {
\music
}
\new Staff
\transpose c g {
\music
}
\new Staff
\music
>>
Re: Key Signature Bug in 2.24.0
You're right, I worked for my last score on 2.22.0 and the bug was there and I didn't notice it... So it isn't specific to 2.22.4 as written in the subject. Le vendredi 13 janvier 2023 à 09:17, Jean Abou Samra a écrit : > Le 13/01/2023 à 09:34, nitra...@posteo.net a écrit : > > Hi all, > > > > I just discovered this huge bug in the recent release of 2.24.0 which > > wasn't in the previous version. > > > What previous version did you test this with? For me, the output is the same > in 2.22 and in 2.18.2. > > Best, > Jean
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
Yes it is better, thank you for your fast reply. But several problems are
still there in my opinion:
- The first note of the measure doesn't align with the last accidental and
is still too far.
- I don't understand why the distance between different accidentals is
wider (for instance between a natural and a sharp, or between a natural
and a flat).
Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > which wasn't in the previous version.
> > > What previous version did you test this with? For me, the output is
> > > the same in 2.22 and in 2.18.2.
> > Regardless of that, it is indeed a severe bug: No need to ever align
> > key signatures vertically, AFAIK. Simply left-align them.
>
>
> Do you mean like this, or something else?
>
> (NB this is unreliable code, I was surprised that it even works)
>
> \version "2.24.0"
>
> music = \relative c' {
> \override Staff.KeyCancellation.break-align-symbol = #'key-signature
> \override Staff.KeySignature.X-offset =
> #(lambda (grob)
> (let* ((parent (ly:grob-parent grob X))
> (elts (ly:grob-object parent 'elements))
> (can (find (lambda (g)
> (and (grob::has-interface g
> 'key-cancellation-interface)
> (eq? (ly:grob-object g 'staff-symbol)
> (ly:grob-object grob 'staff-symbol
> (ly:grob-array->list elts
> (when can
> (ly:grob-translate-axis!
> grob
> (+ (- (interval-end (ly:grob-extent can parent X))
> (ly:grob-relative-coordinate grob parent X))
> 0.7)
> X
> \key es\major
> c d e f
> \key c\major
> c d e f
> \key as\major
> c d e f
> \key bes\major
> c d e f
> }
>
> \new StaffGroup <<
> \transpose c a {
> \music
> }
> \new Staff
> \transpose c g {
> \music
> }
> \new Staff
> \music
> >>
>
>
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
I was talking about the first note of each measures after the Key Signature.
But you were right, it is the default spacing.
About the distance between different accidentals, consider the example
bellow. You can see a difference between the "Reference staff" and number
"C" in the "Corrected Output". It looks like an extra space has been added
between the key cancellation and the new one.
---
\version "2.24.0"
music = \relative c'' {
\key a\major
a4 4 4 4
\key es\major
g4 4 4 4
\key b\major
fis4 4 4 4
\key f\minor
f4 4 4 4
}
musicCorrected = {
\override Staff.KeyCancellation.break-align-symbol = #'key-signature
\override Staff.KeySignature.X-offset =
#(lambda (grob)
(let* ((parent (ly:grob-parent grob X))
(elts (ly:grob-object parent 'elements))
(can (find (lambda (g)
(and (grob::has-interface g
'key-cancellation-interface)
(eq? (ly:grob-object g 'staff-symbol)
(ly:grob-object grob 'staff-symbol
(ly:grob-array->list elts
(when can
(ly:grob-translate-axis!
grob
(+ (- (interval-end (ly:grob-extent can parent X))
(ly:grob-relative-coordinate grob parent X))
0.7)
X
\music
}
\markup \huge "Reference"
\new Staff \music
\markup \huge "Default Output"
\new StaffGroup <<
\new Staff \with {
instrumentName = "A"
}
\transpose c a {
\music
}
\new Staff \with {
instrumentName = "B"
}
\transpose c g {
\music
}
\new Staff \with {
instrumentName = "C"
}
\music
>>
\markup \huge "Corrected output with still some differences"
\new StaffGroup <<
\new Staff \with {
instrumentName = "A"
}
\transpose c a {
\musicCorrected
}
\new Staff \with {
instrumentName = "B"
}
\transpose c g {
\musicCorrected
}
\new Staff \with {
instrumentName = "C"
}
\musicCorrected
>>
Le vendredi 13 janvier 2023 à 09:39, David Wright a écrit :
> On Fri 13 Jan 2023 at 11:58:42 (+), nitra...@posteo.net wrote:
> > Yes it is better, thank you for your fast reply. But several problems are
> > still there in my opinion:
> >
> > - The first note of the measure doesn't align with the last accidental and
> > is still too far.
>
> None of the first notes in any measure has an accidental, so I'm
> not sure what you mean.
>
> If, by the last accidental, you mean the last symbol in the key
> signature, then you certainly shouldn't place the first note in the
> measure too close to the key signature.
>
> > - I don't understand why the distance between different accidentals is
> > wider (for instance between a natural and a sharp, or between a natural
> > and a flat).
>
> Can you be specific about which symbols you're referring to: can you
> give the staff and measure number for the ones you're comparing.
>
> > Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> > > Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > > > which wasn't in the previous version.
> > > > > What previous version did you test this with? For me, the output is
> > > > > the same in 2.22 and in 2.18.2.
> > > > Regardless of that, it is indeed a severe bug: No need to ever align
> > > > key signatures vertically, AFAIK. Simply left-align them.
> > >
> > >
> > > Do you mean like this, or something else?
> > >
> > > (NB this is unreliable code, I was surprised that it even works)
> > >
> > > \version "2.24.0"
> > >
> > > music = \relative c' {
> > > \override Staff.KeyCancellation.break-align-symbol = #'key-signature
> > > \override Staff.KeySignature.X-offset =
> > > #(lambda (grob)
> > > (let* ((parent (ly:grob-parent grob X))
> > > (elts (ly:grob-object parent 'elements))
> > > (can (find (lambda (g)
> > > (and (grob::has-interface g
> > > 'key-cancellation-interface)
> > > (eq? (ly:grob-object g 'staff-symbol)
> > > (ly:grob-object grob
> > > 'staff-symbol
> > > (ly:grob-array->list elts
> > > (when can
> > > (ly:grob-translate-axis!
> > > grob
> > > (+ (- (interval-end (ly:grob-extent can parent X))
> > > (ly:grob-relative-coordinate grob parent X))
> > > 0.7)
> > > X
> > > \key es\major
> > > c d e f
> > > \key c\major
> > > c d e f
> > > \key as\major
> > > c d e f
> > > \key bes\major
> > > c d e f
> > > }
> > >
> > > \new StaffGroup <<
> > > \transpose c a {
> > > \music
> > > }
> > > \new Staff
> > > \transpose c g {
> > > \music
> > > }
> > > \new Staff
> > > \music
> > > >>
>
> Cheers,
> David.
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
I could have thought of that... Thanks David for the tip and Jean for opening the issue. I'll use the workaround until then... Le vendredi 13 janvier 2023 à 14:03, David Wright a écrit : > On Fri 13 Jan 2023 at 19:30:29 (+), nitra...@posteo.net wrote: > > I was talking about the first note of each measures after the Key Signature. > > But you were right, it is the default spacing. > > > > About the distance between different accidentals, consider the example > > bellow. You can see a difference between the "Reference staff" and number > > "C" in the "Corrected Output". It looks like an extra space has been added > > between the key cancellation and the new one. > [ … ] > > grob > > (+ (- (interval-end (ly:grob-extent can parent X)) > > (ly:grob-relative-coordinate grob parent X)) > >0.7) > > X > > \music > > } > > Change 0.7 to 0.1 and you can make the cancellation almost touch the > new key signature, so pick your value to taste, I guess. > > You might need to check how a particular value behaves when staves > are stretched or compressed while breaking the music into lines. > (Your Reference staff has slightly different measure lengths from > the Corrected output.) > > Cheers, > David.
