Re: Changing the distance between a slur and a note head
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
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 mats.bengts...@ee.kth.se 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
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 jann...@gnu.org | 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
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
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
}
}
}
inline: test4.png___
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)
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)
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)
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.
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)
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]
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?
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?
Hi,
\layout {
indent = 0.0
}
--
Marek Klein
http://gregoriana.sk
2009/9/28 Br. Athanasius Pelletier athp...@gmail.com
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]
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
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]
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.
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) http://superbonus.project.free.fr Superbonus-Project (Plate-forme d'échange): http://philippe.hezaine.free.fr ___ 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 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
Message: 3 Date: Mon, 28 Sep 2009 10:21:01 +0200 From: Jan Nieuwenhuizen janneke-l...@xs4all.nl Subject: Re: No fiddling claim To: Jonathan Wilkes jancs...@yahoo.com 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
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.
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) http://superbonus.project.free.fr Superbonus-Project (Plate-forme d'échange): http://philippe.hezaine.free.fr ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Conditionally displaying stems in void notation
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 xhero...@gmail.com 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 mats.bengts...@ee.kth.se 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)
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
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
--- On Mon, 9/28/09, Reinhold Kainhofer reinh...@kainhofer.com wrote: From: Reinhold Kainhofer reinh...@kainhofer.com Subject: Re: No fiddling claim To: lilypond-user@gnu.org Cc: Jonathan Wilkes jancs...@yahoo.com 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, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 *
Re: No fiddling claim
Message: 3 Date: Mon, 28 Sep 2009 19:47:44 +0200 From: Jan Nieuwenhuizen janneke-l...@xs4all.nl Subject: Re: No fiddling claim To: Jonathan Wilkes jancs...@yahoo.com 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
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, des, a' }
des 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
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
