Cynthia Karl | 1 Feb 03:15 2015
Picon

Re: 2.19.15 slur accidental collision (Paul Scott)


> Message: 2
> Date: Sat, 31 Jan 2015 13:31:14 -0700
> From: Paul Scott <waterhorse <at> ultrasw.com>
> To: lilypond-user <at> gnu.org
> Subject: 2.19.15 slur accidental collision
> Message-ID: <20150131203114.GA12158 <at> joy3>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> I am trying to make a slur not collide with an accidental.  Reading the 
> Learning Manual I find how to do:
> 
>  \override Slur.avoid-slur = #'inside
> or
>  \override Accidental.avoid-slur = #'inside
> which doesn't seem to do the job.
> 
>> From the LM and the IR I don't follow how to set a value for 
> accidental-collision.  Using the LyricText example I thought that 
> 
>  \override Slur.accidental-collision = #20 
> would work but that gets an warning:
> 
> warning: cannot find property type-check for `accidental-collision' (backend-type?).  perhaps a
typing error?
> 
> \version "2.19.15"
> 
(Continue reading)

Urs Liska | 1 Feb 00:41 2015

Naming convention brainstorming

Hi all,

for quite some time now I've been using a concept that is very useful, 
but finally I'd like to give it an authoritative name to be used in 
different places.

I'm talking about the working, thinking and compiling mode when I'm 
working on the _content_ of a score and not it's final visual 
appearance. This mode is characterized for example by
- not caring too much about layout
- not caring too much about engraving quality
- being interested in visual feedback about manual interventions
   (e.g. coloring annotations or the result of custom functions)

Originally we talked about it as "draft mode" but this doesn't seem to 
hit the spot. Nor do "devel mode" or "preview mode".

I would really like to find the right term now because I want to make 
that kind of an authoritative term for a configuration option in a 
redesigned openLilyLib and sort of a general library specification in 
that context. There should be a common configuration option that library 
authors can (and are encouraged to) respect in their functions. Say I 
have a library function "\crossVoiceTie" that does all the work for me 
with a hidden voice etc. Then this should highlight that tie or the 
hidden noteheads when that special mode is active.
This approach has proven extremely useful and I'd be happy to promote 
this as a more general best-practice.

So what are your feelings about this mode of working *before* finishing 
an engraving to publication quality?
(Continue reading)

Paul Scott | 31 Jan 21:31 2015

2.19.15 slur accidental collision

Hi,

I am trying to make a slur not collide with an accidental.  Reading the 
Learning Manual I find how to do:

  \override Slur.avoid-slur = #'inside
or
  \override Accidental.avoid-slur = #'inside
which doesn't seem to do the job.

From the LM and the IR I don't follow how to set a value for 
accidental-collision.  Using the LyricText example I thought that 

  \override Slur.accidental-collision = #20 
would work but that gets an warning:

warning: cannot find property type-check for `accidental-collision' (backend-type?).  perhaps a
typing error?

\version "2.19.15"

\relative{
  \override Slur.avoid-slur = #'inside
  \override Accidental.avoid-slur = #'inside
  \override Slur.accidental-collision = #20 
  \override Accidental.accidental-collision = #20 
  f'8( bes4)
}

TIA for any help with this,
(Continue reading)

Villum Sejersen | 31 Jan 18:31 2015
Picon

Absolute grob offset

Hello

You run an extremely high risk not getting one single useful answer, not 
telling anything whatsoever about the context of your question.

Is it something you can't find in the documentation or is it for use in 
compilng a score?

In the latter case, provide a minimal example, please.

And always, with what lilypond version? Sometimes it also helps when 
answering, knowing the computewrs' operating system and version.

--

-- 
med venlig hilsen
Villum Sejersen
Nørregade  1 A
DK-4500  Nykøbing Sjælland
mobil   +45   30 34  03 44

_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Stephen MacNeil | 31 Jan 18:22 2015
Picon

#(set-global-staff-size 40)

I would like to increase the staff however when i change  

#(set-global-staff-size 40)

my tagline gets bigger. How can i overcome this?


thanks

_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Picon

Absolute grob offset

I'm trying to get current offset in resulting document, in inches.

Is there any way to obtain it?

Thanks.
Urs Liska | 30 Jan 23:05 2015

Re: ScholarLY - introduction and call for collaboration

Hi Craig,

Am 30.01.2015 um 17:59 schrieb Craig Dabelstein:
Urs,

Here is a zip of the complete project.

Thank you, this was indeed instructive (and a nice score BTW).

