glissando or something similar in drummmode

[Mason Hock]

I'm working on a percussion piece in which the performers play, in addition to 
unpitched percussion instruments, roto toms, which they occasionally play with 
one hand while adjusting the pitch of the other in order to achieve a glissando 
effect. Only the direction, maxima, and minima of the glissando is important, 
not the specific pitch at a given moment, so when this effect is used the 
performers would prefer to switch from a 5-line percussion staff to a 1-line 
staff indicating the rhythm and drawing the glissando direction.

Below is what I have so far. I'm happy with the transition to a 1-line staff 
and the notation of rhythm with headless stems, but the gliss line does not 
render. It makes sense that the gliss line would not render; since this is a 
DrumStaff the notes do not represent pitches, making a glissando meaningless. 
However, I do want to use a DrumStaff for the upitched passages, and I'm not 
sure how to turn DrumStaff into a Staff in the middle of the music.

Can anyone suggest (a) a better approach than what I'm trying or (b) a hack to 
make the glissando engraver draw glissandi between noteheads that Lilypond does 
not think represent pitches?

Thanks,

Mason 


\version "2.19.82"

drumPitchNames.cy = #'cymbal
drumPitchNames.br = #'brakedrum
drumPitchNames.to = #'tom
drumPitchNames.ro = #'rototom
drumPitchNames.rt = #'rototomtop
drumPitchNames.ba = #'bassdrum
drumPitchNames.ta = #'tamtam

#(define drumstaff
  '((cymbal xcircle #f   3)
(brakedrum  cross   #f   1)
(tomdefault #f  -1)
(rototomdefault #f   0)
(rototomtop default #f   4)
(timpanidefault #f  -4)
(bassdrum   default #f  -3)
(tamtam harmonic-mixed  #f  -3)))

rotogliss = {
  \stopStaff
  \override Staff.StaffSymbol.line-positions = #'(0)
  \startStaff
}

normalstaff = {
  \stopStaff
  \revert Staff.StaffSymbol.line-positions
  \startStaff
}

glon = {
  \override NoteColumn.glissando-skip = ##t
  \hide NoteHead
}

gloff = {
  \revert NoteColumn.glissando-skip
  \undo \hide NoteHead
}

notes = \drummode {
  ba4 r   |
  to16 to to to 8  ro ro ro ro |
  \rotogliss
  ro \glissando \glon ro ro ro ro ro ro ro |
  \gloff rt16 rt rt rt rt8 \glissando \glon ro ro ro ro ro |
  ro ro ro ro \gloff \normalstaff ro ro ro ro |

}

\score {
   \new DrumStaff
\with {
  drumStyleTable = #(alist->hash-table drumstaff)
}
\notes
  \layout {}
}



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

Re: Repeat question

[David Wright]

[I haven't reattached the images.]

On Tue 26 Jun 2018 at 18:22:00 (+0200), Jacques Menu Muzhic wrote:
> Hello David & Torsten,
> 
> The snippet file in my OP is actually a shortened version of a file contained 
> in the LilyPond Unofficial Test Suite.

Which version?

> 
> Adding the missing 
> 
> MuseScore 2.1.0 ignores , hence the quarter notes, but is otherwise 
> OK:

Could you give us the sequence of notes that this score represents.
I get as far as:

c' d' (1st ending)
c' e' f' g' (2nd ending, then a :| missing)
c' a' b' c'' d'' e'' (3rd ending's 1st ending)
c' a' b' c'' d'' (3rd ending's… ) f'' (2nd ending? "5"?)
c' (whither now?)

> Finale 2014 is OK, and I discovered on this occasion that the alternative 
> lines with 2 hooks, one a each end, are in fact two superposed lines, each 
> one with a hook at one end. Moving them apart give:

Should we have more colours? Which hook closes which volta?

> musicxml2ly does not do a good job in that case on alternatives 2 et 3:

What defines a good job? I assume I could replicate the MuseScore 2.1.0
with LP by using a few Score.repeatCommands (though I don't feel I'll
learn anything in the attempt) but in order to get useful LP code, one
has to decide what the score's semantics are. For me, duplicating the
notational syntax is a waste of time.

> Interesting!

Knowing little about XML, let alone MusicXML, I don't know how much of
the semantics of repeats can be expressed and enforced.

> Le 26 juin 2018 à 15:41, David Wright  a écrit :

[one spurious quote marker removed]

> > On Mon 25 Jun 2018 at 12:34:13 (-0700), Torsten Hämmerle wrote:
> >> Ok, when looking at the XML data, I'll have to admit that Finale, Musescore
> >> and Sibelius (just tested it) are closer to the XML reality, whereas
> >> LilyPond fills in missing parts.
> > 
> > I'd agree, and would say that the XML is simply malformed, so the
> > musicxml2ly program is trying to correct it. AFAICT the output is
> > consistent with prioritising the earliest elements encountered in
> > the source, ie the volta brackets.
> > 
> >> Import into Sibelius:
> >>  
> >> 
> >> But I think there's a 
> >>
> >> missing in the XML file at the end of measure 2 (within )
> >> 
> >> If you insert this, the missing repeat barline between the volta brackets
> >> will even show up in Finale/Sibelius/MuseScore. ;)

I didn't understand that then, and I don't now. Your .xml file posted
here seemed to have a whole ending (numbered 8) added to it.

> > But if you insert a :| at the end of bar 2, then the bar sequence
> > played becomes 1 2 1 3 1 4, so bar 4 still needs an open-ended
> > volta |¯¯ marked with 3 for third time (open-ended, assuming that
> > the single bar 4 is a placeholder for a passage of music).

Cheers,
David.

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

Re: Reusability of lilypond code?

[Mason Hock]

On 06/27, Ben wrote:
> Mason,
> 
> Does that mean for every piece of yours you have separate dynamic contexts
> for every single instrument? I'd imagine that could possibly clutter up your
> score a bit, no?
> 
> To have many dynamic context variables mapped to all their appropriate
> instruments, just curious how you manage it all? Do you only pick a few
> dynamic contexts for main instruments, or really all?
> 
> Interested to hear more :)

I try to avoid clutter by breaking my project into many .ily files, each either 
containing one kind of information or fulfilling one role in piecing together 
the project. For example, each instrument has one file containing all of its 
notes and one file containing all of its dynamics. These files are included in 
another file defining that instrument's staff, which looks like this:

---
\new Staff { \include "../music/instrument-name/notes.ily" }
\new Dynamics \with {
  \override VerticalAxisGroup.staff-affinity = #UP 
} { \include "../music/instrument-name/dynamics.ily" }
---

This file is in turn included in another file that puts together that 
instrument's part, like this: 

---
\score {
  <<
\include "../staves/instrument.ily"
  >>
  \layout {}
}
---

as well as the file that puts together the score, which contains something like 
this:

---
\score {
  <<
\include "../staves/instrument.ily"
\include "../staves/another-instrument.ily"
\include "../staves/a-third-instrument.ily"
\include "../staves/etc.ily"
  >>
  \layout {}
}
---

As an example of how I organize all this, here's the project setup for the 
piece I'm about to start engraving: 
https://notabug.org/chaosmonk/untouchable-space

This isn't the final setup. I'll make the score and part generation more 
modular and give instruments edition-mods.ily files once all the notes are in 
and I start tweaking and creating editions for different paper/tablet sizes.

I'd be interested to hear about other approaches. How do you normally manage 
your projects with respect to dynamics and in general?


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

Re: \bookparts and scaling

[crimsonsunrise]

 Mensagem Original 
Ativo 27 de jun de 2018 18:43, Flaming Hakama by Elaine escreveu:

Subject: Re: \bookparts and scaling

Hi, Torsten!

On Wed, Jun 27, 2018 at 2:49 AM, Torsten Hämmerle  wrote:

Hi Ralph,

I'm neither Crimson nor Sunrise, but I guess having both full score and
parts together in one PDF is quite a common requirement.

Using smaller print for the full score but using larger print for the parts
while keeping up natural spacing is not easy to achieve in LilyPond, because
set-global-staff-size only works for whole books, i.e. separate output
files.

Here's a minimal example (without any attempt do alter score sizes yet) as a
working basis for the implementation of different approaches:

%%

\version "2.19.81"

#(set-default-paper-size "a6")

fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }

\bookpart {
  \header { instrument = "Full Score" }
  \score {
\new StaffGroup   \new Staff \with { instrumentName = "Fl. 1" } \fluteI
  \new Staff \with { instrumentName = "Fl. 2" } \fluteII
>>
  }
}

\bookpart {
  \header { instrument = "Flute 1" }
  \score {
\new Staff \fluteI
  }
}

\bookpart {
  \header { instrument = "Flute 2" }
  \score {
\new Staff \fluteII
  }
}

%%

First, there is the full score, containing Flute 1 and Flute 2.
This full score should use smaller print, cf. #(set-global-staff-size 10) in
a \book.
The parts, however, should look as if printed with #(set-global-staff-size
20).
And all within one single PDF.

These extreme differences should make spacing problems obvious.

How do you (to the list in general) handle such a case without using
external PDF postprocessing programs?
I'm usually working around the problem by using (at least) two PDF files -
one for the full score and one (or even individual files) for the parts -
for several reasons.

%{

I'm sure there are some many imperfections with using magnifyStaff, but it is 
pretty easy to use and gets you within the ballpark:

%}

\version "2.19.81"

#(set-default-paper-size "a6")

fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }

fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }

\bookpart {

  \header { instrument = "Full Score" }

  \score {

\new StaffGroup
  \new Staff \with {

instrumentName = "Fl. 1"

\magnifyStaff #1/2

  } \fluteI

  \new Staff \with {

instrumentName = "Fl. 2"

\magnifyStaff #1/2

  } \fluteII

>>

  }

}

\bookpart {

  \header { instrument = "Flute 1" }

  \score {

\new Staff \fluteI

  }

}

\bookpart {

  \header { instrument = "Flute 2" }

  \score {

\new Staff \fluteII

  }

}

Elaine Alt

415 . 341 .4954   "Confusion is highly 
underrated"

ela...@flaminghakama.com

Producer ~ Composer ~ Instrumentalist

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 It could help if we knew what #(set-global-staff-size) does exactly. It's not 
in the manual or at least I couldn't find it.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: music-function name shadowing a Scheme keyword

[Flaming Hakama by Elaine]

> Subject: Re: music-function name shadowing a Scheme keyword
> Am 27.06.2018 um 11:15 schrieb Urs Liska:
> >
> >
> > Am 27.06.2018 um 11:09 schrieb Urs Liska:
> >> Hi Jan-Peter,
> >>
> >>
> >> Am 27.06.2018 um 10:48 schrieb Jan-Peter Voigt:
> >>> Hi Urs,
> >>>
> >>> you might import the SRFI-1 span-function and give that a new name.
> >>> The counterpart-function to span is break, which "conflicts with the
> >>> break binding established by while (see while do). Applications
> >>> wanting to use break from within a while loop will need to make a new
> >>> define under a different name."
> >>> You might provide such an alternative name for "span".
> >>>
> >>> Personally I'd prefer another name for your function, because
> >>> srfi-1-span is "prior art" ;-)
> >>> and *now* you can give it a name that does not conflict.
> >>>
> >>
> >> Hm, I was afraid of that comment. I agree that asking users using my
> >> module to change any occurence of "span" to
> >> "span-saved-from-openlilylib" is no viable option ...
> >>
> >> However, what *would* be a suitable name, then? \span is just perfect.
> >> \markup would be good, or \tag, but of course ...
> >
> >   * \class ("\class new" as shorthand for ) (maybe
> > also too generic?)
> >   * \tagSpan
> >   * \markupSpan
> >
> > ?
> Yes, class is quite generic. I don't know, if it conflicts.
> IMO \tagSpan is a viable name.
>

+1

Or, along the same lines, since it creates a element in the DOM (Document
Object Model), and since "tag" already has an LP-specific meaning,

\domSpan


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

Re:\bookparts and scaling

[Flaming Hakama by Elaine]

> Subject: Re: \bookparts and scaling
> Hi, Torsten!
>
> On Wed, Jun 27, 2018 at 2:49 AM, Torsten Hämmerle <
> torsten.haemme...@web.de> wrote:
>
>> Hi Ralph,
>>
>> I'm neither Crimson nor Sunrise, but I guess having both full score and
>> parts together in one PDF is quite a common requirement.
>>
>> Using smaller print for the full score but using larger print for the
>> parts
>> while keeping up natural spacing is not easy to achieve in LilyPond,
>> because
>> set-global-staff-size only works for whole books, i.e. separate output
>> files.
>>
>>
>> Here's a minimal example (without any attempt do alter score sizes yet)
>> as a
>> working basis for the implementation of different approaches:
>>
>>
>> %%
>>
>> \version "2.19.81"
>>
>> #(set-default-paper-size "a6")
>>
>> fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
>> fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }
>>
>> \bookpart {
>>   \header { instrument = "Full Score" }
>>   \score {
>> \new StaffGroup <<
>>   \new Staff \with { instrumentName = "Fl. 1" } \fluteI
>>   \new Staff \with { instrumentName = "Fl. 2" } \fluteII
>> >>
>>   }
>> }
>>
>> \bookpart {
>>   \header { instrument = "Flute 1" }
>>   \score {
>> \new Staff \fluteI
>>   }
>> }
>>
>> \bookpart {
>>   \header { instrument = "Flute 2" }
>>   \score {
>> \new Staff \fluteII
>>   }
>> }
>>
>> %%
>>
>>
>> First, there is the full score, containing Flute 1 and Flute 2.
>> This full score should use smaller print, cf. #(set-global-staff-size 10)
>> in
>> a \book.
>> The parts, however, should look as if printed with #(set-global-staff-size
>> 20).
>> And all within one single PDF.
>>
>> These extreme differences should make spacing problems obvious.
>>
>> How do you (to the list in general) handle such a case without using
>> external PDF postprocessing programs?
>> I'm usually working around the problem by using (at least) two PDF files -
>> one for the full score and one (or even individual files) for the parts -
>> for several reasons.
>>
>

%{

I'm sure there are some many imperfections with using magnifyStaff, but it
is pretty easy to use and gets you within the ballpark:

%}

\version "2.19.81"

#(set-default-paper-size "a6")

fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }

\bookpart {
  \header { instrument = "Full Score" }
  \score {
\new StaffGroup <<
  \new Staff \with {
instrumentName = "Fl. 1"
\magnifyStaff #1/2
  } \fluteI
  \new Staff \with {
instrumentName = "Fl. 2"
\magnifyStaff #1/2
  } \fluteII
>>
  }
}

\bookpart {
  \header { instrument = "Flute 1" }
  \score {
\new Staff \fluteI
  }
}

\bookpart {
  \header { instrument = "Flute 2" }
  \score {
\new Staff \fluteII
  }
}



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

Re: scheme with Frescobaldi

[David Kastrup]

Aaron Hill  writes:

