Re: A contribution (was Re: snippet to properly align dynamics with expressive text)

[Richard Shann]

On Mon, 2017-07-10 at 09:06 +0200, Jacques Menu Muzhic wrote:
> Hello Richard,
> 
> Just for the record: I’m using LilyDev 4, in which LilyPond builds
> seamlessly. The work to have it running in your virtual machines
> environment
Unfortunately my Debian Stable installation won't install the virtual
machine software any more, the package manager failed to find files it
needed on the Debian servers.

Richard



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A contribution (was Re: snippet to properly align dynamics with expressive text)

[Jacques Menu Muzhic]

Hello Richard,

Just for the record: I’m using LilyDev 4, in which LilyPond builds seamlessly. 
The work to have it running in your virtual machines environment is not that 
great.

JM

> Le 10 juil. 2017 à 08:44, Urs Liska  a écrit :
> 
> 
> 
> Am 08.07.2017 um 16:58 schrieb Simon Albrecht:
>> On 08.07.2017 15:49, Richard Shann wrote:
>>> I was intrigued by this, as I have a patch to the figured bass formatter
>>> that has been hanging around because the route to making contributions
>>> that I knew about involved a virtual machine which I can't get working
>>> on my current system.
>> 
>> The method Urs named is possible with openLilyLib, but not with the
>> LilyPond source.  That
>> means you would have to get a VM to work, or install a Unix system in
>> parallel – both a lot of
>> effort for one small patch obviously.  Or you just e-mail your patch
>> to the devel list and ask for
>> someone to shepherd it through the review process and into the code
>> base for you, which is done
>> from time to time.
>> 
>> Best, Simon
> 
> I have to add something here.
> 
> Simon is correct that I described a method for openLilyLib, not
> LilyPond. The Github copy of the LilyPond code is not up-to-date and is
> basically a mirror that *can* at any time made ready for people to
> contribute with a lower entry barrier than setting up a developer
> account on LilyPond's proper repository.
> However, this would still require a developer *with* such an account to
> process a patch, i.e. pull it to his local machine and upload it to
> LilyPond as a patch for review. So nothing would be won with that for
> your use-case, Richard.
> 
> HOWEVER:
> Linux (i.e. for you, a virtual machine) is required for BUILDING
> LilyPond, not actually for contributing. If you don't have that you by
> definition can't do any modifications that require building LilyPond but
> you can only work on the LilyPond and Scheme files.
> 
> What you need for contributing, i.e. sending patches into the review
> line and eventually the code base is:
> 
> * Git
> * git-cl
> (http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl)
> * Accounts on the sourceforge tracker and the savannah git repository
> 
> git-cl is a Python script, so that should be possible to install on any
> computer.
> So essentially, if you are planning to contribute .scm or .ly files only
> (and as you don't have a build system I assume this is the case) I'm
> sure you can set up a proper contribution toolchain on your OS of choice.
> 
> Urs
> 
> 
> -- 
> u...@openlilylib.org
> https://openlilylib.org
> http://lilypondblog.org
> 
> 
> ___
> 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: Place text next to rehearsal mark, or with left edge over barline if there is none

[Wols Lists]

On 10/07/17 18:35, Simon Albrecht wrote:
> On 10.07.2017 15:41, Wols Lists wrote:
>> On 09/07/17 21:20, Simon Albrecht wrote:
>>> On 09.07.2017 21:21, Wols Lists wrote:
 Maybe, but placing all related marks one after the other is just as
 semantically correct as placing them one on top of the other ...
>>> That’s nonsense, and it is for the same reason that it’s not a trivial
>>> decision to loosen horizontal alignment in general.
>> Why's it nonsense? "semantics" to me means "meaning", and if I see a
>> bunch of marks grouped together, they mean (to me at least) that they
>> all apply together. The fact that they are sequential rather than
>> stacked is irrelevant.
> 
> In tempo marks, horizontal position is related to semantics. If you
> place the tempo indication over a different moment, it means something
> different. What’s so hard to get about that? Or are you suggesting
> spreading the notes out by the entire width of the MetronomeMark? (I
> can’t think of tempo indications so short that this wouldn’t be
> ridiculous.)

No. I just view a markup block as exactly that - a block. So what if it
consists of several individual marks stacked horizontally. To me, a
tempo mark always belongs *after* a rehearsal mark if they collide, not
above it. And I can't remember whether the melody name goes above or
below the tempo.

I think I get your point a bit, though, in that I expect to see the
rehearsal mark above the barline. Iirc it's often left-justified, though ...
> 
>>> If you shift a tempo indication a tiny bit to the side, it makes no
>>> difference. But if it’s a
>>> slightly larger bit, such as the width of a quarter note, then the tempo
>>> change applies to a different moment. And preservation of semantic
>>> information (almost) always has to take precedence over elegant layout.
>>>
> Finally, these two statements are contradictory:
>
>   A real engraver who wanted to stick to those conventions would
>   presumably shift the note to the right
>
>   wasted white space is high on my list of priorities
>
 How come? Shifting the notes to the right wastes maybe one
 note-width of
 one stave. Stacking marks on top of each other wastes an entire line of
 text - bad enough in portrait music but appalling in landscape (where
 saving space tends to be extremely important - the music is only A5 to
 start with!)
>>> It’s obvious that your use case is special in its extremely tight
>>> restrictions on paper size and page turns. So I’m afraid you have to
>>> lower your expectations as to how well Lily will cope with that special
>>> situation in difficult circumstances. I assume you’re aware of
>>> possibilities like
>>>
>>> \paper {
>>>page-count = 2
>>>system-count = 10
>>>systems-per-page = 5
>>> }
>>>
>>> – your use case might take benefit from specifying _all three_ of these.
>>>
>> And this would gain me what? Loads of wasted white space? On a bandstand
>> that's probably not *too* bad, but I was recently playing and a single
>> sheet of A4 was a nightmare!
> 
> Look, I understood from your previous e-mails that your usecase
> sometimes requires fitting the music on exactly two pages of A5 so they
> may be used for marching. Is that correct?

Marching it has to be a single side of A5. Anything else is just
impractical (as I found out a week ago :-)

Playing on a bandstand, two sides of A4 is okay, three at a pinch (on
three sheets of paper stuck together!), and four is a real pain. I'd
rather cram it on to one, than spread it over two.

> If you face such a situation and Lily by default spaces the music out to
> three pages, you can specify page-count to force it on two pages. In
> such tight constraints, the spacing algorithms often produce better
> results if you also specify the total number of staves as well as the
> number of staves on each page. If you have trouble applying that to your
> real-world example, maybe try to understand it better by reading it up
> in the Notation Reference, or ask back with an actual example.

I've done that. Lily seems to be doing much better in that regard,
recently, but in my experience it often seems to give up with "no can
do" (as I say, recent experience is much better).
> 
>> Lilypond claims to be "a system for producing beautiful music". The
>> reality seems to be it's a system for producing standard orchestral
>> music. Fact is, there are a lot of traditions out there besides the
>> traditional western orchestra, and by default lilypond seems to have
>> great headaches handling what - to a lot of people - is perfectly normal
>> music typesetting.
>>
>> Take for instance marks! I can't remember why I had the four marks that
>> I mentioned earlier, but a large minority of the pieces I play will have
>> three - a rehearsal mark, a tempo mark, and a melody name. Oh - and
>> given that they typically go up to a rehearsal mark somewhere near S or
>> P, and I've known AA and beyond, I 

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[Simon Albrecht]

On 10.07.2017 15:41, Wols Lists wrote:

On 09/07/17 21:20, Simon Albrecht wrote:

On 09.07.2017 21:21, Wols Lists wrote:

Maybe, but placing all related marks one after the other is just as
semantically correct as placing them one on top of the other ...

That’s nonsense, and it is for the same reason that it’s not a trivial
decision to loosen horizontal alignment in general.

Why's it nonsense? "semantics" to me means "meaning", and if I see a
bunch of marks grouped together, they mean (to me at least) that they
all apply together. The fact that they are sequential rather than
stacked is irrelevant.


In tempo marks, horizontal position is related to semantics. If you 
place the tempo indication over a different moment, it means something 
different. What’s so hard to get about that? Or are you suggesting 
spreading the notes out by the entire width of the MetronomeMark? (I 
can’t think of tempo indications so short that this wouldn’t be ridiculous.)



If you shift a tempo indication a tiny bit to the side, it makes no difference. 
But if it’s a
slightly larger bit, such as the width of a quarter note, then the tempo
change applies to a different moment. And preservation of semantic
information (almost) always has to take precedence over elegant layout.


Finally, these two statements are contradictory:

  A real engraver who wanted to stick to those conventions would
  presumably shift the note to the right

  wasted white space is high on my list of priorities


How come? Shifting the notes to the right wastes maybe one note-width of
one stave. Stacking marks on top of each other wastes an entire line of
text - bad enough in portrait music but appalling in landscape (where
saving space tends to be extremely important - the music is only A5 to
start with!)

It’s obvious that your use case is special in its extremely tight
restrictions on paper size and page turns. So I’m afraid you have to
lower your expectations as to how well Lily will cope with that special
situation in difficult circumstances. I assume you’re aware of
possibilities like

\paper {
   page-count = 2
   system-count = 10
   systems-per-page = 5
}

– your use case might take benefit from specifying _all three_ of these.


And this would gain me what? Loads of wasted white space? On a bandstand
that's probably not *too* bad, but I was recently playing and a single
sheet of A4 was a nightmare!


Look, I understood from your previous e-mails that your usecase 
sometimes requires fitting the music on exactly two pages of A5 so they 
may be used for marching. Is that correct?
If you face such a situation and Lily by default spaces the music out to 
three pages, you can specify page-count to force it on two pages. In 
such tight constraints, the spacing algorithms often produce better 
results if you also specify the total number of staves as well as the 
number of staves on each page. If you have trouble applying that to your 
real-world example, maybe try to understand it better by reading it up 
in the Notation Reference, or ask back with an actual example.



Lilypond claims to be "a system for producing beautiful music". The
reality seems to be it's a system for producing standard orchestral
music. Fact is, there are a lot of traditions out there besides the
traditional western orchestra, and by default lilypond seems to have
great headaches handling what - to a lot of people - is perfectly normal
music typesetting.

Take for instance marks! I can't remember why I had the four marks that
I mentioned earlier, but a large minority of the pieces I play will have
three - a rehearsal mark, a tempo mark, and a melody name. Oh - and
given that they typically go up to a rehearsal mark somewhere near S or
P, and I've known AA and beyond, I don't think cramming them in to two
pages will work :-)

