Re: Changing the distance between a slur and a note head

[Marc Hohl]

Kieren MacMillan schrieb:

Hi Marc,

is there a way to lower the distance between the point where a slur 
starts (or ends, respectively)
and the corresponding (tab) note head *without* manipulating every 
slur's control-points?


Can you increase the Y-offset?

Um, no.

I tried this by inserting

\override Voice.Slur #'Y-offset = #0 (or any other - even negative - number)

but nothing changed. Or was I misunderstanding your proposal?

Marc


Cheers,
Kieren.





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

Re: Conditionally displaying stems in void notation

[Rodolfo Zitellini]

Yes, but I would not have correct crotchets - in this type of void
notation crotchets are written out as quavers, with connected stems
and all, but with a white notehead.
I think I can:
1) write out everything in 3/2 and then alter manually every note <=
than a quarter to transform it in an eight
2) Halve all the values of the original, writing it in 3/4, then
blanking out all the noteheads (with duration-log). In this case all
the quarters are displayed corretly - they effectively become eights
with white noteheads - but (obviously) all the whole notes in the
original now are written as minims. I then manually turn off their
stem to make them wholes again. This is because I am faking 3/2 using
3/4 (for the abovementioned eigths).
I can do this all manually, but it is quite tedious and long, and in
clutters my code (since I have to torn off stems almost every 2 notes)
- a way of turning off stems for all minims would be much more simple.

Thanks,
Rodolfo

On Sat, Sep 26, 2009 at 9:54 PM, Mats Bengtsson
 wrote:
> Isn't it simplest to first use the trick described in
> http://lsr.dsi.unimi.it/LSR/Item?id=305 to modify the duration of each note
> to the double, and then alter the note heads. This should give you correct
> stems.
>
>   /Mats
>
> Rodolfo Zitellini wrote:
>>
>> Hello list,
>> I am trying to typeset a piece in 3/2 void notation. I entered all the
>> music in 3/4 and altered the noteheads with #'duration-log = 1 to make
>> all notes white. This fakes 3/2 ok, but all notes bigger than a minim
>> (in 3/2) now have stem, which requires me to turn on and off all the
>> stems manually for every note that should not have one (i.e. all the
>> semibreves in 3/2).
>> I understand that in scheme it is possible to access the value of
>> duration-log to conditionally change the notehead stencil, it it
>> possible to do the same for the stem? I would just need to hide the
>> stem for all notes with value >= 2 (as entered in lilypond).
>> Regards
>> Rodolfo
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
>
> --
> =
>        Mats Bengtsson
>        Signal Processing
>        School of Electrical Engineering
>        Royal Institute of Technology (KTH)
>        SE-100 44  STOCKHOLM
>        Sweden
>        Phone: (+46) 8 790 8463
>       Fax:   (+46) 8 790 7260
>        Email: mats.bengts...@ee.kth.se
>        WWW: http://www.s3.kth.se/~mabe
> =
>
>


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

Re: No fiddling claim

[Jan Nieuwenhuizen]

Op zondag 27-09-2009 om 14:22 uur [tijdzone -0700], schreef Jonathan
Wilkes:

Hi Jonathan,

>  Not too long ago, I gave my opinion that "No fiddling" should be 
> changed to "less fiddling" for the new website.
>  After trying to do a quick exercise with a Schumann score, which I 
> posted here concerning a slur tweak after a line break, I don't think the 
> "less fiddling" claim is valid, either.

You seem to miss the point of the "no fiddling" remark.  

As an aside: this is exactly why I do not like the newly fumbled
"less fiddling", it turns people's heads into the direction of
fiddling.  People have come to think fiddling is normal and required.
More often than not it isn't.  We do not want less fiddling, we want
bug reports and no fiddling.  Okay... 

The idea of LilyPond is that the output should be beautiful without
fiddling.  While this may not have been achieved yet for some pieces of
music, it may be true next year.  We found that if you wanted 
beautifully engraved music, you would need to move almost every freaking
note, beam, barline, slur, accidental and lyric when using an expensive,
popular GUI program.

It may be that some tweaks, esp. where you need visible feedback
take more time to do in LilyPond than they do in a GUI program.
I don't think we particularly care about this.  The upside here
is that any tweaks you do need, can be quite easily improved
incrementally, saved for a next time, discussed on a mailing
list -- while mouse movements cannot.

If you want to help, please post a minimal snippet with the slur
or grace note that you do not like to the bug-lilypond list.

Jan.


-- 
Jan Nieuwenhuizen  | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl| http://lilypond.org



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

Re: Problem spacing arpeggio

[Nick Payne]

Kieren MacMillan wrote:

Hi Nick,


in the second bar, using the same override does nothing to
increase the spacing between the arpeggio and the preceding note.


Hmmm... that's probably because of the multiple-voices... but seems 
like maybe a bug?



What means can I use to increase the spacing there?


Well, it's kind of hacky, but...