> On 2018-06-27 08:14, Simon Albrecht wrote:
>> On 26.06.2018 03:02, Aaron Hill wrote:
>>> Here is the reference on `let` for Guile:
>>>
>>> https://www.gnu.org/software/guile/manual/html_node/Local-Bindings.html#Local-Bindings
>>
>> I guess for the time being we should stick with the Guile 1.8 manual:
>> 
>
> Ah, sorry about that.  The new docs are always what shows up in a web
> search, and I forgot to manually adjust for the older version of Guile
> that LilyPond uses.  That said, I doubt the concept of `let` has
> changed all that much since 1958.  ;)

Since 1958, named let has been added.  Also let* and letrec .

-- 
David Kastrup

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

Re: scheme with Frescobaldi

[Aaron Hill]

On 2018-06-27 08:14, Simon Albrecht wrote:

On 26.06.2018 03:02, Aaron Hill wrote:

Here is the reference on `let` for Guile:

https://www.gnu.org/software/guile/manual/html_node/Local-Bindings.html#Local-Bindings


I guess for the time being we should stick with the Guile 1.8 manual:



Ah, sorry about that.  The new docs are always what shows up in a web 
search, and I forgot to manually adjust for the older version of Guile 
that LilyPond uses.  That said, I doubt the concept of `let` has changed 
all that much since 1958.  ;)


-- Aaron Hill

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

My finances.

[David Kastrup]

Hi folks,

I've been afraid of looking at my bank account for the past months but
finally had to do so.  For the last three months, the payments from
LilyPond users were stable: one paying €100 monthly, one paying €75
monthly, one paying €10 monthly.  Thanks, you know who you are (I hope).

When adding in the payments arriving via Paypal, I am at about €200 per
month.  Which doesn't pay for a whole lot of bills in Germany.

Now obviously I am not currently providing a whole lot of value in
return but at least enough that we will hopefully be seeing a reasonably
tolerable stable version 2.20 soonish and it's not like I have nothing
to do with it, either.  And it's not like when I wasn't yet hampered as
absolutely by the blood pressure medication until skipping it gave me a
stroke and not burned out as much that I earned as much as a software
developer of my productivity then.  Or even as much as a janitor.

I'll go looking for a menial minimum wage job soonish where I don't need
to be creative on command.  In the meantime, try thinking about whether
my contributions to what LilyPond is have been of value to you.  And if
they were, consider giving some back.  And if you can't think of
anything better than money, that's ok with me too.

All the best

David

-- 
David Kastrup

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

Re: Reusability of lilypond code?

[Ben]

On 6/27/2018 1:20 PM, Mason Hock wrote:

On 06/27, lyuser.theg...@spamgourmet.com wrote:

But I have one issue with the reuse of my work. My last score e.g. has
four voices (T1, T2, B1, B2). I assign music and lyrics for each voice
to a variable and combine them info a choir staff. So for our
rehearsal, everybody can see all the voices.

There are other usecases, where I would like to have only one
voice per staff. I can do that with lilypond, of course, by reusing
the variables that I created before.

Now comes the problem:

For the "one voice per staff" solution (and for midi files, by the
way), the single voices have to be annotated with all "bells and
whistles", like dynamics, for example.

But for the "four voices per staff", all the annotations would pile
up (one 'p' above the other 'p' for the two tenor voices, for example)
and with all the duplicated dynamic, hairpins, markup, the score would
become unreadable.

I typically use a separate Dynamics staff, which can then be attached once to 
any music staff as appropriate. This will also align dynamics vertically, which 
is my preference. Notice that in the third example the p is not aligned with 
the other dynamics.

-
\version "2.19.82"

notesA = \relative c' {
   a'2. a4 | a
}

notesB = \relative c' {
   d2. d4 | a
}

dynamics = {
   s2\fp\< s4 s\f s\p
}

notesBdynamics = \relative c' {
   d2.\fp\< d4\f a\p
}

\score {
   <<
 \new Staff \notesA
 \new Dynamics \with {
   \override VerticalAxisGroup.staff-affinity = #UP
 } \dynamics
 \new Staff \notesB
 \new Dynamics \with {
   \override VerticalAxisGroup.staff-affinity = #UP
 } \dynamics
   >>
   \layout { }
}

\score {
   <<
 \new Staff \partcombine \notesA \notesB
 \new Dynamics \with {
   \override VerticalAxisGroup.staff-affinity = #UP
 } \dynamics
   >>
   \layout { }
}

\score {
   <<
 \new Staff \notesBdynamics
   >>
   \layout { }
}
-


Mason,

Does that mean for every piece of yours you have separate dynamic 
contexts for every single instrument? I'd imagine that could possibly 
clutter up your score a bit, no?


To have many dynamic context variables mapped to all their appropriate 
instruments, just curious how you manage it all? Do you only pick a few 
dynamic contexts for main instruments, or really all?


Interested to hear more :)


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

Re: Reusability of lilypond code?

[Mason Hock]

On 06/27, lyuser.theg...@spamgourmet.com wrote:
> But I have one issue with the reuse of my work. My last score e.g. has
> four voices (T1, T2, B1, B2). I assign music and lyrics for each voice
> to a variable and combine them info a choir staff. So for our
> rehearsal, everybody can see all the voices.
> 
> There are other usecases, where I would like to have only one
> voice per staff. I can do that with lilypond, of course, by reusing
> the variables that I created before.
> 
> Now comes the problem:
> 
> For the "one voice per staff" solution (and for midi files, by the
> way), the single voices have to be annotated with all "bells and
> whistles", like dynamics, for example.
> 
> But for the "four voices per staff", all the annotations would pile
> up (one 'p' above the other 'p' for the two tenor voices, for example)
> and with all the duplicated dynamic, hairpins, markup, the score would
> become unreadable.

I typically use a separate Dynamics staff, which can then be attached once to 
any music staff as appropriate. This will also align dynamics vertically, which 
is my preference. Notice that in the third example the p is not aligned with 
the other dynamics.

-
\version "2.19.82"

notesA = \relative c' {
  a'2. a4 | a
}

notesB = \relative c' {
  d2. d4 | a
}

dynamics = {
  s2\fp\< s4 s\f s\p
}

notesBdynamics = \relative c' {
  d2.\fp\< d4\f a\p
}

\score {
  <<
\new Staff \notesA
\new Dynamics \with {
  \override VerticalAxisGroup.staff-affinity = #UP 
} \dynamics
\new Staff \notesB
\new Dynamics \with {
  \override VerticalAxisGroup.staff-affinity = #UP 
} \dynamics
  >>
  \layout { }
}

\score {
  <<
\new Staff \partcombine \notesA \notesB
\new Dynamics \with {
  \override VerticalAxisGroup.staff-affinity = #UP 
} \dynamics
  >>
  \layout { }
}

\score {
  <<
\new Staff \notesBdynamics
  >>
  \layout { }
}
-


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

Re: scheme with Frescobaldi

[Simon Albrecht]

On 26.06.2018 03:02, Aaron Hill wrote:

Here is the reference on `let` for Guile:

https://www.gnu.org/software/guile/manual/html_node/Local-Bindings.html#Local-Bindings


I guess for the time being we should stick with the Guile 1.8 manual:


Best, Simon

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

Re: Accidental style in presence of mid-bar line breaks.

[Simon Albrecht]

On 26.06.2018 09:11, Richard Shann wrote:

In this connection, I noticed that LilyPond skips printing the bar
number at the beginning of each line if the bar is being split over a
line.


That’s configurable:

%%%
\version "2.19.80"

\layout {
  \context {
    \Score
    barNumberVisibility = #(every-nth-bar-number-visible 1)
    \override BarNumber.break-visibility = #begin-of-line-visible
  }
}