At the end of the day, people want to use lilypond to produce beautiful
music - like me! But to argue that the orchestral *tradition* is "the
final arbiter" of what is right or wrong is simply going to put peoples'
backs up.


How did I suggest that a certain tradition was the ‘final arbiter’? The 
final arbiter is always legibility, and it so happens that traditional 
engravers of orchestral parts have achieved a very high standard in 
legibility. Producing high-quality parts is difficult enough for an 
orchestral setting where parts are normally larger than A4, there is no 
wind, no rain, and page turns are possible at appropriate locations. I 
totally accept yours as a valid use case, and still you have to admit 
that the constraints you cite are making the task much more difficult.
You can only cram so much music on a page while keeping optimal 
legibility, and if you try to exceed that amount, Lily will choke. There 
are countless possibilities to deal with this situation, but no magical 
ones to solve all problems without drawbacks.



  Face it. I (and the OP) are trying to use lilypond. It's not
making our lives easy, because it 

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[Wols Lists]

On 10/07/17 14:58, Karlin High wrote:
> On 7/10/2017 8:41 AM, Wols Lists wrote:
>> given that they typically go up to a rehearsal mark somewhere near S or P, 
>> and I've known AA and beyond
> 
> This sounds like over 26 rehearsal marks. And elsewhere this thread says 
> the audience's ideal paper sizes are like A5 or half-letter? I have 
> trouble imagining. Or maybe those 2 conditions aren't often combined.

Sorry. Same musicians, different pieces :-)

But typical band/bandstand music. A5 for playing on the march, at most
two sides of A4 for playing on the bandstand. We do go to 3 or 4 on the
bandstand but it really isn't ideal ...

But it's band music, not orchestral.

Cheers,
Wol


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ChordMarkup context

[Kieren MacMillan]

Hi Matthew (et al.),