\stemPad = {
  \once \override Staff.Stem #'X-extent = #'(0 . 2)
Thanks, that does the trick. And further on, where I had an arpeggio 
that was sitting on top of the preceding barline, I had to use \once 
\override Staff.BarLine #'extra-spacing-width = #'(0 . 2)


Nick


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

Beaming rules in 2.13.4

[Nick Payne]

It's nice now to be able to have per-Voice beaming rules, but there 
seems to be a problem with the beaming defaults. See attached. The 
eighth notes in the middle voice are getting all beamed together unless 
an override is used.


Nick
\version "2.13.4"

#(ly:set-option 'delete-intermediate-files #t)

\pointAndClickOn

treble = \relative c' {
	f,32 d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,,
	\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 32) . (4 4 4 4 4 4))) 
	f d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,, f d a'' d,,
}

bass = \relative c {
	d,4 r d
	d r d
}

middle = \relative c {
	f8 f f f f f
	\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 8) . (2 2 2))) 
	f f f f f f
}

\score {
	<<
		\context Staff = guitar {
			\set Staff.connectArpeggios = ##t
			\clef "treble_8"
			\key d \minor
			\time 3/4
			<<
\context Voice = "1" { \voiceOne \treble }
\context Voice = "4" { \voiceFour \bass }
\context Voice = "2" { \voiceTwo \middle }
			>>
		}
	>>
	\layout {
		\context {
			\Staff 
\consists "Span_arpeggio_engraver"
		}
	}
}

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

Re: another route from MIDI to lilypond (from NtEd developer)

[Joerg Anders]

A word from NtEd developer:

On Sat, 26 Sep 2009, Laura Conrad wrote:


A quick test on the same MIDI file as earlier shows that it spells Bb
wrong, and doesn't correct it if I edit the key signature.


Hmm! I imported a MIDI which includes a simple Bb scale. The
LilyPond export gives:


   \header {
   }

   #(set-default-paper-size "a4")
   StaffA = \new Staff \relative c' { \set Staff.instrumentName = "Inst 1 "
  \clef treble\key bes \major \time 4/4
 bes'4  c  d  es | % 2
 f  g  a  bes | % 3


   }

   \score {
<<
\StaffA
>>
\layout { }
   }

Which in turn creates a correct Bb scale. What is misspelled ? "bes" ?


if I figure out
either how to get it to speak English or how to understand all the
German options.


It is not German it is Dutch! NtEd assumes you don't include any special
language package nor do you use a certain LilyPond version (Therefore the
warning "no \version statement found"). And in this
case LilyPond "speaks" (or better "reads") Dutch. And "bes" is Dutch
for "Bb"

On Sat, 26 Sep 2009, Laura Conrad wrote:


but unlike the others, it gets some length(s?)
wrong so that not all the parts are the same length.


The reason is: Unlike other score editors on Linux, NtEd does not assume
a shortest note and recognizes triplets.

Furthermore: NtEd is the one and only score editor on
Linux which distributes the MIDI notes onto different
voices if necessary:



--|\-|\-
--|--|--
--|--|--
-/--/---

 /
|
|
|

All others try this:


-
--|\--|\-
--|---|--
--|---|--
-/|--/|--
  |   |
 /   /

  \  /


--
J.Anders, GERMANY, TU Chemnitz, Fakultaet fuer Informatik


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

Re: another route from MIDI to lilypond (from NtEd developer)

[Martin Tarenskeen]

On Mon, Sep 28, 2009 at 11:19:26AM +0200, Joerg Anders wrote:
> A word from NtEd developer:
>
> On Sat, 26 Sep 2009, Laura Conrad wrote:
>
>> A quick test on the same MIDI file as earlier shows that it spells Bb
>> wrong, and doesn't correct it if I edit the key signature.

>bes'4  c  d  es | % 2
>f  g  a  bes | % 3

> Which in turn creates a correct Bb scale. What is misspelled ? "bes" ?

Hi Joerg and Laura,

I think I can explain the problem.

You are using a correct MIDI file with the key signature in the MIDI 
meta events.

The MIDI file examples that Laura is using (she mailed them to me) 
contain Bb/A# notes but do not contain (a correct) Key Signature MIDI 
Meta Event. In MIDI there is no simple way to see the difference between 
A# and Bb (It's just a note number) if such a Key Signature MIDI Meta 
Event is not present or is simply giving a default "C Major".

That's why midi2ly has a "--key=..." commandline option. Unfortunately 
this option is not working ( The commandline key-signature is 
overwritten by the one in the MIDI meta events). I'm looking into it to 
solve this problem. 

One workaround that sort of worked for me: I converted Laura's file with 
midi2ly (unreleased version), edited the ly file to include \key d 
\minor in all parts and a midi{} block, created a new midifile with it, 
ran midi2ly on the new midifile, and finally I was having a ly file with 
Bb instead of A#. We don't want that, right ?

If I succeed in fixing this problem plus the problems with long notes, 
ties-across-barlines, and barcheck calculations when meter changes, I 
think we will have a pretty usable midi2ly utility ...

-- 

Martin Tarenskeen



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

Re: another route from MIDI to lilypond (from NtEd developer)

[Martin Tarenskeen]

On Mon, Sep 28, 2009 at 11:19:26AM +0200, Joerg Anders wrote:
> A word from NtEd developer:


> Furthermore: NtEd is the one and only score editor on
> Linux which distributes the MIDI notes onto different
> voices if necessary:

