barNumberCheck with repeats

2016-11-08 Thread Robert Schmaus

Dear Ponderers,

I've got the following question about a problem involving bar number 
checks and repeats. When I'm engraving a bigger project, I find it 
useful to employ bar number checks. I also find it very useful to use 
the technique of having seperate layout and midi score blocks, the 
latter with \unfoldRepeats, as described here:

http://lilypond.org/doc/v2.18/Documentation/notation/repeats-in-midi

However, if there are "repeat volta" sections present in the score, all 
bar number checks seem to be off in the midi generation. Consider the 
following snippet:


%%%
\version "2.19.35"

music = \relative c'' {

  \barNumberCheck #1
  c c c c

  \barNumberCheck #2
  \repeat volta 2 { d d d d }

  \barNumberCheck #3
  e e e e
}

\score {
  \unfoldRepeats
  \music
  \layout{}
}
%%%

If unfoldRepeat is used in the score block, the bar number check 
(sensibly) expects the last bar to be bar # 4, not 3.


As workaround, I could leave out \unfoldRepeats while creating the score 
and just use it for the final engraving. But there might be some trick 
to have the bar number checks supressed in a score block - does anyone know?


Thanks!
Best,
Robert

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


Re: color in polyphony

2016-11-08 Thread David Kastrup
Mario Moles  writes:

> Hello guys! You can color a single note in ? If you use  \override NoteHead.color = #red b> error happens.

If you don't want to learn too much new (or want to use one of the
shortcut commands for creating an override), you can convert an override
(which holds at one or more time steps and thus cannot occur in a chord)
into a tweak (which works on a single _item_) by preceding it with
\single , like



-- 
David Kastrup

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


Re: color in polyphony

2016-11-08 Thread Mario Moles
In data mercoledì 9 novembre 2016 07:59:41, Jan-Peter Voigt ha scritto:
> Hi Mario
> 
> in this case use the \tweak command:
> 
> {  }
> 
> HTH Jan-Peter
Oh! Good!
Thanks a lot! :)-- 
/oiram/bin/selom/
/Da ognuno secondo le proprie capacità ad ognuno secondo i propri 
bisogni./
/MIB-kernellinux-tester/
http://mariomoles.altervista.org/[1] 
Linux[2] 
MIB[3] Lilypond[4] Frescobaldi[5] Rosegarden[6] 


[1] http://mariomoles.altervista.org/
[2] https://www.kernel.org/
[3] http://mib.pianetalinux.org/blog/
[4] http://lilypond.org/
[5] http://www.frescobaldi.org/
[6] http://www.rosegardenmusic.com/
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: color in polyphony

2016-11-08 Thread Jan-Peter Voigt

Hi Mario

in this case use the \tweak command:

{  }

HTH Jan-Peter


Am 09.11.2016 um 07:56 schrieb Mario Moles:


Hello guys! You can color a single note in ? If you use \override NoteHead.color = #red b> error happens. Thanks


--

oiram/bin/selom

Da ognuno secondo le proprie capacità ad ognuno secondo i propri bisogni.

MIB-kernellinux-tester

http://mariomoles.altervista.org/

Linux 

MIB  Lilypond 
 Frescobaldi  
Rosegarden 




___
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


color in polyphony

2016-11-08 Thread Mario Moles
Hello guys! You can color a single note in ? If you use  error happens.

-- 
/oiram/bin/selom/
/Da ognuno secondo le proprie capacità ad ognuno secondo i propri 
bisogni./
/MIB-kernellinux-tester/
http://mariomoles.altervista.org/[1] 
Linux[2] 
MIB[3] Lilypond[4] Frescobaldi[5] Rosegarden[6] 


[1] http://mariomoles.altervista.org/
[2] https://www.kernel.org/
[3] http://mib.pianetalinux.org/blog/
[4] http://lilypond.org/
[5] http://www.frescobaldi.org/
[6] http://www.rosegardenmusic.com/
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Karlin High
On 11/8/2016 8:14 PM, Andrew Bernard wrote:
> For this person who insults us takes the cowardly
> approach of hiding behind anonymity, against all conventions of mailing list
> communities

I expect this person experiences the lilypond-user list as a web forum 
via Nabble rather than a mailing list.

In another online community, the grc.com newsgroups (Steve Gibson, 
SecurityNow, SpinRite, ShieldsUp, etc) which are NNTP-only and not even 
email, there is a recurring claim that quality of discussions stays 
higher on a newsgroup if it's not mindlessly easy for any passerby to 
post messages to it. I am not suggesting that lilypond-user should 
emulate that, though. Rather, I've been favorably impressed with the 
considerable grace and intelligence shown here to various 
less-experienced users, who occasionally or usually fail to abide by 
community norms. But of course, you can't barge into an established 
community, push all the hot buttons in sight, and expect lots of love 
and respect for doing so.
--
Karlin High
Missouri, USA

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


RE: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Andrew Bernard
Hello Carl,

I engrave scores for a colleague who is a prominent representative of the
New Complexity School. Recently, with the advent of people such as Phantomas
here (Thanks, Urs! For this person who insults us takes the cowardly
approach of hiding behind anonymity, against all conventions of mailing list
communities) the intent of the New Complexity founders seems to have been
distorted into self indulgent complexity for its own sake, resulting in
unplayable scores of no real artistic value. To this extent, since the
concept has been devalued and polluted, most New Complexity composers now
distance themselves from this term. One can see why. We have a good (bad?)
example here.

But I just wanted to mention that in my work over the last couple of years I
have been able to develop an extensive library of Scheme code and various
extensions that enable me to set music that is only partly similar to the
Common Era period notation that lilypond excels in. It is a tribute to the
extraordinary excellence of lilypond that it can be made to create scores of
a type never originally envisioned, with a high degree of beauty. I am also
at great pains to point out that I could never have built up this library
without the kind generosity and open heartedness of the skilled list members
here: Thomas Morley, David Kastrup, Urs Liska, David Nalesnik, Simon
Albrecht, David Wright, Kieran MacMillan, and many others (pardon me for
omitting names!). Without their unstinting help I could not have achieved
the excellence in my engraving that people comment on so positively. This
sort of result takes a lot of effort, but success can be achieved.

This is a valuable and precious community. Those like Phantomas who do not
understand this are free to start their own communities. Perhaps they
should.

Andrew



-Original Message-
From: lilypond-user
[mailto:lilypond-user-bounces+andrew.bernard=gmail@gnu.org] On Behalf Of
Carl Sorensen
Sent: Wednesday, 9 November 2016 11:50 AM
To: mclaren ; lilypond-user@gnu.org
Subject: Re: How to get irrational tuplets inside a regular meter like 9/8


If you look at the founding documents for LilyPond, you will see that
LilyPond was not created to be a tool for representing New Complexity
scores.  In fact, the essay says:

"LilyPond is inspired by traditional manual engravings published by European
music publishers in and towards the end of the first half of the twentieth
century, including Bärenreiter, Duhem, Durand, Hofmeister, Peters, and
Schott. This is sometimes regarded as the peak of traditional musical
engraving practice. As we have studied these editions we have learned a
great deal about what goes into a well-engraved score, and the aspects that
we wanted to imitate in LilyPond.":

LilyPond's target is traditional musical engraving.  Anything else is gravy.



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


Re: Combining \markup and \set

2016-11-08 Thread Flaming Hakama by Elaine
> Subject: Re: Combining \markup and \set
> - Original Message - From: "David Sumbler" 
> To: 
> Sent: Tuesday, November 08, 2016 3:14 PM
> Subject: Combining \markup and \set
>
>
> 
>>
>> \version "2.19.48"
>>
>> pizz = \markup { \larger \italic "pizz." }
>> midiPizz = \set Staff.midiInstrument = "pizzicato strings"
>>
>> arco = \markup { \larger \italic "arco" }
>> midiArco = \set Staff.midiInstrument = "violin"
>>
>> \score {
>> \relative c'' {
>> \new Staff \with { midiInstrument = "violin" } {
>> c2 \midiPizz c4^\pizz c |
>> \midiArco c2^\arco r \bar "|."
>> }
>> }
>> \layout { }
>> \midi { }
>> }
>>
>> 
>>
>> The above works as I would wish it to. However, I am wondering whether
>> it can be simplified.
>>
>> 1) Is there a way of combining \pizz and \midiPizz into one variable?
>> Preferably it needs to be attached to the note (as \pizz already is)
>> so that the printed marking can be placed above or below the stave.
>> Similarly, of course, for \arco and \midiArco.
>>
>> 2) '\unset Staff.midiInstrument' would be preferable to 'set
>> Staff.midiInstrument = "violin"', because it would not need to be
>> redefined in each instrumental part. However it does not work in a
>> voice context. Is there a way of reverting the midiInstrument to its
>> previous setting which could still be included in a variable?
>>
>> David
>>
>

Just curious, does changing the Staff.midiInstrument midstream produce more
than one MIDI track?



Below is one way to simplify your expressions.

I wasn't happy with this solution in that I couldn't find a way to apply a
markup to the music expression $note within the music function, and instead
had to apply it to an empty chord preceding the note.



\version "2.19.15"

pizz = \markup { \larger \italic "pizz." }
midiPizz = \set Staff.midiInstrument = "pizzicato strings"
myPizz = #(define-music-function (parser location note) (ly:music?) #{
{ \midiPizz <>^\pizz $note  }
#})

arco = \markup { \larger \italic "arco." }
midiArco = \set Staff.midiInstrument = "violin"
myArco = #(define-music-function (parser location note) (ly:music?) #{
{ \midiArco <>^\arco $note  }
#})

\score {
\new Staff \with { midiInstrument = "violin" } {
\relative c'' {

c2 \midiPizz c4^\pizz c |
\midiArco c2^\arco r \bar "|." \break

c2 \myPizz c4 c |
\myArco c2 r \bar "|."
}
}
\layout { }
\midi { }
}





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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Carl Sorensen


