Re: Paper size survey

[Urs Liska]

Am 20.04.2015 um 08:45 schrieb Andrew Bernard:

So Ponders,

What size paper do you print scores on?



A4 exclusively, sometimes folded A3 (but only when letting print through 
external service providers).


But I always suffer from that being somewhat too small for really usable 
scores. If I had the printer or would find a suitable service provider I 
would prefer folded A3+


Maybe we could extend this survey by the _type_ of paper?
Of course for day-to-day use I print on standard office paper, but what 
I found extremely beautiful for scores is Munken Pure 100g/m2 or 130 g/m2.


Urs


Andrew





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


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

Re: Paper size survey

[Jan-Peter Voigt]

Hi Andrew,

I use A4 for most "small" or "normal" scores (SATB choir). Sometimes A5
But full scores for the director with an orchestral score I use B4 - 
sometimes A3.


Cheers,
Jan-Peter


Am 20.04.2015 um 08:45 schrieb Andrew Bernard:

So Ponders,

What size paper do you print scores on?

Andrew





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


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

Paper size survey

[Andrew Bernard]

So Ponders,

What size paper do you print scores on?

Andrew



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

Re: B Series paper

[Andrew Bernard]

Hi Brian,

We could go halves in a shipping container.

Andrew


On 20 April 2015 at 05:29:07, Brian Barker (b.m.bar...@btinternet.com) wrote


I've got this down to 19 tonnes, but I doubt that's any more useful! 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Do we really offer the future?

[Johan Vromans]

On Sun, 19 Apr 2015 21:39:29 -0400
Kieren MacMillan  wrote:

> Do you not remember the tipping point when OpenOffice was
> embraced over Microsoft Office as the official office application suite
> by certain governments?

That's a totally different case: OO and MSO are two similar tools, that
have a similar approach, similar workflow, and produce similar results.

LilyPond approach and workflow is totally different from Sibelius and
Finale and alikes.

To mimic the OO <-> MSO comparison, MuseScore would be a better candidate.

-- Johan

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

Page numbers

[Andrew Bernard]

If you want to put an arbitrary page number in the header, not the proper 
consecutive one, how can this be done?

Useful when setting a score where you do not necessary;y do the pages in 
monotonically increasing order.

Andrew



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

Re: Do we really offer the future?

[Andrew Bernard]

Hi Urs,

Can you tell me why we should be interested in helping music publishers exactly?

If they are such corporate dinosaurs that do not recognise the benefits of 
advanced lilypond technology, open source and open systems, of what concern is 
it to the community of lilypond engravers?

I would have thought that, like the invention of desktop publishing in the 
1980’s, which allowed small scale companies and individuals to produce 
professional publications, lilypond frees composers, musicians, and engravers 
from the tyranny - and rejections - of the hidebound established music 
publishers. Why do we need Peters and Barenreiter and others? Their editions 
are full of mistakes and not particularly well done. How would using a finer 
engraving tool help the overall end product? The Barenreiter Bach Violin 
Sonatas are unusable due to editorial weakness, not engraving issues.

My composer colleague of the New Complexity School will never be published by 
the Big Firms. But he will be published by me. And with the web nowadays, the 
big distribution networks the Old Companies have is no longer important.

So I don’t quite understand the need to help out these companies. What exactly 
is the motivation? What would they put back to the lilypond development effort?

I would like to see the whole world coding in Haskell. And using Emacs. And I 
would like to see every engraver using lilypond - I am just as keen as you are. 
But we have to face the fact that these are tools for Kenner und Liebhamer - 
Connoisseurs and Amateurs (CPE Bach!), and not for the Hoi Polloi. It’s often 
the case with the best technology.

I would rather see lilypond promoted among individuals and small scale, human, 
firms and individual craftsmen than attempting to foist it on the established 
firms. Let them use it if they are enlightened. If they need vast amounts of 
explaining to understand it, they simply will not get it.

Andrew




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

Re: Survey: Large scores

[H. S. Teoh]

On Sun, Apr 19, 2015 at 03:12:20PM +0200, Orm Finnendahl wrote:
[...]
> Another thing: For me, also the implementation of transposing
> instruments is less than ideal (I prefer to write the pitches in
> concert pitch and have them transposed for the parts, rather than the
> other way around, as it is implemented at the moment). I would be very
> willing to sponsor this.
[...]

This is not hard to implement at all, you just have to set things up
appropriately. I also always write at concert pitch, and I use a
combination of \transposition and \transpose so that the part is printed
with the correct transposition. Here's roughly how I do it:

clarinetIPart = \relative c'' {
... % clarinet music here
}

clarinetIIPart = \relative c'' {
... % clarinet music here
}

clarinets = new Staff {
set Staff.instrumentName = #"Clarinets in B\flat I, II"
\transposition bes
\transpose bes c' \partcombine
\clarinetIPart \clarinetIIPart
}

The music in \clarinetIPart and \clarinetIIPart is written in concert
pitch. Later on, \clarinets is used to create the conductor's score with
the right transpositions applied. A similar setup is used for generating
parts for the individual clarinets with the right transpositions.