> My guess is that since chord names are most often used at all for things
> like popular songs, which are relatively short and may not contain a whole
> lot of other difficult engraving, this won't be prohibitive in practice.

Unfortunately, that won't help me in many of my use cases (e.g., 2-hour stage 
musicals or operas, using chord names throughout). Hopefully, this will add a 
minimal performance hit — Lilypond already takes a *long* time to compile my 
major scores.

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: Music fonts in local directory

[David Bellows]

> If your software is able to determine the lilypond installation directory it 
> could create the appropriate symlinks.

Is there a Lilypond command for that? I'm using OS system commands to
call Lilypond from inside my software so I could get that information
if that's the case.

> Apart from that I think I recall someone wrote you can add the font directory 
> to LilyPond's include path.

That would work nicely as well. Hopefully someone can give me a hint
about that as well.

On Sun, Jul 9, 2017 at 9:53 PM, Urs Liska  wrote:
>
>
> Am 10. Juli 2017 04:29:35 MESZ schrieb David Bellows :
>>I fear I already know the answer to this question but I thought I'd try
>>anyway.
>>
>>I have a project that generates music and sheet music using Lilypond.
>>I want to allow the user to use any music font they want (the free
>>music fonts). But I want to keep things as simple as possible. So I
>>don't want for them to have to figure out how to install the music
>>fonts into the standard places that Lilypond looks for them.
>>
>>Instead I'd love for them to be able to download my software and keep
>>those music fonts in a subdirectory of my project and for Lilypond to
>>be able to find them.
>>
>>I've experimented a lot with this and cannot get anything to work. And
>>based on what I've read I don't think it is possible, but I'm hoping
>>this isn't the case. I really don't want to have to deal with making
>>people install these fonts when it feels like I can just include them
>>with my project.
>>
>>Thanks,
>>Dave Bellows
>
> If your software is able to determine the lilypond installation directory it 
> could create the appropriate symlinks.
>
> Apart from that I think I recall someone wrote you can add the font directory 
> to LilyPond's include path.
>
> HTH
> Urs
>>
>>___
>>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: Music fonts in local directory

[David Bellows]

> Its relative path is "../share/lilypond/current/fonts/otf"
> Linux package maintainers may organize things differently, though.

So it sounds like, for now, at least, if I want to do this I would be
better off providing installation instructions for the fonts for the
various platforms (OSX, Windows, and Linux). Ugh. While I know where
to put the fonts in Linux, I'm not sure if I could come up with
general enough instructions for all Linux users and then Mac and
Windows users -- who knows?

Or does there already exist a set of instructions for this for all platforms?

Dave


On Mon, Jul 10, 2017 at 2:02 PM, Urs Liska  wrote:
> [CCing back to the list]
>
>
> Am 10.07.2017 um 22:02 schrieb David Bellows:
>>> If your software is able to determine the lilypond installation directory 
>>> it could create the appropriate symlinks.
>> Is there a Lilypond command for that?
>
> No.
>
>> I'm using OS system commands to
>> call Lilypond from inside my software so I could get that information
>> if that's the case.
>
> Well, that's what I would do. However, there are different ways how
> LilyPond is installed, depending on OS and method. With binary releases
> you can find the font directory from the executable. Its relative path
> is "../share/lilypond/current/fonts/otf"
> Linux package maintainers may organize things differently, though.
>
>>
>>> Apart from that I think I recall someone wrote you can add the font 
>>> directory to LilyPond's include path.
>> That would work nicely as well. Hopefully someone can give me a hint
>> about that as well.
>
> Hm, I just tested adding the folder to LilyPond's include path where the
> fonts are, and that did *not* work.
> So it seems my recollection was wrong ...
>
> Best
>
> Urs
>
>>
>> On Sun, Jul 9, 2017 at 9:53 PM, Urs Liska  wrote:
>>>
>>> Am 10. Juli 2017 04:29:35 MESZ schrieb David Bellows 
>>> :
 I fear I already know the answer to this question but I thought I'd try
 anyway.

 I have a project that generates music and sheet music using Lilypond.
 I want to allow the user to use any music font they want (the free
 music fonts). But I want to keep things as simple as possible. So I
 don't want for them to have to figure out how to install the music
 fonts into the standard places that Lilypond looks for them.

 Instead I'd love for them to be able to download my software and keep
 those music fonts in a subdirectory of my project and for Lilypond to
 be able to find them.

 I've experimented a lot with this and cannot get anything to work. And
 based on what I've read I don't think it is possible, but I'm hoping
 this isn't the case. I really don't want to have to deal with making
 people install these fonts when it feels like I can just include them
 with my project.

 Thanks,
 Dave Bellows
>>> If your software is able to determine the lilypond installation directory 
>>> it could create the appropriate symlinks.
>>>
>>> Apart from that I think I recall someone wrote you can add the font 
>>> directory to LilyPond's include path.
>>>
>>> HTH
>>> Urs
 ___
 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
>
> --
> u...@openlilylib.org
> https://openlilylib.org
> http://lilypondblog.org
>

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

How to make this postscript spanner to work with L bound-details?

[dtsmarin]

vibratospanner.ly
  

I want to be able to lengthen/shorten this spanner so that I can avoid
potential collisions. The left padding works perfectly  but the end of the
spanner doesn't respond to any kind of padding. It's too complicated for my
Scheme skills so I need your help. 

Thanks,
Dimitris



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-make-this-postscript-spanner-to-work-with-L-R-bound-details-tp204375.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:Place text next to rehearsal mark, or with left edge over barline if there is none

[Flaming Hakama by Elaine]

> >>> Since you want the tempo to appear over beat 2, you could try placing
> >>> the tempo there, rather than at the downbeat.
> >>>
> >>> Your desired solution is non-semantic, so it's coding will reflect
> that.
> >>>
> >> Maybe, but placing all related marks one after the other is just as
> >> semantically correct as placing them one on top of the other ...
> >
> > That’s nonsense, and it is for the same reason that it’s not a trivial
> > decision to loosen horizontal alignment in general.
>
> Why's it nonsense? "semantics" to me means "meaning", and if I see a
> bunch of marks grouped together, they mean (to me at least) that they
> all apply together. The fact that they are sequential rather than
> stacked is irrelevant.


You can say that, but then you have no way of notating a tempo change on
beat 2, since it would look identical to this.