On 11/8/16 4:02 PM, "mclaren"  wrote:

>Whatever Lilypond is doing internally, there's some arbitrary limit to the
>numbers it uses. Time signatures above some large value cause a crash. Too
>many tuplets of too many different kinds causes Lilypond to crash.
>
>There's no reason for that. None whatever. A competent programmer would
>not
>impose some arbitrary limit on internal number values, other than floating
>point overflow, or 64-bit integer limits. It seems safe to say that a
>64-bit
>integer is going to allow any time signature a user might conceivably
>need.
>Instead, when you get to time signature above a few thousand, Lilypond
>crashes and gives an error.

Well, currently LilyPond uses 64-bit integers for the numerator and
denominator of the Rational type.  So at least the design decision appears
to be 64-bit integers.

>
>That's stupid, because adding broken tuplets inside a measure quickly
>increases the time signature. A quick Fermi estimate shows that if you use
>prime number tuplets, you're going to get a time signature roughly on the
>order of whatever prime number you're using factorial times a few
>thousand.
>Since 10 factor is more than a mllion, using tuplets from (say) 3 through
>23
>is going to give you a time signature in the ballpark of
>23*19*17*13*11*7*5*3 times several thousand.  That value is ~
>111,546,435*10,000, or slightly over a trillion. Anyone who knows anything
>about how broken tuplets work will recognize instantly that when you've
>got
>7 or 8 or 10 prime numbers, finding the lowest common denominator is going
>to produce large numbers very quickly. That's 3rd grade arithmetic. Didn't
>the programmers who worked on Lilypond's internal ever pass 3rd grade
>arithmetic?

I guess not.  I only have a PhD in Materials Science and a BS in Physics.
SO I never passed 3rd grade arithmetic.  I'm sorry.  Perhaps you should
show us how LilyPond should be programmed.

>
>Reality check: programmers are ont in the business of telling composers
>how
>they should compose.

Reality check: nobody programming on LilyPond is in business.  We're all
doing it on a volunteer basis.

When you pay for LilyPond, then you have some basis for demanding
something.  Other than that, you are getting whatever value you get simply
off the generosity of others.

If someone offers you a free prime rib, it's pretty rude to complain it's
not filet mignon.

As a matter of fact, if someone offers you a free hamburger, it's pretty
rude to complain it's not a cheeseburger.

>Programmers should be in the business of getting the
>computer to represent the kinds of notatoins that musicians use. Musicians
>use broken tuplets nowadays. Lots of composers use lots of broken tuplets.
>Setting up Lilypond so that it crashes if you use too many broken tuplets
>in
>a measure is ridiculous. It's on the level of setting up Lilypond to crash
>if the user tries to enter a time signature other than 4/4, or note values
>smaller than a sixteenth note.

If you look at the founding documents for LilyPond, you will see that
LilyPond was not created to be a tool for representing New Complexity
scores.  In fact, the essay says:

"LilyPond is inspired by traditional manual engravings published by
European music publishers in and towards the end of the first half of the
twentieth century, including Bärenreiter, Duhem, Durand, Hofmeister,
Peters, and Schott. This is sometimes regarded as the peak of traditional
musical engraving practice. As we have studied these editions we have
learned a great deal about what goes into a well-engraved score, and the
aspects that we wanted to imitate in LilyPond.":

LilyPond's target is traditional musical engraving.  Anything else is
gravy.

It's getting a bit old hearing from you that the volunteer LilyPond
development team should be your slaves, to produce code that meets your
imperious demands, and satisfies your expectations.

One of the things I love about working on LilyPond is that it is
open-source, so if there's something I want, I can add it.  And then it's
available to others.

If you want the ability to use huge time signatures with broken tuplets,
nobody is stopping you from implementing it in LilyPond.  And if you came
and asked how it might be done, I think you'd get people offering help.

But when you come in and call us all stupid, it certainly destroys my
motivation for helping you.  The way you have insulted me and, more
importantly, my friends, who have spent thousands of hours creating a
wonderful tool makes me unwilling to even look at the problems you've
identified.  After all, there are plenty of other issues that are mor
significant for my use of LilyPond and that will help people who are
friendly, kind, and helpful.

I don't know why your emails take the tone that they do.  I'm not saying
you need to do anything different; you are free to behave as you choose
to.  But I have decided to take one shot at informing you that your
behavior decreases the 

Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Urs Liska


Am 09.11.2016 um 01:25 schrieb Carl Sorensen:
>
> On 11/8/16 4:02 PM, "mclaren"  wrote:
>
>> Reality check: programmers are ont in the business of telling composers
>> how
>> they should compose. Programmers should be in the business of getting the
>> computer to represent the kinds of notatoins that musicians use. Musicians
>> use broken tuplets nowadays. Lots of composers use lots of broken tuplets.
>> Setting up Lilypond so that it crashes if you use too many broken tuplets
>> in
>> a measure is ridiculous. It's on the level of setting up Lilypond to crash
>> if the user tries to enter a time signature other than 4/4, or note values
>> smaller than a sixteenth note.
>
> Patches are always welcome.

It's ridiculous to ask Phantomas for patches, I'd say. He/she is the
musician and we're the programmers. So it's *our* historic duty to
develop what he/she needs to perform his/her art. If we should grow
beyond our inherent incompetence, that is ;-)

>
> Thanks,
>
> Carl
>
>
> ___
> 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: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Carl Sorensen


On 11/8/16 4:02 PM, "mclaren"  wrote:

>
>Reality check: programmers are ont in the business of telling composers
>how
>they should compose. Programmers should be in the business of getting the
>computer to represent the kinds of notatoins that musicians use. Musicians
>use broken tuplets nowadays. Lots of composers use lots of broken tuplets.
>Setting up Lilypond so that it crashes if you use too many broken tuplets
>in
>a measure is ridiculous. It's on the level of setting up Lilypond to crash
>if the user tries to enter a time signature other than 4/4, or note values
>smaller than a sixteenth note.


Patches are always welcome.

Thanks,

Carl


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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread David Kastrup
mclaren  writes:

> Whatever Lilypond is doing internally, there's some arbitrary limit to the
> numbers it uses. Time signatures above some large value cause a crash. Too
> many tuplets of too many different kinds causes Lilypond to crash. 
>
> There's no reason for that. None whatever.

Since you know how it is done right, your patches are awaited eagerly.

> A competent programmer would not impose some arbitrary limit on
> internal number values, other than floating point overflow, or 64-bit
> integer limits. It seems safe to say that a 64-bit integer is going to
> allow any time signature a user might conceivably need.

Reality check: LilyPond does use 64bit numbers for the constituents of
its rational numbers.  Its rational numbers were conceived before Guile
gained its own "arbitrary" precision arithmetic.

Its just that 64bit numbers are exhausted pretty fast if you start
adding numbers with unrelated denominators.

Your "it seems safe to say" statement is exactly underlying LilyPond's
implementation.

> Instead, when you get to time signature above a few thousand, Lilypond
> crashes and gives an error.

Above a few thousand _what_?  LilyPond does not have a problem with such
time signatures, but if you keep adding material with _different_
denominators into it, the resulting fraction elements and/or the
intermediate results when manipulating them exceed the 64bit range.

> That's stupid, because adding broken tuplets inside a measure quickly
> increases the time signature. A quick Fermi estimate shows that if you
> use prime number tuplets, you're going to get a time signature roughly
> on the order of whatever prime number you're using factorial times a
> few thousand.  Since 10 factor is more than a mllion, using tuplets
> from (say) 3 through 23 is going to give you a time signature in the
> ballpark of 23*19*17*13*11*7*5*3 times several thousand.  That value
> is ~ 111,546,435*10,000, or slightly over a trillion. Anyone who knows
> anything about how broken tuplets work will recognize instantly that
> when you've got 7 or 8 or 10 prime numbers, finding the lowest common
> denominator is going to produce large numbers very quickly. That's 3rd
> grade arithmetic. Didn't the programmers who worked on Lilypond's
> internal ever pass 3rd grade arithmetic?

You mean, the programmers implementing exactly the reasoning you give
yourself?

> The point is that whatever Lilypond is doing internally, on a computer
> with 64 bit integers, there is absolutely no reason whatsoever to
> arbitrarily limit Lilypond to some small internal value such that the
> program crashes when you try to enter a time signature above a few
> thousand. That's ridiculous.

Uh, do you understand what fractions are?  Basically you are ranting at
your own statements here and it looks silly.

> Reality check: programmers are ont in the business of telling
> composers how they should compose. Programmers should be in the
> business of getting the computer to represent the kinds of notatoins
> that musicians use.

You still don't understand.  There are not two different classes of
people working on or with LilyPond.  Stuff that people (who usually are
both musicians and programmers to various degree) want to do they might
do.

Your rants make for really piss-poor motivational material however.
I actually happen to have a (pretty stale) branch where I started
replacing the use of the home-brewn rationals in musical moments with
Guile's "arbitrary" precision ones.  I can send it to you and you can
try to continue working on it.  It is a whole lot of work, though, and
integrating it with garbage collection is not going to be small feat.

There are a lot of things in LilyPond that have not been implemented
because nobody could be found who cared enough to go through with it.
If it is important to you and you don't feel up to do it yourself, you
may want to set a bounty on that feature.  However, for a large-scale
task like that, an amount that would be alone motivation enough to do it
will not exactly be small.  And your communication style does not
exactly provide additional motivation or an incentive to pool resources
with you.

You are so much more smart than everybody else, so why don't you do it
yourself?

-- 
David Kastrup

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Nathan Ho

On 2016-11-08 15:02, mclaren wrote:
Whatever Lilypond is doing internally, there's some arbitrary limit to 
the
numbers it uses. Time signatures above some large value cause a crash. 
Too

many tuplets of too many different kinds causes Lilypond to crash.


Hi mclaren,

So you found bugs in LilyPond. In fact, I can reproduce the time 
signature issue in 2.19.50, since this code causes LilyPond to hang:


{
  \time 99/1
  s1
}

You don't need to go on a whole rant about how it's stupid or unmusical, 
and you don't need to accuse LilyPond of being backed by a conspiracy of 
programmers out to destroy music. It's a mistake, plain and simple, and 
it was overlooked because nobody has reported it before, and nobody has 
reported it before because such time signatures are extremely rare. I 
certainly would not expect to see them outside of "score as art" works, 
such as some of Tom Johnson's graphic scores or John Stump's infamous 
parody engravings.


I agree that these limitations are flaws in LilyPond that should be 
fixed. Maybe if you could grow up and stop being so entitled and 
accusative, the dev team would be willing to accommodate these needs, 
prioritization issues notwithstanding.



Nathan

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


Re: Notational conventions

2016-11-08 Thread Thomas Morley
2016-11-09 0:07 GMT+01:00 Hans Åberg :
>
>> On 8 Nov 2016, at 23:41, Thomas Morley  wrote:
>>
>> 2016-11-08 22:20 GMT+01:00 Hans Åberg :
>>
>>> And a reason of writing a complex time signature might be to make it 
>>> impossible for the performer to follow it: In Balkan music, one plays by 
>>> ear, and the variation is greater than the irrational time signature 
>>> examples I gave. A Western musician when seeing 12/8, 12 = 3+2+2+3+2 with 
>>> quadruplets on them, might try to play it as exactly as possible, but that 
>>> is not how it should be performed.
>>
>> Let me step in here.
>>
>> This sounds (partly) like obfuscating the music to force the reader of
>> the score to do some thorough studies before trying to perform.
>
> Western composers have done it for a long time. Somebody wrote time 
> signatures with e and pi decades ago, and modern complexity takes it to an 
> another level. Cf.
>   https://www.youtube.com/watch?v=46w99bZ3W_M
>
> As for myself, I just happened to discover a way to typeset it.
>
>> Isn't it a good idea to do _always_ such studies?
>> You can't even perform baroque-music adequat without them.
>> Another example, I recall several printed editions of
>> Flamenco-Alegrias in 3/4, but following exactly the 3/4 would come out
>> completely wrong. It's often easier to get an raw glance, though.
>>
>> Reading a score is not (and never was) enough to get an impression how
>> the music _should_ sound or to perform it.
>>
>> So I ask myself, why make it even more difficult for the reader with
>> impossible things?
>
> But for whom do you notate? Flamenco music does not notate the correct time 
> signature. If you would toss skilled Western musicians a score, how would you 
> notate it? Getting them to study Flamenco music and its notational traditions 
> would be very costly.
>

Isn't _every_ written notation an approximation? Baroque often notates
only a skeleton and the musician performing it has to fill in,
ofcourse needing the knowledge howto. (Only one example, a plethora of
others existing)

And I _am_ a western musician, who learned Flamenco.
I looked for and found a good teacher and yes, this costs money.

Cheers,
  Harm

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Urs Liska
So you have learned nothing so far? Instead of cooperating with the
community to narrow down possible actual issues (as we've requested more
than enough) you simply stop answering the threads you opened and throw
lots of new material at LilyPond and us.

At the same time insulting us and demanding assistance although you have
never paid for anything that would *entitle* you to support?

Seriously, did anyone teach you how to behave in a human community when
you were a child? Let alone in a virtual community where you have to
expect all sorts of cultural differences and possible misunderstandings?


Am 09.11.2016 um 00:02 schrieb mclaren:
> Reality check: 

PLEASE: provide us with a reality check. Before claiming a single time
again that LilyPond is stupid or fails at baby tasks please show us how
you achieve these baby tasks with Finale, Sibelius or any other notation
program.
Or shut up.

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


RE: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Andrew Bernard
@metachromatic - we still don't know your name,

One is becoming tired of your shouting rants against programmers and
lilypond and your fantasies about what you somehow expect it can do. It is
about time the list moderator stepped in.

Use a different program if lilypond is not up to your standards, and stop
adding ranting noise to this list, and hooking people in to waste their time
refuting nonsense.

Andrew



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


Notational conventions

2016-11-08 Thread Hans Åberg

> On 8 Nov 2016, at 23:41, Thomas Morley  wrote:
> 
> 2016-11-08 22:20 GMT+01:00 Hans Åberg :
> 
>> And a reason of writing a complex time signature might be to make it 
>> impossible for the performer to follow it: In Balkan music, one plays by 
>> ear, and the variation is greater than the irrational time signature 
>> examples I gave. A Western musician when seeing 12/8, 12 = 3+2+2+3+2 with 
>> quadruplets on them, might try to play it as exactly as possible, but that 
>> is not how it should be performed.
> 
> Let me step in here.
> 
> This sounds (partly) like obfuscating the music to force the reader of
> the score to do some thorough studies before trying to perform.

Western composers have done it for a long time. Somebody wrote time signatures 
with e and pi decades ago, and modern complexity takes it to an another level. 
Cf.
  https://www.youtube.com/watch?v=46w99bZ3W_M

As for myself, I just happened to discover a way to typeset it.

> Isn't it a good idea to do _always_ such studies?
> You can't even perform baroque-music adequat without them.
> Another example, I recall several printed editions of
> Flamenco-Alegrias in 3/4, but following exactly the 3/4 would come out
> completely wrong. It's often easier to get an raw glance, though.
> 
> Reading a score is not (and never was) enough to get an impression how
> the music _should_ sound or to perform it.
> 
> So I ask myself, why make it even more difficult for the reader with
> impossible things?

But for whom do you notate? Flamenco music does not notate the correct time 
signature. If you would toss skilled Western musicians a score, how would you 
notate it? Getting them to study Flamenco music and its notational traditions 
would be very costly.



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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread mclaren
Whatever Lilypond is doing internally, there's some arbitrary limit to the
numbers it uses. Time signatures above some large value cause a crash. Too
many tuplets of too many different kinds causes Lilypond to crash. 

There's no reason for that. None whatever. A competent programmer would not
impose some arbitrary limit on internal number values, other than floating
point overflow, or 64-bit integer limits. It seems safe to say that a 64-bit
integer is going to allow any time signature a user might conceivably need.
Instead, when you get to time signature above a few thousand, Lilypond
crashes and gives an error.

That's stupid, because adding broken tuplets inside a measure quickly
increases the time signature. A quick Fermi estimate shows that if you use
prime number tuplets, you're going to get a time signature roughly on the
order of whatever prime number you're using factorial times a few thousand.
Since 10 factor is more than a mllion, using tuplets from (say) 3 through 23
is going to give you a time signature in the ballpark of
23*19*17*13*11*7*5*3 times several thousand.  That value is ~
111,546,435*10,000, or slightly over a trillion. Anyone who knows anything
about how broken tuplets work will recognize instantly that when you've got
7 or 8 or 10 prime numbers, finding the lowest common denominator is going
to produce large numbers very quickly. That's 3rd grade arithmetic. Didn't
the programmers who worked on Lilypond's internal ever pass 3rd grade
arithmetic?

The point is that whatever Lilypond is doing internally, on a computer with
64 bit integers, there is absolutely no reason whatsoever to arbitrarily
limit Lilypond to some small internal value such that the program crashes
when you try to enter a time signature above a few thousand. That's
ridiculous. 

Moreover, there's a good solid practical reason why musicians might want to
use large time signatures. Lots of different broken tuplets inside a measure
require a large time signature. There's absolutely no reason not to allow
one.

Naturally, the varoius people on this forum will try to claim that "no one
would ever want to do that" or "musicians should not be using lots of broken
tuplets in a measure."

Reality check: programmers are ont in the business of telling composers how
they should compose. Programmers should be in the business of getting the
computer to represent the kinds of notatoins that musicians use. Musicians
use broken tuplets nowadays. Lots of composers use lots of broken tuplets.
Setting up Lilypond so that it crashes if you use too many broken tuplets in
a measure is ridiculous. It's on the level of setting up Lilypond to crash
if the user tries to enter a time signature other than 4/4, or note values
smaller than a sixteenth note. 



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-get-irrational-tuplets-inside-a-regular-meter-like-9-8-tp196323p196358.html
Sent from the User mailing list archive at Nabble.com.

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