{
  1 2 \bar "" \break 2
}
%%%

Best, Simon

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

Re: openLilyLib

[Karlin High]

On 6/27/2018 8:30 AM, Urs Liska wrote:
Right now I'm writing a manual for the package I've started to write, 
but I'm not fully sure yet if that's the right way forward. I'm writing 
in Markdown and use Pandoc (with lyluatex) to produce a PDF from it. One 
thing I'm missing is a proper way to generate an HTML site from that 
(for example to have online documentation on openlilylib.org) -- which 
Pandoc should in principle support.


In a past discussion here, ReadTheDocs was mentioned.



No experience with it. But it does claim to produce multiple formats 
including PDF and HTML websites. Also claims integration with Git and 
other version control systems. Native format is Sphinx reStructuredText, 
what the Python documentation uses. But it has some support for Markdown.




Google found another project that uses Markdown and Pandoc with 
ReadTheDocs. This is from 2016:



--
Karlin High
Missouri, USA

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

Re: openLilyLib

[Urs Liska]

Am 27.06.2018 um 14:16 schrieb Jan-Peter Voigt:

Hi Urs, Aaron,

Am 27.06.2018 um 08:35 schrieb Urs Liska:

Hi Aaron,

thank you for the interest in openLilyLib.



> ...
>
pre-alpha state, which does explain things. 


Unfortunately this is true, and basically because the project didn't 
really gain traction. Progress is usually been made when someone has 
a reason to contribute something, usually a package or some 
functionality for a package. In many cases that someone is me, but 
there are a few major contributors to different packages.
Wait a second ... oll-core with its package management is working very 
well so what are the issues preventing from naming the core a RC? or 
at least beta?


Essentially the lack of documentation.

The great thing about it is that anything is modularized so any 
package or module that is not in that state should be marked alpha. 
But the core? AFAICS a desired feature list naming all the core 
elements already available is missing to name it beta. Then a testing 
phase would make it a RC and then stable.


What is missing is a "community" with the intent of bringing 
openLilyLib into a more generally usable state. Which is a pity 
because I'm convinced it is a very useful toolkit worth of being more 
widely known and used.
I believe it very important to name it something more then pre-alpha. 
I know Its a bit funny if I say so, because I didn't promote my work 
that way ... but! Few people want to be beta-tester so it should be 
called "use it! here's how to install"


I would have done that for ages if there were a proper installation 
manual and overview documents for the different packages.


Right now I'm writing a manual for the package I've started to write, 
but I'm not fully sure yet if that's the right way forward. I'm writing 
in Markdown and use Pandoc (with lyluatex) to produce a PDF from it. One 
thing I'm missing is a proper way to generate an HTML site from that 
(for example to have online documentation on openlilylib.org) -- which 
Pandoc should in principle support. The other issue is that this is 
totally independent from the actual code, so anything (and especially 
any updates) has to be documented *manually*. Which seems risky to me, 
since there is no formal review process in place like with LilyPond that 
makes it less likely to add functionality without documentation.




Documentation would be a good start with this - unfortunately at the 
same time a vital goal, a vicious circle ...

+1

> ...

The newer one is the "package" system, which essentially means that 
after \include "oll-core/package.ily" further package and/or modules 
can be loaded through \loadPackage and \loadModule. (BTW: this 
ensures that modules are parsed only once ...This is IMO a very 
usable infrastructure. The thing is that installing a 
package means `git clone https://`. That is easy if you 
are familiar with git, but it may disturb users that are not. So a 
package-manager that installs packages would be great thing to help 
those who are not familiar with git. But this is for now just an idea.


Actually Sharon Rosner has written such a package manager. But for some 
irrational reason I haven't followed up on that, maybe because he 
decided to add yet another language (Ruby) to the ecosystem, maybe 
because (IIUC) that requires adapting an OLL package to the package 
manager. But what that project promised (and kept?) to solve is handling 
transitive version dependencies (i.e. when package A depends on package 
B >= 0.6 load that package version, and at least determine impossible 
cross-dependencies).


Another idea I had already started on is adding openLilyLib support to 
Frescobaldi. As a first step I wanted to have a tool that shows all 
available package and their metadata, then I wanted to be able to 
download and install packages.
Once all that would be in place there would be the basis to add user 
interface elements, the first and foremost being an annotation 
browser/editor so you can click on an item and enter an annotation right 
through a pop-up dialog.


I'm not really sure about that whole project since Wilbert (rightfully) 
wants to keep Frescobaldi focused on its core concerns (editing LilyPond 
input files), and supporting stuff that requires external libraries is 
somewhat detrimental to that idea.
OTOH I think that there are many things that Frescobaldi could actually 
use as editing features (for example: switching between different sets 
of line/page breaks), and it would be comparably simple to make such 
functionality only available when openLilyLib is "installed".
Well, I don't have the time to go further on that so for now this 
question isn't really one ...


Best
Urs



What services does oll-core provide to packages/modules?  Basically, 
if I were to come up with an idea for an extension to LilyPond, how 
would I best evaluate whether openLilyLib would make a good platform 
on which to build and how would I go about integrating it?

Re: \bookparts and scaling

[crimsonsunrise]

 Mensagem Original 
Ativo 27 de jun de 2018 05:49, Torsten Hämmerle escreveu:

Hi Ralph,

I'm neither Crimson nor Sunrise, but I guess having both full score and
parts together in one PDF is quite a common requirement.

Using smaller print for the full score but using larger print for the parts
while keeping up natural spacing is not easy to achieve in LilyPond, because
set-global-staff-size only works for whole books, i.e. separate output
files.

Here's a minimal example (without any attempt do alter score sizes yet) as a
working basis for the implementation of different approaches:

%%

\version "2.19.81"

#(set-default-paper-size "a6")

fluteI = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }

\bookpart {
\header { instrument = "Full Score" }
\score {
\new StaffGroup \new Staff \with { instrumentName = "Fl. 1" } \fluteI
\new Staff \with { instrumentName = "Fl. 2" } \fluteII
>>
}
}

\bookpart {
\header { instrument = "Flute 1" }
\score {
\new Staff \fluteI
}
}

\bookpart {
\header { instrument = "Flute 2" }
\score {
\new Staff \fluteII
}
}

%%

First, there is the full score, containing Flute 1 and Flute 2.
This full score should use smaller print, cf. #(set-global-staff-size 10) in
a \book.
The parts, however, should look as if printed with #(set-global-staff-size
20).
And all within one single PDF.

These extreme differences should make spacing problems obvious.

How do you (to the list in general) handle such a case without using
external PDF postprocessing programs?
I'm usually working around the problem by using (at least) two PDF files -
one for the full score and one (or even individual files) for the parts -
for several reasons.

All the best,
Torsten

==

It's also suggested by the manual that #(set-global-staff-size) is limited in 
scope by the \book block. However, if you encase the book part inside one, as 
to limit where the function will scale, Lilypond flat out ignores it or uses 
the scaling setting of the same function if it exists outside the block.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \bookparts and scaling

[Abraham Lee]

Hi, Torsten!

On Wed, Jun 27, 2018 at 2:49 AM, Torsten Hämmerle 
wrote:

> Hi Ralph,
>
> I'm neither Crimson nor Sunrise, but I guess having both full score and
> parts together in one PDF is quite a common requirement.
>
> Using smaller print for the full score but using larger print for the parts
> while keeping up natural spacing is not easy to achieve in LilyPond,
> because
> set-global-staff-size only works for whole books, i.e. separate output
> files.
>
>
> Here's a minimal example (without any attempt do alter score sizes yet) as
> a
> working basis for the implementation of different approaches:
>
>
> %%
>
> \version "2.19.81"
>
> #(set-default-paper-size "a6")
>
> fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
> fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }
>
> \bookpart {
>   \header { instrument = "Full Score" }
>   \score {
> \new StaffGroup <<
>   \new Staff \with { instrumentName = "Fl. 1" } \fluteI
>   \new Staff \with { instrumentName = "Fl. 2" } \fluteII
> >>
>   }
> }
>
> \bookpart {
>   \header { instrument = "Flute 1" }
>   \score {
> \new Staff \fluteI
>   }
> }
>
> \bookpart {
>   \header { instrument = "Flute 2" }
>   \score {
> \new Staff \fluteII
>   }
> }
>
> %%
>
>
> First, there is the full score, containing Flute 1 and Flute 2.
> This full score should use smaller print, cf. #(set-global-staff-size 10)
> in
> a \book.
> The parts, however, should look as if printed with #(set-global-staff-size
> 20).
> And all within one single PDF.
>
> These extreme differences should make spacing problems obvious.
>
> How do you (to the list in general) handle such a case without using
> external PDF postprocessing programs?
> I'm usually working around the problem by using (at least) two PDF files -
> one for the full score and one (or even individual files) for the parts -
> for several reasons.
>

I can see reasons for wanting to do separate PDF files for this, and I've
done it many times myself, but I also have wished the mechanics for this
were better handled for varied staff sizes within a single \book. If I
could voice my deepest desire for this, it would be that it would have
configurable scope all the way down at the \score level, so that each
\score can have its own nominal/global size that is user-settable, and then
allow the individual staves can resize themselves around that if desired. I
can see plenty of reasons why the engraver might want that nominal size to
be different from one \score to the next. Worst case, it would be nice to
have it settable at the \bookpart level so that examples like yours can be
handled the way you describe while taking advantage of \book level
logistics like page numbering, table of contents, etc.

My two cents.

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

Re: music-function name shadowing a Scheme keyword

[Urs Liska]

Am 27.06.2018 um 14:51 schrieb David Kastrup:

Andrew Bernard  writes:


Hi Urs,

It's not a Scheme language keyword, but a procedure name from SRFI-1.

(srfi srfi-1) is loaded and imported into the parser by default.


which makes it not a real Scheme keyword but from the perspective of my 
question I should treat it like one ...


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

Re: scheme with Frescobaldi

[Freeman Gilmore]

​

On Wed, Jun 27, 2018 at 2:39 AM, Urs Liska  wrote:

[And please allow me a plug: you may find rewarding to have a look at
https://scheme-book.ursliska.de, which is far from complete but aims at
giving a slow-paced and detailed introduction specifically from a LilyPond
perspective]


> ​This is what I have been looking for.   Is there a PDF?​
>
>
>
> No, and currently my (Gitbook) build system is broken, so I can't even
> upload updates. But the content is available in a bunch of Markdown files,
> and I'd be ready to move on to a new system, possibly Pandoc-based. If
> someone has a good suggestion for a tool/set-up to create PDF documents and
> HTML sites from Markdown content (with LilyPond syntax highlighting and
> inclusion of LilyPond scores) I'd be glad to look into it.
> ​
>

That would be nice, wish I could help!​



> ​Check your ​URL in this:
> Last part of https://scheme-book.ursliska.de/scheme/expressions.html
> "You can and should for now ignore everything you don't know about that
> (we'll soon cover it in the chapter about variable binding
> ) but simply realize
> that within that “mess” we have inserted ..."
>
>
> Well, like with Wiki systems you can enter links to pages that don't exist
> yet. So that's simply part of the incompleteness of the "book", and I can't
> do anything about it right now.
>
​The URL *does exist* if you remove .html it should works fine​

​.​

Thank you, ƒg​

>
> Best
> Urs
>
>
> ​Thank you, ƒg
> ​
>
> Best
> Urs
>
>
> ​Thank you,
> ƒg​
>
>
>>
>> ​​
>>
>>
>>
>
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: music-function name shadowing a Scheme keyword

[David Kastrup]

Andrew Bernard  writes:

> Hi Urs,
>
> It's not a Scheme language keyword, but a procedure name from SRFI-1.

(srfi srfi-1) is loaded and imported into the parser by default.

-- 
David Kastrup

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

Re: music-function name shadowing a Scheme keyword

[Andrew Bernard]

Hi Urs,

It's not a Scheme language keyword, but a procedure name from SRFI-1. I
concur with the others that it is not really good practice to override
this, even though Scheme allows you to do many wonderful things. That's
bound to lead to hard to diagnose unpredictable behaviour for users at some
point.

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

Re: Reusability of lilypond code?

[Torsten Hämmerle]

Hi Markus,

\tags are, as Aaron said, the way to go.

I'd just like to mention the way I often handle this, perhaps this is on any
help:

Instead of tagging each and every single dynamic element, I often completely
\omit certain stencils of a voice, if applicable.

The following example, while not being quite correct (because each voice
should get its own dynamics if they differ in any way), the DynamicText (and
Hairpin) stencils of hornII will be omitted in the score, the dynamics of
hornI will be used for both in the score and placed below the stave.
The parts keep their individual dynamics.

%%
\version "2.19.81"

hornI = { 
  \tag score \dynamicDown
  g'1\p\< ~ 1 ~ 1 ~ 1\f  
}
hornII = { 
  \tag score { \omit Voice.DynamicText \omit Voice.Hairpin }
  R1  c'\mp\< ~ 1 ~ 1\f 
}

\score {
  \new Staff \partcombine \hornI \hornII
}

\score {
  \new Staff \removeWithTag score \hornI
}

\score {
  \new Staff \removeWithTag score \hornII
}
%%

 

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: openLilyLib

[Jan-Peter Voigt]

Hi Urs, Aaron,

Am 27.06.2018 um 08:35 schrieb Urs Liska:

Hi Aaron,

thank you for the interest in openLilyLib.



> ...
>
pre-alpha state, which does explain things. 


Unfortunately this is true, and basically because the project didn't 
really gain traction. Progress is usually been made when someone has a 
reason to contribute something, usually a package or some functionality 
for a package. In many cases that someone is me, but there are a few 
major contributors to different packages.
Wait a second ... oll-core with its package management is working very 
well so what are the issues preventing from naming the core a RC? or at 
least beta?
The great thing about it is that anything is modularized so any package 
or module that is not in that state should be marked alpha. But the 
core? AFAICS a desired feature list naming all the core elements already 
available is missing to name it beta. Then a testing phase would make it 
a RC and then stable.


What is missing is a "community" with the intent of bringing openLilyLib 
into a more generally usable state. Which is a pity because I'm 
convinced it is a very useful toolkit worth of being more widely known 
and used.
I believe it very important to name it something more then pre-alpha. I 
know Its a bit funny if I say so, because I didn't promote my work that 
way ... but! Few people want to be beta-tester so it should be called 
"use it! here's how to install"


Documentation would be a good start with this - unfortunately at the 
same time a vital goal, a vicious circle ...

+1

> ...