Granted, that is probably unlikely in marching band music.  But, if you are
quibbling about semantics, that's the question that makes the point about
why the lily default is what is semantically correct.



> Take for instance marks! I can't remember why I had the four marks that
> I mentioned earlier, but a large minority of the pieces I play will have
> three - a rehearsal mark, a tempo mark, and a melody name.


Perhaps all that, plus a segno?  Or maybe a bag of chips?

Semantically, these are all marks except the tempo, so if you want the
marks in the same line:

\version "2.19.15"

\relative c' {
c1 1 1 \bar "||"
\mark \markup { \box "Trio" \bold \musicglyph #"scripts.segno"
"Curmudgeonly" }
c1 1 1 \bar "|."
}


So, the problem ends up being how do you want the tempo displayed on the
same line.

Clearly, for such extensive markup as is in the above example, there is no
reasonable way to also have a tempo also be on the same line, and all these
markings to be comprehended as being simultaneous.

So, you will have to determine where you actually want the tempo.  The
previous suggestion is still a reasonable approach: place it semantically
at the note above where you want it to appear.


For smaller collisions, I would suggest using right alignment of the mark.
This is a harsher version of your ideal, which is to nudge the mark to the
left a bit.

But if you are allergic to manual tweaks, this at least keeps everything
together, places the combined markup + tempo more or less centered, and
works the same every time.

As I'm sure you know, you can also use \once on the rehearsal mark
alignment command if you prefer left- or center-alignment everywhere else.


\version "2.19.15"

\relative c' {
c1 1 1 \bar "||"
\override Score.RehearsalMark.self-alignment-X = #RIGHT
\mark \markup \box "Trio"
\tempo 4=120
c1 1 1 \bar "|."
}



> Face it. I (and the OP) are trying to use lilypond. It's not
> making our lives easy, because it comes from a different tradition to
> us.


No, it is making your life easy since it allows you to engrave music.
What exactly are you comparing it to?  By hand, by Finale or Sibelius?




> And to claim that we're wrong because we're experienced musicians
> who've never seem music like you describe (and let's face it, I very
> rarely see music like you describe) doesn't make you look good.
>

I think many of us are familiar with lyre style layout.  It's just that
that is a very demanding format that is hard to read, and as such is not
the basis of the standards.  Standards are based on readability, not
page-turnability.

Your notion of "semantic" is largely irrelevant when you abandon semantics
to optimize for squeezing everything on one page, and move things to the
wrong places.

As I demonstrated above, you can easily put multiple marks horizontally
rather than vertically stacked.

You can either 1) treat the tempo as yet another mark and include it in the
markup queue,  2) code the tempo to the place in the score where you want
it to actually appear,  or 3) move the markup to accommodate the location
of the tempo.

You have at least 3 approaches that are both trivial to implement and get
you what you want.

That seems pretty easy and flexible to me.


HTH,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Music fonts in local directory

[Urs Liska]

Am 10.07.2017 um 23:34 schrieb David Bellows:
>> Its relative path is "../share/lilypond/current/fonts/otf"
>> Linux package maintainers may organize things differently, though.
> So it sounds like, for now, at least, if I want to do this I would be
> better off providing installation instructions for the fonts for the
> various platforms (OSX, Windows, and Linux). Ugh. While I know where
> to put the fonts in Linux, I'm not sure if I could come up with
> general enough instructions for all Linux users and then Mac and
> Windows users -- who knows?
>
> Or does there already exist a set of instructions for this for all platforms?f

Not that I know of.
But in your case I would suggest not to provide installation
*instructions* but installation *scripts* for the different platforms.

Best
Urs

>
> Dave
>
>
> On Mon, Jul 10, 2017 at 2:02 PM, Urs Liska  wrote:
>> [CCing back to the list]
>>
>>
>> Am 10.07.2017 um 22:02 schrieb David Bellows:
 If your software is able to determine the lilypond installation directory 
 it could create the appropriate symlinks.
>>> Is there a Lilypond command for that?
>> No.
>>
>>> I'm using OS system commands to
>>> call Lilypond from inside my software so I could get that information
>>> if that's the case.
>> Well, that's what I would do. However, there are different ways how
>> LilyPond is installed, depending on OS and method. With binary releases
>> you can find the font directory from the executable. Its relative path
>> is "../share/lilypond/current/fonts/otf"
>> Linux package maintainers may organize things differently, though.
>>
 Apart from that I think I recall someone wrote you can add the font 
 directory to LilyPond's include path.
>>> That would work nicely as well. Hopefully someone can give me a hint
>>> about that as well.
>> Hm, I just tested adding the folder to LilyPond's include path where the
>> fonts are, and that did *not* work.
>> So it seems my recollection was wrong ...
>>
>> Best
>>
>> Urs
>>
>>> On Sun, Jul 9, 2017 at 9:53 PM, Urs Liska  wrote:
 Am 10. Juli 2017 04:29:35 MESZ schrieb David Bellows 
 :
> I fear I already know the answer to this question but I thought I'd try
> anyway.
>
> I have a project that generates music and sheet music using Lilypond.
> I want to allow the user to use any music font they want (the free
> music fonts). But I want to keep things as simple as possible. So I
> don't want for them to have to figure out how to install the music
> fonts into the standard places that Lilypond looks for them.
>
> Instead I'd love for them to be able to download my software and keep
> those music fonts in a subdirectory of my project and for Lilypond to
> be able to find them.
>
> I've experimented a lot with this and cannot get anything to work. And
> based on what I've read I don't think it is possible, but I'm hoping
> this isn't the case. I really don't want to have to deal with making
> people install these fonts when it feels like I can just include them
> with my project.
>
> Thanks,
> Dave Bellows
 If your software is able to determine the lilypond installation directory 
 it could create the appropriate symlinks.

 Apart from that I think I recall someone wrote you can add the font 
 directory to LilyPond's include path.

 HTH
 Urs
> ___
> 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
>> --
>> u...@openlilylib.org
>> https://openlilylib.org
>> http://lilypondblog.org
>>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[Kieren MacMillan]

Hi Wol (et al.),

> No. I just view a markup block as exactly that - a block.

The problem is, given enough horizontal offset, eventually the reader can't 
tell what's part of the original block and what's a new chunk [based over a new 
moment]. Vertical stacking doesn't have that potential ambiguity.