There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue.

Each annotation is generated multiple times - once for each time you included annotate.ily.
So you should only include it once, which is what I would have recommended anyway.

Usually I have a set-up along these lines:

One main-init.ily file with global definitions and includes that apply for any file in the project.

Two files like score-init.ily and part-init.ily.
These include main-init.ily and add specific settings to score or part compilation

The score file includes score-init.ily and each part file includes part-init.ily

This way everything is only included once, and can also be modified in one single place.

###
However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on "my" side.

It seems each time you include annotate.ily you create a new instance of the engraver.
I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled.
So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times.

If you carefully inspect the console output you will notice that the output file is rewritten multiple times too.
Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting).
This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times.

As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place.

Thanks for reporting
Best
Urs




On Fri Jan 30 2015 at 11:26:57 PM Urs Liska <ul <at> openlilylib.org> wrote:

Am 30.01.2015 um 08:16 schrieb Urs Liska:

Am 30.01.2015 um 08:13 schrieb Philippe Massart:
Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs
These are based on the sample file included :

Ah, OK.
I see the offending LaTeX code, but I'll have to look into the reason why this is generated.
The #f in the first line of the .inp file is the result of exporting something that evaluates to false.

Urs


It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned "#f".

Pushed a fix, should work now.
Thanks for the report.

Best

Urs
_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Philippe Massart | 30 Jan 21:50 2015
Picon

Rep: ScholarLY - introduction and call for collaboration



It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned "#f".

Pushed a fix, should work now.
Thanks for the report.

Best
Urs

Thanks :-)

I still have an issue on the example file, on the custom annotation, with this message:

./annotate.annotations.inp:15: Undefined control sequence.
<argument> See \textbackslash what is \possible 
                                                [opts]{args}
l.15     {custom-annotation}


Something else I noted: the lilypond code in the custom annotation is transformed into a <LilyPond Music> tag in the .inp file. Is that normal?

Philippe

_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Peter Gentry | 30 Jan 21:27 2015
Picon

Where are Lilypond Scheme functions documented?


>Date: Thu, 29 Jan 2015 22:16:12 +0100
>From: "anders <at> andis59.se" <anders <at> andis59.se>
>To: lilypond-user <lilypond-user <at> gnu.org>
>Subject: Where are Lilypond Scheme functions documented?
>Message-ID: <54CAA31C.1060704 <at> andis59.se>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
Have a look at music-scheme.cc in the Lily source files

LY_DEFINE (ly_music_property, "ly:music-property",
           2, 1, 0, (SCM mus, SCM sym, SCM val),
           "Return the value for property  <at> var{sym} of music expression"
           "  <at> var{mus}.  If no value is found, return  <at> var{val} or"
           "  <at> code{'()} if  <at> var{val} is not specified.")

HTH but don't ask me to explain it!

Peter G
David Sumbler | 30 Jan 20:45 2015
Picon

Re: Key signature and key cancellation need to be aligned