Re: [Why you don't really want] irrational tuplets [nor CF approximations]

2016-11-08 Thread Thomas Morley
2016-11-08 22:20 GMT+01:00 Hans Åberg :

> And a reason of writing a complex time signature might be to make it 
> impossible for the performer to follow it: In Balkan music, one plays by ear, 
> and the variation is greater than the irrational time signature examples I 
> gave. A Western musician when seeing 12/8, 12 = 3+2+2+3+2 with quadruplets on 
> them, might try to play it as exactly as possible, but that is not how it 
> should be performed.

Let me step in here.

This sounds (partly) like obfuscating the music to force the reader of
the score to do some thorough studies before trying to perform.

Isn't it a good idea to do _always_ such studies?
You can't even perform baroque-music adequat without them.
Another example, I recall several printed editions of
Flamenco-Alegrias in 3/4, but following exactly the 3/4 would come out
completely wrong. It's often easier to get an raw glance, though.

Reading a score is not (and never was) enough to get an impression how
the music _should_ sound or to perform it.

So I ask myself, why make it even more difficult for the reader with
impossible things?

Cheers,
  Harm

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


Re: e in the time of phi and square root of pi tuplet hijinks

2016-11-08 Thread mclaren
Okay, here's the complete version with Unicode chars escaped into the score.
A proper Greek phi and pi symbol. Adding Unicode chars turns out to be dead
simple in Lilypond. 


 

And here's the Lilypond code:

\version "2.18.2"

above = { \once \override Script #'script-priority = #-100 } 
below = { \once \override TextScript #'script-priority = #-100 } 


irrtupleta = \once \override TupletNumber.text = 
 \markup \concat { 

   "e:" \char ##x03D5  
   
 } 
 
 irrtupletb = \once \override TupletNumber.text = 
 \markup \concat { 

   \tiny "√" 
   \hspace #-0.15 
   \override #'(offset . -16) 
   \override #'(thickness . 1.6) 
   \underline \char ##x03c0  
   ":"
  
   "1"
 } 
  

<<
   
   \new Staff { \clef "treble"
\time 14/8
\relative c'
  \override TupletNumber #'text = #tuplet-number::calc-fraction-text

{
c''8[ c''8]
 \irrtupleta \tuplet 1000/595{c''8[ c''8 c''8]} 
 c''8[ c''8]
 \irrtupletb \tweak direction #up \tuplet 1000/564{c''8[ c''8]} 

c''8 c''8
 \irrtupleta \tuplet 1000/595{c''8[ c''8 c''8]} 
 c''8[ c''8]
 \irrtupletb \tweak direction #up \tuplet 1000/564{c''8 c''8} 
 
\tweak direction #down \tuplet 1000/174{ r8}
}

\relative c'
  \override TupletNumber #'text = #tuplet-number::calc-fraction-text

{
c''8[ c''8]
 \irrtupleta \tuplet 1000/595{c''8[ c''8 c''8]} 
 c''8[ c''8]
 \irrtupletb \tweak direction #up \tuplet 1000/564{c''8[ c''8]} 

c''8 c''8
 \irrtupleta \tuplet 1000/595{c''8[ c''8 c''8]} 
 c''8[ c''8]
 \irrtupletb \tweak direction #up \tuplet 1000/564{c''8 c''8} 
 
\tweak direction #down \tuplet 1000/174{ r8}
}
 
}


>>



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/e-in-the-time-of-phi-and-square-root-of-pi-tuplet-hijinks-tp196325p196356.html
Sent from the User mailing list archive at Nabble.com.

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


Re: merge-rests engraver doesn't merge dots

2016-11-08 Thread Thomas Morley
2016-11-08 11:44 GMT+01:00 Urs Liska :
> Hello all,
>
> On https://github.com/openlilylib/snippets/issues/123 it was reported
> that the engraver merging rests
> (https://github.com/openlilylib/snippets/tree/master/editorial-tools/merge-rests-engraver)
> fails to merge dots of dotted rests. This can be seen here:
> http://lilybin.com/r1jcpm/3
>
> I think this should be quite easy to fix and update, but I don't know
> how to do it in that engraver. So any solution would be welcome. If
> you're an openLilyLib user/contributor you may do this directly as a
> pull request.
>
> Thanks
> Urs


Hi Urs,

how about the code below?
I did some general updating as well.
Just in case I overlooked something, thorough testing is recommended ;)

\version "2.19.49"

#(define merge-rests-engraver
   (lambda (context)
 (let ((rests '())
   (dots '())
   (moment=?
 (lambda (a b) (not (or (ly:moment= (length rests) 2)
(not (any (lambda (x) (not (moment=?(car durs) x))) durs)))
   (begin
 (for-each
   (lambda (rest) (ly:grob-set-property! rest 'Y-offset 0))
  rests)
(if (pair? dots)
(for-each ly:grob-suicide! (cdr dots)))
 (acknowledgers
  ;; We go for 'dot-column-interface to catch the dots, because we're
  ;; interested in the dots _in_ the column, not single dots per Voice.
  ((dot-column-interface engraver grob source-engraver)
   (set!
 dots
 (append (ly:grob-array->list (ly:grob-object grob 'dots)) dots)))
  ((rest-interface engraver grob source-engraver)
;; we go for grob::name, because 'rest-interface would probably
;; catch MMRS as well.
;; n.b. grob::name is not present in 2.18.2, use instead
;(if (eq? 'Rest (assoc-ref (ly:grob-property grob 'meta) 'name))
(if (eq? (grob::name grob) 'Rest)
(set! rests (cons grob rests)

%%%
%% Example
%%%

\score
{
  \new Staff
  <<
\new Voice { \voiceOne r4. \oneVoice r4. \voiceOne r4.   r4 }
\new Voice { \voiceTwo r4.   s4.   r4 s8 r4. }
  >>
  \layout {
\context { \Staff \consists #merge-rests-engraver } % merges non-whole rests
  }
}


Cheers,
  Harm

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


Re: openLilyLib

2016-11-08 Thread Noeck
Hi Urs,

I liked the idea of oll from the start and I used it quite often after
you published functions used in the Fried songs publication.
I liked because:
- the nice functions (mostly around the Fried project)
- it's a place where code can go more quickly than into lilypond proper
- the edition engraver is great
- it's like the LSR but, updateable (git pull) and includable (no
  copy)

But then I never understood how oll is supposed to work after the
restructuring and the restructuring is going on for much too long. So I
decoupled from the remote version and just kept what I had.

I have about six tools I use regularly which I have in a branch of my
local copy of oll and I already wanted to contribute them (if they are
helpful, a few are perhaps too trivial). But the current state is too
confusing for me.

I just respond to your mail, other than that I consider my contribution
and possible future contribution too small to be relevant or to be
demanding.

Some more comments inline:

> 1)
> A "snippets" library located at https://github.com/openlilylib/snippets.

That's the part, I know and like. If I use it for a score and want to
have it standalone, I can just copy a function I need to avoid the
dependency. \include is easy to understand and use.

> 2)
> A library infrastructure. Below https://github.com/openlilylib/ there is
> a number of repositories circling around the oll-core package.

I don't understand the point of such an endeavor, yet.

> Unfortunately 2) is still a work in progress or rather a construction
> site 

That's the problem. I remember that I once wanted to use a script and I
found 3 instances in different places and on different branches. One
more outdated than the other. It is a chicken-and-egg problem.

I won't be available for a GSoC project, but in general a library could
be built from small contributions if the infrastructure (module
mechanism) was working and if the general structure was defined.

lyp, oll. What other repositories do you think of?

Best,
Joram

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


Re: [Why you don't really want] irrational tuplets [nor CF approximations]

2016-11-08 Thread Hans Åberg

> On 8 Nov 2016, at 21:00, Alexander Kobel  wrote:
> 
> On 2016-11-08 18:15, Hans Åberg wrote:
>> I gave an example of a true irrational time signature [1]. The code
>> is actually written in 12/8, with a MIDI approximation in 19/8. Such
>> meter approximations can be obtained using continued fractions
>> convergents [2]. For the rendering, it suffices with an approximation
>> that separates and orders the notes that occur at different times.
>> For the MIDI it suffices to be within its accuracy, or alternatively,
>> what performers might do.
> 
> Seriously: I'm a half-mathematician by training (probably a lesser one than 
> Hans, but still), and work all day in computer algebra; I share the 
> admiration for the elegance of CF approximations. But for this purpose, I 
> really think you should use dyadic fractions, say, 2^-20. 
...
> On a side note, CF approximations are optimal in the sense that they give the 
> best approximation with numerator and denominator that do not exceed any 
> given bound. But they are /not/ better than dyadic approximations if your 
> measure is the asymptotic growth of the worst-case bitlength of numerator and 
> denominator that is required to achieve a certain approximation quality.

The user does not see the rational approximation, so just use whatever does the 
job. (Guile has some functions for that, I think.)

And a reason of writing a complex time signature might be to make it impossible 
for the performer to follow it: In Balkan music, one plays by ear, and the 
variation is greater than the irrational time signature examples I gave. A 
Western musician when seeing 12/8, 12 = 3+2+2+3+2 with quadruplets on them, 
might try to play it as exactly as possible, but that is not how it should be 
performed. Check out the metric time bends indicated here:
  https://en.wikipedia.org/wiki/Leventikos

Otherwise, if one really wants it to be played exactly, a sequencer track would 
be necessary.



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


[Why you don't really want] irrational tuplets [nor CF approximations]

2016-11-08 Thread Alexander Kobel

On 2016-11-08 18:15, Hans Åberg wrote:

I gave an example of a true irrational time signature [1]. The code
is actually written in 12/8, with a MIDI approximation in 19/8. Such
meter approximations can be obtained using continued fractions
convergents [2]. For the rendering, it suffices with an approximation
that separates and orders the notes that occur at different times.
For the MIDI it suffices to be within its accuracy, or alternatively,
what performers might do.


Seriously: I'm a half-mathematician by training (probably a lesser one 
than Hans, but still), and work all day in computer algebra; I share the 
admiration for the elegance of CF approximations. But for this purpose, 
I really think you should use dyadic fractions, say, 2^-20. Or at least 
fractions with a common denominator, say, 1,000,000, if you're anything 
like other humans and consider them easier to parse.


Let's do the math: For rendering purposes, with a resolution of 1200 
dpi, you have 12,000 dots on a 10-inch wide paper. You will not be able 
to distinguish any resolution higher than 1 ppm for sure.
For musical purposes (by a computer, not a human - that's out of 
question), assume 192 kHz frequency at max. Account for Shannon's 
theorem and aliasing issues, that makes it 384 kHz. With a reasonable 
base tempo of one quarter per second, that's appx. (1.6e6 s)^-1 max 
resolution. Granted: that's slightly more than what you get with a 
million as a denominator, but just.
(BTW: I didn't check the above calculations; probably the numbers are 
off, because the mathematician in me ignores constant factors, and the 
computer scientist in me doesn't do calculations in his head... ;-))


There are multiple benefits: No blow-up of the least common multiple of 
the denominators - it simply stays the same. No issues with accuracy - 
fits well to machine integers used for the rationals. In particular, no 
crashes because you suddenly exceed the implementation-based range. Even 
exactly convertible to hardware floats (double prec) if you use dyadic 
fractions. Finally: Significantly easier calculations for you to do to 
figure out the right durations to sync at barlines.


Of course, it's much more satisfying to do the "right thing" (tm). But 
that's using the exact values.
Exact computation is non-trivial even for arbitrarily large rationals. 
Exact calculations with algebraic numbers are possible, but not quite 
around the corner (that's good; otherwise, I'd need a new job). Exact 
representation and /some/ operations with an /a priori/ chosen subset of 
/some/ of the transcendentals is just possible, but a long way around 
several corners (that's even better, just in case I need a new job at 
some point). Exact computation with arbitrary real numbers is infeasible.
And that's not a "today's computers are not fast enough". It's simply 
fundamentally impossible.


And the most interesting numbers for a creative mind will be those that 
are the most complicated to capture and implement. Which reminds me of 
the phonograph in Hofstadter's wonderful "Gödel, Escher, Bach - an 
Eternal Golden Braid". If you didn't read it yet, here's a hint for a 
christmas gift...


On a side note, CF approximations are optimal in the sense that they 
give the best approximation with numerator and denominator that do not 
exceed any given bound. But they are /not/ better than dyadic 
approximations if your measure is the asymptotic growth of the 
worst-case bitlength of numerator and denominator that is required to 
achieve a certain approximation quality.



Cheers,
Alexander

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Hans Åberg

> On 8 Nov 2016, at 08:28, mclaren  wrote:
> 
> An alternative method involves simply adding in the required rests, rather
> than squishing or stretching the entire measure with a large tuplet. Since
> this method is easy to calculate exactly because you're just adding and
> subtracting various integer fractions, it always produces guaranteed
> results. With very large tuplets, there seem to sometimes be floating point
> inaccuracies in the calculations done inside Lilypond, so sometimes the
> large tuplet method doesn't work exactly and barlines don't precisely add
> up. 

I gave an example of a true irrational time signature [1]. The code is actually 
written in 12/8, with a MIDI approximation in 19/8. Such meter approximations 
can be obtained using continued fractions convergents [2]. For the rendering, 
it suffices with an approximation that separates and orders the notes that 
occur at different times. For the MIDI it suffices to be within its accuracy, 
or alternatively, what performers might do.

1. https://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00237.html
2. https://en.wikipedia.org/wiki/Continued_fraction



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


Re: e in the time of phi and square root of pi tuplet hijinks

2016-11-08 Thread Hans Åberg

> On 8 Nov 2016, at 08:45, mclaren  wrote:
> 
> This example eschews numbers for the irrational tuplets in favor of Greek
> letters, or at least the Greek names for the symbols. I'm not sure how to
> get a Greek font in Lilypond. 

There are the STIX fonts  for use with mathematics.



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


Re: Organize collection of scores

2016-11-08 Thread Federico Bruni
Il giorno sab 5 nov 2016 alle 11:31, Noeck  ha 
scritto:

Hi Federico,

thanks for your reply. I also looked at Mutopia and I have to revise
things: My currently planned approach is now B and A would be an
alternative.

Am 05.11.2016 um 10:43 schrieb Federico Bruni:

 Il giorno sab 5 nov 2016 alle 0:55, Noeck  ha
 scritto:

 A) *folders per compilation step and file type*
 ... The disadvantage is that it would
 probably be impossible to produce the output with a simple 
lilypond call

 but only the scripts would be able to engrave the score.


 This is a serious disadvantage.


Well, it probably could still be typed by hand but it would be a long
command with a lot of optional settings.

 What are the LilyPond or Frescobaldi limitations/missing features 
for

 this approach to be possible?


-o can specify the output file or folder. I don't know if it exists 
for

midi files separately.


Actually, I was hoping that it was possible to set the output directory 
*within the input file*, not in the command line. Something like:


#(ly:set-option 'output "mydirectory")



 The audio files would still have to be generated by a script.. Or 
do you

 use the audio export of Frescobaldi?


Yes, that would be an extra script in any case.


 B) *folders per score*



 This is what I use and I think it's the best approach.
 If I want to find a specific file type (PDF or MIDI) I use a file
 manager or a documents manager (like Gnome Documents).


My concern was more about clean folders: The ly files contain the
information in a condensed form (in terms of file format simplicity 
and

file size). The pdfs and audio files are reproducible. In variant A, I
could delete the pdf and audio folders and start from scratch, I could
see by the folder sizes how large the music information is (ly) and 
how

large the derived files.

But scripts that tell me these sizes are easy to write and in git I 
can

ignore file types, so the folder separation is not necessary.



I agree


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


Re: need help

2016-11-08 Thread Federico Bruni
Il giorno lun 7 nov 2016 alle 20:00, Carl Sorensen  
ha scritto:



On 11/7/16 8:48 AM, "Urs Liska"  wrote:


Am 07.11.2016 um 15:35 schrieb David Sumbler:

 On Sun, 2016-11-06 at 11:28 +0100, Malte Meyn wrote:


 Am 06.11.2016 um 11:25 schrieb David Sumbler:


 How do I find out what changes have been made between (for
 instance)
 2.19.48 and 2.19.49?

 You could read the commit messages in the git log:
 http://git.savannah.gnu.org/cgit/lilypond.git/log/


 Well, I could read them, and I have now done so.  But most of it 
makes

 little sense to me!



Which is perfectly understandable, but unfortunately it's the only 
way

to find what you're looking for (IISC). The Changes document always
refers to the latest stable version.

Maybe it would be a good thing to have the Changes document either
structured by unstable release (so one immediately can access the
"release notes" for, say, 2.19.45) or each item tagged by its release
number? This would probably need some organization overhead but 
might be

useful for users?


One could also search the issues database for Fixed tags.



Better idea, as this list takes off translation stuff and minor changes.

David, this is an example:
https://sourceforge.net/p/testlilyissues/issues/search/?q=labels:%22Fixed_2_19_49%22




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


Re: Combining \markup and \set

2016-11-08 Thread Phil Holmes
- Original Message - 
From: "David Sumbler" 

To: 
Sent: Tuesday, November 08, 2016 3:14 PM
Subject: Combining \markup and \set





\version "2.19.48"

pizz = \markup { \larger \italic "pizz." }
midiPizz = \set Staff.midiInstrument = "pizzicato strings"

arco = \markup { \larger \italic "arco" }
midiArco = \set Staff.midiInstrument = "violin"

\score {
\relative c'' {
\new Staff \with { midiInstrument = "violin" } {
c2 \midiPizz c4^\pizz c |
\midiArco c2^\arco r \bar "|."
}
}
\layout { }
\midi { }
}



The above works as I would wish it to. However, I am wondering whether
it can be simplified.

1) Is there a way of combining \pizz and \midiPizz into one variable?
Preferably it needs to be attached to the note (as \pizz already is)
so that the printed marking can be placed above or below the stave.
Similarly, of course, for \arco and \midiArco.

2) '\unset Staff.midiInstrument' would be preferable to 'set
Staff.midiInstrument = "violin"', because it would not need to be
redefined in each instrumental part. However it does not work in a
voice context. Is there a way of reverting the midiInstrument to its
previous setting which could still be included in a variable?

David


In http://lilypond.org/doc/v2.19/Documentation/notation/writing-parts 
there's a section starting: "The shortInstrumentName may be changed in the 
middle of a piece"  This seems to me to be what you want?


--
Phil Holmes 



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


Combining \markup and \set

2016-11-08 Thread David Sumbler


\version "2.19.48"

pizz = \markup { \larger \italic "pizz." }
midiPizz = \set Staff.midiInstrument = "pizzicato strings"

arco =  \markup { \larger \italic "arco" }
midiArco = \set Staff.midiInstrument = "violin"

\score {
  \relative c'' {
\new Staff \with { midiInstrument = "violin" } {
  c2 \midiPizz c4^\pizz c |
  \midiArco c2^\arco r \bar "|."
}
  }
  \layout { }
  \midi { }
}



The above works as I would wish it to.  However, I am wondering whether
it can be simplified.

1) Is there a way of combining \pizz and \midiPizz into one variable?
 Preferably it needs to be attached to the note (as \pizz already is)
so that the printed marking can be placed above or below the stave.
 Similarly, of course, for \arco and \midiArco.

2) '\unset Staff.midiInstrument' would be preferable to 'set
Staff.midiInstrument = "violin"', because it would not need to be
redefined in each instrumental part.  However it does not work in a
voice context.  Is there a way of reverting the midiInstrument to its
previous setting which could still be included in a variable?

David

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Simon Albrecht

On 08.11.2016 14:42, Karlin High wrote:

"It is the easiest thing in the world to write a piece virtually or
totally impossible to perform—but oddly enough that is not what I prefer
to do; I prefer to study the conditions of performance and shape my
music to them."
- Benjamin Britten, "On Receiving the First Aspen Award"
https://www.aspenmusicfestival.com/benjamin-britten/


I love the man, his music and the quotation :-)
Best, Simon

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Urs Liska


Am 08.11.2016 um 14:42 schrieb Karlin High:
> On 11/8/2016 2:09 AM, Jacques Menu Muzhic wrote:
>> Hello McLaren,
>>
>> As a newbie to this kind of calculations in notes length, how I am supposed 
>> to play them?
>> In particular, if others play them too?
>>
>> JM
> "It is the easiest thing in the world to write a piece virtually or 
> totally impossible to perform—but oddly enough that is not what I prefer 
> to do; I prefer to study the conditions of performance and shape my 
> music to them."
> - Benjamin Britten, "On Receiving the First Aspen Award"
> https://www.aspenmusicfestival.com/benjamin-britten/
>
> --
> Karlin High
> Missouri, USA
>

"Was geht mich Ihre verdammte Geige an?" ("Hey, I don't care about your
stupid fiddle")
- Ludwig van Beethoven (attributed)

Urs

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


Re: Counterpoint

2016-11-08 Thread Urs Liska


Am 08.11.2016 um 14:30 schrieb bart deruyter:
> hey,
>
> seems like my thoughts did spark some interest :-) . 
> I had no knowledge of Humdrum at all,

This is pretty much a niche technology. But LilyPond is also a niche
technology, so that comment isn't a judgement ;-)
Humdrum is a *data format* with a large set of analytical tools written
for it. The original idea of creating Humdrum was to create a format
usable for computer-assisted analysis.
Chances are that there will be Humdrum-to-LilyPond integration in the
not-too-distant future BTW.

> but I've read something about music21 before. If I'm reading it right
> Music21 is a python library to analyse music. I'm probably thinking
> way to simplistic, but frescobaldi is written in python too. Maybe
> there are possibilities to make the one work with the other.

In principle, yes.

>
> I see in the music21 reference manual a converter from music21 to
> lilypond. If there would be a converter from lilypond to music21, it
> would be the easiest solution

One should ask the music21 people about that.

> (maybe ly to musicxml export would be a good option too, but I don't
> think the musicxml exporter of frescobaldi is up to the task yet, or
> would I be wrong?).

You can alway try it out, but I wouldn't recommend relying on it
professionally.

> Embedded as an 'analysis' menu in frescobaldi (similare to page check
> rendering), frescobaldi could pass the score to music21, which
> analyses it, then sends the results back to frescobaldi, which renders
> it with the code generated by music21.lily.translate.

I think this will not be happening in this way, as I'm sure Wilbert
Berendsen will not want to add such a heavyweight library to Frescobaldi.

What should be possible is calling/including music21 from within a
"Snippet" that you can create/add to Frescobaldi. That should work already.

Another option is the plugin infrastructure that has been on the wish
list for quite some time now.

>
> Having analysis options and counterpoint checks, voiceleading checks
> etc. added to OpenLilyLib would on the other hand be very interesting
> because of less dependencies on external technologies and no
> conversion issues.

Indeed. But if these external technologies have already solved the
actual problems one tries to solve that is a strong point.
I think it should still be possible to use openLilyLib as a wrapper,
i.e. the interface to integrate to LilyPond documents and call external
tools through Scheme. Just as another option.

Urs


>
> Just thinking out loud here, I'm already glad there is some interest
> in it :-)
>
> grtz,
> Bart
>
>
> http://www.bartart3d.be/
> On Twitter 
> On Identi.ca 
> On Google+ 
>
> 2016-11-08 12:38 GMT+01:00 Frauke Jurgensen  >:
>
> In short, yes, such things exist, though not in Lilypond. I am a
> computational musicologist that collaborates in developing tools
> for analysing counterpoint. We've got tools like this to use in
> Humdrum or Music21. I think the Lilypond implementation would not
> be trivial (as Urs says), but I'll talk to one of my colleagues
> who is a much better programmer and see what he says.
>
> On Tue, Nov 8, 2016 at 9:57 AM, Urs Liska  > wrote:
>
>
>
> Am 07.11.2016 um 13:21 schrieb bart deruyter:
> > On a sidenote (perhaps for a different topic), in Musescore
> there is
> > the possibility to create plugins which provide harmony checks,
> > someone also did a plugin for a previous Musescore version which
> > checked only first species counterpoint.
> >
> > I know lilypond's first purpose is creating sheet music, not
> composing
> > music, but are there snippets of scheme or libraries around
> which
> > could do the same?
> >
> > I think, for people who study counterpoint and voice
> leading, or any
> > other rule-set in music, it would be very interesting to
> have a an
> > option to check if they've followed the rules. In my case I
> have no
> > teacher, can't afford private lessons, so I have to figure
> it out on
> > my own without any way to check if I'm actually correct in
> > interpreting the rules and executing the exercises.
> >
>
> I don't know if any code for this or similar purposes is
> already around
> (I suspect not, otherwise you'd have got a reply), but I think
> from the
> organizational POV it should be pretty easy to write something
> like
> that. Basically it would work similar to the part combiner:
> take two (or
> more) music expressions, perform the calculation and produce some
>

Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Karlin High
On 11/8/2016 2:09 AM, Jacques Menu Muzhic wrote:
> Hello McLaren,
>
> As a newbie to this kind of calculations in notes length, how I am supposed 
> to play them?
> In particular, if others play them too?
>
> JM

"It is the easiest thing in the world to write a piece virtually or 
totally impossible to perform—but oddly enough that is not what I prefer 
to do; I prefer to study the conditions of performance and shape my 
music to them."
- Benjamin Britten, "On Receiving the First Aspen Award"
https://www.aspenmusicfestival.com/benjamin-britten/

--
Karlin High
Missouri, USA
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Counterpoint (was: request for programming advice)

2016-11-08 Thread bart deruyter
hey,

seems like my thoughts did spark some interest :-) .
I had no knowledge of Humdrum at all, but I've read something about music21
before. If I'm reading it right Music21 is a python library to analyse
music. I'm probably thinking way to simplistic, but frescobaldi is written
in python too. Maybe there are possibilities to make the one work with the
other.

I see in the music21 reference manual a converter from music21 to lilypond.
If there would be a converter from lilypond to music21, it would be the
easiest solution (maybe ly to musicxml export would be a good option too,
but I don't think the musicxml exporter of frescobaldi is up to the task
yet, or would I be wrong?).
Embedded as an 'analysis' menu in frescobaldi (similare to page check
rendering), frescobaldi could pass the score to music21, which analyses it,
then sends the results back to frescobaldi, which renders it with the code
generated by music21.lily.translate.

Having analysis options and counterpoint checks, voiceleading checks etc.
added to OpenLilyLib would on the other hand be very interesting because of
less dependencies on external technologies and no conversion issues.

Just thinking out loud here, I'm already glad there is some interest in it
:-)

grtz,
Bart


http://www.bartart3d.be/
On Twitter 
On Identi.ca 
On Google+ 

2016-11-08 12:38 GMT+01:00 Frauke Jurgensen :

> In short, yes, such things exist, though not in Lilypond. I am a
> computational musicologist that collaborates in developing tools for
> analysing counterpoint. We've got tools like this to use in Humdrum or
> Music21. I think the Lilypond implementation would not be trivial (as Urs
> says), but I'll talk to one of my colleagues who is a much better
> programmer and see what he says.
>
> On Tue, Nov 8, 2016 at 9:57 AM, Urs Liska  wrote:
>
>>
>>
>> Am 07.11.2016 um 13:21 schrieb bart deruyter:
>> > On a sidenote (perhaps for a different topic), in Musescore there is
>> > the possibility to create plugins which provide harmony checks,
>> > someone also did a plugin for a previous Musescore version which
>> > checked only first species counterpoint.
>> >
>> > I know lilypond's first purpose is creating sheet music, not composing
>> > music, but are there snippets of scheme or libraries around which
>> > could do the same?
>> >
>> > I think, for people who study counterpoint and voice leading, or any
>> > other rule-set in music, it would be very interesting to have a an
>> > option to check if they've followed the rules. In my case I have no
>> > teacher, can't afford private lessons, so I have to figure it out on
>> > my own without any way to check if I'm actually correct in
>> > interpreting the rules and executing the exercises.
>> >
>>
>> I don't know if any code for this or similar purposes is already around
>> (I suspect not, otherwise you'd have got a reply), but I think from the
>> organizational POV it should be pretty easy to write something like
>> that. Basically it would work similar to the part combiner: take two (or
>> more) music expressions, perform the calculation and produce some
>> output. I don't immediately see how the actual content checks would have
>> to be implemented, but the infrastructure should be striaghtforward.
>>
>> I can see different ways to approach it: one could have a function that
>> simply performs the checks and prints out the results to the console, or
>> it could actually modify the music expressions in a way that the results
>> are printed directly in the score (e.g. coloring or other visible hints).
>> In a similar way one could also write functions for harmonic analysis.
>>
>> Probably the actual implementation is not all that trivial, and I
>> wouldn't start working on it. But I think it would make a good
>> openLilyLib package, and if someone is interested in the topic and has
>> the necessary Scheme skills I'd be happy to help with the openLilyLib
>> part of things.
>>
>> 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: Counterpoint (was: request for programming advice)

2016-11-08 Thread Frauke Jurgensen
In short, yes, such things exist, though not in Lilypond. I am a
computational musicologist that collaborates in developing tools for
analysing counterpoint. We've got tools like this to use in Humdrum or
Music21. I think the Lilypond implementation would not be trivial (as Urs
says), but I'll talk to one of my colleagues who is a much better
programmer and see what he says.

On Tue, Nov 8, 2016 at 9:57 AM, Urs Liska  wrote:

>
>
> Am 07.11.2016 um 13:21 schrieb bart deruyter:
> > On a sidenote (perhaps for a different topic), in Musescore there is
> > the possibility to create plugins which provide harmony checks,
> > someone also did a plugin for a previous Musescore version which
> > checked only first species counterpoint.
> >
> > I know lilypond's first purpose is creating sheet music, not composing
> > music, but are there snippets of scheme or libraries around which
> > could do the same?
> >
> > I think, for people who study counterpoint and voice leading, or any
> > other rule-set in music, it would be very interesting to have a an
> > option to check if they've followed the rules. In my case I have no
> > teacher, can't afford private lessons, so I have to figure it out on
> > my own without any way to check if I'm actually correct in
> > interpreting the rules and executing the exercises.
> >
>
> I don't know if any code for this or similar purposes is already around
> (I suspect not, otherwise you'd have got a reply), but I think from the
> organizational POV it should be pretty easy to write something like
> that. Basically it would work similar to the part combiner: take two (or
> more) music expressions, perform the calculation and produce some
> output. I don't immediately see how the actual content checks would have
> to be implemented, but the infrastructure should be striaghtforward.
>
> I can see different ways to approach it: one could have a function that
> simply performs the checks and prints out the results to the console, or
> it could actually modify the music expressions in a way that the results
> are printed directly in the score (e.g. coloring or other visible hints).
> In a similar way one could also write functions for harmonic analysis.
>
> Probably the actual implementation is not all that trivial, and I
> wouldn't start working on it. But I think it would make a good
> openLilyLib package, and if someone is interested in the topic and has
> the necessary Scheme skills I'd be happy to help with the openLilyLib
> part of things.
>
> 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: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Andrew Bernard
Hi David,

I know. It is the unreasonable bashing of floating point inaccuracies
comment that I was referring to, rather than what lilypond actually does.



On 8 November 2016 at 22:23, David Kastrup  wrote:

> "Andrew Bernard"  writes:
>
>
> Since LilyPond does not use floating point numbers for durations, all
> this is a bit beside the point.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Urs Liska


Am 08.11.2016 um 12:23 schrieb David Kastrup:
>> loating point calculations on computers are inherently
>> > inaccurate, due to the design and limitations of computers.
> Since LilyPond does not use floating point numbers for durations, all
> this is a bit beside the point.
>

Not really as the OP is constantly talking about that and trying  to
make us believe LilyPond would be much simpler and more powerful if
things could simply be done as floating points.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread David Kastrup
"Andrew Bernard"  writes:

> It's a pity you have shown aggressive contempt for programmers and
> computer scientists in general on this list, and yet you seem to want
> to use computers. Any introductory course in numerical analysis will
> teach you that floating point calculations on computers are inherently
> inaccurate, due to the design and limitations of computers.

Since LilyPond does not use floating point numbers for durations, all
this is a bit beside the point.

> Therefore, claiming it is a lilypond problem that floating point
> calculations is incorrect, and lacks insight, and is simply an empty
> opinion based assertion.

It is a LilyPond problem that the rational arithmetic it employs has
restrictions on the size of the fraction constituents.  If you want to
hash out some series, you run out of valid values pretty fast.  The
resulting fractions may not make a whole lot of sense but it would be a
boon if you did not have to think about approximations for such rather
special applications.  Even if it made LilyPond slow down to a crawl.

-- 
David Kastrup

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


Re: openLilyLib

2016-11-08 Thread Federico Bruni
Il giorno mar 8 nov 2016 alle 9:50, Urs Liska  ha 
scritto:
So the first thing I would really like to see (and this is actually 
independent from GSoC) is getting more people involved in 
openLilyLib, and also that people from the one-digit commit count 
aspire to get to a two-digit count and those in the lower two-digit 
range try to somewhat narrow the gap to the top three contributors 
;-) I see there are many open branches, and it would be good to work 
on reducing that by either dropping or merging work.


I used and "contributed" to OLL only to keep track of the changes 
contributed by Harm to the old bend.ly. Now that Harm is working on a 
new bending engraver the whole tablature library¹ is going to be 
obsolete soon.


So I guess that you won't see other commits from me.
That said, I wish the best to openLilyLib. For me it remains the best 
place for creating and maintaining LilyPond snippets for the community.


¹ https://github.com/openlilylib/snippets/tree/master/ly/tablature


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


merge-rests engraver doesn't merge dots

2016-11-08 Thread Urs Liska
Hello all,

On https://github.com/openlilylib/snippets/issues/123 it was reported
that the engraver merging rests
(https://github.com/openlilylib/snippets/tree/master/editorial-tools/merge-rests-engraver)
fails to merge dots of dotted rests. This can be seen here:
http://lilybin.com/r1jcpm/3

I think this should be quite easy to fix and update, but I don't know
how to do it in that engraver. So any solution would be welcome. If
you're an openLilyLib user/contributor you may do this directly as a
pull request.

Thanks
Urs


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


Re: crop marks in PDF for printing

2016-11-08 Thread Alexander Kobel

On 2016-11-07 08:16, Henning Hraban Ramm wrote:

Am 2016-11-06 um 22:56 schrieb Alexander Kobel :


In many brochure-bound volumes of more than two or three sheets (say, 60+ 
pages), the paper is cut to align flush when the brochure is closed.  So the 
inner sheets are (sometimes significantly, say in the order of 5mm per page or 
10mm per sheet) narrower than the outer ones.  Does / should this impact the 
layout of the page?  And if so, how?


It should affect the layout insofar as the page contents (should) get moved a 
few millimeters.
That’s a task for the imposition software at the printshop, or previously for the 
"Druckvorlagenhersteller" (lithographer?).


Should the contents be moved towards the binding or towards the outer edge?


Oh my, I gave away all of my technical literature years ago...

See e.g. "Seitenversatz" at 
https://helpx.adobe.com/de/indesign/using/printing-booklets.html
in English: "Creep" at 
https://helpx.adobe.com/indesign/using/printing-booklets.html

You can either move the contents of the outer pages of a fold *away from* the 
gutter/spine, or move the contents of the inner pages *to* the gutter/spine.


I see. So it's up to the designer/typographer to decide.
For text, I can imagine that this makes sense, in particular increasing 
the inner margin - after all, the edges of the other pages of an open 
book create another kind of optical outer margin that adds to the existing.
For music, the situation is slightly different; margins are typically 
smaller, since the requirements for long lines are totally different 
from text; visibility of everything and practicality for holding the 
book without covering content are more important there IMHO. Form 
follows function.



Interesting approach – I never heard of anyone doing this, but it makes sense 
and could even be applied to text layout.
[...]

Yes, TeX has issues with changing line widths (even in columns) and additional 
variables that affect line breaking, but modern computers are good enough WRT 
speed and memory, and esp. LuaTeX allows for enough control to cope even with 
irregular layouts (as ConTeXt can do, i.e. that *you* can do using ConTeXt).

I can imagine it would be possible to tell TeX (ConTeXt) which column or 
horizontal layout area to adapt to the binding correction to achieve pure 
harmony in book design ;)


But at least I'm glad that an experienced typesetter agrees with my idea. :-)


I’ll try to infect some TeX gurus with the idea.


Keep me in the loop... ;-) I wonder whether this will be worth the effort.


Usual layout correction affects only the margins.

Pure lazyness. ;-)


Call it efficiency. A typesetter (or imposer/lithographer/printer) is no artist 
who can work for years at one piece. Even in Gutenberg’s era, production 
efficiency was crucial - since the printers tried to provide the quality of 
writing monks (copy writers?) for much lower costs, while work time had a much 
lower value than today.


Of course. Lazyness and efficiency are closely related. :-)
Given the advent of e-ink readers, I'm afraid we'll no longer have to 
think about such issues for everything except extraordinary design 
projects anymore in due time...



Cheers,
Alexander

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


RE: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Andrew Bernard
It's a pity you have shown aggressive contempt for programmers and computer 
scientists in general on this list, and yet you seem to want to use computers. 
Any introductory course in numerical analysis will teach you that floating 
point calculations on computers are inherently inaccurate, due to the design 
and limitations of computers. Floating point is an approximation to real 
numbers, not an exact map. The people you dislike so much have devoted decades 
of study to floating point theory and chip design. The scientific community has 
been aware of these issues and topics since the 1960's. For example. you cannot 
compare two floating point numbers for equality - you can only test to see if 
they are within a specified epsilon of each other. There are papers on floating 
point accuracy that are considered to be essential reading for any programmer. 
I am able to send you the links should you care to avail yourself of that help.

Therefore, claiming it is a lilypond problem that floating point calculations 
is incorrect, and lacks insight, and is simply an empty opinion based assertion.

Andrew



-Original Message-
From: lilypond-user 
[mailto:lilypond-user-bounces+andrew_bernard=hotmail@gnu.org] On Behalf Of 
mclaren
Sent: Tuesday, 8 November 2016 6:29 PM
To: lilypond-user@gnu.org
Subject: How to get irrational tuplets inside a regular meter like 9/8

An alternative method involves simply adding in the required rests, rather than 
squishing or stretching the entire measure with a large tuplet. Since this 
method is easy to calculate exactly because you're just adding and subtracting 
various integer fractions, it always produces guaranteed results. With very 
large tuplets, there seem to sometimes be floating point inaccuracies in the 
calculations done inside Lilypond, so sometimes the large tuplet method doesn't 
work exactly and barlines don't precisely add up. But with this method, 
barlines always line up exactly and no extreme unction is required to add 
barlines or to fiddle with any kind of make-moment value to get the barlines 
right.



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


RE: e in the time of phi and square root of pi tuplet hijinks

2016-11-08 Thread Andrew Bernard
You could read the manual. Lilypond supports Unicode, hence Greek.

Andrew


-Original Message-
From: lilypond-user On Behalf Of mclaren
Sent: Tuesday, 8 November 2016 6:45 PM
To: lilypond-user@gnu.org
Subject: e in the time of phi and square root of pi tuplet hijinks

This example eschews numbers for the irrational tuplets in favor of Greek 
letters, or at least the Greek names for the symbols. I'm not sure how to get a 
Greek font in Lilypond. It might not be possible. In any case it's not 
important, since that can always be fixed in the mix with photoshop. e is the 
familiar constant 2.71828... while phi is the golden section, 1.6180339...



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


Counterpoint (was: request for programming advice)

2016-11-08 Thread Urs Liska


Am 07.11.2016 um 13:21 schrieb bart deruyter:
> On a sidenote (perhaps for a different topic), in Musescore there is
> the possibility to create plugins which provide harmony checks,
> someone also did a plugin for a previous Musescore version which
> checked only first species counterpoint.
>
> I know lilypond's first purpose is creating sheet music, not composing
> music, but are there snippets of scheme or libraries around which
> could do the same? 
>
> I think, for people who study counterpoint and voice leading, or any
> other rule-set in music, it would be very interesting to have a an
> option to check if they've followed the rules. In my case I have no
> teacher, can't afford private lessons, so I have to figure it out on
> my own without any way to check if I'm actually correct in
> interpreting the rules and executing the exercises.
>

I don't know if any code for this or similar purposes is already around
(I suspect not, otherwise you'd have got a reply), but I think from the
organizational POV it should be pretty easy to write something like
that. Basically it would work similar to the part combiner: take two (or
more) music expressions, perform the calculation and produce some
output. I don't immediately see how the actual content checks would have
to be implemented, but the infrastructure should be striaghtforward.

I can see different ways to approach it: one could have a function that
simply performs the checks and prints out the results to the console, or
it could actually modify the music expressions in a way that the results
are printed directly in the score (e.g. coloring or other visible hints).
In a similar way one could also write functions for harmonic analysis.

Probably the actual implementation is not all that trivial, and I
wouldn't start working on it. But I think it would make a good
openLilyLib package, and if someone is interested in the topic and has
the necessary Scheme skills I'd be happy to help with the openLilyLib
part of things.

Urs

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


Re: Variable weirdness

2016-11-08 Thread David Sumbler
Thank you.  I might find this useful some time, if I have correctly
understood what the purpose of it is.

For the particular case I was concerned with, though, simply using
#(define partName "Cello 1")
seems a lot simpler.

I just wondered why the Lilypond form isn't allowed in a situation
where the Scheme form works absolutely fine.  I'm still wondering.

David


On Tue, 2016-11-08 at 07:44 +0100, Jan-Peter Voigt wrote:
> Hello,
> 
> here is a demo of the code:
> 
> %%% snip
> \version "2.19.49"
> 
> % the 2.18 version would just use parser and layout in the signature
> and 
> the additional parser-argument in the ly:parser-define! call
> parserDefine =
> #(define-scheme-function (vkey val)(symbol? scheme?)
> (ly:parser-define! vkey val))
> 
>  Demo
> 
> \parserDefine music \relative c'' { c b bes a }
> 
> { \music }
> %%% /snip
> 
> HTH
> Jan-Peter
> 
> Am 08.11.2016 um 07:06 schrieb Jan-Peter Voigt:
> > 
> > Hello,
> > 
> > in these situations I use a little scheme-function like this:
> > 
> > parserDefine =
> > #(define-scheme-function (key val)(symbol? scheme?)
> > (ly:parser-define! key val))
> > 
> > !!!(I will correct this later, when I am on real computer )
> > 
> > This scheme-function works on every level defining a variable into
> > the 
> > current parser.
> > 
> > HTH
> > Jan-Peter
> > 
> > Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
> > :
> > 
> > On 07.11.2016 17:56, David Kastrup wrote:
> > 
> > David Sumbler  writes:
> > 
> > I had the following lines in the main file of my
> > current
> > Lilypond project: \book { \bookOutputName
> > "../firstCello"
> > partName = "Cello 1" \include "frontcover.ily"
> > \bookpart {
> > %music... The file "frontcover.ily" contains a
> > \bookpart
> > block which prints a front cover with title, composer
> > etc.
> > - these are defined elsewhere. But it needs one more
> > variable, viz. 'partName'. I discovered that Lilypond
> > will
> > not accept a variable definition in Lilypond format in
> > the
> > position I have put it: at the top level of a \book
> > block.
> > Nor will it accept it in a \bookpart block. But at a
> > higher or a lower level, it will. This seems a bit
> > weird
> > (to say the least), in view of the fact that by
> > replacing
> > the line partName = "Cello 1" with the Scheme form
> > #(define partName "Cello 1") everything works as
> > intended.
> > Is there any useful reason why a variable cannot be
> > defined in Lilypond format in these contexts? 
> > 
> > Because they would not be local to these contexts? 
> > 
> > 
> > In other words, to make this work, books and bookparts would
> > need their
> > own namespaces, am I right? What would be the drawbacks of
> > that? I
> > daresay it would be pretty intuitive to use, and I’ve also
> > found myself
> > wanting that feature in the past, mainly to simplify \include
> > structures.
> > 
> > Best, Simon
> > 
> > ---
> > -
> > 
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> > 
> > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9
> > Mail 
> > gesendet.
> > 
> > ___
> > 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


openLilyLib

2016-11-08 Thread Urs Liska
Hi all,

this is an update and "call for action" regarding openLilyLib.

For those not familiar with openLilyLIb a short recap what it is, or
rather what the different parts of it are:

1)
A "snippets" library located at https://github.com/openlilylib/snippets.

This is similar to the official LSR (http://lsr.di.unimi.it/LSR/Search),
a collection of sort-of-organized LilyPond function. The main
differences to the LSR are:

  * it is simply managed as a Git repository on Github, so it is
somewhat more straightforward to maintain in a collaborative manner
  * It is not compiled on the server, so there's no requirement that all
code matches a given LilyPond version
  * It is designed to be *includable*, that is one directly uses the
snippets instead of copying them in one's own files

2)
A library infrastructure. Below https://github.com/openlilylib/ there is
a number of repositories circling around the oll-core package. The idea
is to provide cleanly structured and usable packages/libraries/modules,
however you'd like to name it. This way including a certain package
easily gives access to a certain functionality. As an example the
"page-layout" package allows to specify sets of breaks that can then
simply be applied to a score (so I can define the breaks of, say, the
manuscript and original edition and switch between them. Or define
breaks for A4 paper and screen display).

One neat thing about that is that it's possible to provide functionality
that other functionality can build upon (well, that's what libraries
mostly are about). I have recently seen how fundamentally it makes it
easier to build complex functionality in LilyPond when you can reuse
rather large building blocks.

###

Unfortunately 2) is still a work in progress or rather a construction
site because much is missing, most importantly an automated system for
testing and documentation generation. This is the main reason why I have
been reluctant so far to add further libraries because they necessarily
have to be somewhat undocumented - and I know that it will be hard to
catch up with this if we should implement a documentation system after
having created dozens of libraries ...

Another thing I dearly miss is a proper integration with Sharon Rosner's
approach at a LilyPond package manager
(https://github.com/noteflakes/lyp), which would actually make
openLilyLib installation a less manual task.

(Both these would make for good GSoC projects BTW)

###

So now that I've said what openLilyLib is and what it mostly lacks I'd
like to share an idea and shout out for a community effort.

Knowing it will be an unlikely bet I still would like to apply for
openLilyLib becoming a Google Summer of Code org independently from
LilyPond. This year I mentored an openLilyLib project on behalf of
LilyPond, and while that worked out it somehow felt not fully natural
because my student didn't work on actual LilyPond code, and because that
seems to have made him less inclined to engage with the LilyPond
community as well. And above all an independent openLilylib org could
eventually lead to more GSoC slots in total for us.

I know it's unlikely openLilyLib would get accepted as a mentoring
organization right away but I would like to try it anyway. Even if it
doesn't work out the effort would give the project a push. The program
rules are not out yet, but application is from mid January to mid
February, and I know the basic requirements:

First of all we need to be a community. There is no given minimum number
to this and it "just can't be two developers but we need a community".
https://github.com/orgs/openlilylib/people actually looks pretty good,
but if you look at that graph:
https://github.com/openlilylib/snippets/graphs/contributors it becomes
clear that there is actually a steep curve *and* there are long periods
of near inactivity (OK, this graph is for the one repo only, there has
been more activity recently to other repos).

So the first thing I would really like to see (and this is actually
independent from GSoC) is getting more people involved in openLilyLib,
and also that people from the one-digit commit count aspire to get to a
two-digit count and those in the lower two-digit range try to somewhat
narrow the gap to the top three contributors ;-) I see there are many
open branches, and it would be good to work on reducing that by either
dropping or merging work.

The second thing I would be happy about is to see more packages emerge.
This can be done by pulling out coherent sets of functionality from the
snippets repository to new packages or by creating new ones from
scratch. Of course this is a more involved thing, particularly as it is
not properly documented yet and not even fully stable with regard to
structure. But more activity would also be the frame for improving on
this aspect.

Finally for becoming a mentoring organization there have to be two
volunteers serving as "org admins" over the project cycle (i.e. from
February to 

Re: e in the time of phi and square root of pi tuplet hijinks

2016-11-08 Thread Alexander Kobel

On 2016-11-08 08:45, mclaren wrote:

Technically speaking, we're also dealing with transcendental tuplets rather
than irrationals here, since the square root of pi is a transcendental
number (I think. Pi is known to be transcendental, but is the square of pi
proven to be transcendental?).


Algebraic numbers form a field. So yes - if sqrt(pi) were algebraic, so 
would be pi. Obviously, they are also closed under root extraction (more 
precisely, powers to rational exponents); hence pi^2 is transcendental, too.



Cheers,
Alexander

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


Re: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread Jacques Menu Muzhic
Hello McLaren,

As a newbie to this kind of calculations in notes length, how I am supposed to 
play them?
In particular, if others play them too?

JM

> Le 8 nov. 2016 à 09:02, David Kastrup  a écrit :
> 
> mclaren  writes:
> 
>> An alternative method involves simply adding in the required rests, rather
>> than squishing or stretching the entire measure with a large tuplet. Since
>> this method is easy to calculate exactly because you're just adding and
>> subtracting various integer fractions, it always produces guaranteed
>> results. With very large tuplets, there seem to sometimes be floating point
>> inaccuracies in the calculations done inside Lilypond,
> 
> LilyPond does not work with floating point or other inaccurate types for
> musical length calculations.  Its own rationals (where it uses them
> rather than Guile's rather large rationals) however are limited in the
> maximum value of numerator and denominator.  I don't think that it
> checks all cases for overflow, so when you exceed their sizes, results
> will not be inaccurate as much as completely off the wall.
> 
> -- 
> David Kastrup
> 
> ___
> 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: How to get irrational tuplets inside a regular meter like 9/8

2016-11-08 Thread David Kastrup
mclaren  writes:

> An alternative method involves simply adding in the required rests, rather
> than squishing or stretching the entire measure with a large tuplet. Since
> this method is easy to calculate exactly because you're just adding and
> subtracting various integer fractions, it always produces guaranteed
> results. With very large tuplets, there seem to sometimes be floating point
> inaccuracies in the calculations done inside Lilypond,

LilyPond does not work with floating point or other inaccurate types for
musical length calculations.  Its own rationals (where it uses them
rather than Guile's rather large rationals) however are limited in the
maximum value of numerator and denominator.  I don't think that it
checks all cases for overflow, so when you exceed their sizes, results
will not be inaccurate as much as completely off the wall.

-- 
David Kastrup

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