Yeah, that's magick! Midi2ly also fails hopelessly with polyphony in  
one track :-(

-- 

Martin Tarenskeen



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

Re: The new Drummer's Gigsaw: first edition.

[rosea grammostola]

Philippe Hezaine wrote:

Philippe Hezaine a écrit :

Hi all,

Here is the new Puzzle du Batteur-The Drummer's Gigsaw.
Published under GPLv3 or later Licence, at this time it's only available
for Linux.
Forget the old versions and first of all read the README.
Feedbacks, suggestions, criticisms are welcome, of course.

Download the tar.bz2 archive here:

http://philippe.hezaine.free.fr/spip.php?article46

Cheers.


Sorry. I've found several mistakes in the PATH.
Here is a corrected version:

http://philippe.hezaine.free.fr/spip.php?article46

Hopefully it works. Tell me if it doesn't.
Cheers.

Did you made some progress getting a better midi output?

\r


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

Re: another route from MIDI to lilypond (from NtEd developer)

[Joerg Anders]

On Mon, 28 Sep 2009, Martin Tarenskeen wrote:



The MIDI file examples that Laura is using (she mailed them to me)
contain Bb/A# notes but do not contain (a correct) Key Signature MIDI
Meta Event. In MIDI there is no simple way to see the difference between
A# and Bb (It's just a note number) ...
if such a Key Signature MIDI Meta
Event is not present or is simply giving a default "C Major".

That's why midi2ly has a "--key=..." commandline option. Unfortunately
this option is not working ( The commandline key-signature is
overwritten by the one in the MIDI meta events). I'm looking into it to
solve this problem.


NtEd has such a "--key=..." option implicitely! Assume because of the missing 
key
signature NtEd recognizes:

   either:

  A# C D D# F G A A#

   or

  Bb C D Eb F G A Bb

Click the staff not too close to a measure bar! The staff config dialog
appears. Make sure the "adjust notes" is checked (default) and
select "B flat Major;g minor" and press OK!

In both cases you get a Bb signature at the beginning of the staff
and the scale without signs. Note! If NtEd recognizes:

   A# C D D# F G A A#

NtEd corrects also the lines: A# --> Bb; D# --> Eb

I can't see any problem here.

--
J.Anders, GERMANY, TU Chemnitz, Fakultaet fuer Informatik


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

[OT] Re: another route from MIDI to lilypond (from NtEd developer) [OT]

[rosea grammostola]

Sorry a bit OT but I get

Err http://pini.free.fr testing Release.gpg
 Could not resolve 'pini.free.fr'
Err http://pini.free.fr testing/main Translation-en_US
 Could not resolve 'pini.free.fr'



\r


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

How do I disable indentation of the first line?

[Br. Athanasius Pelletier]

I am trying to format music for a hymnal and I do not want the first
stanza/line ( I don't know what it is called) to be indented.  How can
it be prevented?



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

Re: How do I disable indentation of the first line?

[Marek Klein]

Hi,

\layout {
  indent = 0.0
}

-- 
Marek Klein
http://gregoriana.sk

2009/9/28 Br. Athanasius Pelletier 

> I am trying to format music for a hymnal and I do not want the first
> stanza/line ( I don't know what it is called) to be indented.  How can
> it be prevented?
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [OT] Re: another route from MIDI to lilypond (from NtEd developer) [OT]

[Joerg Anders]

On Mon, 28 Sep 2009, rosea grammostola wrote:


Sorry a bit OT but I get

Err http://pini.free.fr testing Release.gpg
Could not resolve 'pini.free.fr'
Err http://pini.free.fr testing/main Translation-en_US
 Could not resolve 'pini.free.fr'


what gives:

  nslookup pini.free.fr

--
J.Anders, GERMANY, TU Chemnitz, Fakultaet fuer Informatik


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

Re: Using \lyricsto with \partcombine

[rkimpel]

Carl Sorensen-3 wrote:
> 
> I figured out a method of setting four-voice music in a single staff,
> using
> partcombine.
> 
> The key issue was to add a separate hidden voice that wouldn't interfere
> with any of the visible voices, and use that for the \lyricsto.
> 
> 

I have found two problems with this method.

1) Any slurs and markings on the notes still print, just far above the
staff.
I solved this by making a dummy part with just notes and durations, using
melismas to make extenders and hyphens work properly.

2) The note columns in the treble and bass clefs don't line up.
I have tried to solve this by:
- Changing the shiftOn level
- Adding the dummy part to the bass cleff
- Moving the parts around

I know lyricsto with partcombine has been a problem for years, so I'm sure
somebody has solved it by now. Any ideas?
-- 
View this message in context: 
http://www.nabble.com/Using-%5Clyricsto-with-%5Cpartcombine-tp20446452p25634655.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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

Re: [OT] Re: another route from MIDI to lilypond (from NtEd developer) [OT]

[rosea grammostola]

Joerg Anders wrote:

On Mon, 28 Sep 2009, rosea grammostola wrote:


Sorry a bit OT but I get

Err http://pini.free.fr testing Release.gpg
Could not resolve 'pini.free.fr'
Err http://pini.free.fr testing/main Translation-en_US
 Could not resolve 'pini.free.fr'


what gives:

  nslookup pini.free.fr


It works now.

Does NtEd have Jack support?

\r


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

Re: The new Drummer's Gigsaw: first edition.

[Philippe Hezaine]

rosea grammostola a écrit :

Philippe Hezaine wrote:

Philippe Hezaine a écrit :

Hi all,

Here is the new Puzzle du Batteur-The Drummer's Gigsaw.
Published under GPLv3 or later Licence, at this time it's only available
for Linux.
Forget the old versions and first of all read the README.
Feedbacks, suggestions, criticisms are welcome, of course.

Download the tar.bz2 archive here:

http://philippe.hezaine.free.fr/spip.php?article46

Cheers.


Sorry. I've found several mistakes in the PATH.
Here is a corrected version:

http://philippe.hezaine.free.fr/spip.php?article46

Hopefully it works. Tell me if it doesn't.
Cheers.

Did you made some progress getting a better midi output?

\r


Hi,

The Gigsaw's midi output from a lilypond file gives you a midi file with 
 velocities values. You haven't this option from a default lilypond 
file which only implements volume values per channel.
But the Gigsaw uses a special way to get this result. Lilypond's midi 
output is especially buggy to do a sort about Param. It doesn't forget 
them but sometimes they are not in the right order for a clean midi 
file. Hence some unsolvable issues when I used Mididings.

You can check what i say with midicomp.

For this reason Gigsaw's midi files are stamped +veloc.
Have you succeed to install and run the new Drummer's Gigsaw?
There are around 250 downloads on my site and nobody gives me a 
feedback. I'm a bit disappointed.


P.S. A second edition is coming soon with an easier install. All the 
stuff will be done by a bash script. Ouf!


Cheers.
--
  Phil.
Superbonus-Project (Site principal) 

Superbonus-Project (Plate-forme d'échange):



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

Re: The new Drummer's Gigsaw: first edition.

[rosea grammostola]

Philippe Hezaine wrote:

rosea grammostola a écrit :

Philippe Hezaine wrote:

Philippe Hezaine a écrit :

Hi all,

Here is the new Puzzle du Batteur-The Drummer's Gigsaw.
Published under GPLv3 or later Licence, at this time it's only 
available

for Linux.
Forget the old versions and first of all read the README.
Feedbacks, suggestions, criticisms are welcome, of course.

Download the tar.bz2 archive here:

http://philippe.hezaine.free.fr/spip.php?article46

Cheers.


Sorry. I've found several mistakes in the PATH.
Here is a corrected version:

http://philippe.hezaine.free.fr/spip.php?article46

Hopefully it works. Tell me if it doesn't.
Cheers.

Did you made some progress getting a better midi output?

\r


Hi,

The Gigsaw's midi output from a lilypond file gives you a midi file 
with  velocities values. You haven't this option from a default 
lilypond file which only implements volume values per channel.
But the Gigsaw uses a special way to get this result. Lilypond's midi 
output is especially buggy to do a sort about Param. It doesn't forget 
them but sometimes they are not in the right order for a clean midi 
file. Hence some unsolvable issues when I used Mididings.

You can check what i say with midicomp.

For this reason Gigsaw's midi files are stamped +veloc.
Have you succeed to install and run the new Drummer's Gigsaw?
There are around 250 downloads on my site and nobody gives me a 
feedback. I'm a bit disappointed.


P.S. A second edition is coming soon with an easier install. All the 
stuff will be done by a bash script. Ouf!


Mmh yeah, for composition stuff it would be nice if the midi output of 
lilypond could be improved.


About your project. I like the fact that you do something with Lilypond, 
but I don't know the goal of the project very well and so I don't know 
if it's interesting for me personaly.


\r



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

Re: No fiddling claim

[Jonathan Wilkes]

> 
> Message: 3
> Date: Mon, 28 Sep 2009 10:21:01 +0200
> From: Jan Nieuwenhuizen 
> Subject: Re: No fiddling claim
> To: Jonathan Wilkes 
> Cc: lilypond-user@gnu.org
> Message-ID: <1254126061.1689.5876.ca...@heerbeest>
> Content-Type: text/plain; charset="UTF-8"
> 
> Op zondag 27-09-2009 om 14:22 uur [tijdzone -0700], schreef
> Jonathan
> Wilkes:
> 
> Hi Jonathan,
> 
> >      Not too long ago, I gave my
> opinion that "No fiddling" should be 
> > changed to "less fiddling" for the new website.
> >      After trying to do a quick
> exercise with a Schumann score, which I 
> > posted here concerning a slur tweak after a line
> break, I don't think the 
> > "less fiddling" claim is valid, either.
> 
> You seem to miss the point of the "no fiddling"
> remark.  
> 
> As an aside: this is exactly why I do not like the newly
> fumbled
> "less fiddling", it turns people's heads into the direction
> of
> fiddling.  People have come to think fiddling is
> normal and required.
> More often than not it isn't.  We do not want less
> fiddling, we want
> bug reports and no fiddling.  Okay... 

Hi Jan,
 I don't understand the meaning of the statement "More often than not 
it isn't." There are tweaks in all of the examples from the canon that 
begin the sections in NR, plus there are plenty of engraving mistakes in those 
examples as well that would require more tweaks (i.e., fiddling) to 
fix. For example, in Op. 53 in NR 1.1:
* "cresc." should be centered
* the end points of the slur in m. 36 should start about a half-space 
higher (or possibly at the top of the stem on the left end point)
* sf and hairpin should be higher
* hairpin shouldn't touch the right barline
* l.h. slurs in m. 34 and 36 should have more arc to be further from the 
sharp sign
* p in m. 38 should be centered
and whole-note, respectively

If the "no fiddling" thing is supposed to be the 
underlining philosophy of Lilypond, I definitely understand what you say. 
If it's supposed to draw current users of GUI programs to Lilypond with 
the idea that, more often than not, fiddling is not required, I don't 
think that's true except for the most rudimentary examples.

> 
> The idea of LilyPond is that the output should be beautiful
> without
> fiddling.  While this may not have been achieved yet
> for some pieces of
> music, it may be true next year.
> We found that if you
> wanted 
> beautifully engraved music, you would need to move almost
> every freaking
> note, beam, barline, slur, accidental and lyric when using
> an expensive,
> popular GUI program.

Actually, that's why I'd like to see how the process works for a Finale 
guru vs. Lilypond guru: not as a contest to see who "wins", but as a way 
to get a sense of how each copyist/engraver spends most of their time. 
For example, I'm pretty sure the Finale user wouldn't need to move 
every beam manually (though I'm not sure about note positions in the newer 
versions).

> 
> It may be that some tweaks, esp. where you need visible
> feedback
> take more time to do in LilyPond than they do in a GUI
> program.
> I don't think we particularly care about this.  The
> upside here
> is that any tweaks you do need, can be quite easily
> improved
> incrementally, saved for a next time, discussed on a
> mailing
> list -- while mouse movements cannot.
> 
> If you want to help, please post a minimal snippet with the
> slur
> or grace note that you do not like to the bug-lilypond
> list.

I'm happy to help and post some examples of the behavior I want to 
tweak.  The main tweak headache I'm having concerns cross staff beams, and 
slurs broken over barlines (esp. long ones).

Thanks a lot for the response.

-Jonathan

> 
> Jan.





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

Re: No fiddling claim

[Jan Nieuwenhuizen]

Op maandag 28-09-2009 om 10:33 uur [tijdzone -0700], schreef Jonathan
Wilkes:

>  I don't understand the meaning of the statement "More often than not 
> it isn't."

What I meant to say is that certain tweaks are fundamentally
not automatable.  However, in many cases  we should expect
lilypond to do the right thing and if she doesn't, strive
to make it so.

> For example, in Op. 53 in NR 1.1:

Link please?

I do not see anything you mention here
http://lilypond.org/doc/v2.13/Documentation/notation/Pitches#Pitches


Jan.




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

Re: The new Drummer's Gigsaw: first edition.

[Philippe Hezaine]

rosea grammostola a écrit :


About your project. I like the fact that you do something with Lilypond, 
but I don't know the goal of the project very well and so I don't know 
if it's interesting for me personaly.


\r


Here is the old introduction of the Gigsaw, when it was the Drummer's 
Free Art around two years ago.


Really, there is a lack of possibilities in the free world about to use
pre-built drums patterns as a machine drum. As the novice as the song’s
composer who wants to outline a arrangement, the assessment is: there’s 
still no consistent free possibilities. The project "The Drummer’s 
Gigsaw" aims to fill this gap.


Since this claim the project is becoming more mature. I plan to split 
the project in two parts. One with BASES-patterns and midi+veloc, the 
other as a duplicate book for a real drummer. The latter will be going 
more in the scope of Lilypond. (with its goal) But given the power of 
Lilypond and its GNU/GPL license I have had an idea to extend it for my 
purpose in the free world. It's as simple as I tell you. And it works 
very well at home.


Cheers.
--
  Phil.
Superbonus-Project (Site principal) 

Superbonus-Project (Plate-forme d'échange):



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

Re: No fiddling claim

[Reinhold Kainhofer]

Am Montag, 28. September 2009 19:33:09 schrieb Jonathan Wilkes:
> Hi Jan,
>  I don't understand the meaning of the statement "More often than not
> it isn't." There are tweaks in all of the examples from the canon that
> begin the sections in NR, plus there are plenty of engraving mistakes in
>  those examples as well that would require more tweaks (i.e., fiddling) to
>  fix. For example, in Op. 53 in NR 1.1:

Please compare with several printed versions of this piece:
http://imslp.org/wiki/Piano_Sonata_No.21,_Op.53_(Beethoven,_Ludwig_van)

> * "cresc." should be centered

Some editions center it, some right-align it, some left-align it like 
lilypond...

> * the end points of the slur in m. 36 should start about a half-space
> higher (or possibly at the top of the stem on the left end point)

Granted.

> * sf and hairpin should be higher

Why should it be higher rather than vertically centered?

Also please note that piano centered dynamics is not a supported feature. In 
particular, see section 2.2.1:
"Dynamics are not automatically centered, but workarounds do exist. One option 
is the ‘piano centered dynamics’ template under  Piano templates; another 
option is to increase the staff-padding of dynamics as discussed in  objects 
Moving objects."

Yes, that's a real drawback, but unless someone steps up to improve piano-
centered dynamics, things will not improve



BTW, which version are we talking about? 2.12 or 2.13 docs? The 2.12 dynamics 
look perfectly centered. In 2.13 they are not, because that snippet uses one 
of the mentioned workarounds, which apparently no longer works...

> * hairpin shouldn't touch the right barline

Granted, there should be a little space.

> * l.h. slurs in m. 34 and 36 should have more arc to be further from the
> sharp sign

In almost all of the scores the slur and the accidental touch.

> * p in m. 38 should be centered

Isn't it?

> and whole-note, respectively

What should be different with the whole-note?

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org


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

Re: Conditionally displaying stems in void notation

[Rodolfo Zitellini]

It turns out I was wrong, duration-log can be accessed for the stems.
The code now is really simple:

turnStemOff =
#(lambda (grob)
  (let* ((dur (ly:grob-property grob 'duration-log)))
  (if (> dur 1)
(ly:stem::print grob

And thanks to Mats' snippet, I can (almost) automatically produce void
3/2 and 'normal' 3/2 from the same input.

Thanks all!

On Mon, Sep 28, 2009 at 10:20 AM, Rodolfo Zitellini  wrote:
> Yes, but I would not have correct crotchets - in this type of void
> notation crotchets are written out as quavers, with connected stems
> and all, but with a white notehead.
> I think I can:
> 1) write out everything in 3/2 and then alter manually every note <=
> than a quarter to transform it in an eight
> 2) Halve all the values of the original, writing it in 3/4, then
> blanking out all the noteheads (with duration-log). In this case all
> the quarters are displayed corretly - they effectively become eights
> with white noteheads - but (obviously) all the whole notes in the
> original now are written as minims. I then manually turn off their
> stem to make them wholes again. This is because I am faking 3/2 using
> 3/4 (for the abovementioned eigths).
> I can do this all manually, but it is quite tedious and long, and in
> clutters my code (since I have to torn off stems almost every 2 notes)
> - a way of turning off stems for all minims would be much more simple.
>
> Thanks,
> Rodolfo
>
> On Sat, Sep 26, 2009 at 9:54 PM, Mats Bengtsson
>  wrote:
>> Isn't it simplest to first use the trick described in
>> http://lsr.dsi.unimi.it/LSR/Item?id=305 to modify the duration of each note
>> to the double, and then alter the note heads. This should give you correct
>> stems.
>>
>>   /Mats
>>
>> Rodolfo Zitellini wrote:
>>>
>>> Hello list,
>>> I am trying to typeset a piece in 3/2 void notation. I entered all the
>>> music in 3/4 and altered the noteheads with #'duration-log = 1 to make
>>> all notes white. This fakes 3/2 ok, but all notes bigger than a minim
>>> (in 3/2) now have stem, which requires me to turn on and off all the
>>> stems manually for every note that should not have one (i.e. all the
>>> semibreves in 3/2).
>>> I understand that in scheme it is possible to access the value of
>>> duration-log to conditionally change the notehead stencil, it it
>>> possible to do the same for the stem? I would just need to hide the
>>> stem for all notes with value >= 2 (as entered in lilypond).
>>> Regards
>>> Rodolfo
>>>
>>>
>>> ___
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>
>>
>> --
>> =
>>        Mats Bengtsson
>>        Signal Processing
>>        School of Electrical Engineering
>>        Royal Institute of Technology (KTH)
>>        SE-100 44  STOCKHOLM
>>        Sweden
>>        Phone: (+46) 8 790 8463
>>       Fax:   (+46) 8 790 7260
>>        Email: mats.bengts...@ee.kth.se
>>        WWW: http://www.s3.kth.se/~mabe
>> =
>>
>>
>


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

Re: another route from MIDI to lilypond (from NtEd developer)

[Martin Tarenskeen]

On Mon, Sep 28, 2009 at 01:32:37PM +0200, Joerg Anders wrote:
> On Mon, 28 Sep 2009, Martin Tarenskeen wrote:
>
>> That's why midi2ly has a "--key=..." commandline option. Unfortunately
>> this option is not working ( The commandline key-signature is
>> overwritten by the one in the MIDI meta events). I'm looking into it to
>> solve this problem.
>
> NtEd has such a "--key=..." option implicitely! 

> I can't see any problem here.

Yes, NtEd does a pretty good job. It's just that I'm a commandline fan 
and want to try to debug and improve midi2ly anyway. 

-- 

Martin Tarenskeen





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

Re: Beaming rules in 2.13.4

[Nicolas Sceaux]

Le 28 sept. 09 à 10:34, Nick Payne a écrit :

	\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 32) . (4 4 4  
4 4 4)))

\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 8) . (2 2 2)))


These are not a correct beam rules, as I was told lately.
A beam setting override *must* contain all rules that apply to a given
time signature. Here, you specify the 32th note or the 8th note rules,
but no default rule.

So (anyone, please correct me if I'm wrong):
- you open scm/beam-settings.scm
- you look for the (3 . 4) settings
- you copy the rules, that is:

((* . (3))
  ((1 . 16) . (4 4 4))
  ((1 . 32) . (8 8 8))
  ((1 . 64) . (16 16 16))
  ((1 . 128) . (32 32 32)))

Now, if all you want to change is, say, the 32th note rule, you fix it:

\overrideBeamSettings #'Voice #'(3 . 4) #'end #'((* . (3))
   ((1 . 16) . (4 4 4))
   ((1 . 32) . (4 4 4 4 4 4)) ;; your change is here
   ((1 . 64) . (16 16 16))
   ((1 . 128) . (32 32 32)))

nicolas



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

Re: No fiddling claim

[Jonathan Wilkes]

--- On Mon, 9/28/09, Reinhold Kainhofer  wrote:

> From: Reinhold Kainhofer 
> Subject: Re: No fiddling claim
> To: lilypond-user@gnu.org
> Cc: "Jonathan Wilkes" 
> Date: Monday, September 28, 2009, 8:20 PM
> Am Montag, 28. September 2009
> 19:33:09 schrieb Jonathan Wilkes:
> > Hi Jan,
> >      I don't understand the meaning of
> the statement "More often than not
> > it isn't." There are tweaks in all of the examples
> from the canon that
> > begin the sections in NR, plus there are plenty of
> engraving mistakes in
> >  those examples as well that would require more
> tweaks (i.e., fiddling) to
> >  fix. For example, in Op. 53 in NR 1.1:
> 
> Please compare with several printed versions of this
> piece:
> http://imslp.org/wiki/Piano_Sonata_No.21,_Op.53_(Beethoven,_Ludwig_van)
> 
> > * "cresc." should be centered
> 
> Some editions center it, some right-align it, some
> left-align it like 
> lilypond...
> 
> > * the end points of the slur in m. 36 should start
> about a half-space
> > higher (or possibly at the top of the stem on the left
> end point)
> 
> Granted.
> 
> > * sf and hairpin should be higher
> 
> Why should it be higher rather than vertically centered?

If it were higher it would be centered.  In that image I count about 11 
pixels from the bottom of the rh staff to the top of the f, and 5 pixels 
from the bottom of the f to the lh staff.

> 
> Also please note that piano centered dynamics is not a
> supported feature. In 
> particular, see section 2.2.1:
> "Dynamics are not automatically centered, but workarounds
> do exist. One option 
> is the ‘piano centered dynamics’ template under 
> Piano templates; another 
> option is to increase the staff-padding of dynamics as
> discussed in  objects 
> Moving objects."
> 
> Yes, that's a real drawback, but unless someone steps up to
> improve piano-
> centered dynamics, things will not improve

This is why I think "no fiddling" is a philosophy rather than an answer 
to "why use lilypond?"  Actually, I think I would be less critical of 
this claim if it were specific: "No note-spacing headaches" is something 
I would agree with.

> 
> 
> 
> BTW, which version are we talking about? 2.12 or 2.13 docs?
> The 2.12 dynamics 
> look perfectly centered. In 2.13 they are not, because that
> snippet uses one 
> of the mentioned workarounds, which apparently no longer
> works...

Oh, sorry, I'm looking at the 2.13 docs.

> 
> > * hairpin shouldn't touch the right barline
> 
> Granted, there should be a little space.
> 
> > * l.h. slurs in m. 34 and 36 should have more arc to
> be further from the
> > sharp sign
> 
> In almost all of the scores the slur and the accidental
> touch.

I'm looking at the dover edition edited by Schenker, and the von Bulow 
edition on the IMSLP (I can't find the second volume my Henle edition).  
In neither does the accidental actually touch the slur.  Furthermore, 
in both editions the slurs "match," von Bulow's has big broad slurs, and 
Schenker's are less exagerrated.  In the lilypond example, there is a 
mixture of curvy slurs and straight ones which is visually distracting 
(i.e., Lilypond doesn't seem to have a "house style" to its default slurs).

> 
> > * p in m. 38 should be centered
> 
> Isn't it?

No, it's basically in the same position as the sf of the previous system. 
(see above)

> 
> > and whole-note, respectively
> 
> What should be different with the whole-note?

Well, I thought the slur got to close, but now I think the problem is the 
difference between the arc of that slur and the one above it.

I'll go ahead and list the other problems I saw in the NR examples.

1.2 Rhythms

In the two scores I've looked at (referenced above), the lh notes are 
beamed in groups every eighth note- not every quarter.

Grace notes don't affect the spacing in the left hand (they are just 
fitted into the space between the eighth and the following sixteenth 
note.

In the second measure of the rh, beat 2, the sixteenths are beamed 
separately from the 32nds (same thing in m. 4).

\p\> is not centered

in the 3rd measure, the 128th-note beam seems to be shifted too far down 
(I'm not sure what the rule is for the positions of such small durations, 
however in the Schenker score the bottom of the beam stays within a half- 
space of the bottom line of the staff).

1.5 Simultaneous Notes

The hairpin in the top system collides with the slur.

The trill symbols in the second system touch each other.

The trill flat looks a little too small.

The dynamics in the system aren't centered.

Second system, 4th measure, lh: the dot of the dotted eighth rest is 
inside the f clef (should be a whole rest here anyway).

1.7 Editorial Annotations

The beam on the l.h. grace note is too high.

-Jonathan

> 
> Cheers,
> Reinhold
> 
> -- 
> --
> Reinhold Kainhofer, reinh...@kainhofer.com,
> http://reinhold.kainhofer.com/
>  * Financial & Actuarial Math., Vienna Univ. of
> Technology,

Re: No fiddling claim

[Jonathan Wilkes]

> Message: 3
> Date: Mon, 28 Sep 2009 19:47:44 +0200
> From: Jan Nieuwenhuizen 
> Subject: Re: No fiddling claim
> To: Jonathan Wilkes 
> Cc: lilypond-user@gnu.org
> Message-ID: <1254160064.1689.5885.ca...@heerbeest>
> Content-Type: text/plain; charset="UTF-8"
> 
> Op maandag 28-09-2009 om 10:33 uur [tijdzone -0700],
> schreef Jonathan
> Wilkes:
> 
> >      I don't understand the meaning of
> the statement "More often than not 
> > it isn't."
> 
> What I meant to say is that certain tweaks are
> fundamentally
> not automatable.  However, in many cases  we
> should expect
> lilypond to do the right thing and if she doesn't, strive
> to make it so.

That sounds good to me.

> 
> > For example, in Op. 53 in NR 1.1:
> 
> Link please?
> 
> I do not see anything you mention here
>     http://lilypond.org/doc/v2.13/Documentation/notation/Pitches#Pitches

Yep, that's it.  Right underneath The heading "1.1 Pitches", there's a 
dotted line, then two systems from a Beethoven Sonata with a green 
border around it.

-Jonathan

> 
> 
> Jan.





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

Slur through a rest

[Jonathan Wilkes]

Hello,
 Below is an example of a slur that's stumping me.  Could anyone 
suggest a way of avoiding the rest that doesn't mess up the continuation 
after the line break?  I've tried adjusting 'positions but it doesn't 
produce an effect.

Also, I noticed that when I use the \break that is commented out instead of the 
other one, I get the following error and no line break:

warning: forced break was overridden by some other event, should you be using 
bar checks?

It obviously has to do with grace notes, and I saw a relevant email here:

http://lists.gnu.org/archive/html/bug-lilypond/2005-10/msg00040.html

but what does it mean to "sync" grace notes across staves?

Thanks,
Jonathan

snippet:

\version "2.13.3"

staffPiano = \new PianoStaff {
\set PianoStaff.midiInstrument = #"acoustic grand"
\set PianoStaff.instrumentName = #"Piano  "
\time 3/4
<<
\context Staff = "RH" {  % Right hand 
\clef treble
\key c \major
\relative c' {
\new TimeSig
  R2. | R2. | r4 r s4 | s2. %\break
  |
  s2. | R2. | R2. |
}
}
\context Staff = "LH" {  % Left hand
\clef bass
\key c \major
\relative c {
<<
{ s2. | 
  s2. |
  aes8^\p\( bes \times 2/3 { f' g d' } \change 
Staff = "RH" fis b |
  e bes' \times 2/3 { c g d } \times 2/3 { 
fis'4-- e,8 } \break
  |
  \grace { aes16[ bes] } g'4~--
  \times 2/3 { g8 e \acciaccatura a,  }
  32 c'8\) r16. | \change Staff = "LH" 
s2. | s2. |
}
\new Voice { R2. | R2. | s2. | R2. | R2. | 
R2.*2 }
>>
}
}
>>
}

\score {
<<
\staffPiano
>>
}


  


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

Re: Beaming rules in 2.13.4

[Nick Payne]

Nicolas Sceaux wrote:


Le 28 sept. 09 à 10:34, Nick Payne a écrit :

\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 32) . (4 4 
4 4 4 4)))
\overrideBeamSettings #'Voice #'(3 . 4) #'end #'(((1 . 8) . (2 2 
2)))