> From: Thomas Morley <thomasmorley65 <at> gmail.com>
> To: David Sumbler <david <at> aeolia.co.uk>
> Cc: lilypond-user <lilypond-user <at> gnu.org>
> Subject: Re: Key signature and key cancellation need to be aligned
> Date: Thu, 29 Jan 2015 11:21:15 +0100
> 
> 2015-01-28 19:00 GMT+01:00 David Sumbler <david <at> aeolia.co.uk>:
> >> 2015-01-27 12:56 GMT+01:00 David Sumbler <david <at> aeolia.co.uk>:
> >> > I use Staff.printKeyCancellation = ##f in my score.
> >> >
> >> > At one point the key changes from C major (concert) to C minor.  As the
> >> > piece is for a standard saxophone quartet, this means that 2 of the
> >> > instruments change from D major (notated) to D minor, and the other 2
> >> > change from A major to A minor.
> >> >
> >> > A minor, of course, is the "open" key with no sharps or flats, and,
> >> > notwithstanding the negation of printKeyCancellation, Lilypond correctly
> >> > prints a key cancellation at this point on the 2 staves that require it.
> >> >
> >> > The other 2 parts, in which the key changes from 2 sharps to 1 flat,
> >> > correctly do not get a key cancellation.
> >> >
> >> > So far, so good.
> >> >
> >> > The problem is that the actual key signatures on the 2 staves that have
> >> > them are not vertically aligned with the key cancellations on the other
> >> > 2 staves.  Instead, they are printed after the key cancellations.  In
> >> > other words, each of the 2 key signatures is printed as if there were an
> >> > invisible key cancellation preceding it on the stave.  This looks wrong,
> >> > and I should like them to appear above and below the actual key
> >> > cancellations on the other 2 staves.
> >> >
> >> > I have experimented with changing KeySignature.X-offset (which had no
> >> > effect) and KeySignature.extra-offset.  The latter works, but
> >> > unfortunately the position of the time signature and music which follow
> >> > remain unchanged, so that there is now an unnecessary gap after the key
> >> > signatures/cancellations.
> >> >
> >> > How can I get the effect I want, and get Lilypond to take account of the
> >> > change in the position of the key signatures?
> >> >
> >> > David
> >>
> >>
> >> Hi David,
> >>
> >> how about a minimal example?
> >>
> >> -Harm
> >
> > Here we are, then: the following illustrates the problem.
> >
> > \version "2.18.0"
> > \language "english"
> >
> > \new StaffGroup <<
> >     \new Staff \relative c'' {
> >         \transposition bf
> >         \time 3/4
> >         \key d \major
> >         a2 r4 |
> >         \key d \minor
> >         \time 2/4
> >         R2 |
> >     }
> >     \new Staff \relative c'' {
> >         \transposition ef
> >         \time 3/4
> >         \key a \major
> >         gs2 r4 |
> >         \key a \minor
> >         \time 2/4
> >         R2 |
> >     }
> >>>
> >
> > \layout {
> >     \context {
> >         \Staff printKeyCancellation = ##f
> >     }
> > }
> >
> > I have had 2 very interesting responses to my query, one from Thomas
> > Morley and one (off-list) from Kevin Barry.  Both had slight problems
> > with them, and experimenting with them has once again helped
> > considerably in improving my understanding of the workings of Lilypond.
> >
> > Thomas suggested adding
> >
> >     \once \override Score.KeyCancellation.space-alist.key-signature = #'(extra-space . -2.4)
> >     \once \override Score.KeySignature.space-alist.time-signature = #'(extra-space . 2.6)
> >
> > The only problem was this was that, although it solved the problem in the score,
> > it introduced a problem in the parts for the instruments with an actual
> > key signature.  I could get around this by using tags, of course.
> >
> > Kevin's suggestion, which, after modification, was the one I ultimately
> > used, was to omit '\key a \minor' and to add:
> >
> >     \override Staff.KeyCancellation.stencil = ##f
> >     \set Staff.keySignature = #`((10 . ,NATURAL) (7 . ,NATURAL) (11 . ,NATURAL))
> >
> > This worked well, except that the dummy key signature with natural
> > signs then appeared on every subsequent line.  My final solution is:
> >
> >     \override Staff.KeyCancellation.stencil = ##f
> >     \override Staff.KeySignature.break-visibility = #all-invisible
> >     \set Staff.keySignature = #`((10 . ,NATURAL) (7 . ,NATURAL) (11 . ,NATURAL))
> >
> > Then, immediately before the next key change:
> >
> >     \revert Staff.KeySignature.break-visibility
> >
> > Thank you both for your help.
> >
> > David
> >
> 
> Did you notice Keith reply?
> The mentioned workaround is in comment #2
> http://code.google.com/p/lilypond/issues/detail?id=448#c2
> 
> Cheers,
>   Harm

I confess that I failed to spot the workaround when I looked at the page
before: it is so concise that it's easy to miss (that's my feeble
excuse, anyway).

The workaround adversely affects the parts (the problem only exists in
the score), but was easily solved with a tag, of course.  So I now have 

\tag #'forScore { \once \override Staff.KeyCancellation #'X-extent = #'(0 . 0) }

Neat!

Thanks to all

David
Pierre Perol-Schneider | 30 Jan 12:18 2015
Picon

Re: Hungarian Gregorian

Dear Sister Judit,
Dear All,

I slightly changed the snippet for a much easier typesetting; See: http://lsr.di.unimi.it/LSR/Item?id=973
Now you can include a "modernGregorian.ily" file and simply code like:
...

d d d \melisma { f g \lst a } \orn #1 g g \melisma { g a \lst c' } 

...


Some issues still remain, such as:

- it does not handle midi output

- ledger lines causes disgraced offsets (but can be solved by easy 'extra-offset' workarounds)


Cheers,
Pierre



2015-01-29 21:06 GMT+01:00 Rita Composer <ritacomposer <at> gmail.com>:
Thank you!

Much better! :-)

Sister Judit

 

_______________________________________________
lilypond-user mailing list
lilypond-user <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Gmane