Re: GSoC page: hammer-on and pull-off are already implemented
I'm CCing the tablature list, in case anyone (Patrick?) has some
suggestions about this doc addition.
Il 12/04/2012 00:40, Colin Hall ha scritto:
I think you are right, I cannot find any mention in the doc.
It should be in NR 2.4.1
Pull-off and hammer-on are slurs.
Hammer-on when the pitch goes up, pull-off when it goes down.
I'm not familiar with the terms used by fretted string instrument
musicians, so I'd be very grateful if you or Marc would submit a
suitable documentation suggestion, as decribed here:
http://www.lilypond.org/doc/v2.15/Documentation/contributor/documentation-suggestions
Once the bug squad receive that we can create a tracker for the
Documentation issue.
I would put hammer-on and pull-off in NR 2.4.1, Selected snippets,
before Slides in tablature (because legato slides use slurs).
Sorry for my bad english...here we go.
## Doc snippet ##
Hammer-on and pull-off can be obtained using slurs. Hammer-on is a
raising slur, while pull-off is a falling slur:
\new TabStaff {
\relative c' {
d4( e\2)
a( g)
}
}
The arc of hammer-on and pull-off is upwards in voice one and three,
downwards in voice two and four:
\new TabStaff {
\relative c' {
{ \voiceOne g2( a) }
\\ { \voiceTwo a,( b) }
\oneVoice
}
}
Hammer-on and pull-off work the same way in chords. By default, only one
arc is drawn. You can have a double arc by setting the doubleSlur
property to true (be sure to use \once or set it back to false when you
don't need it anymore):
\new TabStaff {
\relative c' {
% chord hammer-on and pull-off
\once \set doubleSlurs = ##t
g' b8( a c g b)
g( a2) % to check that slur is single again
}
}
[Remember to add the @cindex entries]
I'm not sure if we take bug reports against the GSoC page, but no
matter. Once I have those references from you I can create a tracker.
See issue tracker here:
http://code.google.com/p/lilypond/issues/detail?id=2475
thanks!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: GSoC page: hammer-on and pull-off are already implemented
On Fri, Apr 13, 2012 at 09:08:41AM +0200, Federico Bruni wrote: I'm CCing the tablature list, in case anyone (Patrick?) has some suggestions about this doc addition. Il 12/04/2012 00:40, Colin Hall ha scritto: I think you are right, I cannot find any mention in the doc. It should be in NR 2.4.1 Pull-off and hammer-on are slurs. Hammer-on when the pitch goes up, pull-off when it goes down. I'm not familiar with the terms used by fretted string instrument musicians, so I'd be very grateful if you or Marc would submit a suitable documentation suggestion, as decribed here: http://www.lilypond.org/doc/v2.15/Documentation/contributor/documentation-suggestions Once the bug squad receive that we can create a tracker for the Documentation issue. I would put hammer-on and pull-off in NR 2.4.1, Selected snippets, before Slides in tablature (because legato slides use slurs). Sorry for my bad english...here we go. Good job, Frederico. Thanks very much for taking the time to prepare that doc suggestion. One of the bug squad will create a tracker for this. Any comments from the lists can be added to the tracker in due course. Cheers, Colin. -- Colin Hall ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: include-settings and path or file name with blanks
Graham Percival-3 wrote: On Thu, Apr 12, 2012 at 02:21:57PM -0700, -Eluze wrote: just a question: could we get rid of these -doptions? Maybe as many as 5 of them. Not more. since shortly at least 50% (or is it 80% ? ) can be defined directly in LilyPond without any loss of comfort/functionality - or do I overlook something? AFAIK all of the -d options can be define in lilypond itself, as long as you know scheme. In addition, any of them could be enabled with the -e scheme option. For your own scores, you can certainly do this. But most of those -d options were added for our doc build process, to assist the mutopia project, or for LSR. In those cases, we explicitly do not want to change the .ly source, although we want to use those options. please let me know your opinion - I would be happy to discuss and integrate it in these plans I don't think it's worth trying to mess with -d options, primarily because literally nobody knows which ones are used. Going through all our build scripts, finding out what mutopia is still using, checking with LSR, checking for any other build processes that people are using, would be a huge task. I would rather add something to the docs saying if you're not certain that you need a -d option, then you probably don't, and it will save you time and energy if you do XYZ instead. OK, let's just add a small note, see https://code.google.com/p/lilypond/issues/detail?id=2476thanks=2476ts=1334313574 Eluze -- View this message in context: http://old.nabble.com/include-settings-and-path-or-file-name-with-blanks-tp33661145p33681029.html Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond bug 2368
OK, thanks for explanation! Actually, I've menaged to solve my problem by entering hidden notes with unHidden slur in separate voice. Now the tie refers to the right notes and appeals to my sense of aesthetic - despite colliding with an accidental (take a look at the attachment). Janek, I'm not a student of Politechnika Warszawska - neither former nor present. I'm a former student of Akademia Muzyczna w Gdańsku :) Best Wishes Karol Majewski 2012/4/11 Janek Warchoł janek.lilyp...@gmail.com On Wed, Apr 11, 2012 at 2:36 AM, Colin Hall colingh...@gmail.com wrote: On Sat, Apr 07, 2012 at 05:32:28PM +0200, Karol Majewski wrote: Is it possible to mark 2368 bug as critical? I think this kind of regression is a serious problem. Just take a look at my last comment: http://code.google.com/p/lilypond/issues/detail?id=2368#c6 I agree with you that the notation output is not correct, especially in the sample you provide in comment 6. I'm going to do my best to explain why this issue should not be marked critical. I hope that others will correct my statements as necessary. You might not be aware that there are several open issues for Lilypond that relate to the typesetting of ties and slurs. For example see issue 298, referenced from issue 2368. http://code.google.com/p/lilypond/issues/detail?id=298 There are others. As I understand it the development team have identified that a better implementation of ties is possible but requires aesthetic design work to establish how this feature should work before technical implementation work can begin. The technical work may be substantial. Yes, i do think that it will make more sense to rewrite tie code bearing in mind all bad tie cases instead of fixing the issues one by one. Besides, i suppose that marking this as critical will have only one result: next stable release will be postponed for 3 months or so. It won't make the bug fixed immediately, nor even soon. Janek has a study of Lilypond's typesetting of ties and slurs which is work in progress and which may provide the aesthetic design we need. He mentioned it in response to your original bug report: http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg01203.html Yes. The bad news is that i won't have time to finish it until summer. However, if there's anyone willing to finish it, i can share my results and provide some guidance. The task requires aesthetic sense and analytical skills, and i estimate 40 hours of work is needed to finish the tie analysis - no idea how long implementation will take. Bottom line: find someone to finish tie report and implement it's conclusions (or pay David to implement them - i will add EURO 50 from myself if this is done before May 15). i hope that didn't sound too discouraging :) Janek PS Karol, are you a (former) student of Warsaw University of Technology, Faculty of Electronics (Elka)? attachment: li.png___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond bug 2368
- Original Message - From: Karol Majewski To: Janek Warchoł Cc: LilyPond Developmet Team ; Lilypond Bugs Sent: Wednesday, April 11, 2012 7:33 PM Subject: Re: lilypond bug 2368 OK, thanks for explanation! Actually, I've menaged to solve my problem by entering hidden notes with unHidden slur in separate voice. Now the tie refers to the right notes and appeals to my sense of aesthetic - despite colliding with an accidental (take a look at the attachment). Janek, I'm not a student of Politechnika Warszawska - neither former nor present. I'm a former student of Akademia Muzyczna w Gdańsku :) Best Wishes Karol Majewski Check my suggestion at http://code.google.com/p/lilypond/issues/detail?id=2368 - it works better and is designed for this. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: issues 2266 and 1721
- Original Message -
From: Jean-Charles Malahieude lily...@orange.fr
To: Lily Bugs bug-lilypond@gnu.org; lilypond-devel
lilypond-de...@gnu.org
Sent: Saturday, March 31, 2012 6:47 PM
Subject: Re: issues 2266 and 1721
Hi all,
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present a
translated link towards snippets, like @rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is snippets/hauteurs.fr.html which doesn't
exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is snippets/pitches.fr.html where I want to
go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present a
translated link towards glossary both in LM and NR, and I never get any
kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
music-glossary/pitch-names.fr.html where I want to arrive and it's a
perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and why,
though they look identical do they work differently according to the
target manual?
Cheers,
Jean-Charles
I thought I'd have a look at this, and have just been doing so. I think the
difference between learning and notation is that there is no instance of
@rlsrnamed or @rlsr in learning, whereas it's used extensively in notation.
So there's no difference in the file types, except it's used in one and not
in the other
--
Phil Holmes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: issues 2266 and 1721
Le 13/04/2012 19:54, Phil Holmes disait :
- Original Message - From: Jean-Charles Malahieude
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present a
translated link towards snippets, like @rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is snippets/hauteurs.fr.html which
doesn't exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is snippets/pitches.fr.html where I
want to go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present a
translated link towards glossary both in LM and NR, and I never get
any kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
music-glossary/pitch-names.fr.html where I want to arrive and it's a
perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and
why, though they look identical do they work differently according to
the target manual?
I thought I'd have a look at this, and have just been doing so. I think
the difference between learning and notation is that there is no
instance of @rlsrnamed or @rlsr in learning, whereas it's used
extensively in notation. So there's no difference in the file types,
except it's used in one and not in the other
The fact is that I've added a @rlsrnamed somewhere in the LM in order to
test.
Secondly, both @rglosnamed and @rlsrnamed should have the same effect:
neither glossary nor snippets are translated, an I wonder why I get no
problem at all with @rglosnamed as opposed to @rlsrnamed.
@macro rglosnamed{TEXT,DISPLAY}
@vindex \TEXT\
@ref{\TEXT\,,\DISPLAY\,music-glossary,Glossaire}
@end macro
@macro rlsrnamed{TEXT,DISPLAY}
@ref{\TEXT\,,\DISPLAY\,snippets,Morceaux choisis}
@end macro
and even adding a @vindex \TEXT\ to rlsrnamed doesnt change anything.
Cheers,
Jean-Charles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