The newer one is the "package" system, which essentially means that 
after \include "oll-core/package.ily" further package and/or modules can 
be loaded through \loadPackage and \loadModule. (BTW: this ensures that 
modules are parsed only once ...This is IMO a very usable infrastructure. The thing is that installing a 
package means `git clone https://`. That is easy if you are 
familiar with git, but it may disturb users that are not. So a 
package-manager that installs packages would be great thing to help 
those who are not familiar with git. But this is for now just an idea.


What services does oll-core provide to packages/modules?  Basically, 
if I were to come up with an idea for an extension to LilyPond, how 
would I best evaluate whether openLilyLib would make a good platform 
on which to build and how would I go about integrating it?


...


The edition-engraver is an extremely powerful 
tool and we can't thank Jan-Peter enough for having provided it. But the 
openLilyLib structure makes it possible to create new packages that 
*use* the edition-engraver and provide very simple interfaces for tools 
that would otherwise have to be handled in rather complex manner if 
you'd directly use the edition-engraver. The 
page-layout.conditional-breaks module is a good example for this.
Thank you Urs! It would still reside in my own cosmos and wouldn't be 
available without your package manager!


Jan-Peter





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

Re: Reusability of lilypond code?

[Aaron Hill]

On 2018-06-27 04:08, lyuser.theg...@spamgourmet.com wrote:

What I would like to have is a simple switch in lilypond that
hides the duplicated markup, so that I can use the same variables for
both use cases.


You mentioned finding some proposed solutions already, so I hope I am 
not just reiterating something you already looked at.


Tags might be a reasonably simple option here.  You can tag any elements 
that you only want to show up when the part is used by itself.  Then it 
is easy to reference the part and conditionally include or exclude the 
elements in question.  See the following documentation on tags which 
includes examples:


http://lilypond.org/doc/v2.19/Documentation/notation/different-editions-from-one-source#using-tags

-- Aaron Hill

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

Re: openLilyLib

[Urs Liska]

Am 27.06.2018 um 13:29 schrieb Aaron Hill:

On 2018-06-26 23:35, Urs Liska wrote:

This gives me an opportunity to repeat my call for help with this. The
website is an Angular application (representing my "state" at the end
of a set of online courses), and I got stuck with a practical way of
feeding the content in the site. The placeholder content is all
"authored" in manually written JSON expressions, which is definitely
not the way I want to go forward. So anyone who is interested in
making this a usable site and is fluent in the MEAN stack (more
concretely, getting data (maybe from "M") into the "AN" part) would be
warmly welcomed ...


I, at best, *pretend* to be a web developer.  As far as MEAN goes, I 
have really only done the most with Node.JS itself, only dabbling with 
the other three.  That said, I am a pretty quick learner of new 
languages and frameworks, so I can definitely help you look into 
options for getting the site up and running. 


That would be great!


Though, we should probably take that discussion offline.


Definitely.
I'll see how and when I can prepare something to give it to you.




[...] (for example: "tools providing
organ registration notation" would be a good package scope while
"helper functions for my projects of the last decade" probably less
so) [...]


While I wouldn't think to subject people to my helper functions, your 
phrasing is uncannily accurate as I have in fact been using LilyPond 
for about ten years.  *x-files theme plays*  But I fully understand 
your point about what would be more useful as a package.  In practice, 
I would first review any helper functions to see if they could be 
generalized into a more widely applicable pattern, otherwise there is 
little point of publishing them.


Well, nothing speaks against creating an openLilyLib package *without* 
publishing it, just for personal organization. In that case it would be 
valid to have an uncategorized package with "all my reusable stuff", and 
have *some* organization thorugh modules like "common-tweaks", 
"score-organization", "fancy-score-elements" etc.).


Best
Urs



- - -

All in all, I thank you for providing so much great information, Urs.  
Hopefully, I will be able to contribute in some way and help out the 
project.



-- Aaron Hill

___
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: openLilyLib

[Aaron Hill]

On 2018-06-26 23:35, Urs Liska wrote:

This gives me an opportunity to repeat my call for help with this. The
website is an Angular application (representing my "state" at the end
of a set of online courses), and I got stuck with a practical way of
feeding the content in the site. The placeholder content is all
"authored" in manually written JSON expressions, which is definitely
not the way I want to go forward. So anyone who is interested in
making this a usable site and is fluent in the MEAN stack (more
concretely, getting data (maybe from "M") into the "AN" part) would be
warmly welcomed ...


I, at best, *pretend* to be a web developer.  As far as MEAN goes, I 
have really only done the most with Node.JS itself, only dabbling with 
the other three.  That said, I am a pretty quick learner of new 
languages and frameworks, so I can definitely help you look into options 
for getting the site up and running.  Though, we should probably take 
that discussion offline.



[...] (for example: "tools providing
organ registration notation" would be a good package scope while
"helper functions for my projects of the last decade" probably less
so) [...]


While I wouldn't think to subject people to my helper functions, your 
phrasing is uncannily accurate as I have in fact been using LilyPond for 
about ten years.  *x-files theme plays*  But I fully understand your 
point about what would be more useful as a package.  In practice, I 
would first review any helper functions to see if they could be 
generalized into a more widely applicable pattern, otherwise there is 
little point of publishing them.


- - -

All in all, I thank you for providing so much great information, Urs.  
Hopefully, I will be able to contribute in some way and help out the 
project.



-- Aaron Hill

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

Reusability of lilypond code?

[lyuser . thegrue]

Hello,

This time, I have a more general question:

I've set some scores for my men's choir using lilypond - and I love it
:) With the help of this list, these scores look just like I would
like to have them and our singers like to read them.

But I have one issue with the reuse of my work. My last score e.g. has
four voices (T1, T2, B1, B2). I assign music and lyrics for each voice
to a variable and combine them info a choir staff. So for our
rehearsal, everybody can see all the voices.

There are other usecases, where I would like to have only one
voice per staff. I can do that with lilypond, of course, by reusing
the variables that I created before.

Now comes the problem:

For the "one voice per staff" solution (and for midi files, by the
way), the single voices have to be annotated with all "bells and
whistles", like dynamics, for example.

But for the "four voices per staff", all the annotations would pile
up (one 'p' above the other 'p' for the two tenor voices, for example)
and with all the duplicated dynamic, hairpins, markup, the score would
become unreadable.

What I would like to have is a simple switch in lilypond that
hides the duplicated markup, so that I can use the same variables for
both use cases.

Frescobaldi provides some tools to remove the markup from a
selection. That is not what I want, because it creates two versions of
the music. Not good, they will diverge.

I've searched this and other lists and there seem to be solutions, but
they are too complicated for me: I don't understand them and they
never worked for me

Can you help me this this problem?

cu--
Markus Grunwald
https://www.the-grue.de/~markus/markus_grunwald.gpg



signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: music-function name shadowing a Scheme keyword

[Jan-Peter Voigt]

Am 27.06.2018 um 11:15 schrieb Urs Liska:



Am 27.06.2018 um 11:09 schrieb Urs Liska:

Hi Jan-Peter,


Am 27.06.2018 um 10:48 schrieb Jan-Peter Voigt:

Hi Urs,

you might import the SRFI-1 span-function and give that a new name. 
The counterpart-function to span is break, which "conflicts with the 
break binding established by while (see while do). Applications 
wanting to use break from within a while loop will need to make a new 
define under a different name."

You might provide such an alternative name for "span".

Personally I'd prefer another name for your function, because 
srfi-1-span is "prior art" ;-)

and *now* you can give it a name that does not conflict.



Hm, I was afraid of that comment. I agree that asking users using my 
module to change any occurence of "span" to 
"span-saved-from-openlilylib" is no viable option ...


However, what *would* be a suitable name, then? \span is just perfect. 
\markup would be good, or \tag, but of course ...


  * \class ("\class new" as shorthand for ) (maybe
also too generic?)
  * \tagSpan
  * \markupSpan

?

Yes, class is quite generic. I don't know, if it conflicts.
IMO \tagSpan is a viable name.




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

Re: music-function name shadowing a Scheme keyword

[Jan-Peter Voigt]