> a tempo mark always belongs *after* a rehearsal mark if they collide

In my opinion, a tempo mark belongs exactly over the moment it affects, and all 
other marks need to move (horizontally, vertically, or both) around it.

> tempi and tune names should work well together with rehearsal marks.

Agreed.

> It just seems to me that whenever I need them together
> I end up fighting lily to get a good-looking solution

You could write a [single] function which gracefully handles all possible 
combinations, according to your preference(s)…  =)

> Yes, I know, I'm a grumpy old man :-)

Well, then… there's that.  ;)

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: Music fonts in local directory

[Urs Liska]

[CCing back to the list]


Am 10.07.2017 um 22:02 schrieb David Bellows:
>> If your software is able to determine the lilypond installation directory it 
>> could create the appropriate symlinks.
> Is there a Lilypond command for that? 

No.

> I'm using OS system commands to
> call Lilypond from inside my software so I could get that information
> if that's the case.

Well, that's what I would do. However, there are different ways how
LilyPond is installed, depending on OS and method. With binary releases
you can find the font directory from the executable. Its relative path
is "../share/lilypond/current/fonts/otf"
Linux package maintainers may organize things differently, though.

>
>> Apart from that I think I recall someone wrote you can add the font 
>> directory to LilyPond's include path.
> That would work nicely as well. Hopefully someone can give me a hint
> about that as well.

Hm, I just tested adding the folder to LilyPond's include path where the
fonts are, and that did *not* work.
So it seems my recollection was wrong ...

Best

Urs

>
> On Sun, Jul 9, 2017 at 9:53 PM, Urs Liska  wrote:
>>
>> Am 10. Juli 2017 04:29:35 MESZ schrieb David Bellows :
>>> I fear I already know the answer to this question but I thought I'd try
>>> anyway.
>>>
>>> I have a project that generates music and sheet music using Lilypond.
>>> I want to allow the user to use any music font they want (the free
>>> music fonts). But I want to keep things as simple as possible. So I
>>> don't want for them to have to figure out how to install the music
>>> fonts into the standard places that Lilypond looks for them.
>>>
>>> Instead I'd love for them to be able to download my software and keep
>>> those music fonts in a subdirectory of my project and for Lilypond to
>>> be able to find them.
>>>
>>> I've experimented a lot with this and cannot get anything to work. And
>>> based on what I've read I don't think it is possible, but I'm hoping
>>> this isn't the case. I really don't want to have to deal with making
>>> people install these fonts when it feels like I can just include them
>>> with my project.
>>>
>>> Thanks,
>>> Dave Bellows
>> If your software is able to determine the lilypond installation directory it 
>> could create the appropriate symlinks.
>>
>> Apart from that I think I recall someone wrote you can add the font 
>> directory to LilyPond's include path.
>>
>> HTH
>> Urs
>>> ___
>>> 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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Can't use edition engraver to place \time and \tempo

[caagr98]

After some research, it seems edition engraver only _pretends_ to insert 
arbitrary objects - it actually only supports a select few types of 
objects. Not including \tempo and \time. \time can be worked around 
rather easily (see snippet below), but for \tempo, it seems I'd have to 
modify the source code. I guess I'll try to do that, and then maybe do a 
pull request if it works.


```
timeEdit =
#(define-music-function
   (beat-structure fraction) ((number-list? '()) fraction?)
   (make-sequential-music
 ((assoc-get 'elements-callback
(assoc-get 'TimeSignatureMusic
   music-descriptions))
  (time beat-structure fraction
```

On 07/10/2017 12:49 AM, caag...@gmail.com wrote:
I'd expect the two scores created by this to be identical, but the 
second one only has the \key applied (other stuff such as \bar and <>^"" 
works too), not the \time or \tempo. What am I doing wrong?


Also, it seems only the fourth argument is used for selecting editions 
(with \editionID); what's the first argument for?


```
\version "2.19.63"
\include "edition-engraver/edition-engraver.ily"

\consistToContexts #edition-engraver Score.Staff.Voice
\addEdition time
\editionMod time 1 0/0 E.Staff \key g \major
\editionMod time 1 0/0 E.Score \time 4/4
\editionMod time 1 0/0 E.Score \tempo "Some text" 4=120
\editionMod time 2 0/0 E.Score \time 2/4
\editionMod time 3 0/0 E.Score \time 4/4

\book {
   \score { \new Staff <<
 { b'1 2 1 }
 { \key g \major \time 4/4 \tempo "Some text" 4=120 s1 \time 2/4 s2 
\time 4/4 s1}

   >> }
   \score {
 \new Staff { b'1 2 1 }
 \layout {
   \context {
 \Score
 \editionID E
   }
 }
   }
}
```


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Broken (?) snippets in openlilylib/snippets

[Urs Liska]

Am 08.07.2017 um 20:21 schrieb Paul:
>
> On 07/08/2017 02:03 PM, Paul wrote:
>
>> This fixes the snippet on LilyPond 2.19.41 (The most recent I have
>> installed.)
>
> Just installed LilyPond 2.19.63 and my fixed vertical spacing snippet
> works fine with it. 
>
> I realized that you (Urs) may have another approach in mind for
> detecting lilypond versions...  I don't really use OLL as a whole...
> so my previous email just had a fix for the standalone file for this
> snippet...
>

Thanks.
I took this as an opportunity to fix the broken handling of version
predicates in the snippets repo.

Now the "old" OLL functions (lilypond-greater-than? etc.) and the
backported ly:version? are present in
general-tools/lilypond-version-predicates. Both work, but the old ones
produce a warning.

I've updated your snippet, and made it a module in

https://github.com/openlilylib/snippets/commit/bf7e829077d707da89e3d9eec0fd36817ce17bfb
https://github.com/openlilylib/snippets/commit/1ed2958b04ea75177c30d7146a65f6d458fe52a5
https://github.com/openlilylib/snippets/commit/ee2e83c423edeb64a7e387388a772a9052756af9

Best
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Can't use edition engraver to place \time and \tempo

[Jan-Peter Voigt]

Hi there,