Of course, all this can probably be encapsulated in a convenient macro
that takes a single argument specifying the transposition relative to
c', and generates the requisite commands to make it all work.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

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

Re: Do we really offer the future?

[Kieren MacMillan]

Hi Gilles (et al.),

> To whom LilyPond should strive to "offer the future”?

To everyone it possibly can.  ;)

> IMHO, certainly not to the "[...] big house[s] with traditions,
> regulations and limitations”.

Why not? What’s to say that Lilypond can’t initially fit within those 
traditions, regulations, and limitations, while providing benefits (financial 
and otherwise) to those “big houses”, and can’t eventually help a “big house” 
move past those limitations while maintaining whatever traditions and 
regulations they see as indispensible?

> What's for the LilyPond team in spending resources trying to work around
> those self-inflicted limitations?

Let’s say, for discussion’s sake, we convince a Warner-Chappell, Boosey & 
Hawkes, or Barenreiter to use Lilypond as their primary engraving application. 
You honestly don’t see the potential upsides of that situation? Do you not 
remember the tipping point when OpenOffice was embraced over Microsoft Office 
as the official office application suite by certain governments?

> LilyPond is "[...] a program that creates beautiful sheet music following
> the best traditions of classical music engraving." (excerpt from
> "http://www.lilypond.org/introduction.html";)
> 
> I think that this goal is way more important (to users)
> than trying to convince publishers.

To certain users? Absolutely.
To a majority of users? Possibly.
To all users? Doubtful.

In any case, those aren't mutually exclusive goals. Quite the contrary: almost 
tautologically, the easier it is for an abstract user to “create beautiful 
sheet music following the best traditions of classical music engraving”, the 
easier it will be to convince a given publisher to become a user.

> A project like Mutopia is a promising future

I disagree rather strongly. Mutopia (at least currently) appears to me to be a 
rather damning example of the failure of the open-source philosophy to be able 
to make a broad and lasting impact on its intended market. Worse, far too many 
of the examples there are not, to my eye, “beautiful sheet music following the 
best traditions of classical music engraving”; I would, for example, never send 
someone there if I was trying to impress them with Lilypond’s engraving output.

> If and when "big" publishers use LilyPond, the result will be more
> restricted access (through cost)

Cost of what? Lilypond wouldn’t ever cost any more.

> to culture (because they won't release
> their proprietary contents)

Nor would we necessarily want them to.

> I've thought for a long time that the right way to go is to seek
> public funds for engraving public domain contents with the purpose
> of publishing it under a GPL-like (or Creative Commons) license.

That’s a fine goal… but shouldn’t in any way distract the Lilypond community 
from more important goals which would more immediately and significantly 
benefit the ‘Pond (and beyond). IMHO, one of those more important goals would 
be making a major inroad into the rather small walled city that is the 
commercial music publishing world.

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Do we really offer the future?

[Urs Liska]

Am 17.04.2015 um 16:05 schrieb Kieren MacMillan:

Hi Urs,

First off, thank you so much for your continuing efforts on behalf of Lilypond. 
They are really important, and no doubt time- and energy-consuming for you, 
with little promise of immediate benefit to you personally. The ‘Pond 
appreciates you!


"why should a publishing house use LilyPond?”

We might start by asking the question “Why should *any* person use Lilypond?”, 
and then scale up from there.


Well, this seems a good idea, but not for my original question. I think, 
this is to some extent what I already have, but the different question 
here is "why should anybody who already has existing workflows and 
infrastructure *switch* to LilyPond?"


If you could find the time to put together a list of arguments (or maybe 
a nice blog post) why a *composer* should use LilyPond this would also 
be very helpful. I have had discussions with various composers whom I 
couldn't really convince of the usefulness of giving it a try.
For this kind of people it seems most important to get their music into 
the score as quickly and easily as possible. I'm thinking of composers 
who *do* need performance material but who do not necessarily need 
publication quality, just the one necessary for people to play from the 
material.



...


most publishing houses don't really care anymore about the editorial process, 
and they have the impression that this could actually create more overhead than 
they have currently

We might want to tailor a few “pitches” — complete with working demonstrations 
— to present to organizations with different needs. For example, a 
quick-and-dirty translation which (e.g.) took a Finale source filie and turned 
it [first via MusicXML, probably] into a Henle-lookalike Lilypond file in under 
5 minutes would be VERY compelling to certain people, and they wouldn’t want to 
see (or even care about) edition management, ScholarLY, etc. Then a second 
(likely longer) demo would be available for those working on critical editions. 
And so on.


Sounds reasonable.
I think I've identified (or was told) the following use cases:

- producing scores "for the day" - editions without specialized demands 
and not necessarily intended for extra-long maintainment.
- producing scores on short notice, e.g. performance material when the 
composer delivers too late
- process existing material (either from the archives or from 
heterogenous contributors' systems)

- scholarly editions and edition series with a long-term horizon.

Urs


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

Re: Jianpu Notation

[MING TSANG]

Paul,
It is terrific. Now only one input of notes is generating Voice Staff for 
jianpu notation and new Staff for music score.  Thank you.
I try to put  r8  r16  r32 and I got the following error:Starting 
lilypond-windows.exe 2.19.17 [sample_jianpu2.ly]...Processing 
`K:/sample_lily-code/sample_jianpu2.ly'Parsing...Interpreting 
music...[8]warning: type check for `stencil' failed; value `#' 
must be of type `stencil'fatal error: typecheck failedExited with return code 1.
Thank you again for making this possible. I have been waiting this for years, 
since v2.12.  Silas's and David's solution require to code twice - one for 
jianpu and one for music score.   Your is only one input and straight forward. 
Excellent.
I also try out \transpose c d to both voice & staff and it works.
Immanuel,Ming


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

回复： Jianpu Notation

[Super-User]

Hi,Paul!


I am impressed by your code! You have really made things automated! To note 
about improvement, accidentals in jianpu look identical to those in standard 
notation, but the baseline is about 0.75 height position of numeric note head 
height button up. Lines indicating duration (aka. beams) should be horizontally 
linked together the same way as 5-stave notation.
I have tried changing "\key c \major" to "\key d \major", and found that rules 
dealing with accidentals are still in the old way(eg. the second note should be 
flat-7, not natural-7).


Thanks!


David Zhang




-- 原始邮件 --
发件人: "Paul Morris"; 
发送时间: 2015年4月20日(星期一) 上午6:24
收件人: "Super-User"; 
抄送: "lilypond-user"; 
主题: Re: Jianpu Notation



Hi David,

> On Apr 18, 2015, at 1:14 AM, Paul Morris  wrote:
> 
> In the attached file is a start on a more automated way to do it.  It uses a 
> custom note head engraver and custom rest engraver (written in Scheme) to 
> automatically alter the note head and rest stencils. By going further in this 
> direction it would be possible to also add the dots and lines (that indicate 
> octave and duration) to the note head stencil.  This would automate those 
> parts as well.  

I went ahead and worked some more on this.  (It took me long enough to figure 
out how to do this stuff, so I might as well put it to use so others can 
benefit too.)

See the attached file for another revision that implements these things:
- dots indicating octaves
- lines indicating note and rest durations
- correctly determines Jianpu note number (c major key: c = 0, c minor key: c = 
6, etc.)

It works by incorporating these symbols into the note head stencil.

This is just a quick sketch that can be improved and refined in terms of 
spacing and other details.  Some things still to do are handling dotted notes 
(I haven’t been able to access the dots grob from note head grob, so this seems 
tricky) and Jianpu accidental signs (which will require their own engraver).

HTH,
-Paul___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Jianpu Notation

[Paul Morris]

Hi David,

> On Apr 18, 2015, at 1:14 AM, Paul Morris  wrote:
> 
> In the attached file is a start on a more automated way to do it.  It uses a 
> custom note head engraver and custom rest engraver (written in Scheme) to 
> automatically alter the note head and rest stencils. By going further in this 
> direction it would be possible to also add the dots and lines (that indicate 
> octave and duration) to the note head stencil.  This would automate those 
> parts as well.  

I went ahead and worked some more on this.  (It took me long enough to figure 
out how to do this stuff, so I might as well put it to use so others can 
benefit too.)

See the attached file for another revision that implements these things:
- dots indicating octaves
- lines indicating note and rest durations
- correctly determines Jianpu note number (c major key: c = 0, c minor key: c = 
6, etc.)

It works by incorporating these symbols into the note head stencil.

This is just a quick sketch that can be improved and refined in terms of 
spacing and other details.  Some things still to do are handling dotted notes 
(I haven’t been able to access the dots grob from note head grob, so this seems 
tricky) and Jianpu accidental signs (which will require their own engraver).

HTH,
-Paul 



jianpu2.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: title_page

[bobr...@centrum.is]

Urs,

Yours is the approach I used.  It did exactly what I needed.  Thank you!

In this case I had some parts which started on the left page.  I needed 
something on the "cover" so as not to leave it blank.

-David

- Original Message -
> From: "Urs Liska" 
> To: rich...@rshann.plus.com, bobr...@centrum.is
> Cc: "Lillypond Users Mailing List" 
> Sent: Sunday, April 19, 2015 8:35:02 AM
> Subject: Re: title_page
> 
> 
> 
> Am 19. April 2015 10:09:53 MESZ, schrieb Richard Shann
> :
> >On Sat, 2015-04-18 at 23:33 +, bobr...@centrum.is wrote:
> >> I'm trying to make a title/cover page within LilyPond.  I'm aware of
> >the possibility of workarounds:
> >> 
> >> lilypond-book/LaTeX; Strikes me as a bit ham-fisted, not sure if I
> >would run into trouble as I've seen the warning about \pageBreak not
> >playing well with lilypond-book
> >> 
> >> Create separate title/cover page in LaTeX and assemble the PDFs;
> >seems a bit kludgy, though should work just fine.  Failing any more
> >integrated approach I would probably do this.
> 
> If you don' t find a proper solution I suggest to create the "whole volume"
> file with LaTeX and include the scores with \includepdf.
> 
> What I've done along that line (but I also had other textual pages in
> between) is let LaTeX also do the headers and footers and create the TOC.
> Quite integrated, I think.
> 
> HTH
> Urs
> 
> >> 
> >> I tried to find a LilyPond-only solution but have yet to succeed.
> >What I would like is to have a fairly simple page; composer, title, and
> >instrument.  All centered, in a column, all in a fairly large font with
> >the title being quite large.  It would be very nice if these items
> >could be taken from those relative fields in the overall \header{}
> >block.
> >> 
> >> Does such a solution already exist?
> >
> >>  
> >There is a snippet from Nicolas Sceaux which does this - it is
> >incorporated (in a modified form) in Denemo's output you can find
> >the .ily here
> >
> >http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob_plain;f=actions/lilypond/simplified-book-titling.ily;hb=HEAD
> >
> >
> >Richard
> >
> >>  If not, isn't this something that should be available?
> >> 
> >> -David
> >> 
> >> 
> >> ___
> >> 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: title_page

[Johan Vromans]

On Sat, 18 Apr 2015 23:33:25 + (GMT)
"bobr...@centrum.is"  wrote:

> Create separate title/cover page in LaTeX and assemble the PDFs; seems a
> bit kludgy, though should work just fine.  Failing any more integrated
> approach I would probably do this.

This is the approach I've been using for years, except that I do not use
LaTeX to create the title/cover page.

To be more precise: I create the score (PDF) using LilyPond but without
headers, footers, etc. A custom tool processes this PDF and adds logos,
headings, page numbers and so on. The exact information is in a database
where I register all scores, and the LilyPond \header is not used at all.

It is not LilyPond specific, I use the same approach for several other tools
that produce PDF documents. It has turned out to be much easier than to try
to persuade these tools to create the headers I want. And all resultant
documents have the same looks.

-- Johan

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

Re: Font trouble

[Wols Lists]

On 18/04/15 22:57, Wols Lists wrote:
> I must admit this is an example of "monkey see, monkey do" coding, but
> I'm pretty certain I was given it on this list originally, this is the
> second time I've tried to do something like this, and it's most
> definitely not right ...
> 
> I'm trying to replace the repeat alternative wording, and have used the
> following code ...
> 
>   \repeat volta 2 { s1*12 }
> %\override Staff.VoltaBracket #'font-name = #"sans"
> \override Staff.VoltaBracket #'font-name = #"Tahoma"
> \set Score.repeatCommands = #'((volta "Optional repeat"))
>   { s1*4 }
> \set Score.repeatCommands = #'((volta #f) \text (volta
> "Continue") end-repeat)
>   { s1*1 }
> \set Score.repeatCommands = #'((volta #f))
> %  } \mark \default % 146
>   \mark \default % 146
> 
> You'll see I originally used the sans font, then I've tried to specify
> Tahoma - I don't think specifying tahoma has made any difference
> whatsoever...
> 
> I attach the resulting output, and you'll see the result just before bar
> 146. I'm guessing the font it's actually using is neither sans, nor
> Tahoma, but some default font, seeing as the characters don't seem to be
> all the one font at all!
> 
> How do I get it to actually select a font that works - as I said, this
> is currently "monkey see monkey do" and while it looks like it should
> work, I have no clue as to what is right or wrong with the code.
> 
Finally managed to find an lsr snippet, that told me what the problem
was. VoltaBracket is a Score-level construct, not Staff.

Cheers,
Wol


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

Re: Windows performance

[Keith OHara]

Trevor Daniels  treda.co.uk> writes:

> Martin Tarenskeen wrote Saturday, April 18, 2015 6:29 PM
> 
> > Just a wild guess: did anyone on Windows try the same speed comparison 
using 
> > the --ps option instead of pdf output?
> 
> Just done that.  The conversion from ps to pdf takes only a couple of 
seconds
> with either version, so it looks like GhostScript is *not* involved.  

> On the Pango website I see an entry against the changes for Pango 1.28.2
>  
> - Improve performance on Windows especially for non-Latin scripts
> 
> and in 1.25.4
> 
> - Improved win32 performance 
> 
> Is this the version of Pango installed in 2.19.18?
> 

Until 2.19.17 LilyPond used Pango version 1.26.0 
Just now with 2.19.18 LilyPond switched to Pango verison 1.28.3
( https://github.com/gperciva/gub )

The Pango patch
"[basic-win32] Increase performance of Uniscribe code"
made it into Pango 1.25.4, but it broke ligatures and was reverted
for Pango 1.26.0

It looks like some other regression _also_ broke ligatures on Windows.
The patch that probably solved our ligature/kerning bugs 2656 and 2657
"Bug 609326 - Complex script shaping failed in the FT2 backend on Windows"
made it into Pango 1.28.0

A second attempt at making use of Uniscribe faster
"Improve performance on Windows especially for non-Latin scripts"
made it into Pango 1.28.2 and could be the cause of our speedup
( https://git.gnome.org/browse/pango/log/?h=1.28 )


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

Re: "procedure" vs. "function"

[PMA]

Andrew Bernard wrote:

Yes, it is quite muddy!

I just took a look at the Guile 2.0 reference manual. Generally they use 
procedure but the book also uses the term function interchangeably further on 
inside, so I suppose it does not matter so much! No doubt the book is written 
by a large team of authors.

An argument for using one single term is that by using two terms, it implies 
the possibility that they refer to two different things, which is not the case 
(hence the confusion about returning a value or not).

Andrew





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


Hear hear!  I recall that J-language and BASH folks call every procedure a
"function",  return-value or no.  (BASH code says "function"; J just 
says ':').


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

Re: Something wrong with transposing instruments?

[Gilles]

Hello.

On Sun, 19 Apr 2015 10:00:46 -0400, Kieren MacMillan wrote:

Hi Gilles,


[...]

Another thing: For me, also the implementation of transposing
instruments is less than ideal (I prefer to write the pitches in
concert pitch and have them transposed for the parts, rather than 
the

other way around, as it is implemented at the moment).
[...]


Can you give an example?  To my knowledge, both ways of encoding are
equally simple in LilyPond. [But I perhaps I misunderstood what you
mean.]


This wasn’t from me…


I know; I hadn't seen that yours was the recipient's address.  And I
just hit "Reply all" which usually does the right thing for a ML.
[I don't see the purpose of CC'ing someone who is on the list...]


but I wholeheartedly agree: Lily’s
default/built-in implementation of transposing instruments is rather
incomplete/poor (see, for example,


and


for an idea of the problems and workarounds).

I believe there has been some recent improvement via openlilylib, but
I haven’t had time to investigate
In any case, the main distro should have much better tools to handle
transposing instruments more deftly.


I didn't have all the info; from the statement above it looked like the
"problem" was for encoding a part of a transposing instrument whereas
the links you provided point to difficulties for switching instrument
within a \score.


Sorry for the noise,
Gilles


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

Re: "procedure" vs. "function"

[PMA]

Wols Lists wrote:

On 18/04/15 22:11, PMA wrote:

Aha.  So the improper-er their code got, the tougher time
compilers had trying to -- as Martin says -- "throw it out".

All told, is there now any real need _not_ to use the terms
"function" and "procedure" interchangeably?  That is, any
real need to try to enforce such a distinction?  The terms
are conflated, everybody knows, and there's no problem.

(No response expected -- at this point I'm just ranting.)


Except to me, the terms "function" and "procedure" are NOT the same
thing :-)

A function has a return value, a subroutine does not. A procedure can be
either.

Cheers,
Wol


And that seems rightly to summarize common usage -- in people
speech, anyway.  Maybe, if you're a new programming language,
survival will hinge more on your _exception_ to common usage.

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

Re: B Series paper

[Pierre Perol-Schneider]

Hi Andrew, Hi Nick,
Maybe try small local printers: they can usually cut you custom sizes in
the colour/weight/sort you need.
They'll probably quote for few thousand pieces though...
Cheers,
Pierre

2015-04-19 11:11 GMT+02:00 Nick Payne :

>  On 19/04/2015 18:46, Andrew Bernard wrote:
>
> Dear Ponderers,
>
>  Down under here in Australia we use A4 and A3. A4 is just too small for
> piano music, and A3 is generally too big to fit on the music desk
> comfortably.
>
>  The ideal size for me is Klavierformat (235x310mm) which is the standard
> size of editions such as Henle and so on. This paper size is unobtainable
> except as a printer’s trim size. The next best thing is B4.
>
>  Consumer A3 printers will take B4 paper. But I am completely unable to
> find a source of cut B4 in Australia or online, as a retail customer, in
> standard wrapped reams, or indeed any quantity.
>
>
> I frequently print scores as booklets onto A3+ (329x483) and fold in half,
> giving a page size of 242x329. Most A3+ papers are single-sided for photo
> printing and and about 300gsm - the lightest I've found for double-sided
> printing is this: http://www.pcx.com.au/ProductDetail.aspx?ProductId=2871
>
> Nick
>
> ___
> 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: Something wrong with transposing instruments? (Was: Re: Survey: Large scores)

[Kieren MacMillan]

Hi Gilles,

>> [...]
>> 
>> Another thing: For me, also the implementation of transposing
>> instruments is less than ideal (I prefer to write the pitches in
>> concert pitch and have them transposed for the parts, rather than the
>> other way around, as it is implemented at the moment).
>> [...]
> 
> Can you give an example?  To my knowledge, both ways of encoding are
> equally simple in LilyPond. [But I perhaps I misunderstood what you
> mean.]

This wasn’t from me… but I wholeheartedly agree: Lily’s default/built-in 
implementation of transposing instruments is rather incomplete/poor (see, for 
example, 
 and 
 for an 
idea of the problems and workarounds).

I believe there has been some recent improvement via openlilylib, but I haven’t 
had time to investigate

 In any case, the main distro should have much better tools to handle 
transposing instruments more deftly.

Cheers,
Kieren.
___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info


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

Re: Jianpu Notation

[Pierre Perol-Schneider]

Hi David,

I feel really stupid having said such a silly question just after a first
lecture...
Here's some old open source code just in case it'll help you find some
inspiration ;) : http://www.a1soft.com/smusic/
Sorry for the noise,
Cheers,
Pierre

2015-04-18 15:16 GMT+02:00 Super-User :

> Hi Pierre!
>
> I am not talking about a specific kind of music, but a notation widely
> used in east Asia, especially China. It has all aspects in 5-staff
> notation, and shares some notaions of it, but differs in others.
>
> Thanks!
>
> David Zhang
> 发自我的iPad
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Introducing some 'path' drawing tools

[Pierre Perol-Schneider]

Hi Paul

2015-04-18 21:22 GMT+02:00 Paul Morris :

> Hi Pierre,
>
> Looking at this some more I see how it would really be handy for working
> with paths in LilyPond.  Thanks for creating it and sharing it!  I made
> some revisions to the code in the graph-paper file, simplifying things.
> See attached.
>

Thank you Paul!
Much shorter for sure ;) I'll take a closer look tonight


> I’ve had good luck with a different approach: rendering a glyph to SVG
> with LilyPond (possibly scaling it up by a factor of 10 with
> \magnifyStaff), editing it with InkScape (scaling it back down), then
> opening the .svg file in a text editor, and cutting and pasting the path
> coordinates into a LilyPond file as a path stencil.
>
> Usually it’s not a direct cut and paste, some formatting may be needed.
> This svg transformation tool is handy for that:
> http://petercollingridge.appspot.com/svg_transforms
>
> For example, the code below shows a slightly modified whole note glyph
> created using this process.  So I imagine I’ll probably stick with this
> approach for the most part, but it’s good to have solid tools for other
> options!
>

Very interesting, thanks for the tip!

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

Re: 256th notes (was: How to define a non existing grob)

[Pierre Perol-Schneider]

Added to the LSR: http://lsr.di.unimi.it/LSR/Item?id=995

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

Something wrong with transposing instruments? (Was: Re: Survey: Large scores)

[Gilles]

Hi.

[Sorry for the thread hijacking.]


[...]

Another thing: For me, also the implementation of transposing
instruments is less than ideal (I prefer to write the pitches in
concert pitch and have them transposed for the parts, rather than the
other way around, as it is implemented at the moment).
[...]


Can you give an example?  To my knowledge, both ways of encoding are
equally simple in LilyPond. [But I perhaps I misunderstood what you
mean.]

Best regards,
Gilles


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

Re: Survey: Large scores

[Orm Finnendahl]

Hi Kieren,

Am Samstag, den 18. April 2015 um 17:54:44 Uhr (-0400) schrieb Kieren
MacMillan:
>
> Would love to see it, but the link didn’t work for me… =\

 that's strange. I just tried again and it works for me. Could it be
that your browser complained because of a missing certificate as the
system uses https? You have to ignore this message, the server doesn't
have an official certificate.

Here's the link again:

https://www.selma.hfmdk-frankfurt.de/selmafile/f/4e45ac51ea/

Let me know if you still encounter problems and I'll send it in a
private separate mail.

> Curious! For my 57-part orchestra piece, I only used one source file
> for the notes, and one each for the score and part(s). How do you
> break up all your files (beyond, I’m assuming, a notes-source file
> for each instrument), and what do you see as the big benefit(s) of
> having so many source files?

I split up the music of each individual instrument part plus a file
for the time-signatures and for the tempos into separate files plus a
template for each part and the full score.

The music was split up in different sections, so the number of music
parts have to get multiplied by the number of sections.

On top of this I generated lilypond files for each part and each
section which basically just contained include references for the
music and the templates.

I chose this setup because

1. I was not sure how I'd keep the project manageable before I started
as I feared long rendering times and I wanted to be able to write the
piece in non-consecutive order and instrumented the piece directly
into the lilypond score.

2. With the separation of score files and music I could decide at a
later point how to handle divisi parts in the strings and whether they
needed separate parts or not.

To get this done I wrote a lisp script which would generate all the
empty music and lilypond score and part files and the templates in
separate directories and generate the dependencies in the makefile.
That was quite some work but after generating and checking in with git
everything else was downhill...

> This is a big one for me. I would love to see — and would be happy
> to help fund — a GUPPY (Grand Unified Partcombiner Project, Yay!) to
> tackle a rewrite from the ground up, taking into account all the
> recent advances in divisi writing (still only in openlilylib, I
> believe), etc.

I would take part in it as well.

Another thing: For me, also the implementation of transposing
instruments is less than ideal (I prefer to write the pitches in
concert pitch and have them transposed for the parts, rather than the
other way around, as it is implemented at the moment). I would be very
willing to sponsor this.

--
Orm

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

Re: Problem with repeat alternative endings that contain lyrics andleading rests

[Trevor Daniels]

Peter Heisen wrote Wednesday, March 25, 2015 3:42 AM

> In the following modified example, the first beat of each ending has been 
> changed to a rest, and a syllable removed from the lyrics to match.  Now when 
> compiled, it shows two first endings and two second endings.  Moreover the 
> log contains the error "warning: already have a volta spanner, ending that 
> one prematurely". I have scoured the documentation and searched the list 
> archives, and cannot find any mention of this.  Can you help?
>
> \version "2.18.2"
>
> \score {
>  <<
>\new Staff {
>  \time 2/4
>  \new Voice = "melody" {
>\relative c'' {
>  a4 a a a
>  \repeat volta 2 { b4 b }
>  \alternative { { r b } { r c } }
>}
>  }
>}
>\new Lyrics {
>  \lyricsto "melody" {
>Not re -- peat -- ed.
>\repeat volta 2 { Re -- peat }
>\alternative { { twice. } { twice. } }
>  }
>}
>  >>
> }

Rather too late to be of help to the OP, but a simple work-around using the 
usual \hideNotes trick is to define \vrest (think "vocal rest") like this

vrest = << 
  \once \hideNotes b 
  \new Voice \absolute b'\rest
>> 

and use it instead of the normal rest.  You then need to also add a 
corresponding \skip 1 (or "" ) in the lyrics to step over them.  So Peter's 
faulty example becomes:

\version "2.18"

vrest = << 
  \once \hideNotes b 
  \new Voice \absolute b'\rest
>> 

\score {
  <<
\new Staff {
  \time 2/4
  \new Voice = "melody" {
\relative c'' {
  a4 a a a
  \repeat volta 2 { b4 b }
  \alternative { { \vrest b } { \vrest c } }
}
  }
}
\new Lyrics {
  \lyricsto "melody" {
Not re -- peat -- ed.
\repeat volta 2 { Re -- peat }
\alternative { { "" twice. } { "" twice. } }
  }
}
  >>
}


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

Re: "procedure" vs. "function"

[Andrew Bernard]

Yes, it is quite muddy!

I just took a look at the Guile 2.0 reference manual. Generally they use 
procedure but the book also uses the term function interchangeably further on 
inside, so I suppose it does not matter so much! No doubt the book is written 
by a large team of authors.

An argument for using one single term is that by using two terms, it implies 
the possibility that they refer to two different things, which is not the case 
(hence the confusion about returning a value or not).

Andrew

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

Re: Specifying output format in the .ly file?

[Anton Curl]

Hi Peter,

I don't know if it's possible to specify the output format in the 
Lilypond file, but you can choose the paper size from the command line:

http://www.lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage

Then you have two commands to run, but you don't have to update your 
Lilypond file.
If you absolutely want to run only one command, you can put them in a 
script or use a Makefile.


Anton Curl

On 19/04/2015 04:13, Peter Crighton wrote:

Hello all,

is it possible to not specify the output format via the command line, 
but instead directly in the .ly file? I want to have a score typeset 
with two different page sizes – one as a PDF file and the other one as 
one PNG per page.
Currently I have to switch the paper size every time I want to have 
one of the output formats and then use the appropriate command line 
options.
Ideally, I would like to have two separate book blocks which share the 
same music input, but have different paper blocks, and then just run 
LilyPond once to get my PDF with paper size 1 and a lot of PNGs with 
paper size 2.


--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de


___
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: B Series paper

[Nick Payne]

On 19/04/2015 18:46, Andrew Bernard wrote:

Dear Ponderers,

Down under here in Australia we use A4 and A3. A4 is just too small 
for piano music, and A3 is generally too big to fit on the music desk 
comfortably.


The ideal size for me is Klavierformat (235x310mm) which is the 
standard size of editions such as Henle and so on. This paper size is 
unobtainable except as a printer’s trim size. The next best thing is B4.


Consumer A3 printers will take B4 paper. But I am completely unable to 
find a source of cut B4 in Australia or online, as a retail customer, 
in standard wrapped reams, or indeed any quantity.


I frequently print scores as booklets onto A3+ (329x483) and fold in 
half, giving a page size of 242x329. Most A3+ papers are single-sided 
for photo printing and and about 300gsm - the lightest I've found for 
double-sided printing is this: 
http://www.pcx.com.au/ProductDetail.aspx?ProductId=2871


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

Re: "procedure" vs. "function"

[Urs Liska]

Am 19. April 2015 10:35:08 MESZ, schrieb Andrew Bernard 
:
>Well if you consult the bible Structure and Interpretation of Computer
>Programs by Abelson, Sussman, and Sussman, the term function is
>strictly reserved for mathematical objects, and procedure is uniformly
>used for what people loosely call functions.
>
>As to the discussion about the distinction between procedure and
>function in other languages, from a pure functional programming
>viewpoint a procedure in Pascal and so on is called purely for its side
>effects, on global variables (horror!) for example,  which is why it
>does not return a value, and this is a complete abomination. Of course
>Scheme is a functional language but not pure like Haskell, so this is
>academic in the context of lilypond. Still preferable to avoid
>procedures that are invoked purely for side effects whether your
>language is pure or impure.
>
>So the guile manual is correct to uniformly use the term procedure. But
>if you look at the Racket manual they consistently use the term
>Functions (Procedures) in headings, so they are somewhat looser.
>
>In short, procedure and function are most certainly not synonyms in
>Scheme terminology.
>

Well, I'm still not clear about that really.

As far as I have understood the discussion everything that is called as
(Identifier arg1 arg2 ...)
should be called a procedure in Guile's terminology. Such a procedure can 
evaluate to something or not (in which case the expression's type/value is 
. 

These procedures can also be referred to as functions which is (strictly 
speaking) against the Guile terminology, but doesn't actually pose a problem.
If I'm not mistaken LilyPond’s naming of define-music-function and the type 
 are similarly against the Guile terminology. 
Referring to the fact it does return a value doesn't really make sense as 
that's what procedures do in Guile and because define-void-function creates a 
procedure without return value.

Is that correct?

Urs


>Andrew


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

B Series paper

[Andrew Bernard]

Dear Ponderers,

Down under here in Australia we use A4 and A3. A4 is just too small for piano 
music, and A3 is generally too big to fit on the music desk comfortably.

The ideal size for me is Klavierformat (235x310mm) which is the standard size 
of editions such as Henle and so on. This paper size is unobtainable except as 
a printer’s trim size. The next best thing is B4.

Consumer A3 printers will take B4 paper. But I am completely unable to find a 
source of cut B4 in Australia or online, as a retail customer, in standard 
wrapped reams, or indeed any quantity. [To be accurate, I did find a supplier 
whose minimum order was 100 metric tons.]

The question is, does anybody know if and where B4 can be obtained, or is it 
only a trim size for offset printers?

Andrew




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

Re: Slur inside tuplet bracket

[Andrew Bernard]

Thank you!

I have been using 

\override TupletBracket.avoid-slur = #’outside

to no effect.

Why do you have to adjust the number but not the bracket? Not entirely obvious.

Andrew


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

Re: "procedure" vs. "function"

[Andrew Bernard]

Well if you consult the bible Structure and Interpretation of Computer Programs 
by Abelson, Sussman, and Sussman, the term function is strictly reserved for 
mathematical objects, and procedure is uniformly used for what people loosely 
call functions.

As to the discussion about the distinction between procedure and function in 
other languages, from a pure functional programming viewpoint a procedure in 
Pascal and so on is called purely for its side effects, on global variables 
(horror!) for example,  which is why it does not return a value, and this is a 
complete abomination. Of course Scheme is a functional language but not pure 
like Haskell, so this is academic in the context of lilypond. Still preferable 
to avoid procedures that are invoked purely for side effects whether your 
language is pure or impure.

So the guile manual is correct to uniformly use the term procedure. But if you 
look at the Racket manual they consistently use the term Functions (Procedures) 
in headings, so they are somewhat looser.

In short, procedure and function are most certainly not synonyms in Scheme 
terminology.

Andrew

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

Re: title_page

[Urs Liska]

Am 19. April 2015 10:09:53 MESZ, schrieb Richard Shann 
:
>On Sat, 2015-04-18 at 23:33 +, bobr...@centrum.is wrote:
>> I'm trying to make a title/cover page within LilyPond.  I'm aware of
>the possibility of workarounds:
>> 
>> lilypond-book/LaTeX; Strikes me as a bit ham-fisted, not sure if I
>would run into trouble as I've seen the warning about \pageBreak not
>playing well with lilypond-book
>> 
>> Create separate title/cover page in LaTeX and assemble the PDFs;
>seems a bit kludgy, though should work just fine.  Failing any more
>integrated approach I would probably do this.

If you don' t find a proper solution I suggest to create the "whole volume" 
file with LaTeX and include the scores with \includepdf.

What I've done along that line (but I also had other textual pages in between) 
is let LaTeX also do the headers and footers and create the TOC.
Quite integrated, I think.

HTH
Urs

>> 
>> I tried to find a LilyPond-only solution but have yet to succeed. 
>What I would like is to have a fairly simple page; composer, title, and
>instrument.  All centered, in a column, all in a fairly large font with
>the title being quite large.  It would be very nice if these items
>could be taken from those relative fields in the overall \header{}
>block.
>> 
>> Does such a solution already exist?
>
>>  
>There is a snippet from Nicolas Sceaux which does this - it is
>incorporated (in a modified form) in Denemo's output you can find
>the .ily here
>
>http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob_plain;f=actions/lilypond/simplified-book-titling.ily;hb=HEAD
>
>
>Richard
>
>>  If not, isn't this something that should be available?
>> 
>> -David
>> 
>> 
>> ___
>> 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: title_page

[Richard Shann]

On Sat, 2015-04-18 at 23:33 +, bobr...@centrum.is wrote:
> I'm trying to make a title/cover page within LilyPond.  I'm aware of the 
> possibility of workarounds:
> 
> lilypond-book/LaTeX; Strikes me as a bit ham-fisted, not sure if I would run 
> into trouble as I've seen the warning about \pageBreak not playing well with 
> lilypond-book
> 
> Create separate title/cover page in LaTeX and assemble the PDFs; seems a bit 
> kludgy, though should work just fine.  Failing any more integrated approach I 
> would probably do this.
> 
> I tried to find a LilyPond-only solution but have yet to succeed.  What I 
> would like is to have a fairly simple page; composer, title, and instrument.  
> All centered, in a column, all in a fairly large font with the title being 
> quite large.  It would be very nice if these items could be taken from those 
> relative fields in the overall \header{} block.
> 
> Does such a solution already exist?

>  
There is a snippet from Nicolas Sceaux which does this - it is
incorporated (in a modified form) in Denemo's output you can find
the .ily here

http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob_plain;f=actions/lilypond/simplified-book-titling.ily;hb=HEAD


Richard

>  If not, isn't this something that should be available?
> 
> -David
> 
> 
> ___
> 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