Am 27.06.2018 um 11:09 schrieb Urs Liska:

Hi Jan-Peter,


Am 27.06.2018 um 10:48 schrieb Jan-Peter Voigt:

Hi Urs,

you might import the SRFI-1 span-function and give that a new name. 
The counterpart-function to span is break, which "conflicts with the 
break binding established by while (see while do). Applications 
wanting to use break from within a while loop will need to make a new 
define under a different name."

You might provide such an alternative name for "span".

Personally I'd prefer another name for your function, because 
srfi-1-span is "prior art" ;-)

and *now* you can give it a name that does not conflict.



Hm, I was afraid of that comment. I agree that asking users using my 
module to change any occurence of "span" to 
"span-saved-from-openlilylib" is no viable option ...


However, what *would* be a suitable name, then? \span is just perfect. 


Hm, I doubt that. Not all  Lilyponders are HTML-natives. So to me it 
seems like a function that adds style-attributes to music elements. Am I 
right? Then you might give it a name like applyStyleAttributes ... OK, 
that is of course way too long, but ...

I just received your proposals and I will answer that ;-)


\markup would be good, or \tag, but of course ...

Urs




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

Re: music-function name shadowing a Scheme keyword

[Urs Liska]

Am 27.06.2018 um 11:09 schrieb Urs Liska:

Hi Jan-Peter,


Am 27.06.2018 um 10:48 schrieb Jan-Peter Voigt:

Hi Urs,

you might import the SRFI-1 span-function and give that a new name. 
The counterpart-function to span is break, which "conflicts with the 
break binding established by while (see while do). Applications 
wanting to use break from within a while loop will need to make a new 
define under a different name."

You might provide such an alternative name for "span".

Personally I'd prefer another name for your function, because 
srfi-1-span is "prior art" ;-)

and *now* you can give it a name that does not conflict.



Hm, I was afraid of that comment. I agree that asking users using my 
module to change any occurence of "span" to 
"span-saved-from-openlilylib" is no viable option ...


However, what *would* be a suitable name, then? \span is just perfect. 
\markup would be good, or \tag, but of course ...


 * \class ("\class new" as shorthand for ) (maybe
   also too generic?)
 * \tagSpan
 * \markupSpan

?


Urs


Jan-Peter


Am 26.06.2018 um 22:43 schrieb Urs Liska:

Hi all,

I've mostly completed the implementation of a "span" module that 
provides the \span music-function, which is roughly the same as the 
HTML  element.


Nearly everything works fine by now, and I've been very happy with 
the name - until I realized that a music-function \span can be 
invoked from Scheme with (span), and that this shadows the Scheme 
procedure span from SRFI-1.


Am I right to assume that this *can* work - as long as no user of my 
package will think of using the original Scheme function?


Is there any way to get around this without renaming my music function?

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


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

Re: music-function name shadowing a Scheme keyword

[Urs Liska]

Hi Jan-Peter,


Am 27.06.2018 um 10:48 schrieb Jan-Peter Voigt:

Hi Urs,

you might import the SRFI-1 span-function and give that a new name. 
The counterpart-function to span is break, which "conflicts with the 
break binding established by while (see while do). Applications 
wanting to use break from within a while loop will need to make a new 
define under a different name."

You might provide such an alternative name for "span".

Personally I'd prefer another name for your function, because 
srfi-1-span is "prior art" ;-)

and *now* you can give it a name that does not conflict.



Hm, I was afraid of that comment. I agree that asking users using my 
module to change any occurence of "span" to 
"span-saved-from-openlilylib" is no viable option ...


However, what *would* be a suitable name, then? \span is just perfect. 
\markup would be good, or \tag, but of course ...


Urs


Jan-Peter


Am 26.06.2018 um 22:43 schrieb Urs Liska:

Hi all,

I've mostly completed the implementation of a "span" module that 
provides the \span music-function, which is roughly the same as the 
HTML  element.


Nearly everything works fine by now, and I've been very happy with 
the name - until I realized that a music-function \span can be 
invoked from Scheme with (span), and that this shadows the Scheme 
procedure span from SRFI-1.


Am I right to assume that this *can* work - as long as no user of my 
package will think of using the original Scheme function?


Is there any way to get around this without renaming my music function?

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: \bookparts and scaling

[Torsten Hämmerle]

Hi Ralph,

I'm neither Crimson nor Sunrise, but I guess having both full score and
parts together in one PDF is quite a common requirement.

Using smaller print for the full score but using larger print for the parts
while keeping up natural spacing is not easy to achieve in LilyPond, because
set-global-staff-size only works for whole books, i.e. separate output
files.


Here's a minimal example (without any attempt do alter score sizes yet) as a
working basis for the implementation of different approaches:


%%

\version "2.19.81"

#(set-default-paper-size "a6")

fluteI  = { \repeat unfold 20 { c''8 e'' g'' e'' } \bar "|." }
fluteII = { \repeat unfold 20 { c'4 g' } \bar "|." }

\bookpart {
  \header { instrument = "Full Score" }
  \score {
\new StaffGroup <<
  \new Staff \with { instrumentName = "Fl. 1" } \fluteI
  \new Staff \with { instrumentName = "Fl. 2" } \fluteII
>>
  }
}

\bookpart {
  \header { instrument = "Flute 1" }
  \score {
\new Staff \fluteI
  }
}

\bookpart {
  \header { instrument = "Flute 2" }
  \score {
\new Staff \fluteII
  }
}

%%


First, there is the full score, containing Flute 1 and Flute 2.
This full score should use smaller print, cf. #(set-global-staff-size 10) in
a \book.
The parts, however, should look as if printed with #(set-global-staff-size
20).
And all within one single PDF.

These extreme differences should make spacing problems obvious.

How do you (to the list in general) handle such a case without using
external PDF postprocessing programs?
I'm usually working around the problem by using (at least) two PDF files -
one for the full score and one (or even individual files) for the parts -
for several reasons.

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: music-function name shadowing a Scheme keyword

[Jan-Peter Voigt]

Hi Urs,

you might import the SRFI-1 span-function and give that a new name. The 
counterpart-function to span is break, which "conflicts with the break 
binding established by while (see while do). Applications wanting to use 
break from within a while loop will need to make a new define under a 
different name."

You might provide such an alternative name for "span".

Personally I'd prefer another name for your function, because 
srfi-1-span is "prior art" ;-)

and *now* you can give it a name that does not conflict.

Jan-Peter


Am 26.06.2018 um 22:43 schrieb Urs Liska:

Hi all,

I've mostly completed the implementation of a "span" module that 
provides the \span music-function, which is roughly the same as the HTML 
 element.


Nearly everything works fine by now, and I've been very happy with the 
name - until I realized that a music-function \span can be invoked from 
Scheme with (span), and that this shadows the Scheme procedure span from 
SRFI-1.


Am I right to assume that this *can* work - as long as no user of my 
package will think of using the original Scheme function?


Is there any way to get around this without renaming my music function?

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

Re: scheme with Frescobaldi

[Urs Liska]

Am 27.06.2018 um 07:34 schrieb Freeman Gilmore:




Thanks Urs:

That worked.   Problem was that I did not know that the
results would be displayed in the log window.   The
tutorial I am using had some example like  (+ 1 2 3) =>  and
I was expecting 6 in the same window on the next line when I
compiled.


This is what one refers to as a REPL (read-eval-print-loop),
which is what LilyPond's Scheme sandbox does.


This may be what you mean by " but no immediate expression
evaluation".


Yes. Frescobaldi deals with LilyPond *files*, not an
immediate expression evaluation.


Is => valid in guile?