These are not a correct beam rules, as I was told lately.
A beam setting override *must* contain all rules that apply to a given
time signature. Here, you specify the 32th note or the 8th note rules,
but no default rule.

So (anyone, please correct me if I'm wrong):
- you open scm/beam-settings.scm
- you look for the (3 . 4) settings
- you copy the rules, that is:

((* . (3))
  ((1 . 16) . (4 4 4))
  ((1 . 32) . (8 8 8))
  ((1 . 64) . (16 16 16))
  ((1 . 128) . (32 32 32)))

Now, if all you want to change is, say, the 32th note rule, you fix it:

\overrideBeamSettings #'Voice #'(3 . 4) #'end #'((* . (3))
   ((1 . 16) . (4 4 4))
   ((1 . 32) . (4 4 4 4 4 4)) ;; your change is here
   ((1 . 64) . (16 16 16))
   ((1 . 128) . (32 32 32)))
Thanks. I don't think the documentation makes this clear. All the 
examples of overrideBeamSettings that I looked at in the documentation 
were for uncommon time signatures where only one ducation of note was 
being dealt with.


Nick


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

Re: special markings for string players....

[Marc Hohl]

Ralph Palmer schrieb:

Paul and Marc -

My apologies for the late reply -- I was on vacation last week, with 
no internet access. For the circumflex indicating a half step, take a 
look at the Learning Manual and possibly the index, and look for \markup.
I didn't find anything your problem - but if it is in the Learning 
Manual, there will also be the code to achieve

it, am I wrong?


For the bowing markers, I've seen H or Fr, T or P, M, LH, UH and WH, 
for heel or frog, tip or point, middle, lower half, upper half, and 
whole bow, respectively. I'm also attaching .png files showing graphic 
symbols from a book I have. The symbols should be self-explanatory. If 
not, feel free to email me for clarification.
I think it is possible to draw such symbols with postscript and embed 
these in lilypond \markup commands.
But I am not at all familiar with string music - is this graphical 
representation kind of standard?


Marc


Ralph




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