yes the edition-engraver does not able to insert time and tempo. I 
decided not to include \time, because it would mess with the timing and 
therefore with addressing elements in time. \tempo is just not 
implemented (yet). So if you can provide a reasonable pull request I 
will be happy to merge!
About the \time thing: It should be possible to integrate it, but it 
stays problematic for the mentioned reasons. Perhaps warning messages 
are sufficient while allowing \time for edition-mods.


Jan-Peter

Am 10.07.2017 um 13:03 schrieb caag...@gmail.com:
After some research, it seems edition engraver only _pretends_ to insert 
arbitrary objects - it actually only supports a select few types of 
objects. Not including \tempo and \time. \time can be worked around 
rather easily (see snippet below), but for \tempo, it seems I'd have to 
modify the source code. I guess I'll try to do that, and then maybe do a 
pull request if it works.


```
timeEdit =
#(define-music-function
(beat-structure fraction) ((number-list? '()) fraction?)
(make-sequential-music
  ((assoc-get 'elements-callback
 (assoc-get 'TimeSignatureMusic
music-descriptions))
   (time beat-structure fraction
```

On 07/10/2017 12:49 AM, caag...@gmail.com wrote:
I'd expect the two scores created by this to be identical, but the 
second one only has the \key applied (other stuff such as \bar and 
<>^"" works too), not the \time or \tempo. What am I doing wrong?


Also, it seems only the fourth argument is used for selecting editions 
(with \editionID); what's the first argument for?


```
\version "2.19.63"
\include "edition-engraver/edition-engraver.ily"

\consistToContexts #edition-engraver Score.Staff.Voice
\addEdition time
\editionMod time 1 0/0 E.Staff \key g \major
\editionMod time 1 0/0 E.Score \time 4/4
\editionMod time 1 0/0 E.Score \tempo "Some text" 4=120
\editionMod time 2 0/0 E.Score \time 2/4
\editionMod time 3 0/0 E.Score \time 4/4

\book {
   \score { \new Staff <<
 { b'1 2 1 }
 { \key g \major \time 4/4 \tempo "Some text" 4=120 s1 \time 2/4 
s2 \time 4/4 s1}

   >> }
   \score {
 \new Staff { b'1 2 1 }
 \layout {
   \context {
 \Score
 \editionID E
   }
 }
   }
}
```


___
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

align-lyrics-on-vowels Re: Broken (?) snippets in openlilylib/snippets

[Urs Liska]

I should have looked somewhat more closely at the output:

Am 06.07.2017 um 18:17 schrieb Urs Liska:
> * notation-snippets/align-lyrics-on-vowels
>   (warning: ignored infinite X-offset)

fails with the following message:

lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/skyline.cc:198
<19>: void Skyline::normalize(): Assertion `buildings_.front ().start_
== -infinity_f' failed.

Exited with return code 6.


which is somewhat strange as I ran LilyPond 2.19.60 from a binary release.

Any further ideas?
How is this related to any other current development with lyrics?

Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Can't use edition engraver to place \time and \tempo

[caagr98]

I didn't notice any timing problems with \time. Of course, if you use it 
to add a time signature somewhere weird it gets broken, but that happens 
with inserting random time signatures in the source as well. If used 
responsibly, it works fine.


My \tempo patch seems to work (needs some more testing first). Shouldn't 
be too hard to make one for \time, I hope.


Oh, and another thing - it seems EE creates its own grobs for 
TextScripts and Marks in process-music, rather than handing them to the 
proper engraver in start-translation-timestep. This makes tweaks and 
other custom properties not work, let alone if you install a custom 
engraver for them. Moving their handling to start-translation-timestep 
seems to work fine, so why is it that way? (It does have the advantage 
of allowing multiple \marks at once, though.) TextScripts also don't 
work in the first measure if it's a MMR, which is weird. (Placing an 
empty chord before the MMR makes it work.)


I'm all for having a way to manually place texts/marks, but I personally 
think using the default method should be the, well, default. Changing it 
could break existing projects that rely on that behavior, though, which 
is bad.


On 07/10/2017 01:38 PM, Jan-Peter Voigt wrote:

Hi there,

yes the edition-engraver does not able to insert time and tempo. I 
decided not to include \time, because it would mess with the timing and 
therefore with addressing elements in time. \tempo is just not 
implemented (yet). So if you can provide a reasonable pull request I 
will be happy to merge!
About the \time thing: It should be possible to integrate it, but it 
stays problematic for the mentioned reasons. Perhaps warning messages 
are sufficient while allowing \time for edition-mods.


Jan-Peter

___
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: Broken (?) snippets in openlilylib/snippets

[Urs Liska]

Am 06.07.2017 um 20:37 schrieb Graham King:
> On Thu, 2017-07-06 at 18:17 +0200, Urs Liska wrote:
>> Hi all,
>>
>> I'm wrapping up a number of things in openLilyLib, and I came across
>> snippets where the example files don't compile (with LilyPond 2.19.60).
>> Please go through this list and if you feel responsible for the snippet
>> please have a look:
>>
>> * notation-snippets/blackmensural-notation
> This one is just a copy of Lukas Pietch's code from January 2011 that I
> was trying to get to work with a recent lilypond.  The files have been
> completely superseded by Lukas' more recent work and may safely be
> deleted.
>
> Alas, the more recent version doesn't work either (there is a missing
> file).  Full details at
> https://lists.gnu.org/archive/html/lilypond-user/2016-05/msg00212.html

Sorry, I'm not really sure what to think of these two seemingly
contradictory statements. Is it now working *anywhere*? Can I remove the
snippet from the repository?
What exactly should I do?

Urs

>
> -- Graham
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Broken (?) snippets in openlilylib/snippets

[Graham King]

On Mon, 2017-07-10 at 14:02 +0200, Urs Liska wrote:
> 
> Am 06.07.2017 um 20:37 schrieb Graham King:
> > On Thu, 2017-07-06 at 18:17 +0200, Urs Liska wrote:
> >> Hi all,
> >>
> >> I'm wrapping up a number of things in openLilyLib, and I came across
> >> snippets where the example files don't compile (with LilyPond 2.19.60).
> >> Please go through this list and if you feel responsible for the snippet
> >> please have a look:
> >>
> >> * notation-snippets/blackmensural-notation
> > This one is just a copy of Lukas Pietch's code from January 2011 that I
> > was trying to get to work with a recent lilypond.  The files have been
> > completely superseded by Lukas' more recent work and may safely be
> > deleted.
> >
> > Alas, the more recent version doesn't work either (there is a missing
> > file).  Full details at
> > https://lists.gnu.org/archive/html/lilypond-user/2016-05/msg00212.html
> 
> Sorry, I'm not really sure what to think of these two seemingly
> contradictory statements. Is it now working *anywhere*? Can I remove the
> snippet from the repository?
> What exactly should I do?

Sorry if I was unclear.

The snippet in your repository should be removed, in my opinion.  

For lilypond-user's information only: There is a more recent version, at
a URL in the message to which I referred; however, until we
find/re-invent its missing file, I don't see any point in including it
in openlilylib.  

-- Graham



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A contribution (was Re: snippet to properly align dynamics with expressive text)

[Urs Liska]

Am 08.07.2017 um 16:58 schrieb Simon Albrecht:
> On 08.07.2017 15:49, Richard Shann wrote:
>> I was intrigued by this, as I have a patch to the figured bass formatter
>> that has been hanging around because the route to making contributions
>> that I knew about involved a virtual machine which I can't get working
>> on my current system.
>
> The method Urs named is possible with openLilyLib, but not with the
> LilyPond source.  That
> means you would have to get a VM to work, or install a Unix system in
> parallel – both a lot of
> effort for one small patch obviously.  Or you just e-mail your patch
> to the devel list and ask for
> someone to shepherd it through the review process and into the code
> base for you, which is done
> from time to time.
>
> Best, Simon

I have to add something here.

Simon is correct that I described a method for openLilyLib, not
LilyPond. The Github copy of the LilyPond code is not up-to-date and is
basically a mirror that *can* at any time made ready for people to
contribute with a lower entry barrier than setting up a developer
account on LilyPond's proper repository.
However, this would still require a developer *with* such an account to
process a patch, i.e. pull it to his local machine and upload it to
LilyPond as a patch for review. So nothing would be won with that for
your use-case, Richard.

HOWEVER:
Linux (i.e. for you, a virtual machine) is required for BUILDING
LilyPond, not actually for contributing. If you don't have that you by
definition can't do any modifications that require building LilyPond but
you can only work on the LilyPond and Scheme files.

What you need for contributing, i.e. sending patches into the review
line and eventually the code base is:

* Git
* git-cl
(http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl)
* Accounts on the sourceforge tracker and the savannah git repository

git-cl is a Python script, so that should be possible to install on any
computer.
So essentially, if you are planning to contribute .scm or .ly files only
(and as you don't have a build system I assume this is the case) I'm
sure you can set up a proper contribution toolchain on your OS of choice.

Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A contribution (was Re: snippet to properly align dynamics with expressive text)

[Richard Shann]

On Mon, 2017-07-10 at 08:44 +0200, Urs Liska wrote:
> 
> Am 08.07.2017 um 16:58 schrieb Simon Albrecht:
> > On 08.07.2017 15:49, Richard Shann wrote:
> >> I was intrigued by this, as I have a patch to the figured bass formatter
> >> that has been hanging around because the route to making contributions
> >> that I knew about involved a virtual machine which I can't get working
> >> on my current system.
> >
> > The method Urs named is possible with openLilyLib, but not with the
> > LilyPond source.  That
> > means you would have to get a VM to work, or install a Unix system in
> > parallel – both a lot of
> > effort for one small patch obviously.  Or you just e-mail your patch
> > to the devel list and ask for
> > someone to shepherd it through the review process and into the code
> > base for you, which is done
> > from time to time.
> >
> > Best, Simon
> 
> I have to add something here.
> 
> Simon is correct that I described a method for openLilyLib, not
> LilyPond. The Github copy of the LilyPond code is not up-to-date and is
> basically a mirror that *can* at any time made ready for people to
> contribute with a lower entry barrier than setting up a developer
> account on LilyPond's proper repository.
> However, this would still require a developer *with* such an account to
> process a patch, i.e. pull it to his local machine and upload it to
> LilyPond as a patch for review. So nothing would be won with that for
> your use-case, Richard.
> 
> HOWEVER:
> Linux (i.e. for you, a virtual machine) is required for BUILDING
> LilyPond, not actually for contributing. If you don't have that you by
> definition can't do any modifications that require building LilyPond but
> you can only work on the LilyPond and Scheme files.
> 
> What you need for contributing, i.e. sending patches into the review
> line and eventually the code base is:
> 
> * Git
> * git-cl
> (http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl)
> * Accounts on the sourceforge tracker and the savannah git repository
> 
> git-cl is a Python script, so that should be possible to install on any
> computer.
> So essentially, if you are planning to contribute .scm or .ly files only
> (and as you don't have a build system I assume this is the case) I'm
> sure you can set up a proper contribution toolchain on your OS of choice.
> 
> Urs

Thanks for this - very clear.

Richard




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[Wols Lists]

On 09/07/17 21:20, Simon Albrecht wrote:
> On 09.07.2017 21:21, Wols Lists wrote:
>> On 09/07/17 20:06, Flaming Hakama by Elaine wrote:
>>>  > How can I move the texts to be next to the rehearsal mark
>>> (without
>>>  manual adjustments)?
>>>
>>> Well, you are asking for a manual change (due to a non-standard
>>> placement of tempo), so please expect all solutions will necessarily be
>>> manual.
>>>
>>> Since you want the tempo to appear over beat 2, you could try placing
>>> the tempo there, rather than at the downbeat.
>>>
>>> Your desired solution is non-semantic, so it's coding will reflect that.
>>>
>> Maybe, but placing all related marks one after the other is just as
>> semantically correct as placing them one on top of the other ...
> 
> That’s nonsense, and it is for the same reason that it’s not a trivial
> decision to loosen horizontal alignment in general.

Why's it nonsense? "semantics" to me means "meaning", and if I see a
bunch of marks grouped together, they mean (to me at least) that they
all apply together. The fact that they are sequential rather than
stacked is irrelevant.

 If you shift a tempo
> indication a tiny bit to the side, it makes no difference. But if it’s a
> slightly larger bit, such as the width of a quarter note, then the tempo
> change applies to a different moment. And preservation of semantic
> information (almost) always has to take precedence over elegant layout.
> 
>>> Finally, these two statements are contradictory:
>>>
>>>  A real engraver who wanted to stick to those conventions would
>>>  presumably shift the note to the right
>>>
>>>  wasted white space is high on my list of priorities
>>>
>> How come? Shifting the notes to the right wastes maybe one note-width of
>> one stave. Stacking marks on top of each other wastes an entire line of
>> text - bad enough in portrait music but appalling in landscape (where
>> saving space tends to be extremely important - the music is only A5 to
>> start with!)
> 
> It’s obvious that your use case is special in its extremely tight
> restrictions on paper size and page turns. So I’m afraid you have to
> lower your expectations as to how well Lily will cope with that special
> situation in difficult circumstances. I assume you’re aware of
> possibilities like
> 
> \paper {
>   page-count = 2
>   system-count = 10
>   systems-per-page = 5
> }
> 
> – your use case might take benefit from specifying _all three_ of these.
> 
And this would gain me what? Loads of wasted white space? On a bandstand
that's probably not *too* bad, but I was recently playing and a single
sheet of A4 was a nightmare!

Lilypond claims to be "a system for producing beautiful music". The
reality seems to be it's a system for producing standard orchestral
music. Fact is, there are a lot of traditions out there besides the
traditional western orchestra, and by default lilypond seems to have
great headaches handling what - to a lot of people - is perfectly normal
music typesetting.

Take for instance marks! I can't remember why I had the four marks that
I mentioned earlier, but a large minority of the pieces I play will have
three - a rehearsal mark, a tempo mark, and a melody name. Oh - and
given that they typically go up to a rehearsal mark somewhere near S or
P, and I've known AA and beyond, I don't think cramming them in to two
pages will work :-)

At the end of the day, people want to use lilypond to produce beautiful
music - like me! But to argue that the orchestral *tradition* is "the
final arbiter" of what is right or wrong is simply going to put peoples'
backs up. Face it. I (and the OP) are trying to use lilypond. It's not
making our lives easy, because it comes from a different tradition to
us. And to claim that we're wrong because we're experienced musicians
who've never seem music like you describe (and let's face it, I very
rarely see music like you describe) doesn't make you look good.

Different traditions, different expectations. I know lilypond is a
tricky tool if you don't work with its assumptions. But don't tell us
we're wrong just because we're different.

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[Wols Lists]

On 10/07/17 14:28, Karlin High wrote:
> On 7/9/2017 2:16 PM, Wols Lists wrote:
>> But out in the park, it was hard to stop the music blowing everywhere

> That DOES sound like a problem. I've read of people using electronic 
> displays such as tablets or e-readers for displaying sheet music. 
> Ideally, page turns could be accomplished in one tap of the screen, or 
> even by foot pedals. Example here, GVIDO e-ink sheet music reader from 
> Japan: http://www.gvido.tokyo/ Looks good to me, even if the English 
> website needs translation help some places. And I'm sure there would be 
> technical concerns and device costs to consider - like $1,600 USD 
> multiplied by number of band members? Ouch.

Have you ever tried reading a mobile phone in bright sunlight :-)

(Yes I know you can apparently get screens that aren't hard ...)

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Can't use edition engraver to place \time and \tempo

[Jan-Peter Voigt]

thank you for your messages!

Am 10.07.2017 um 14:33 schrieb caag...@gmail.com:
I didn't notice any timing problems with \time. Of course, if you use it 
to add a time signature somewhere weird it gets broken, but that happens 
with inserting random time signatures in the source as well. If used 
responsibly, it works fine.
... using it responsibly is fine, but I'd like to prevent the novice 
from doing it wrong and not knowing why. A change from 3/4 to 6/8 (for 
example) would not harm anything. So if you provide a PR, I'll have a look.


My \tempo patch seems to work (needs some more testing first). Shouldn't 
be too hard to make one for \time, I hope.

great :-)

Oh, and another thing - it seems EE creates its own grobs for 
TextScripts and Marks in process-music, rather than handing them to the 
proper engraver in start-translation-timestep. This makes tweaks and 
other custom properties not work, let alone if you install a custom 
engraver for them. Moving their handling to start-translation-timestep 
seems to work fine, so why is it that way? (It does have the advantage 
of allowing multiple \marks at once, though.) TextScripts also don't 
work in the first measure if it's a MMR, which is weird. (Placing an 
empty chord before the MMR makes it work.)
This is how I started to implement it. For my own scores it shouldn't be 
a problem to change it. The recent additions - I will push dynamics, 
slurs and beams to another branch in a few minutes - are using broadcast 
event, which might be used for marks and text-scripts as well.


I'm all for having a way to manually place texts/marks, but I personally 
think using the default method should be the, well, default. Changing it 
could break existing projects that rely on that behavior, though, which 
is bad.
again: this is for historical reasons. It should and will be changed - 
carefully, not to break existing scores.


Jan-Peter



On 07/10/2017 01:38 PM, Jan-Peter Voigt wrote:

Hi there,

yes the edition-engraver does not able to insert time and tempo. I 
decided not to include \time, because it would mess with the timing 
and therefore with addressing elements in time. \tempo is just not 
implemented (yet). So if you can provide a reasonable pull request I 
will be happy to merge!
About the \time thing: It should be possible to integrate it, but it 
stays problematic for the mentioned reasons. Perhaps warning messages 
are sufficient while allowing \time for edition-mods.


Jan-Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Place text next to rehearsal mark, or with left edge over barline if there is none

[caagr98]

E-ink displays are supposed to be just like normal paper, aren't they?

On 07/10/2017 03:43 PM, Wols Lists wrote:

On 10/07/17 14:28, Karlin High wrote:

On 7/9/2017 2:16 PM, Wols Lists wrote:

But out in the park, it was hard to stop the music blowing everywhere



That DOES sound like a problem. I've read of people using electronic
displays such as tablets or e-readers for displaying sheet music.
Ideally, page turns could be accomplished in one tap of the screen, or
even by foot pedals. Example here, GVIDO e-ink sheet music reader from
Japan: http://www.gvido.tokyo/ Looks good to me, even if the English
website needs translation help some places. And I'm sure there would be
technical concerns and device costs to consider - like $1,600 USD
multiplied by number of band members? Ouch.


Have you ever tried reading a mobile phone in bright sunlight :-)

(Yes I know you can apparently get screens that aren't hard ...)

Cheers,
Wol

___
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