Re: mutopia's shortcomings
Hi all, Seems to me it has been quite successful in its goals of making sheet music easily available for free, all works in the public domain or under creative commons licenses, in (user-editable, user-improvable) LilyPond format, pdf, and midi — all with volunteer labor. Looks like the total is over 1900 works now. Other than the “user-editable, user-improvable” issue, all of those things are far better done by IMSLP. Put another way, looking at IMSLP (with 310,000 scores) and Mutopia (with 1,900), the shine quickly comes off Mutopia for anyone except the handful of hardcore DIY musicians who (e.g.,) want to take a violin piece from Mutopia and make a guitar arrangement. I think it would be far better — and probably result in better visibility/marketing for Lilypond — if Mutopia were merged into IMSLP. (There appears to have been a thought in this direction at some point, but not any more; cf. http://imslp.org/wiki/IMSLP:Community_Projects/Mutopia_score_archive). Then, for important works, there would be the Lilypond source, side-by-side with scans of existing editions. But it seems this was considered, and rejected for exactly the reasons that Mutopia now flounders (cf. http://imslp.org/wiki/IMSLP_talk:Community_Projects/Mutopia_score_archive). On Apr 20, 2015, at 5:58 PM, Simon Albrecht simon.albre...@mail.de wrote: I think it’s mainly three problems: – Lilypond versions, as Paul already mentioned. Yes. – Coding style: the lilypond code I saw till now from Mutopia mostly gave me a real headache, because it was excessively hard to read, inefficient or hacky. Which makes reusing it an unpleasant experience. Yes. I would call real code reuse — certainly anything other than the most trivial cut-and-paste exercise — essentially impossible. – Visual quality of the output: Many of the scores very effectively display that using Lilypond does not warrant making beautiful scores Yes. Urs and I are hoping to change this (dramatically, for the better, in one fell swoop) with the openLilyLib stylesheet project. But for now, the defaults in Lilypond are far from publication quality (IMO). Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)
Kieren MacMillan wrote Monday, April 20, 2015 9:00 PM Can \repeat not be defined so that — possibly with parameters/switches — it will Do The Right Thing™ in all engraved (e.g., PDF), expressed (e.g., MIDI), and other (e.g., MusicXML) output streams without requiring poor or inefficient structural coding? No doubt it could - but only if someone was prepared to put the effort into coding it. I think the standard response to this is patches welcome ;) Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Am 20.04.2015 um 22:29 schrieb dl.mcnam...@comcast.net: In another thread, it seemed like common knowledge that Mutopia has some serious flaws. Could someone fill me on on what the (most important if there's a whole slew) problems are? I think it’s mainly three problems: – Lilypond versions, as Paul already mentioned. – Coding style: the lilypond code I saw till now from Mutopia mostly gave me a real headache, because it was excessively hard to read, inefficient or hacky. Which makes reusing it an unpleasant experience. – Visual quality of the output: Many of the scores very effectively display that using Lilypond does not warrant making beautiful scores, if you ask me. This might also be due to ancient Lily versions being used, but mainly it’s because Lilypond output only starts to look really pleasing when you increase paper margins, (use another text font – though that’s likely my personal point of view), manually improve page and line breaking etc. etc. That is to say, you need a proper understanding of typographical quality yourself – it’s not much one needs to do, actually, since most things are handled very well, but some things are important /in my eyes/. That’s what I’d call the main problems… Yours, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 11:50:24 +0200, Federico Bruni wrote: 2015-04-17 16:45 GMT+02:00 Gilles gil...@harfang.homelinux.org: A FLOSS like LilyPond is a great opportunity to share (musical) culture, at the lowest possible cost. A project like Mutopia is a promising future: digital scores (of public domain music) that are free of publishers' rights. If and when big publishers use LilyPond, the result will be more restricted access (through cost) to culture (because they won't release their proprietary contents). I've thought for a long time that the right way to go is to seek public funds for engraving public domain contents with the purpose of publishing it under a GPL-like (or Creative Commons) license. Me too.. but unfortunately it's not a good moment to seek public funds. And I don't like much having to deal with public istitutions. Whether or not funds will be obtained is a question that comes only after people at various levels are made aware that LilyPond exists. This perhaps requires a showcase especially crafted for convincing this particular audience... I would prefer if more people were able to use LilyPond and learn to have fun and learn and help others while contributing to Free Culture. That's why I started thinking about bringing LilyPond in music schools. Even though I never tried because of lack of time, I can imagine two major issues: 1. LilyPond is not considered as a professional tool because it's not used by the publishing companies. In general schools teach what the market asks. That's why I think that this effort by Urs is important. 2. Text input. Frescobaldi is doing a good job here, but still.. What I had in mind was creating the scores which music schools use for teaching music (solfege and instrument). Here, (public) music schools were forced to pay publishers a yearly contribution under threats of legal action against them because of their use of photocopies, even though most of the copyrighted material being copied is actually based on public domain contents (classical music). Regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: (hypothetical) Availability of LilyPond engravers
Urs: ... If I should be asked to engrave a big score (as fast as possible) in a commercial context and wouldn't want to reply well, I will ask around and see how many people I can get together, what could I say? Would it be realistic to say that we could (at any time) provide a team of 10 quailfied engravers working full time on a project? Or 15-20 working half time? And what if it were a request for continuous work? Is it realistic to say there are always enough engravers at hand to accept work? ... I'm for hire on a daily, weekly, monthly or longer basis. But where is the money ? I did a plain Mozart requiem for the local choir and got ~100EUR for 30 choirbooks: http://turkos.aspodata.se/git/musik/WAMozart/requiem/ http://turkos.aspodata.se/choir/osthammar/mozart/ Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
On Apr 20, 2015, at 4:40 PM, Steven Weber pant...@hotmail.com wrote: Is there a way in scheme to say “is this grob being typeset because of an explicit command (\clef bass), or implicitly (because of a line break)”? Hmmm… maybe try this clef-interface property (I haven’t tried it yet): non-default (boolean) Set for manually specified clefs. http://lilypond.org/doc/v2.18/Documentation/internals/clef_002dinterface If that doesn’t work I have another trick up my sleeve that should do it. (If you post your override function that will make it easier to help you.) HTH, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
Hi Steven,
On Mon, Apr 20, 2015 at 3:40 PM, Steven Weber pant...@hotmail.com wrote:
Since I always highlight clef changes in my music and I have access to a
color printer, I thought it’d be more efficient to let Lilypond do the
highlighting for me. I wrote a handy function that places a filled-box
behind the clef grob, and it works great, as long as I add it manually for
every clef change. What I really want is to add this to the Staff context
so I never have to think about it again. So I created an override function
for the Staff.Clef.stencil which does the same thing as my manual function
and again, it does highlight the clefs. Unfortunately, it highlights every
single clef (i.e., all the clefs at the beginning of the staves, not just
the clef changes), which is overkill and defeats the purpose of
highlighting things I need to pay attention to.
Is there a way in scheme to say “is this grob being typeset because of an
explicit command (\clef bass), or implicitly (because of a line break)”?
I can think of two ways to go about this. Hopefully the first gives you
what you want, because the second will take some doing.
Breakable items like clefs have directions attached depending on where they
are: -1 means end of line, 0 unbroken, and 1 beginning of line. You can
use the function ly:item-break-dir like so:
\version 2.19
#(define highlight
(lambda (grob)
(let ((ibd (ly:item-break-dir grob)))
(if (= ibd 1) black green
{
\override Staff.Clef.color = #highlight
c' d' e' f'
\clef bass
c d e f
\break
c d e f
\clef treble
c' d' e' f'
\break
c' d' e' f'
\clef bass
\break
c d e f
}
%%%
One drawback here would be if you want to highlight both the cautionary
clef and the beginning-of-line clef at the end of the example... To do
that and not catch other beginning-of-line clefs, we would have to use the
other method, which is to insert the override into the music expression.
I'm going to drop out at this point :) But, as a head start, compare the
results of running the following with the override left in or commented out:
\displayMusic {
c'
%\override Staff.Clef.color = #highlight
\clef bass
c
}
The extending manual discusses this sort of manipulation with respect to
music functions. There are other useful commands like map-some-music which
crop up periodically on the lists.
Hope this is useful--
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
On Mon, Apr 20, 2015 at 3:40 PM, Steven Weber pant...@hotmail.com wrote: Is there a way in scheme to say “is this grob being typeset because of an explicit command (\clef bass), or implicitly (because of a line break)”? To highlight based on an explicit command you will need to analyze and alter the music expression. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
2015-04-21 0:21 GMT+02:00 Thomas Morley thomasmorle...@gmail.com:
2015-04-20 23:45 GMT+02:00 David Nalesnik david.nales...@gmail.com:
Hi Steven,
On Mon, Apr 20, 2015 at 3:40 PM, Steven Weber pant...@hotmail.com wrote:
Since I always highlight clef changes in my music and I have access to a
color printer, I thought it’d be more efficient to let Lilypond do the
highlighting for me. I wrote a handy function that places a filled-box
behind the clef grob, and it works great, as long as I add it manually for
every clef change. What I really want is to add this to the Staff context
so I never have to think about it again. So I created an override function
for the Staff.Clef.stencil which does the same thing as my manual function
and again, it does highlight the clefs. Unfortunately, it highlights every
single clef (i.e., all the clefs at the beginning of the staves, not just
the clef changes), which is overkill and defeats the purpose of highlighting
things I need to pay attention to.
Is there a way in scheme to say “is this grob being typeset because of an
explicit command (\clef bass), or implicitly (because of a line break)”?
I can think of two ways to go about this. Hopefully the first gives you
what you want, because the second will take some doing.
Breakable items like clefs have directions attached depending on where they
are: -1 means end of line, 0 unbroken, and 1 beginning of line. You can use
the function ly:item-break-dir like so:
\version 2.19
#(define highlight
(lambda (grob)
(let ((ibd (ly:item-break-dir grob)))
(if (= ibd 1) black green
{
\override Staff.Clef.color = #highlight
c' d' e' f'
\clef bass
c d e f
\break
c d e f
\clef treble
c' d' e' f'
\break
c' d' e' f'
\clef bass
\break
c d e f
}
%%%
One drawback here would be if you want to highlight both the cautionary clef
and the beginning-of-line clef at the end of the example... To do that and
not catch other beginning-of-line clefs, we would have to use the other
method, which is to insert the override into the music expression.
I'm going to drop out at this point :) But, as a head start, compare the
results of running the following with the override left in or commented out:
\displayMusic {
c'
%\override Staff.Clef.color = #highlight
\clef bass
c
}
The extending manual discusses this sort of manipulation with respect to
music functions. There are other useful commands like map-some-music which
crop up periodically on the lists.
Hope this is useful--
David
Or maybe:
\version 2.19.18
clef-color-engraver =
#(lambda (context)
(let ((clef-props '()))
`((acknowledgers
(clef-interface
. ,(lambda (engraver grob source-engraver)
(let* ((clefGlyph (ly:context-property context 'clefGlyph))
(clefPosition (ly:context-property context 'clefPosition))
(clefTransposition
(ly:context-property context 'clefTransposition 0))
(new-clef-props
(list clefGlyph clefPosition clefTransposition)))
;(display (equal? clef-props new-clef-props))
(if (and (not (equal? clef-props new-clef-props))
;; to have the first clef colored as well
;; comment next line
(not (null? clef-props))
)
(set! (ly:grob-property grob 'color) red))
(set! clef-props new-clef-props
%%%
%% EXAMPLE
%%
\layout {
\context {
\Staff
\consists #clef-color-engraver
}
}
{
\clef bass
R1
\break
R1
\clef alto
R1
\break
\clef G
R1
\clef G_8
R1
\break
R1
\break
R1
}
{
R1
\break
R1
R1
\break
\clef mensural-c3
R1
\clef alto
R1
\break
R1
\break
R1
}
Cheers,
Harm
Didn't know 'non-default myself :(
For the record, with this the engraver could be shortened to:
clef-color-engraver =
#(lambda (context)
(let ((clef-props '()))
`((acknowledgers
(clef-interface
. ,(lambda (engraver grob source-engraver)
(if (boolean? (ly:grob-property grob 'non-default))
(set! (ly:grob-property grob 'color) red
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [OT] Re: Do we really offer the future?
Hi. On Mon, 20 Apr 2015 14:18:19 -0400, Kieren MacMillan wrote: Hi Gilles, On Apr 20, 2015, at 1:19 PM, Gilles gil...@harfang.homelinux.org wrote: When people put convenience above all, they start giving up their freedom. My experience — this thread being no different so far — is that such discussions always end up in absolutist terms (moral and otherwise). It’s almost a defining quality of the FLOSS movement, from what I can tell. Ultimately, such positions are neither realistic, nor productive, nor particularly interesting to me (or many other people I know). I don’t grow my own food, because buying my food — even the organic food I purchase regularly, in person, from farmers I know by name — is not only more convenient, but also cheaper and more freeing than growing, harvesting, and processing it myself. That freedom allows me to do other things that are more important to me, like composition, and using Lilypond to engrave my compositions, instead of heading out at 5AM to feed and milk my cows before the hard 16-hour day tending my subsistence crops. I don’t put convenience above all; I make choices that make sense to me and those around me, in my real-world life. Your earlier comparisons were not really applicable to the situation discussed in this thread. This one is completely off-topic (as you correctly indicated in the subject line) if it purports to argue against something I wrote. I stated explicitly in my previous post what aspects would perhaps be worth working on (IMHO). Because I'm just a little user, and grateful for what the software can do, I always felt I should not complain about such shortcomings, as long as I did not have the time to contribute more productively. As the question was asked on this forum, I felt I could provide my opinion that some effort might be misplaced if its sole purpose was towards improving the publishing business. My opinion is that the future should not be that. The publishers indeed (also) do not care about the real-world principles (free access to culture in this instance) which a FLOSS like LilyPond can help achieve (within their obviously limited sphere). Not that they oppose it, it's simply not their business (which is selling printed scores). They have the right to use the software, like any of us. The point is that they don't want to. Several possible reasons were given by other people in this thread. Of course, you are free to pursue your effort with the publishing houses, despite the preference of some of your fellow LilyPonders... :-) Regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Apr 20, 2015, at 4:29 PM, dl.mcnam...@comcast.net wrote: In another thread, it seemed like common knowledge that Mutopia has some serious flaws. Indeed, I’m thinking sheesh, why’s everybody gotta be pickin on the mutopia project? Seems to me it has been quite successful in its goals of making sheet music easily available for free, all works in the public domain or under creative commons licenses, in (user-editable, user-improvable) LilyPond format, pdf, and midi — all with volunteer labor. Looks like the total is over 1900 works now. Could someone fill me on on what the (most important if there's a whole slew) problems are? One of the problems is that many of the files are for older versions of LilyPond and so they don’t exactly meet the highest standards of engraving aesthetics (or reflect well on the current quality of LilyPond). There is an effort underway to update these older files that has made some substantial progress, see: http://lilypondblog.org/2014/12/catching-up-with-the-mutopia-project/ http://lilypondblog.org/2014/12/catching-up-with-the-mutopia-project/ Another problem is limited volunteer manpower. (So if anyone is looking for something easy they can do to contribute back to the wider LilyPond ecosystem…) Cheers, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
2015-04-20 23:45 GMT+02:00 David Nalesnik david.nales...@gmail.com:
Hi Steven,
On Mon, Apr 20, 2015 at 3:40 PM, Steven Weber pant...@hotmail.com wrote:
Since I always highlight clef changes in my music and I have access to a
color printer, I thought it’d be more efficient to let Lilypond do the
highlighting for me. I wrote a handy function that places a filled-box
behind the clef grob, and it works great, as long as I add it manually for
every clef change. What I really want is to add this to the Staff context
so I never have to think about it again. So I created an override function
for the Staff.Clef.stencil which does the same thing as my manual function
and again, it does highlight the clefs. Unfortunately, it highlights every
single clef (i.e., all the clefs at the beginning of the staves, not just
the clef changes), which is overkill and defeats the purpose of highlighting
things I need to pay attention to.
Is there a way in scheme to say “is this grob being typeset because of an
explicit command (\clef bass), or implicitly (because of a line break)”?
I can think of two ways to go about this. Hopefully the first gives you
what you want, because the second will take some doing.
Breakable items like clefs have directions attached depending on where they
are: -1 means end of line, 0 unbroken, and 1 beginning of line. You can use
the function ly:item-break-dir like so:
\version 2.19
#(define highlight
(lambda (grob)
(let ((ibd (ly:item-break-dir grob)))
(if (= ibd 1) black green
{
\override Staff.Clef.color = #highlight
c' d' e' f'
\clef bass
c d e f
\break
c d e f
\clef treble
c' d' e' f'
\break
c' d' e' f'
\clef bass
\break
c d e f
}
%%%
One drawback here would be if you want to highlight both the cautionary clef
and the beginning-of-line clef at the end of the example... To do that and
not catch other beginning-of-line clefs, we would have to use the other
method, which is to insert the override into the music expression.
I'm going to drop out at this point :) But, as a head start, compare the
results of running the following with the override left in or commented out:
\displayMusic {
c'
%\override Staff.Clef.color = #highlight
\clef bass
c
}
The extending manual discusses this sort of manipulation with respect to
music functions. There are other useful commands like map-some-music which
crop up periodically on the lists.
Hope this is useful--
David
Or maybe:
\version 2.19.18
clef-color-engraver =
#(lambda (context)
(let ((clef-props '()))
`((acknowledgers
(clef-interface
. ,(lambda (engraver grob source-engraver)
(let* ((clefGlyph (ly:context-property context 'clefGlyph))
(clefPosition (ly:context-property context 'clefPosition))
(clefTransposition
(ly:context-property context 'clefTransposition 0))
(new-clef-props
(list clefGlyph clefPosition clefTransposition)))
;(display (equal? clef-props new-clef-props))
(if (and (not (equal? clef-props new-clef-props))
;; to have the first clef colored as well
;; comment next line
(not (null? clef-props))
)
(set! (ly:grob-property grob 'color) red))
(set! clef-props new-clef-props
%%%
%% EXAMPLE
%%
\layout {
\context {
\Staff
\consists #clef-color-engraver
}
}
{
\clef bass
R1
\break
R1
\clef alto
R1
\break
\clef G
R1
\clef G_8
R1
\break
R1
\break
R1
}
{
R1
\break
R1
R1
\break
\clef mensural-c3
R1
\clef alto
R1
\break
R1
\break
R1
}
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Mon, 20 Apr 2015 19:07:46 -0400, Kieren MacMillan wrote: Hi all, Seems to me it has been quite successful in its goals of making sheet music easily available for free, all works in the public domain or under creative commons licenses, in (user-editable, user-improvable) LilyPond format, pdf, and midi — all with volunteer labor. Looks like the total is over 1900 works now. Other than the “user-editable, user-improvable” issue, all of those things are far better done by IMSLP. Put another way, looking at IMSLP (with 310,000 scores) and Mutopia (with 1,900), the shine quickly comes off Mutopia for anyone except the handful of hardcore DIY musicians who (e.g.,) want to take a violin piece from Mutopia and make a guitar arrangement. I think it would be far better — and probably result in better visibility/marketing for Lilypond — if Mutopia were merged into IMSLP. (There appears to have been a thought in this direction at some point, but not any more; cf. http://imslp.org/wiki/IMSLP:Community_Projects/Mutopia_score_archive). Then, for important works, there would be the Lilypond source, side-by-side with scans of existing editions. But it seems this was considered, and rejected for exactly the reasons that Mutopia now flounders (cf. http://imslp.org/wiki/IMSLP_talk:Community_Projects/Mutopia_score_archive). Some pieces accessible on IMSLP were typeset for Mutopia, with a publisher link to Mutopia's site. So visibility of LilyPond can be achieved through publishing to IMSLP in addition to Mutopia. On Apr 20, 2015, at 5:58 PM, Simon Albrecht simon.albre...@mail.de wrote: I think it’s mainly three problems: – Lilypond versions, as Paul already mentioned. Yes. – Coding style: the lilypond code I saw till now from Mutopia mostly gave me a real headache, because it was excessively hard to read, inefficient or hacky. Which makes reusing it an unpleasant experience. Yes. I would call real code reuse — certainly anything other than the most trivial cut-and-paste exercise — essentially impossible. – Visual quality of the output: Many of the scores very effectively display that using Lilypond does not warrant making beautiful scores Yes. Urs and I are hoping to change this (dramatically, for the better, in one fell swoop) with the openLilyLib stylesheet project. But for now, the defaults in Lilypond are far from publication quality (IMO). A word like stylesheet looks promising. I looked at the openlilylib.org web site but could not find the stylesheets. All the problems with Mutopia stem from not having a standardized way of managing the layout and contents. Mutopia should not be like IMSLP; rather it should be a database of LilyPond input format (the _music_ part). With standard stylesheets, one would be able to automatically update/adapt the contents. Of course, the devil is in the details... :-} Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Override KeySignature end-of-line-invisible
As explained in the docs:
http://www.lilypond.org/doc/v2.18/Documentation/notation/visibility-of-objects#special-considerations
the syntax \override Staff.KeySignature.break-visibility = #...
only affects the key signature at the *beginning* of the line (not sure
why, but that's what it says). The correct syntax, it says, is
\set Staff.explicitKeySignatureVisibility = #end-of-line-invisible
which works for me.
HTH,
Abraham
On Mon, Apr 20, 2015 at 2:13 PM, SonusProj . [via Lilypond]
ml-node+s1069038n174876...@n5.nabble.com wrote:
I am quite sure that I am improperly applying the method to make invisible
the key signature at the end of a line when the key changes beginning on
the next staff.
The code below shows my attempt to use the method in two different manners
at several points. I have commented out the non-working code. However,
compilation works fine.
I don't actually know which object I am to be overriding and which is
proper syntax. I have seen several examples written in the forms I have
shown. The ??? is my indication of Which object?
harmonies = \chordmode {
c1:maj7 d:m7 e:m7 f:maj7 g:7 a:m7 b:m7.5-
\break d1:maj7 e:m7 fis:m7 g:maj7 a:7 b:m7 cis:m7.5-
}
upper = \relative c' {
\clef treble
\key c \major
\time 4/4
c e g b1 d f a c1 e g b d1 f a c e1 g b d f1 a c e g1 b d f
a1
* %\override ???.keysignature.break-visibility = #end-of-line-invisible*
\break
\key d \major
d, fis a cis1 e g b d1 fis a cis e1 g b d fis1 a cis e g1 b d
fis a1 cis e g b1
}
lower = \relative c,{
\clef bass
\key c \major
\time 4/4
c e g b1 d f a c1 e g b d1 f a c e1 g b d f1 a c e g1 b d f
a1
* %once \override ???.keysignature.break-visibility =
#end-of-line-invisible*
\break
\key d \major
d, fis a cis1 e g b d1 fis a cis e1 g b d fis1 a cis e g1 b d
fis a1 cis e g b1
}
\score {
\new PianoStaff
*%\override PianoStaff.KeySignature.break-visibility=
#end-of-line-invisible \new ChordNames {*
\set chordChanges = ##t
\harmonies
}
\new Staff = upper \upper
*%\once \override Staff.KeySignature #'break-visibility = #'#(#f #t
#t)*
\new Staff = lower \lower
*%\once \override Staff.KeySignature #'break-visibility = #'#(#f #t
#t)*
\layout {
\context { \Staff \RemoveEmptyStaves }
}
\midi { }
}
___
lilypond-user mailing list
[hidden email] http:///user/SendEmail.jtp?type=nodenode=174876i=0
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
If you reply to this email, your message will be added to the discussion
below:
http://lilypond.1069038.n5.nabble.com/Override-KeySignature-end-of-line-invisible-tp174876.html
To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
To unsubscribe from Lilypond, click here
http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
.
NAML
http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Override-KeySignature-end-of-line-invisible-tp174876p174878.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)
Kieren MacMillan wrote Monday, April 20, 2015 5:05 PM
On Apr 19, 2015, at 6:11 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
[snip incomplete example]
Is it really a best practice to put \repeat volta structures in multiple
locations? I just responded to a post a few days ago where (I believe, though
the OP hasn’t followed it through to terminus) the primary source of the
compilation troubles was asynchronous voltas.
Sure you did, but the point of the example the OP submitted from the NR was to
show how to allow lyrics to be unfolded along with the music. Granted this was
not obvious from my post, unless you knew where the example came from.
1. Shouldn’t we be [heavily] promoting, even in tiny snippets, the use of
global variables to hold \repeat structures that are used in multiple places?
No, not in this particular case - it doesn't work.
2. And in this particular example, why use \repeat at all in the lyrics?
Doesn’t the following (with the unnecessary braces left in for structural
clarity) work equally well?
\new Lyrics {
\lyricsto melody {
Not re -- peat -- ed.
Re -- peat { { twice. } { twice. } }
}
}
Not when unfolded.
Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can you determine why a grob is being typeset in scheme?
On Mon, Apr 20, 2015 at 4:55 PM, David Nalesnik david.nales...@gmail.com wrote: On Mon, Apr 20, 2015 at 3:40 PM, Steven Weber pant...@hotmail.com wrote: Is there a way in scheme to say “is this grob being typeset because of an explicit command (\clef bass), or implicitly (because of a line break)”? To highlight based on an explicit command you will need to analyze and alter the music expression. Learn something new every day... #(define highlight (lambda (grob) (if (boolean? (ly:grob-property grob 'non-default)) red black --DN ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
No mixing of different beams
Hi,
is there a general setting to avoid the beaming of the first note here:
{ a8 a16 a a a a a }
such that it looks like:
{ a8\noBeam a16 a a a a a }
Cheers,
Joram
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Can you determine why a grob is being typeset in scheme?
Since I always highlight clef changes in my music and I have access to a color printer, I thought it'd be more efficient to let Lilypond do the highlighting for me. I wrote a handy function that places a filled-box behind the clef grob, and it works great, as long as I add it manually for every clef change. What I really want is to add this to the Staff context so I never have to think about it again. So I created an override function for the Staff.Clef.stencil which does the same thing as my manual function and again, it does highlight the clefs. Unfortunately, it highlights every single clef (i.e., all the clefs at the beginning of the staves, not just the clef changes), which is overkill and defeats the purpose of highlighting things I need to pay attention to. Is there a way in scheme to say is this grob being typeset because of an explicit command (\clef bass), or implicitly (because of a line break)? Thanks! --Steven ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pango Update in new binaries
On Mon, Apr 20, 2015 at 01:14:55PM +0200, Federico Bruni wrote: 2015-04-07 19:47 GMT+02:00 Joshua Nichols josh.d.nich...@gmail.com: Hello all, I apologize if this question has already been asked. Has the new version of pango been ported to the binaries on mac/windows/linux? I noticed here https://code.google.com/p/lilypond/issues/detail?id=2656 that there has since been bug issues with a previous version that LilyPond has been using, and now there's been fixes to those bugs. I noticed its in the latest dev release of LilyPond, but my question is: is it being retroactively implemented in the stable release? Hi Josh Nobody replied to you. According to a recent discussion in this list, it seems that the new Pango version in GUB makes lilypond compile much faster. This would be another good reason to make a 2.18.3 release. Unless 2.20 is close... What developers think about it? (I'm cc-ing lilypond-devel). I'm not sure whether this is germane to Josh's question, but I'm running Lilypond 2.18.2 and pango 1.36.8, and haven't noticed any problems. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Hi, IMSLP (with 310,000 scores) and Mutopia (with 1,900) I don’t think that it should be put this way. IMSLP looks nicer, has much more scores and thus the chances to find what you are looking for is much better. But Mutopia’s focus is on editable LilyPond scores while IMSLP is mostly scanned scores. This implies extra reasons to exist for Mutopia: - scores can be edited by the user with a free program - the github repository in the back allows for a consistently managing updates But most of all there is no either-or: Nobody prevents you from putting LilyPond scores on Mutopia *and* on IMSLP. Even more, you can link from an IMSLP entry to the source on Mutopia. This combines the best of two sites: Score updates can be handled in the Mutopia github repo and the scores can be presented to a wider public on the nice IMSLP web page. I think it’s mainly three problems: – Lilypond versions, as Paul already mentioned. Which are updated pretty successfully step by step, despite the low manpower. https://github.com/MutopiaProject/MutopiaProject/milestones – Coding style: the lilypond code I saw till now from Mutopia mostly gave me a real headache, because it was excessively hard to read, inefficient or hacky. Which makes reusing it an unpleasant experience. Yes. I would call real code reuse — certainly anything other than the most trivial cut-and-paste exercise — essentially impossible. I would not be so harsh. I just picked three input files at random and I would say, I could use all of them, because the musical content is properly written there. I would add more tweaks but it is a good start. I already used one and edited it for a choir (in real life ;) ). I am not sure yet whether my improvements should be pushed to Mutopia: https://github.com/MutopiaProject/MutopiaProject/issues/575 – Visual quality of the output: Many of the scores very effectively display that using Lilypond does not warrant making beautiful scores This is true and it reassures me that you mention exactly the points I would change in virtually any score: increase paper margins, use another text font, manually improve page and line breaking (cf. https://github.com/MutopiaProject/MutopiaProject/issues/141) Yes. Urs and I are hoping to change this (dramatically, for the better, in one fell swoop) with the openLilyLib stylesheet project. But for now, the defaults in Lilypond are far from publication quality (IMO). I am looking forward to that. – Another issue is: Mostly only small pieces can be found for obvious reasons (less effort). But this is also addressed: https://github.com/MutopiaProject/MutopiaProject/issues/355 and this might give more visibility of LilyPond also on IMSLP. I complained about Mutopia my self some years ago, starting a similar thread (mainly about visual quality and the web-design). But I think it is the same situation as for many LilyPond issues: Complaining does not help. It needs volunteers and work to change things. The people working on Mutopia are open for any good proposals. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pango Update in new binaries
Is there not a procedure for builds that use the same version number but import newer (fixed) library? Or is the issue about packagers? I am currently using a MacPorts build of 2.18.2, which gives the desired output. I also downloaded the 2.19.18 version and am getting great results. I'm just thinking about the benefit for others to finally have the proper kerning in the more regularly downloaded versions. IC, Josh On Mon, Apr 20, 2015 at 9:04 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Federico Bruni fedel...@gmail.com To: Joshua Nichols josh.d.nich...@gmail.com Cc: lilypond-devel lilypond-de...@gnu.org; Mailinglist lilypond-user lilypond-user@gnu.org Sent: Monday, April 20, 2015 12:14 PM Subject: Re: Pango Update in new binaries 2015-04-07 19:47 GMT+02:00 Joshua Nichols josh.d.nich...@gmail.com: Hello all, I apologize if this question has already been asked. Has the new version of pango been ported to the binaries on mac/windows/linux? I noticed here https://code.google.com/p/lilypond/issues/detail?id=2656 that there has since been bug issues with a previous version that LilyPond has been using, and now there's been fixes to those bugs. I noticed its in the latest dev release of LilyPond, but my question is: is it being retroactively implemented in the stable release? Hi Josh Nobody replied to you. According to a recent discussion in this list, it seems that the new Pango version in GUB makes lilypond compile much faster. This would be another good reason to make a 2.18.3 release. Unless 2.20 is close... What developers think about it? (I'm cc-ing lilypond-devel). I don't think an update to 2.18 just to pick up the updated Pango would be a good idea. Updates to stable are there really to correct problems that slipped through into the previous version, not to provide upgrades. If the performance improvement is important, I would suggest using 2.19.18. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Fri, Apr 17, 2015 at 04:45:20PM +0200, Gilles wrote: If and when big publishers use LilyPond, the result will be more restricted access (through cost) to culture (because they won't release their proprietary contents). Forgive me if I've missed important bits of this conversation, but I'm not I understand your point here -- can you expand on this statement? Why do you feel that large-scale adoption of OSS (in general) will restrict and increase the cost of cultural access? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Jianpu Notation
Hi Ming, On Apr 19, 2015, at 8:22 PM, MING TSANG tsan...@rogers.com wrote: It is terrific. Now only one input of notes is generating Voice Staff for jianpu notation and new Staff for music score. Thank you. I try to put r8 r16 r32 and I got the following error: Starting lilypond-windows.exe 2.19.17 [sample_jianpu2.ly]... Processing `K:/sample_lily-code/sample_jianpu2.ly' Parsing... Interpreting music...[8] warning: type check for `stencil' failed; value `#unspecified' must be of type `stencil' fatal error: typecheck failed Exited with return code 1. Thanks for catching this. I’ve fixed it in the next version (jianpu3), attached to my other message. Thank you again for making this possible. I have been waiting this for years, since v2.12. Silas's and David's solution require to code twice - one for jianpu and one for music score. Your is only one input and straight forward. Excellent. Glad I could help! I’m sure it’s not yet as mature or complete as Silas’s approach, but it can be improved and refined over time. Cheers, -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Jianpu Notation
Hi David, On Apr 19, 2015, at 7:28 PM, Super-User david...@qq.com wrote: I am impressed by your code! You have really made things automated! Thanks! I am attaching the next revision to this email. To note about improvement, accidentals in jianpu look identical to those in standard notation, but the baseline is about 0.75 height position of numeric note head height button up. I haven’t done anything about this or any other spacing adjustments. It would be great if you could work on the spacing parts since you know Jianpu and what it should look like. Feel free to ask questions on this list if you need to. Lines indicating duration (aka. beams) should be horizontally linked together the same way as 5-stave notation. This will probably be tricky and/or difficult to do. Maybe it is possible by overriding beams and flags rather than adding these symbols to the note head stencil? This is difficult though because the octave dots fall below these duration dashes for 8th notes, 16th, 32nd, etc. So the positioning won’t be easy. I have tried changing \key c \major to \key d \major, and found that rules dealing with accidentals are still in the old way(eg. the second note should be flat-7, not natural-7). The latest version (attached) includes a custom accidental sign engraver to provide Jianpu accidentals. I may have missed some edge cases, but I don’t think so. (There are no triple sharp or triple flat glyphs in LilyPond so I reached the limit of what can be done there.) Let me know if you find accidentals that are not right. The shorter rests (8th, 16th, 32nd, etc.) are now fixed as well. Wikipedia shows the following for dotted half and whole notes, which is still not supported: Whole (semibreve): 1 - - - Dotted whole: 1 - - - - - Double dotted: 1 - - - - - - Half (minim): 1 - Dotted half: 1 - - Double dotted: 1 - - · I’m sure there are other things too, but this is a good start. Hopefully I’ve given you enough to build on, since I have other things I need to work on and I’m not sure how much more time I’ll be able to spend on this for now. Cheers, -Paul jianpu3.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, Apr 20, 2015 at 08:19:37PM -0700, Jim Long wrote: ... I'm not I understand ... I'm not *sure that* I understand ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Override KeySignature end-of-line-invisible
I am quite sure that I am improperly applying the method to make invisible
the key signature at the end of a line when the key changes beginning on
the next staff.
The code below shows my attempt to use the method in two different manners
at several points. I have commented out the non-working code. However,
compilation works fine.
I don't actually know which object I am to be overriding and which is
proper syntax. I have seen several examples written in the forms I have
shown. The ??? is my indication of Which object?
harmonies = \chordmode {
c1:maj7 d:m7 e:m7 f:maj7 g:7 a:m7 b:m7.5-
\break d1:maj7 e:m7 fis:m7 g:maj7 a:7 b:m7 cis:m7.5-
}
upper = \relative c' {
\clef treble
\key c \major
\time 4/4
c e g b1 d f a c1 e g b d1 f a c e1 g b d f1 a c e g1 b d f
a1
* %\override ???.keysignature.break-visibility = #end-of-line-invisible*
\break
\key d \major
d, fis a cis1 e g b d1 fis a cis e1 g b d fis1 a cis e g1 b d
fis a1 cis e g b1
}
lower = \relative c,{
\clef bass
\key c \major
\time 4/4
c e g b1 d f a c1 e g b d1 f a c e1 g b d f1 a c e g1 b d f
a1
* %once \override ???.keysignature.break-visibility =
#end-of-line-invisible*
\break
\key d \major
d, fis a cis1 e g b d1 fis a cis e1 g b d fis1 a cis e g1 b d
fis a1 cis e g b1
}
\score {
\new PianoStaff
*%\override PianoStaff.KeySignature.break-visibility=
#end-of-line-invisible \new ChordNames {*
\set chordChanges = ##t
\harmonies
}
\new Staff = upper \upper
*%\once \override Staff.KeySignature #'break-visibility = #'#(#f #t
#t)*
\new Staff = lower \lower
*%\once \override Staff.KeySignature #'break-visibility = #'#(#f #t
#t)*
\layout {
\context { \Staff \RemoveEmptyStaves }
}
\midi { }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
mutopia's shortcomings
In another thread, it seemed like common knowledge that Mutopia has some serious flaws. Could someone fill me on on what the (most important if there's a whole slew) problems are? Dave ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pango Update in new binaries
- Original Message - From: Federico Bruni fedel...@gmail.com To: Joshua Nichols josh.d.nich...@gmail.com Cc: lilypond-devel lilypond-de...@gnu.org; Mailinglist lilypond-user lilypond-user@gnu.org Sent: Monday, April 20, 2015 12:14 PM Subject: Re: Pango Update in new binaries 2015-04-07 19:47 GMT+02:00 Joshua Nichols josh.d.nich...@gmail.com: Hello all, I apologize if this question has already been asked. Has the new version of pango been ported to the binaries on mac/windows/linux? I noticed here https://code.google.com/p/lilypond/issues/detail?id=2656 that there has since been bug issues with a previous version that LilyPond has been using, and now there's been fixes to those bugs. I noticed its in the latest dev release of LilyPond, but my question is: is it being retroactively implemented in the stable release? Hi Josh Nobody replied to you. According to a recent discussion in this list, it seems that the new Pango version in GUB makes lilypond compile much faster. This would be another good reason to make a 2.18.3 release. Unless 2.20 is close... What developers think about it? (I'm cc-ing lilypond-devel). I don't think an update to 2.18 just to pick up the updated Pango would be a good idea. Updates to stable are there really to correct problems that slipped through into the previous version, not to provide upgrades. If the performance improvement is important, I would suggest using 2.19.18. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
lilypond fedora 22
Hi, I am giving Fedora 22 (alpha release) a try - just curiosity. It seems it currently has lilypond-2.19.18 in updates-testing. I am not sure having unstable development versions in official distributions repo is a good idea, is it? -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Peter (et al.), As someone who has made the journey from (one of) the two established notation programs to LilyPond, I'm convinced it was the right decision for me but it would honestly be hard for me to recommend it for anyone else - composer or editor - at this point. Unfortunately, I am in exactly the same boat as you. I *have* attempted in the fairly recent past to get many of my colleagues to dip their toes in the ‘Pond. Every single one of them jumped back out saying, “I envy you the output, but I’ll keep my GUI and workflow, thanks.” we are more or less rapidly closing in on the point where it would be possible to recommend it to more than a few (albeit not all) +1 Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Johan, Why should serious businesses use Unix? Outcome: they didn’t. Actually, they do, on quite a large scale: UNIX and UNIX-like servers have a ~68% market share for public servers. And the share of internal (corporate) servers is not insignificant (though not nearly 2/3, of course). Why should serious businesses use LaTeX instead of MSO? Outcome: they didn’t. Depends entirely on which “serious business” you’re talking about. I’m about to have my sixth number theory paper published by the American Mathematical Monthly, a “serious business” if there ever was one; they, of course, required the submission in LaTeX, like all reputable journals. My point is, such [ultimately rhetorical] questions only make sense in a correct and fairly narrowly-defined context. Why should serious businesses use Linux instead of Windows? Outcome: they didn’t. Here I fully agree with you… and this is the [analogous] battleground where Lilypond’s make-or-break battles will be won or lost. For us, command line driven programming may feel normal I am completely comfortable with command-line programming. But I *never* use it with Lilypond: I only use tools (e.g., Frescobaldi, or even the Mac OS X built-in “Lilypad editor) which abstracts all of that for me. it will never become broadly accepted Totally true, of course — and not necessarily a bad thing. Our willingness to accept that and give [potential] users what they need to get around without the command-line will almost single-handedely determine the degree to which Lilypond successfully penetrates the wider market. I did some book productions for a big publisher. I convinced them that I would be delivering high-quality camera-ready materials. They didn't care how I did it, what tools I used, even though my results looked better than theirs. Unfortunately, that just isn’t the way with music publishers: they almost universally demand the “source code” (by which they mean Finale or Sibelius music file), which they then manipulate as they deem necessary. Bottom line: Let's have fun the way *we* do it. Let's show the world the beautiful scores we make. If people wants to join us, let's welcome them and guide them patiently through the learning curve. And enjoy. To my mind, a better bottom line would be to flatten the learning curve significantly for [potential] new users without reducing Lily's power, flexibility, and beautiful output. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Survey: Large scores
Hi,
This is not hard to implement at all, you just have to set things up
appropriately.
You give a perfect example of why we need to improve Lilypond’s implementation.
The method
clarinetIPart = \relative c'' {
... % clarinet music here
}
clarinetIIPart = \relative c'' {
... % clarinet music here
}
clarinets = new Staff {
set Staff.instrumentName = #Clarinets in B\flat I, II
\transposition bes
\transpose bes c' \partcombine
\clarinetIPart \clarinetIIPart
}
not only requires too much overhead/effort, it requires extra workarounds when
key signatures are triggered externally (i.e., in a global variable). Rather,
one should simply be able to say [something like]
clarinets = {
\takeInstrument #”clar.Bf”
%% Bb clarinet music here
\takeInstrument #“clar.A”
%% A clarinet music here
}
and all scores (transposing and concert-pitch) should Do The Right Thing™, with
perhaps a few parameters/switches to help as necessary.
Having engraved at least a hundred multi-instrumentalist movements from my own
music (for both classical and musical theatre orchestras), I can report with
great confidence that Lily’s current built-in implementation is frustrating to
the point of insufficiency.
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pango Update in new binaries
Federico Bruni fedel...@gmail.com writes: 2015-04-07 19:47 GMT+02:00 Joshua Nichols josh.d.nich...@gmail.com: Hello all, I apologize if this question has already been asked. Has the new version of pango been ported to the binaries on mac/windows/linux? I noticed here https://code.google.com/p/lilypond/issues/detail?id=2656 that there has since been bug issues with a previous version that LilyPond has been using, and now there's been fixes to those bugs. I noticed its in the latest dev release of LilyPond, but my question is: is it being retroactively implemented in the stable release? Hi Josh Nobody replied to you. According to a recent discussion in this list, it seems that the new Pango version in GUB makes lilypond compile much faster. This would be another good reason to make a 2.18.3 release. Unless 2.20 is close... What developers think about it? (I'm cc-ing lilypond-devel). I don't think 2.20 is that close: it would be nice to have it work with GUILE-2.0. There is rather slow progress on this: the main symptom of any progress is occasional weird commits to LilyPond, a large amount of frustration and procrastination on my side that leads to low responsiveness and productivity of mine, and a number of bug reports of mine eventually making it into the GUILE issue tracker. Basically, it's a continuous stream of oh, that doesn't seem to work under those circumstances or oh, that doesn't seem to work as intended with suggestions for alternatives that trip up in different ways. And tracking and boiling the new problems down into useful test routines one can report is not fun. I am not sure that I'll have every problem in check by the time GUILE 2.0.12 comes out. However, it would appear that the 2.18 variant you are envisioning is basically rather 2.18.3a: identical sources, different build system. It might be possible to roll something like that if it would help people. It would still self-identify as 2.18.3 but the installers would get a different file name. No idea how much of a nuisance that would be for our package providers. If that trips up procedures all too much, one might just release 2.18.4 regularly. But then the question arises whether one should incorporate other fixes. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paper size survey
Am 20.04.2015 um 09:17 schrieb Richard Shann: On Mon, 2015-04-20 at 08:50 +0200, Urs Liska wrote: Am 20.04.2015 um 08:45 schrieb Andrew Bernard: So Ponders, What size paper do you print scores on? I use A4 exclusively, only because that's my printer's capacity (and its cheap locally). I'm primarily creating stuff for my own use, and avoid page turns by opening out three, even sometimes four, pages of A4, having stuck the pages together with sticky tape. A4 exclusively, sometimes folded A3 I'm puzzled, if you fold A3 don't you just get two pages of A4? Yes, but I think the question was about the actual media and hardware to use (and buy), and so it is something different. (but only when letting print through external service providers). Is there a typo in this sentence? (when getting [it] print[ed] ... ???) Yes, that's what I mean. I don't own an A3 printer. But I always suffer from that being somewhat too small for really usable scores. If I had the printer or would find a suitable service provider I would prefer folded A3+ yes, a bigger page would be better, but it would be expensive in the current situation :( Yes. There's a reason why most classical publications use larger paper. I think LilyPond's default page layout (i.e. the page margins on A4) is quite ugly, but if you make the margins larger you have a significantly too small page area and line width for notation, so it's probably a necessary compromise (think of the page layout LaTeX gives you if you simply throw some text on its default document classes). Urs Richard ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paper size survey
Hi, for the orchestra parts I used B4 portrait. Orchestra musicians love this format as this fits well on a music stand (A3 is too big) and fits more music than A4 (less page turns). I also used thicker paper (120 g/m2) and a special binding method (glue and tape) to make the pages stay open and page turns less noisy. The score was A2, but it was extremely difficult to find companies which still have machines to print two-sided A2 in low volumes. I ended up asking Schott publishers where they printed their large format scores and they told me the print shop they're using. -- Orm Am Montag, den 20. April 2015 um 08:50:21 Uhr (+0200) schrieb Urs Liska: Am 20.04.2015 um 08:45 schrieb Andrew Bernard: So Ponders, What size paper do you print scores on? A4 exclusively, sometimes folded A3 (but only when letting print through external service providers). But I always suffer from that being somewhat too small for really usable scores. If I had the printer or would find a suitable service provider I would prefer folded A3+ Maybe we could extend this survey by the _type_ of paper? Of course for day-to-day use I print on standard office paper, but what I found extremely beautiful for scores is Munken Pure 100g/m2 or 130 g/m2. Urs Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Fri, 17 Apr 2015 15:03:19 +0200 Urs Liska u...@openlilylib.org wrote: The questions came in various variants of why should a publishing house use LilyPond? And despite all the reasoning and writing I have produced over the last years I didn't always find the striking key features that were convincing in the concrete situation. Déjà vu all over again... Why should serious businesses use Unix? Outcome: they didn't. Why should serious businesses use LaTeX instead of MSO? Outcome: they didn't. Why should serious businesses use Linux instead of Windows? Outcome: they didn't. The LilyPond versus Sibelius/Finale/... case is very similar to LaTeX versus MSO. Both LP and LaTeX (can) produce superior results, but have a weird way of working -- at least, in the eyes of many. For us, command line driven programming may feel normal, but for the rest of the world it is not, and in my belief it will never become broadly accepted. I did some book productions for a big publisher. I convinced them that I would be delivering high-quality camera-ready materials. They didn't care how I did it, what tools I used, even though my results looked better than theirs. Bottom line: Let's have fun the way *we* do it. Let's show the world the beautiful scores we make. If people wants to join us, let's welcome them and guide them patiently through the learning curve. And enjoy. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
2015-04-17 16:45 GMT+02:00 Gilles gil...@harfang.homelinux.org: A FLOSS like LilyPond is a great opportunity to share (musical) culture, at the lowest possible cost. A project like Mutopia is a promising future: digital scores (of public domain music) that are free of publishers' rights. If and when big publishers use LilyPond, the result will be more restricted access (through cost) to culture (because they won't release their proprietary contents). I've thought for a long time that the right way to go is to seek public funds for engraving public domain contents with the purpose of publishing it under a GPL-like (or Creative Commons) license. Me too.. but unfortunately it's not a good moment to seek public funds. And I don't like much having to deal with public istitutions. I would prefer if more people were able to use LilyPond and learn to have fun and learn and help others while contributing to Free Culture. That's why I started thinking about bringing LilyPond in music schools. Even though I never tried because of lack of time, I can imagine two major issues: 1. LilyPond is not considered as a professional tool because it's not used by the publishing companies. In general schools teach what the market asks. That's why I think that this effort by Urs is important. 2. Text input. Frescobaldi is doing a good job here, but still.. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paper size survey
On Mon, 2015-04-20 at 08:50 +0200, Urs Liska wrote: Am 20.04.2015 um 08:45 schrieb Andrew Bernard: So Ponders, What size paper do you print scores on? I use A4 exclusively, only because that's my printer's capacity (and its cheap locally). I'm primarily creating stuff for my own use, and avoid page turns by opening out three, even sometimes four, pages of A4, having stuck the pages together with sticky tape. A4 exclusively, sometimes folded A3 I'm puzzled, if you fold A3 don't you just get two pages of A4? (but only when letting print through external service providers). Is there a typo in this sentence? (when getting [it] print[ed] ... ???) But I always suffer from that being somewhat too small for really usable scores. If I had the printer or would find a suitable service provider I would prefer folded A3+ yes, a bigger page would be better, but it would be expensive in the current situation :( Richard ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On 2015-04-17 15:03, Urs Liska wrote: - most people in the business have moved away from taken the status quo with Finale and Sibelius for granted. - they know that they *have* to find new answers. - many (except a few die-hard reactionists) see that LilyPond and friends *can* offer answers to their questions - but they also see that these are maybe not the only possible answers and - that we (currently) can't guarantee straightforward migration paths. Market is hard, and everything is moving quite slowly, of course. But IF we should be able to come up with convincing solutions or at least roadmaps I see that we now have better chances than ever to get LilyPond a foot in the door with the publishing business in general. Sorry for that elaborate text, but I think it is important and hopefully fruitful. Indeed! I only want to make a short personal comment at this point and I may or may not enter the real debate later: As someone who has made the journey from (one of) the two established notation programs to LilyPond, I'm convinced it was the right decision for me but it would honestly be hard for me to recommend it for anyone else - composer or editor - at this point. In this respect I agree with your concern, Urs. But in analogy with Linux and others, LilyPond has a great community where some contribute to the core and others contribute to making tools, documentation etc that makes the rough core accessible to more people! So in my view we are more or less rapidly closing in on the point where it would be possible to recommend it to more than a few (albeit not all). Urs, I'd like to take the opportunity to thank you for all your effort in making LilyPond better! Best Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Am 20.04.2015 um 12:00 schrieb Federico Bruni: 2015-04-20 4:33 GMT+02:00 Andrew Bernard andrew.bern...@gmail.com mailto:andrew.bern...@gmail.com: So I don’t quite understand the need to help out these companies. What exactly is the motivation? What would they put back to the lilypond development effort? Maybe nothing, but never say never... Possible advantages: - you, as a typesetter, may be allowed to submit lilypond projects to them. I don't know this market but I guess that a publishing company wants to own the source files (they can understand and edit) and not just the PDF. - if they use LilyPond they may be interested in sponsoring some features. - if LilyPond was used by some of the major publishing companies, it would get a better status and be accepted in music schools. If more students learned using lilypond, they might contribute to Mutopia. I have written two detailed posts to this thread (which I want to be reviewed before actually posting), but I think these points are very important. To add to your list is that acceptance with music publishers would stop ruling out engravers who work for music publishers as users for LilyPond. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: B Series paper
On 20/04/2015 16:44, Andrew Bernard wrote: Hi Brian, We could go halves in a shipping container. For Oz users, I've just found that Officeworks sell Fuji Xerox A3+ copy paper in various weights: 90gsm, 100gsm, 120gsm, 140gsm, etc. Go to their web site at https://www.officeworks.com.au/ and search for sra3 colotech. I checked on the Fuji Xerox web site to be sure of the size, and they show that paper size as 450x320 (p.3 of http://www.fujixerox.com.au/general/content_request/paper.pdf), so folded would give 225x320, pretty close to the B4 that is unobtainable here. Works for me as I have two printers that can take that paper size. Nick ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
2015-04-20 4:33 GMT+02:00 Andrew Bernard andrew.bern...@gmail.com: So I don’t quite understand the need to help out these companies. What exactly is the motivation? What would they put back to the lilypond development effort? Maybe nothing, but never say never... Possible advantages: - you, as a typesetter, may be allowed to submit lilypond projects to them. I don't know this market but I guess that a publishing company wants to own the source files (they can understand and edit) and not just the PDF. - if they use LilyPond they may be interested in sponsoring some features. - if LilyPond was used by some of the major publishing companies, it would get a better status and be accepted in music schools. If more students learned using lilypond, they might contribute to Mutopia. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 12:00:19 +0200 Federico Bruni fedel...@gmail.com wrote: - you, as a typesetter, may be allowed to submit lilypond projects to them. I don't know this market but I guess that a publishing company wants to own the source files (they can understand and edit) and not just the PDF. I don't know this market either, but if it is similar to the printed books business they just don't have the knowledge and skills to deal with our sources. They'll most happily accepts PDFs. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pango Update in new binaries
2015-04-07 19:47 GMT+02:00 Joshua Nichols josh.d.nich...@gmail.com: Hello all, I apologize if this question has already been asked. Has the new version of pango been ported to the binaries on mac/windows/linux? I noticed here https://code.google.com/p/lilypond/issues/detail?id=2656 that there has since been bug issues with a previous version that LilyPond has been using, and now there's been fixes to those bugs. I noticed its in the latest dev release of LilyPond, but my question is: is it being retroactively implemented in the stable release? Hi Josh Nobody replied to you. According to a recent discussion in this list, it seems that the new Pango version in GUB makes lilypond compile much faster. This would be another good reason to make a 2.18.3 release. Unless 2.20 is close... What developers think about it? (I'm cc-ing lilypond-devel). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Andrew (et al.), I would have thought that, like the invention of desktop publishing in the 1980’s, which allowed small scale companies and individuals to produce professional publications, lilypond frees composers, musicians, and engravers from the tyranny - and rejections - of the hidebound established music publishers. Why do we need Peters and Barenreiter and others? Have you seen the “graphic design” of the millions of people who bought a Mac (or whatever) and Adobe Illustrator (or whatever) and started cranking out “design”? The situation is exactly analogous in the music world: the vast majority of people (composers, etc.) *think* they know how to make a readable music score, or at least trust that Finale/Sibelius/whatever will do it for them, and the results are atrocious. Publishing houses, for the most part, are Awfulness Sieves… and as such are [mostly] necessary evils, at a certain level. My composer colleague of the New Complexity School will never be published by the Big Firms. But he will be published by me. And with the web nowadays, the big distribution networks the Old Companies have is no longer important. For better or worse, I have chosen to self-publish my own works. But I’m not deluding myself into thinking that “the big distribution networks the Old Companies have is no longer important” — that’s a fallacy, and easily debunked. It may well be that *one day* that statement will be more true than false… but we’re still at least a decade off from that Rapture, maybe more. I would like to see every engraver using lilypond I don’t really care; I only care about engraving quality. What I *would* like to see is every engraver outputting music of equal or superior quality to the scores I engrave myself in Lilypond, and that’s clearly not happening right now. If (as some have suggested) Steinberg’s pending application has output of equal or greater quality to Lilypond, and there is some reasonable way (e.g., MusicXML or MEI) for me to “own the source indefinitely”, that application's ease of use (read: GUI and other tools and workflows) could certainly sway me into abandoning Lilypond. Unlike many on this list, I have no burning need to force Open Source Philosophy on the world if it’s not willing to prove its own worth. If [established firms] need vast amounts of explaining to understand it, they simply will not get it. So true. Hence my repeated pleas to try to make Lilypond usable without vast amounts of explaining. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hello. On Sun, 19 Apr 2015 21:39:29 -0400, Kieren MacMillan wrote: Hi Gilles (et al.), To whom LilyPond should strive to offer the future”? To everyone it possibly can. ;) Yes, but we are all aware of the limited resources, and I doubt that focusing on how to please established editing houses will lead us closer to the principles and goals of free software. IMHO, certainly not to the [...] big house[s] with traditions, regulations and limitations”. Why not? What’s to say that Lilypond can’t initially fit within those traditions, regulations, and limitations, while providing benefits (financial and otherwise) to those “big houses”, and can’t eventually help a “big house” move past those limitations while maintaining whatever traditions and regulations they see as indispensible? Your question is quite fair. But why do you ask _me_? ;-) I'd answer that, yes, they can and should use LilyPond, if they care for their business' future. The point is that _they_ don't understand, and that bright people here will (probably) waste their time trying to figure out their business case for them. Some software projects try to please their users, sometimes through decisions that could hurt long-term improvements. Even worse is giving the priority to non-users! What's for the LilyPond team in spending resources trying to work around those self-inflicted limitations? Let’s say, for discussion’s sake, we convince a Warner-Chappell, Boosey Hawkes, or Barenreiter to use Lilypond as their primary engraving application. You honestly don’t see the potential upsides of that situation? Sure, I could imagine them. I could parallel the comparison with big companies starting to pay programmers for contributing to the development of Linux. But, actually, the situation is upside down: the Linux team did not try to please e.g. IBM; rather, IBM figured out what their best interest was. Publishers would be expected to give back if (when) they benefit financially from using LilyPond. The discussion here is that LilyPond should give even more to them, right now. Do you not remember the tipping point when OpenOffice was embraced over Microsoft Office as the official office application suite by certain governments? Again, this is different in a very significant aspect: the citizen benefit (in principle at least) when public institutions become independent of private interests (by adopting FLOSS). In this case, we consider FLOSS being adopted by a private company. I'm sure the company can benefit; I'm not sure that the public will. LilyPond is [...] a program that creates beautiful sheet music following the best traditions of classical music engraving. (excerpt from http://www.lilypond.org/introduction.html;) I think that this goal is way more important (to users) than trying to convince publishers. To certain users? Absolutely. To a majority of users? Possibly. To all users? Doubtful. If one goal of LilyPond was to immediately grab all users of the existing alternatives, it should have renounced to implement its way of inputting contents... It's good (for the goal of creating beautiful scores automatically) that the chosen approach was different. With the difference came incomprehension of most people who are generally averse to change, whatever the number of rational arguments you can throw at them. In any case, those aren't mutually exclusive goals. Quite the contrary: almost tautologically, the easier it is for an abstract user to “create beautiful sheet music following the best traditions of classical music engraving”, the easier it will be to convince a given publisher to become a user. I agree with the rationality of the argument: the reality is different (cf. previous paragraph), unfortunately. A project like Mutopia is a promising future I disagree rather strongly. Mutopia (at least currently) appears to me to be a rather damning example of the failure of the open-source philosophy to be able to make a broad and lasting impact on its intended market. Worse, far too many of the examples there are not, to my eye, “beautiful sheet music following the best traditions of classical music engraving”; I would, for example, never send someone there if I was trying to impress them with Lilypond’s engraving output. I meant the _idea_ of Mutopia: a repository of free sheet music. One can rightly be disappointed that the quality of the contents does not evolve in step with LilyPond. Can it be blamed on LilyPond's shortcomings? I'd like to know what people think it would take to make the endeavour really take off. I possible, I'd rather use resources for that project. If and when big publishers use LilyPond, the result will be more restricted access (through cost) Cost of what? Lilypond wouldn’t ever cost any more. I didn't mean LilyPond; I meant that rather than accumulating scores forever free (as should be the case if encoding them was done thanks to public funding),
Re: Paper size survey
Wow, so far the replies have all been fairly similar. Maybe it's not so interesting, but here's my answer: Most of the time I am printing choral scores. The ideal size for a choral octavo I think is about 174 x 260mm; I could probably make folded B4s work if I were living outside the US. Since I'm in the US I print on tabloid paper (~A3) and trim it down. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Paper-size-survey-tp174825p174854.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Gilles (et al.), we are all aware of the limited resources, and I doubt that focusing on how to please established editing houses will lead us closer to the principles and goals of free software. Now *that* I totally agree with. And perhaps this discussion will always split along the line separating those whose primary goal is the advancement of FLOSS and those whose primary goal is the advancement of beautiful music engraving. The point is that _they_ don't understand, and that bright people here will (probably) waste their time trying to figure out their business case for them. That’s a fair point. But their business case is, at least for me personally, partly my business case, whereas FLOSS’s “business case” isn’t. Even worse is giving the priority to non-users! Some say that Microsoft obtained its original OS dominance (which at one point was approaching 95%) specifically by giving the priority to non-users: it wilfully allowed (or even secretly supported) the proliferation of pirated copies of early Windows versions, in order to take the beachhead. Whether or not they properly managed that dominance in the following decades is a different debate. Lilypond could only dream of having such a market-share dominance to squander in the music engraving world. Publishers would be expected to give back if (when) they benefit financially from using LilyPond. I wouldn’t expect that at all. (Again, this discussion might always split along that fundamental line.) If one goal of LilyPond was to immediately grab all users of the existing alternatives, it should have renounced to implement its way of inputting contents… That doesn’t logically follow. Imagine the following three-step scenario, none of which is gargantuan: 1. We perfect the translation of ANY musical source (Finale, Sibelius, OpusModus, Igor Engraver, MIDI, or whatever) into a form that Lilypond handles natively. 2. We perfect the stylesheet and grid system that Urs and I (and others) are currently working on. 3. We perfect the editionEngraver that Jan-Peter created (and Urs and I and others are working on). Now you’re in a situation where someone can *INPUT* contents any way they want, using any application/tool they’re comfortable with, but Lilypond does the engraving work with super-easy tools for maintaining and manipulating (read: further beautifying) the final output. We didn’t renounce anything about the way Lilypond inputs contents — only opened the doors for Lilypond to “play well with others”. With the difference came incomprehension of most people who are generally averse to change, whatever the number of rational arguments you can throw at them. Which is exactly why (as I’ve been implying) we should through emotional arguments at them: “Look how beautiful!”, “Look how easy!”, “Look how all-inclusive!”, “Look how cheap!”. The problem is that few people here seem interested in making those emotional arguments actually true. I meant the _idea_ of Mutopia: a repository of free sheet music Well, the _idea_ of FLOSS is wonderful, too… but currently it fails most use-cases just as spectacularly as Mutopia fails its use-case. Can it be blamed on LilyPond's shortcomings? No. But it can be blamed in part on FLOSS’s shortcomings. I'd rather use resources for that project. As someone else said, nobody’s stopping you! =) I agree that a truly impressive Mutopia would be nothing but a good thing for both FLOSS and Lilypond… I just feel the cost/benefit equation currently (and massively) favours a route like the one Urs is investigating. we'll continue in the same system where musicians continue to pay for works long gone out of copyright. You’ll get no argument from me on the topic of the current copyright and intellectual property system(s) — they suck. But the way to fix that is legislative, not pricking at Goliath’s heel with a Lilypond needle. Best regards, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Federico (et al.), Possible advantages: - you, as a typesetter, may be allowed to submit lilypond projects to them. I don't know this market but I guess that a publishing company wants to own the source files (they can understand and edit) and not just the PDF. The smaller and/or younger the house, the more likely they’ll accept PDFs — they simply “pass them through” for reprinting and selling. That being said, if I started a publishing house today, I wouldn’t accept 99% of the PDFs I see from *any* application, Lilypond included: they’re just not up to my standards. - if they use LilyPond they may be interested in sponsoring some features. +1 - if LilyPond was used by some of the major publishing companies, it would get a better status and be accepted in music schools. +1 If more students learned using lilypond, they might contribute to Mutopia. As mentioned before, this effect is of little interest to me… but if it helps the larger ‘Pond, I’m all for it! Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi. On Mon, 20 Apr 2015 09:52:54 -0400, Kieren MacMillan wrote: Hi Federico (et al.), I've thought for a long time that the right way to go is to seek public funds for engraving public domain contents Me too. I think it’s telling that most of the non-publishing music world is going in exactly the opposite direction: schools are adding “musical entrepreneurship” courses, programs, and degrees all over, in an attempt to teach musicians how to avoid the trap of relying only on public funds; and there is a significant (and mostly successful) grassroots effort to abandon the dying “not-for-profit” model of musical organziations in favour of a model where pleasing the paying audience actually matters to some extent. I started thinking about bringing LilyPond in music schools. Even though I never tried because of lack of time, I can imagine two major issues: 1. LilyPond is not considered as a professional tool because it's not used by the publishing companies. In general schools teach what the market asks. That's why I think that this effort by Urs is important. 2. Text input. Frescobaldi is doing a good job here, but still. From the [many] discussions I’ve had with music schools large and small, the second is *far* less important than the first. And rightly so: all other things being equal, higher education should be teaching students skills and tools [!!] which they can immediately apply to their careers. This cannot be the overall guiding rule, if progress has any value at all. Is the sole expectation, of students attending music schools, to be hired by a publishing company? Personally, I think that it is equally wrong to teach (how to become dependent of) proprietary products, the more so when a free (and more fit to the task!) alternative exists. [Cf. M$-Office versus LaTeX for typographic quality and consistency.] Unfortunately, as long as Lilypond is a pariah amongst publishers, it does a disservice to students to teach them Lilypond at the expense of other things. I might be wrong, but I think that the vast majority of music engraving software users don't make their choice based on what a publishing company uses. LilyPond is at a disadvantage mainly because of marketing reasons (and aversion to changing one's viewpoint on certain tasks). As Urs mentioned, LilyPond would be a serious alternative for new publishing houses. Teaching it is offering business opportunities for people so inclined. Best, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Survey: Large scores
Hi,
this is the way how I finally had to do it in my piece, but
unfortunately this method doesn't work very well in orchestra parts
where instruments are changed (like Clarinets changing between Eb, Bb
and Bassclarinet, or French Horns changing from G-Clef to F-Clef) as
you either have to compensate for the transposition (which means you
have to be aware of the context, an instrument change is happening
in), or to not wrap the whole part in the transpose statement, but the
sections with the individual instruments.
Especially if you split the music into multiple sections this is
asking for trouble as you either have to live with dangling open
braces between sections or restate an instrument change which already
has happened.
--
Orm
Am Sonntag, den 19. April 2015 um 19:20:57 Uhr (-0700) schrieb H. S. Teoh:
This is not hard to implement at all, you just have to set things up
appropriately. I also always write at concert pitch, and I use a
combination of \transposition and \transpose so that the part is printed
with the correct transposition. Here's roughly how I do it:
clarinetIPart = \relative c'' {
... % clarinet music here
}
clarinetIIPart = \relative c'' {
... % clarinet music here
}
clarinets = new Staff {
set Staff.instrumentName = #Clarinets in B\flat I, II
\transposition bes
\transpose bes c' \partcombine
\clarinetIPart \clarinetIIPart
}
The music in \clarinetIPart and \clarinetIIPart is written in concert
pitch. Later on, \clarinets is used to create the conductor's score with
the right transpositions applied. A similar setup is used for generating
parts for the individual clarinets with the right transpositions.
Of course, all this can probably be encapsulated in a convenient macro
that takes a single argument specifying the transposition relative to
c', and generates the requisite commands to make it all work.
T
--
Why are you blatanly misspelling blatant? -- Branden Robinson
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Federico (et al.), I've thought for a long time that the right way to go is to seek public funds for engraving public domain contents Me too. I think it’s telling that most of the non-publishing music world is going in exactly the opposite direction: schools are adding “musical entrepreneurship” courses, programs, and degrees all over, in an attempt to teach musicians how to avoid the trap of relying only on public funds; and there is a significant (and mostly successful) grassroots effort to abandon the dying “not-for-profit” model of musical organziations in favour of a model where pleasing the paying audience actually matters to some extent. I started thinking about bringing LilyPond in music schools. Even though I never tried because of lack of time, I can imagine two major issues: 1. LilyPond is not considered as a professional tool because it's not used by the publishing companies. In general schools teach what the market asks. That's why I think that this effort by Urs is important. 2. Text input. Frescobaldi is doing a good job here, but still. From the [many] discussions I’ve had with music schools large and small, the second is *far* less important than the first. And rightly so: all other things being equal, higher education should be teaching students skills and tools [!!] which they can immediately apply to their careers. Unfortunately, as long as Lilypond is a pariah amongst publishers, it does a disservice to students to teach them Lilypond at the expense of other things. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: auto force accidentals
At 19:16 on 20 Apr 2015, Mátyás Seress wrote: Hi all, I have a question: do you know any command in Lilypond to automatically force those accidentals which have been changed in the preceding measure? Let me give you an example: See Documentation: Notation Reference 1.1.3 Displaying pitches - Automatic accidentals, and choose your preferred accidental style. -- Mark Knoop ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:Do we really offer the future?
Well after reading many responses to this question I thought I would give my own. I think first one must answer Why do publishers use other programs? Who submits to publishers? Why do users use other programs? Why do publishers use other programs? Obviously there was typesetting before computers, so why did they favour certain graphical applications instead of text/code based. Well you have to ask yourself, who is in this field? The simple answer is musicians. Back when these programs came out the people in this field new nothing or little about computers, especially coding. They were taught “this is a computer, this is the internet, and this is email.” As computers grew and software developed it had to cater not only to the needs of customers but also the skill level at the time. Graphical applications where great because users could acquire great results with little knowledge and little effort. Who submits to publishers? The majority are musicians – again with little or no knowledge of text/code based applications – One would say this applies to other aspects as well. People favour Graphical word processors over say Tex -. This also has to be broken down even further. What genre? Well pop music continues to sell most in publications as well as record sales, followed by rock, country, dance RB, Blues etc. Classical is above Jazz and Jazz only above Other. When you group the top categories together as “Current Music” they leave classical and jazz with only a small part of the pie. You can also break this further. If you consider the top instruments today you see piano (no idea why – joke) and guitar second most popular. Why is this all important? Well because of the next question! Why do users use other programs? First who are the users of lilypond? Well I break it down as “professionals in the computer industry with a love/passion in music” and “professional musicians with a love/passion in computers”. Why is this important? A good friend of mine is Dennis Clarke who was a major part of Blastwave.org, and in my opinion one of the best programers I know. He also is an amateur musician. I on the other hand am a professional musician with an understanding of computers. Why bring this up? Well the way I look at it is that I also think he has a greater understanding of music than most. As I do with computers. However, as much as he knows he could never understand music in the same way I do, nor could I computers in the way he does. As much as he knows, he may not be nor would I expect him to be familiar with performance practices in each era of music and how it affects interpretation. Or to be 100% knowledgeable about pedagogy or agogics and it's applications etc. This being said I would never expect a publisher or want them to publish pieces that does not relay the true nature of the score. This is why most serious musicians use urtext or facsimiles of earlier prints. Since most is in public domain the only need to typeset the score would be in a scholarly approach- or “current music”. Based on this most publishers look for respected members in that field specifically educated in that subject. And to be honest most lack the knowledge to use lilypond. Lets face it unless you are fairly comfortable with computers lilypond is not going to cut it. Go back to question two “Who submits to publishers?”. Most of what a user expects and publishers for that matter is that it does what they need. Therefore it has to be able to accomplish the needs of all users and all genre. As a guitarist that has used Linux since 1996 and has never ran any other operating system – well windows 3.11? (but only for six months). Lilypond to me is a comfortable choice. However, as a guitarist I find most of the things required for guitar incorrect or only half available. The biggest drawback is that one has to search forums, lists, LSR, git etc. Just to be able to do basic functions that should be there already. I have to say that over the years I have used lilypond I have had to write most of the “guitar specific” things that 1. most users would expect and 2. the average user would be incapable of doing. Again this is a collection over years of personal work. So you can't expect publishers or users to move to a system that doesn't have all aspects of what they need ready and available – for all genre and instruments. As much as the over all look is concerned I think lilypond is superior and that's why I use it but, others will sacrifice the look for a system that easily accommodates ones needs. Again I wouldn't expect a person wanting to write a fantasy novel to use Latex just because I think it's better. This being said students and the average person have more knowledge of computers and programing then ever before. Computers are taught in school and Linux is in popular use. So eventually text/code based editing will be as easy as writing your native language. As for the comments on mutopia project.. Well I don't
Re: Paper size survey
Hi Andrew, What size paper do you print scores on? Full orchestra scores: U.S. tabloid (11x17) portrait Choral octavo scores: U.S. tabloid (11x17) landscape, folded/stapled and trimmed to octavo booklet-face dimension (7x10.5) Organ scores: usually U.S. tabloid (11x17) landscape, trimmed to standard organ score size; sometimes just U.S. legal (8.5x14) landscape essentially all other scores and parts: U.S. letter (8.5x11) portrait When possible, I use off-white (“cream”, “ivory”, etc.) paper, of higher density than standard copier paper”. Hope this helps! Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
RE:auto force accidentals
take a look here http://fritz.rmi.de/dokumentation/lilypond/Documentation/user/lilypond/Automatic-accidentals.html HTH Stephen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
[OT] Re: Do we really offer the future?
Hi Gilles, On Apr 20, 2015, at 1:19 PM, Gilles gil...@harfang.homelinux.org wrote: When people put convenience above all, they start giving up their freedom. My experience — this thread being no different so far — is that such discussions always end up in absolutist terms (moral and otherwise). It’s almost a defining quality of the FLOSS movement, from what I can tell. Ultimately, such positions are neither realistic, nor productive, nor particularly interesting to me (or many other people I know). I don’t grow my own food, because buying my food — even the organic food I purchase regularly, in person, from farmers I know by name — is not only more convenient, but also cheaper and more freeing than growing, harvesting, and processing it myself. That freedom allows me to do other things that are more important to me, like composition, and using Lilypond to engrave my compositions, instead of heading out at 5AM to feed and milk my cows before the hard 16-hour day tending my subsistence crops. I don’t put convenience above all; I make choices that make sense to me and those around me, in my real-world life. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
auto force accidentals
Hi all,
I have a question: do you know any command in Lilypond to automatically
force those accidentals which have been changed in the preceding measure?
Let me give you an example:
\score {
\relative c' {
\clef G
\key c \major
\time 4/4
a8 b c d e f gis a
a g f e d c b a
}
}
Because it is annoying that I have to constantly look out for notes like
the g in the second measure to code it like g! in order for making the
score look nicer.
Do you know any good solution on how to automatize this?
Thanks in advance,
Mat
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 10:22:23 -0400, Kieren MacMillan wrote: Hi Andrew (et al.), I would have thought that, like the invention of desktop publishing in the 1980’s, which allowed small scale companies and individuals to produce professional publications, lilypond frees composers, musicians, and engravers from the tyranny - and rejections - of the hidebound established music publishers. Why do we need Peters and Barenreiter and others? Have you seen the “graphic design” of the millions of people who bought a Mac (or whatever) and Adobe Illustrator (or whatever) and started cranking out “design”? The situation is exactly analogous in the music world: the vast majority of people (composers, etc.) *think* they know how to make a readable music score, or at least trust that Finale/Sibelius/whatever will do it for them, and the results are atrocious. Publishing houses, for the most part, are Awfulness Sieves… and as such are [mostly] necessary evils, at a certain level. My composer colleague of the New Complexity School will never be published by the Big Firms. But he will be published by me. And with the web nowadays, the big distribution networks the Old Companies have is no longer important. For better or worse, I have chosen to self-publish my own works. But I’m not deluding myself into thinking that “the big distribution networks the Old Companies have is no longer important” — that’s a fallacy, and easily debunked. It may well be that *one day* that statement will be more true than false… but we’re still at least a decade off from that Rapture, maybe more. I would like to see every engraver using lilypond I don’t really care; I only care about engraving quality. What I *would* like to see is every engraver outputting music of equal or superior quality to the scores I engrave myself in Lilypond, and that’s clearly not happening right now. If (as some have suggested) Steinberg’s pending application has output of equal or greater quality to Lilypond, and there is some reasonable way (e.g., MusicXML or MEI) for me to “own the source indefinitely”, that application's ease of use (read: GUI and other tools and workflows) could certainly sway me into abandoning Lilypond. Unlike many on this list, I have no burning need to force Open Source Philosophy on the world if it’s not willing to prove its own worth. In F - Free L - Libre O - Open S - Source S - Software the most important word is Libre (as in freedom). When people put convenience above all, they start giving up their freedom. And yes, we are heading in that direction (through lazyness, despite all the wonderful work build by the _original_ OSS movement, and the increasing availability of free alternatives). It's the wrong direction. If [established firms] need vast amounts of explaining to understand it, they simply will not get it. So true. Hence my repeated pleas to try to make Lilypond usable without vast amounts of explaining. In some sense, LilyPond is usable with a little amount of explanation. As you know, some people will turn away just because of text input, even though I'm sure that, for simple tasks, it requires less time get up to speed with LilyPond than with a GUI software. [That is, unless one insists that softwares must be usable without reading the usage instructions...] Vast explanations are needed for example when it comes to making things that are not part of the LilyPond language. [Whenever Scheme code is part of the solution, it can never be easy from viewpoint of someone who does not know the language.] It may also be a problem that the software is so flexible: there are (too?) many ways to organize a large work, at which LilyPond is probably much better than the competition. Along the years, several add-ons (templates, makefile, scripts, snippets) have been mentioned here but, unless I'm mistaken, they didn't yet evolve into a compelling standard set of files with features that would cover most needs. As a concrete example, I'd favour recommending that _any_ piece of music (small or large, it does not matter) be encoded in files that separate layout from contents; the official documentation provides templates where everything is in a single file. Best regards, Gilles Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
best practices for volta (was Re: Problem with repeat alternative endings that contain lyrics andleading rests)
Hi all,
On Apr 19, 2015, at 6:11 AM, Trevor Daniels t.dani...@treda.co.uk wrote:
\score {
\new Staff {
\time 2/4
\new Voice = melody {
\relative c'' {
a4 a a a
\repeat volta 2 { b4 b }
\alternative { { \vrest b } { \vrest c } }
}
}
}
\new Lyrics {
\lyricsto melody {
Not re -- peat -- ed.
\repeat volta 2 { Re -- peat }
\alternative { { twice. } { twice. } }
}
}
}
Looking at that example gives my brain hives. ;)
Is it really a best practice to put \repeat volta structures in multiple
locations? I just responded to a post a few days ago where (I believe, though
the OP hasn’t followed it through to terminus) the primary source of the
compilation troubles was asynchronous voltas.
1. Shouldn’t we be [heavily] promoting, even in tiny snippets, the use of
global variables to hold \repeat structures that are used in multiple places?
2. And in this particular example, why use \repeat at all in the lyrics?
Doesn’t the following (with the unnecessary braces left in for structural
clarity) work equally well?
\new Lyrics {
\lyricsto melody {
Not re -- peat -- ed.
Re -- peat { { twice. } { twice. } }
}
}
Thanks,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Gilles, This cannot be the overall guiding rule, if progress has any value at all. Is the sole expectation, of students attending music schools, to be hired by a publishing company? Of course not — I neither said nor even implied that. However, right now schools have the choice between spending valuable education time teaching young composers command-line programming for the purpose of using Lilypond to engrave scores which would never under any circumstances be accepted by any serious music publisher, or teaching them how to use the (e.g.) Sibelius GUI to quickly prepare a score that would be accepted (and in some cases demanded) by almost all publishers. It’s a no-brainer, and always will be. And we’re not even talking about non-composers, i.e., the vast majority of music school students (singers and instrumentalists) who want to quickly crank out a transposition of a song or whatever. Expecting them or teaching them to use today’s Lilypond is beyond laughable: it’s actually cruel. Personally, I think that it is equally wrong to teach (how to become dependent of) proprietary products, the more so when a free (and more fit to the task!) alternative exists. [Cf. M$-Office versus LaTeX for typographic quality and consistency.] I still think they should be teaching long division and cursive writing in elementary school, so you’re preaching to the choir to some degree. But it’s clearly not serving any student to teach them LaTeX at the expense of Microsoft Word, if any portion of their education is ostensibly so that they can graduate and fairly quickly become a productive member of today’s larger society. The ratio of job postings I’ve seen that ask for “Microsoft Word skills” to those asking for “LaTeX skills” is on the order of 99:1. Far better — to extend your analogy — would be to shift the business world to using LaTeX *first* (or, at the very least, *simultaneously*), so that there is an actual demand for the [superior] skills we personally want to see taught. I might be wrong, but I think that the vast majority of music engraving software users don't make their choice based on what a publishing company uses. Well that’s self-evidently true for Lilypond users. ;) But you’re 100% wrong for the rest of the engraving world: as a working composer, arranger, and educator, I can say with 100% certainty that any GUI-based consideration beyond Finale or Sibelius (e.g., NoteAbilityPro, etc.) is met with intense skepticism in significant part because no publisher will accept the files once completed. (The GUIs are essentially in feature- and ease-parity, so that’s not a factor. And price doesn’t stop anyone: they either pony up or pirate.) The very biggest hurdle is, and will probably always be, inertia: music schools install and instruct on Finale or Sibelius. And that’s in largest part because those are the [publishing] industry standards, so that just further proves my point. LilyPond would be a serious alternative for new publishing houses. Not if it can’t *very easily* handle input files from Finale, Sibelius, and other “industry standard” engraving applications. That’s an almost foolproof recipe for financial failure. Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hi Urs, this seems a good idea, but not for my original question. Fair point. If you could find the time to put together a list of arguments (or maybe a nice blog post) why a *composer* should use LilyPond this would also be very helpful. I would *love* to do that — a blog post sounds like the best approach (for maximum visibility/distribution). I might even “simulcast” it on my own website! Once I get my current scores out the door, I’ll move this up on the priority list. For this kind of people it seems most important to get their music into the score as quickly and easily as possible. I'm thinking of composers who *do* need performance material but who do not necessarily need publication quality, just the one necessary for people to play from the material. That’s a huge audience, of course. That being said, I will always whip out my trump card: at 7:30PM on the opening night of “Robin Hood”, I ran into the theatre office, pointed their browser at lilybin.com, and cranked out an engraved piccolo part for the Overture which the player sight-read at 8PM. That was pretty quick and easy”, all things considered. ;) Sounds reasonable. I think I've identified (or was told) the following use cases: - producing scores for the day - editions without specialized demands and not necessarily intended for extra-long maintainment. - producing scores on short notice, e.g. performance material when the composer delivers too late - process existing material (either from the archives or from heterogenous contributors' systems) - scholarly editions and edition series with a long-term horizon. I think, as (if?) this discussion moves forward, it will be critical to lay out the use cases — a Venn diagram might actually be a useful tool here! — and see which are viable targets for attack. Best, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)
On 04/20/2015 08:01 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: 1. Shouldn?t we be [heavily] promoting, even in tiny snippets, the use of global variables to hold \repeat structures that are used in multiple places? No, that's asking for trouble! The code should primarily reflect the musical interpretation, not just the notation. In know that it works to do as you propose in many examples, but it clearly does not work if you use \unfoldRepeats (in MIDI), for example. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: auto force accidentals
Hi guys, thank you for the support! I got the answer! :) Best regards, Mat 2015-04-20 20:17 GMT+02:00 Stephen MacNeil classicalja...@gmail.com: take a look here http://fritz.rmi.de/dokumentation/lilypond/Documentation/user/lilypond/Automatic-accidentals.html HTH Stephen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Survey: Large scores
On Mon, Apr 20, 2015 at 09:18:39AM -0400, Kieren MacMillan wrote:
Hi,
This is not hard to implement at all, you just have to set things up
appropriately.
You give a perfect example of why we need to improve Lilypond’s
implementation. The method
clarinetIPart = \relative c'' {
... % clarinet music here
}
clarinetIIPart = \relative c'' {
... % clarinet music here
}
clarinets = new Staff {
set Staff.instrumentName = #Clarinets in B\flat I, II
\transposition bes
\transpose bes c' \partcombine
\clarinetIPart \clarinetIIPart
}
not only requires too much overhead/effort, it requires extra
workarounds when key signatures are triggered externally (i.e., in a
global variable).
Actually, I do put key signatures in a global variable too. To get it to
take effect correctly (i.e. correctly transposed to the instrument's
pitch), I do this:
clarinets = new Staff {
set Staff.instrumentName = #Clarinets in B\flat I, II
\transposition bes
\transpose bes c'
\global
\partcombine \clarinetIPart \clarinetIIPart
}
Rather, one should simply be able to say [something
like]
clarinets = {
\takeInstrument #”clar.Bf”
%% Bb clarinet music here
\takeInstrument #“clar.A”
%% A clarinet music here
}
and all scores (transposing and concert-pitch) should Do The Right
Thing™, with perhaps a few parameters/switches to help as necessary.
I agree that the current implementation could be improved. I was just
pointing out that Lilypond does give you the facilities to put most of
these workarounds in macros that would alleviate the need to worry about
fiddling with the dirty details every time. Ostensibly, these could be
included as part of the standard \include files shipped with Lilypond so
that users don't have to do this manually.
Having engraved at least a hundred multi-instrumentalist movements
from my own music (for both classical and musical theatre orchestras),
I can report with great confidence that Lily’s current built-in
implementation is frustrating to the point of insufficiency.
[...]
To support switching between instruments of different transpositions, I
wonder if we could cook up a Scheme function that postprocesses a music
expression and wrap sub-expressions within the appropriate \transpose
blocks based on a running state associated with the Staff (or Voice).
For example, we might make it so that you could write:
clarinetPart = {
\set Staff.autoTransposition = bes
... % concert pitch music here
\markup Switch to A clarinet
\set Staff.autoTransposition = a
... % more concert pitch music here
\markup Switch to B\flat clarinet
\set Staff.autoTransposition = bes
... % yet more concert pitch music here
}
clarinetMusic = \autoTranspose \clarinetPart
I think something like these would be a valuable addition to the
standard \include library.
T
--
Век живи - век учись. А дураком помрёшь.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Survey: Large scores
Hi,
Rather, one should simply be able to say [something
like]
clarinets = {
\takeInstrument #”clar.Bf”
%% Bb clarinet music here
\takeInstrument #“clar.A”
%% A clarinet music here
}
and all scores (transposing and concert-pitch) should Do The Right
Thing™, with perhaps a few parameters/switches to help as necessary.
To support switching between instruments of different transpositions, I
wonder if we could cook up a Scheme function that postprocesses a music
expression and wrap sub-expressions within the appropriate \transpose
blocks based on a running state associated with the Staff (or Voice).
For example, we might make it so that you could write:
clarinetPart = {
\set Staff.autoTransposition = bes
... % concert pitch music here
\markup Switch to A clarinet
\set Staff.autoTransposition = a
... % more concert pitch music here
\markup Switch to B\flat clarinet
\set Staff.autoTransposition = bes
... % yet more concert pitch music here
}
clarinetMusic = \autoTranspose \clarinetPart
I think we’re saying the same thing. My hypothetical \takeInstrument syntatic
sugar would put the desired markup, \set the autoTransposition, and a number of
other things, as set in some \addInstrument (or other) definition.
I think something like these would be a valuable addition to the
standard \include library.
Agreed. I’ve been offering to sponsor this for nearly a decade — hopefully it
happens soon!
Thanks,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)
Hi Mats, No, that's asking for trouble! The code should primarily reflect the musical interpretation, not just the notation. In know that it works to do as you propose in many examples, but it clearly does not work if you use \unfoldRepeats (in MIDI), for example. Can \repeat not be defined so that — possibly with parameters/switches — it will Do The Right Thing™ in all engraved (e.g., PDF), expressed (e.g., MIDI), and other (e.g., MusicXML) output streams without requiring poor or inefficient structural coding? Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Page numbers
If you want to put an arbitrary page number in the header, not the proper consecutive one, how can this be done? Useful when setting a score where you do not necessary;y do the pages in monotonically increasing order. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Sun, 19 Apr 2015 21:39:29 -0400 Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Do you not remember the tipping point when OpenOffice was embraced over Microsoft Office as the official office application suite by certain governments? That's a totally different case: OO and MSO are two similar tools, that have a similar approach, similar workflow, and produce similar results. LilyPond approach and workflow is totally different from Sibelius and Finale and alikes. To mimic the OO - MSO comparison, MuseScore would be a better candidate. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: B Series paper
Hi Brian, We could go halves in a shipping container. Andrew On 20 April 2015 at 05:29:07, Brian Barker (b.m.bar...@btinternet.com) wrote I've got this down to 19 tonnes, but I doubt that's any more useful! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Paper size survey
So Ponders, What size paper do you print scores on? Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paper size survey
Hi Andrew, I use A4 for most small or normal scores (SATB choir). Sometimes A5 But full scores for the director with an orchestral score I use B4 - sometimes A3. Cheers, Jan-Peter Am 20.04.2015 um 08:45 schrieb Andrew Bernard: So Ponders, What size paper do you print scores on? Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paper size survey
Am 20.04.2015 um 08:45 schrieb Andrew Bernard: So Ponders, What size paper do you print scores on? A4 exclusively, sometimes folded A3 (but only when letting print through external service providers). But I always suffer from that being somewhat too small for really usable scores. If I had the printer or would find a suitable service provider I would prefer folded A3+ Maybe we could extend this survey by the _type_ of paper? Of course for day-to-day use I print on standard office paper, but what I found extremely beautiful for scores is Munken Pure 100g/m2 or 130 g/m2. Urs Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