No.


 How would I display the results of (+ 1 2 3), at this point
of the tutorial it just says  "(+ 1 2 3)  => 6"?


When a tutorial writes "=>" it means: "You type in '(+ 1 2
3)', and the REPL will display '6'. So "=>" isn't a
syntactical construct but a typographical convention for "the
expression to the left evaluates to the datum on the right".

Tutorials usually want you to learn from this immediate
evaluation, and in Frescobaldi you have to always do that
extra step to display something. But in general it's worth
the effort, and I do that 90% of the time when I want to try
something out or learn more about Scheme.

​​
For displaying values you can use #(display) or #(ly:message
"Some value: ~a" data) (to start with ...)

HTH
Urs



Thank you,
ƒg​


​Urs:

In you first example #(let...) what function does 'let'
preform?    From your examples in "​For displaying values you can
use #(display) or #(ly:message "Some value: ~a" data) (to start
with ...)", could you please give me examples of each?   I need
this to study the tutorial using Frescobaldi.


OK, it probably wasn't such a good idea to use non-atomic examples.
Let me try to put it another way: what you have in Frescobaldi is
a LilyPond file. This file may include Scheme code, and LilyPond
even works if there is *only* Scheme code in the file and no score
is even generated. That way you can use LilyPond and Frescobaldi
as a tool to experiment with Scheme code.

​When I started this post​ I was hoping that Scheme work with out score.


The way to include Scheme in LilyPond is the '#'. Whenever
LilyPond encounters this hash it will have the immediately
following expression evaluated by Scheme. Essentially the
expression is replaced by the resulting value.

​This helped​
​a lot.​


What you have already noticed is that this Scheme code is not
evaluated immediately (as is done on a REPL and what your tutorial
seems to assume), but only when compiling the LilyPond file.

One more thing to understand is the following: any Scheme
expression *evaluates to* something (like (+ 1 2 3) evaluates to
6). In a REPL this value is displayed but in LilyPond/Frescobaldi
it is not. If you write #(+ 1 2 3) in a LilyPond file it *will*
evaluate to 6 but it only has the effect of placing that value 6
in the LilyPond file, which will have no effect at all.

​I figured this​.


The additional effort you have to make is explicitly print any
value you want to inspect to the log window. Scheme provides some
functions for that purpose: display, print, pretty-print, and more.
​​
  #(define my-var 12)
  #(display my-var)
will print '12' to the log window,
  #(display (+ 1 2 3))
will print '6'

​Now this helped because I was making it work with #(let...; above is 
much simpler.



Note that display won't add a line break, so when you want to see
more than one value you'll want to add #(newline) expressions in
between.

​Read that sum place.​


A final remark: there are many Scheme implementations (or
dialects) around, with more or less subtle differences. When you
use LilyPond you have a very specific dialect available (the Guile
implementation in its version 1.8), plus when starting up LilyPond
a number of extra Guile modules and many LilyPond features are
automatically added. This means that when you follow a "Scheme
tutorial" not necessarily everything will match what you find in
LilyPond.

[And please allow me a plug: you may find rewarding to have a look
at https://scheme-book.ursliska.de
, which is far from complete but
aims at giving a slow-paced and detailed introduction specifically
from a LilyPond perspective]

​This is what I have been looking for.   Is there a PDF?    ​


No, and currently my (Gitbook) build system is broken, so I can't even 
upload updates. But the content is available in a bunch of Markdown 
files, and I'd be ready to move on to a new system, possibly 
Pandoc-based. If 

openLilyLib (was: Need help creating Scheme functions to automate includes of many scores in a project)

[Urs Liska]

Hi Aaron,

thank you for the interest in openLilyLib.


Am 27.06.2018 um 00:41 schrieb Aaron Hill:

On 2018-06-25 22:42, Urs Liska wrote:

Also, not directly. But you can make it happen.
Basically you have to define some variable in the top-level file, say
#(define is-main-file #t). Then you can check in the included file for
#(if (defined? is-main-file)


That was the general idea I was thinking for a workaround, possibly 
building on the tag system that already exists.



You may look at this file:
https://git.openlilylib.org/bfsc/das-trunkne-lied/blob/master/library/ly/makescore/compile-segment.ily 


which does more or less what you are looking for.
However, I don't know whether that is at all understandable,
especially on its own. But it might give you an idea.


Actually, that was perfectly clear.  Thanks!

Speaking of openlilylib, I have seen you and others recommend it on 
many occasions.  The openlilylib.org website, though, appears to be 
all placeholder content. 


Indeed :-(

This gives me an opportunity to repeat my call for help with this. The 
website is an Angular application (representing my "state" at the end of 
a set of online courses), and I got stuck with a practical way of 
feeding the content in the site. The placeholder content is all 
"authored" in manually written JSON expressions, which is definitely not 
the way I want to go forward. So anyone who is interested in making this 
a usable site and is fluent in the MEAN stack (more concretely, getting 
data (maybe from "M") into the "AN" part) would be warmly welcomed ...


The GitHub for openlilylib/oll-core mentions everything is in 
pre-alpha state, which does explain things. 


Unfortunately this is true, and basically because the project didn't 
really gain traction. Progress is usually been made when someone has a 
reason to contribute something, usually a package or some functionality 
for a package. In many cases that someone is me, but there are a few 
major contributors to different packages.


What is missing is a "community" with the intent of bringing openLilyLib 
into a more generally usable state. Which is a pity because I'm 
convinced it is a very useful toolkit worth of being more widely known 
and used.
Documentation would be a good start with this - unfortunately at the 
same time a vital goal, a vicious circle ...


So is the only option, then, to just dive into the code at this point? 


A good starting point would be diving into the usage-examples that 
should generally be available. They give a pretty good idea of what the 
packages are about, and when you're interested in the implementation 
they can also give you starting points where to look at.


Then currently the best bet would be to post questions on the 
lilypond-user list, possibly triggering some discussion and input about 
what the packages are used for by others and with what success.


Would there be a particular subset of plugins (e.g. edition-engraver) 
that you feel are most representative of the project?


That is difficult to say. edition-engraver and scholarLY are maybe the 
most powerful and consequential packages - but also the most complex ones.



Am 27.06.2018 um 01:35 schrieb Aaron Hill:
That said, what I was seeking was information about openLilyLib 
itself.  How is the project structured? 


There are two distinct elements. One (historically the origin) is the 
"snippets" repository, containing self-contained code snippets for a 
wide range of tasks. This is quite similar to the LSR, with the main 
difference being that these snippets can be \include-d (instead of 
having to be copied over to your own code).


The newer one is the "package" system, which essentially means that 
after \include "oll-core/package.ily" further package and/or modules can 
be loaded through \loadPackage and \loadModule. (BTW: this ensures that 
modules are parsed only once ...)


What services does oll-core provide to packages/modules?  Basically, 
if I were to come up with an idea for an extension to LilyPond, how 
would I best evaluate whether openLilyLib would make a good platform 
on which to build and how would I go about integrating it?


Generally, if you have some new functionality (for personal or general 
use) that is conceptually coherent (for example: "tools providing organ 
registration notation" would be a good package scope while "helper 
functions for my projects of the last decade" probably less so) it may 
be a good candidate. Creating a package and setting it up for use 
(especially when you collaborate and have to tell contributors how to 
set up their system) requires *some* overhead, but it makes using the 
functionality cleaner and simpler, so that's the trade-off you would 
have to consider.


The fundamental services oll-core provides for packages are:

 * Package/module handling (preventing repeated parsing of packages),
   that is the mechanism to load modules, optionally with configuration
   options passed.
 * Option