formatting only one syllabe in a word - please help
Hi,
probably this is quite basic, but i'm in a hurry and can't find it in manuals...
I want only one syllabe in a word be formatted, for example i'd like
to have syllabe ma in word malicious bold and underlined.
Unfortunately the code \markup { {\bold \underline ma} licious }
produces two words: ma licious.
How should it be done?
cheers,
Jan
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: formatting only one syllabe in a word - please help
Am 24.11.2010 09:27, schrieb Janek Warchoł:
Hi,
probably this is quite basic, but i'm in a hurry and can't find it in manuals...
I want only one syllabe in a word be formatted, for example i'd like
to have syllabe ma in word malicious bold and underlined.
Unfortunately the code \markup { {\bold \underline ma} licious }
produces two words: ma licious.
How should it be done?
Maybe \concat solves your problem? See
http://lilypond.org/doc/v2.13/Documentation/notation/align
HTH
Marc
cheers,
Jan
___
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: formatting only one syllabe in a word - please help
2010/11/24 Janek Warchoł lemniskata.bernoull...@gmail.com:
Hi,
probably this is quite basic, but i'm in a hurry and can't find it in
manuals...
I want only one syllabe in a word be formatted, for example i'd like
to have syllabe ma in word malicious bold and underlined.
Unfortunately the code \markup { {\bold \underline ma} licious }
produces two words: ma licious.
How should it be done?
For example
\markup {\concat{ {\bold\underline ma} licious }}
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: formatting only one syllabe in a word - please help
2010/11/24 Francisco Vila paconet@gmail.com:
2010/11/24 Janek Warchoł lemniskata.bernoull...@gmail.com:
Unfortunately the code \markup { {\bold \underline ma} licious }
produces two words: ma licious.
How should it be done?
For example
\markup {\concat{ {\bold\underline ma} licious }}
It works, thank you!
(now i know which part of the manual i've overlooked...)
cheers,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to get half-bar used in Bach Music?
Much neater, thank you.
M
On 11/22/2010 12:03 PM, Alexander Kobel wrote:
[ with cc to lilypond-user; please keep the discussions on the mailing
list, others might have the same problems and can find the solutions
in the mailing list archives ]
On 2010-11-22 12:38, Martin Kemp wrote:
I've just been struggling with this too. All else having failed, I faked
it by using an invisible bar line and adding:
\once \override TextScript #'extra-offset = #'(-1 . 3.5) c8_\markup {
\musicglyph #rests.M2mensural }
Woah, that's some ugly hack...
Again, I don't see the need for this - I just tested the following,
and it works just perfect for me (use \halfBar to make a real bar
line at the end of a measure appear smaller, and \halfAddBar to insert
a fake barline of half the usual extent). If it doesn't in your
setting, could you give a small compiling example to show the problem?
halfBar = \once \override Staff . BarLine #'bar-size = #2
halfAddBar = { \halfBar \bar | }
\relative c' {
c4 c \halfAddBar c c \halfBar |
c c c c |
}
Cheers,
Alexander
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
Am 24.11.2010 um 07:13 schrieb Steve Yegge: Hi Patrick, this sounds awesome. I think it will be very useful. However, I also think that Marc Hohl's suggestion is more general and would in fact cover many more of the use cases I have in mind. I think it might be appropriate to implement both of them. Marc's suggestion from earlier in the thread, if I may un-fork here, is: Hm, I don't know how you would invoke such a feature - perhaps like (pseudo-syntax!) \useStrings #'(3 5) to tell lilypond only to use these strings within the fret number calculation? Sounds interesting, but I don't know how to implement it. I had the same idea immediately after sending my original post. The idea is to subset the available strings -- simply take up to N-1 of them out of the picture. The syntax Marc suggested is ideal, because it lets you specify non-adjacent strings (as opposed to, say, specifying a string range, which fails on the examples below.) Here's why his idea works better for me than chord shapes. Consider the following passage of consecutive ascending thirds, intended to be played on the fourth and fifth strings: c e d f e g f a g b a c b d c e Your patch for using chord shapes may not cover this whole passage because they change shape! The fingerings would be, for example: c-2 e-1 d-3 f-1 e-3 g-1 f-2 a-1 g-2 b-1 a-3 c-1 b-3 d-1 c-2 e-1 Unless I'm mistaken this would require up to five applications of your chord-shape instructions, at which point you're little better off than when setting TabStaff.minimumFret on roughly every other chord change (which is what it works out to in practice.) No, all thirds on the fourth and fifth strings would/could be covered by the c-shape definitions. The major thirds are part of the c-major- shape, the minor thirds belong to the c-minor-shape. (All shapes work in 17 keys.) So you'd just have to write: \cShape c e d f e g f a g b a c b d c e It could get pretty bad in pathological situations where you have minor mode scales with long intervals, or mid-progression key changes, or a temporary switch to fourths or even sixths between thirds -- all of which I have seen in the violin music I'm arranging for guitar. And my example is just thirds. I also have to arrange progressions of fourths, sixths, ninths, tenths, and hybrids/mixtures that move along a predefined set of strings for many beats. Even when your feature does the right thing for me, it's conceptually simpler to write (and think) in terms of which strings you're using rather than which shapes your hand is taking. This is probably true. On the other hand the chord shape is pretty obvious when you fret the root of a chord on a particular string. In most cases you only have two alternatives. If the root is e.g. on the fifth string, you have to decide whether your interval/chord rather belongs to the c-shape or to the a-shape. Oh yeah, and another big category is pedal tones (for lack of a more precise term for it -- even though the low note isn't sustained, it's a similar effect to pedal tones). I have lots of music that looks like this: d f' d g' d a'' d f' ... and so on, where you're playing an elevated melody over an open string. A classic example of this technique is the opening of AC/DC's For Those About To Rock, which uses the open-B as the pedal tone. The tab calculator is useless for this situation, and I don't see how chord shapes would help even if it were user-extensible. But the useStrings feature would solve it as neatly as it solves the other cases. I see you point in this particular example. On the other hand consider this: c e c g c c' c e' If you wanted to play this in first position you would have to use four useStrings-commands: pseudo-code \useStrings #'(4 5) c e \useStrings #'(3 5) c g useStrings #'(2 5) c c' useStrings #'(1 5) c e' /pseudo-code With the chord shape system you'd just enter \cShape c e c g c c' c e' and that's it, provided that all possible intervals/chords will have been defined in the chord shape files one lucky day. (BTW the chord shapes *are* user-extensible). The manual definition of intervals/ chords is interesting but time-consuming and probably error-prone. I see this as the main drawback of the chord shape system. Don't get me wrong -- I think your feature is going to be wonderful for most idiomatic guitar music. But there are lots of situations it won't cover, It all depends on the completeness of the chord shape files and some technical aspects. so I think having a more general mechanism would also be very useful. +1 Thanks, patrick Thanks, -steve On Tue, Nov 23, 2010 at 1:09 AM, Patrick Schmidt p.l.schm...@gmx.de wrote: Hi Steve, Am 23.11.2010 um 08:37 schrieb Steve Yegge: Hi all, The TabStaff is amazingly cool. I'm not a big tab user myself, but for people who want tabs, LilyPond makes it easy to add them. I've been busily adding tabs for a few months and have some
Re: Lyric tie
2010/11/23 Werner LEMBERG w...@gnu.org: http://paconet.org/prueba.pdf It looks all right in evince, but prints very misplaced on printer and looks the same in jedit/lilypondtool. This your file looks fine with all PDF viewers I've installed on my system; the lyric tie is taken from the `FreeSerif' font. I've tried your input file on my box, and here the lyric tie is taken from the `Sazanami-Mincho-Regular' font (which looks good too, BTW). In other words, you have to fiddle with the configuration of FontConfig to get a decent fallback font; this can't be controlled by lilypond. The fact is, my default configuration exhibits the problem. I'll try to do what you suggest (no the slightest idea about how to, at present). Do you know a way of figuring out which font does a glyph of the PDF belong to? Post-mortem, this is not difficult: Just use the --ps option of lilypond and search for `/uni203F' in the created PS file. Yes. That single character adds 2,855,700 bytes to the PS and 62,425 bytes to the PDF. (!) \override LyricText #'font-name = #DejaVuLGC Hmm. I've the DejaVu fonts installed too, but calling `fc-list', I can't find an entry for `DejaVuLGC'. Looking at http://dejavu-fonts.org/wiki/Main_Page I can see that this is a derivative which contains only Latin, Greek, and Cyrillic glyphs. And it doesn't contain the undertie `uni203F'! Uh, oh. Checking the complete font, `DejaVu Serif' (version 2.32), I see that it doesn't contain `uni203F' either... So you should stay with the `FreeSerif' font: \override LyricText #'font-name = #FreeSerif Which causes my problem, as far as I know. Oh, I like CenturySchlbk for lyrics, it's a real pity that things are not so straightforward for my systems (both Ubuntu 10.04). Where to start from about fiddling against callback fonts? Thanks, Werner and all! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lyric tie
Post-mortem, this is not difficult: Just use the --ps option of lilypond and search for `/uni203F' in the created PS file. Yes. That single character adds 2,855,700 bytes to the PS This is normal, since lilypond doesn't do font subsetting. Sazanami adds about 20MByte... and 62,425 bytes to the PDF. (!) This is a problem of Ghostscript which apparently doesn't do optimal font subsetting. Without checking, I suspect that it only strips the font's `glyf' table to a single glyph, leaving `cmap' and other tables unchanged. So you should stay with the `FreeSerif' font: \override LyricText #'font-name = #FreeSerif Which causes my problem, as far as I know. Oh, I like CenturySchlbk for lyrics, it's a real pity that things are not so straightforward for my systems (both Ubuntu 10.04). Where to start from about fiddling against callback fonts? There is no GUI to fontconfig, AFAIK. You have to fiddle around with the configuration files in `/etc/fonts/conf.d'. For example, I have, on my openSuSE box, a file `58-suse-post-user.conf' (this is a soft link to another file but fontconfig reads files from that very directory) which starts with !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig !-- Set fonts to be preferred when the standard aliases serif, sans-serif, and monospace are used. -- alias familyserif/family prefer familyDejaVu Serif/family familyLiberation Serif/family familyTimes New Roman/family familyThorndale AMT/family familySUSE Serif/family familyBitstream Vera Serif/family familyNimbus Roman No9 L/family familyLuxi Serif/family familyLikhan/family familyKacstBook/family familyFrank Ruehl CLM/family familyTimes/family familyKhmer OS System/family familyLohit Punjabi/family familyLohit Oriya/family familyPothana2000/family familyTSCu_Times/family familyBPG Chveulebrivi/family familyNazli/family familyFreeSerif/family familyMS PMincho/family familyMS Mincho/family familySazanami Mincho/family ... As you can see, `FreeSerif' is quite low in the hierarchy. BTW, I've updated fontconfig recently (to the above configuration), so I no longer get the lyric tie from `Sazanami Mincho'. If you like Century Schoolbook you should consider installing TeX Gyre Schola, which is a clone with a much increased number of glyphs (and it contains a glyph for the lyric tie): http://www.gust.org.pl/projects/e-foundry/tex-gyre/schola/qcs2.005otf.zip It was my plan to use these fonts as a replacement within LilyPond because of the much larger number of glyphs. Unfortunately, they don't contain Cyrillic glyphs yet (or rather, they had been removed due to copyright issues), so I'm postponing it. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lyric tie
2010/11/22 Francisco Vila paconet@gmail.com:
Hello, I have been searching a lot and still can not find a solution
for my lyric ties. I obtain very misplaced ones and I know that a
font like DejaVuLGC installed should do the trick in my Ubuntu system.
My problem is: I have it installed, how do I force lilypond to use
that font?
\version 2.13.40
\relative c' {
r4 f e d | c2 c
}
\addlyrics { Buon gior -- no~al mon -- do. }
http://paconet.org/prueba.pdf
It looks all right in evince, but prints very misplaced on printer and
looks the same in jedit/lilypondtool.
The situation is even more strange. I have installed the gv viewer
and currenly:
- gv shows and prints the lyric tie correctly. It shows a tiny
dialog that asks for a command, default is lpr, I simply accept.
- evince shows the lyric tie correctly. Prints it strangely misplaced.
- lpr command from a terminal prints it strangely misplaced, too.
- lilypondtool builtin PDF viewer shows it misplaced.
So, the winner is gv. Adobe reader is not an option.
Although I already know that fontconfig settings cause my problems, I
encounter difficult to climb that mountain and I need a solution that
just works right now, in the meantime while I finally understand how
to correctly set things up.
It's enigmatic why lpr on console doesn't work well, whilst gv's lpr
command does.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
After reading Marc's responses I think I see where I may have
sewn some confusion. I have conventional string numbers in the
non-tab staff, since my audience is partly classical guitarists who
cannot (or do not) read tab. So the information I'm providing is
redundant -- it's for two separate audiences. At some point I'll
be looking into compiling them separately, but for now I show
both staffs on each page.
So I can't just turn off string numbers as a workaround for this issue.
Sorry for not being clearer about that,
-steve
On Tue, Nov 23, 2010 at 9:25 PM, Steve Yegge steve.ye...@gmail.com wrote:
On Tue, Nov 23, 2010 at 10:16 AM, Carl Sorensen c_soren...@byu.eduwrote:
On 11/23/10 12:37 AM, Steve Yegge steve.ye...@gmail.com wrote:
Hi all,
The TabStaff is amazingly cool. I'm not a big tab user myself,
but for people who want tabs, LilyPond makes it easy to add them.
I've been busily adding tabs for a few months and have some feature
requests to put into the queue if possible.
1) Setting fixed strings to use for ascending/descending chords.
Currently it's nontrivial to specify tab positions for something like:
c c' d d' e e' f f'
g g' a a' b b' c c'
I've found it's most convenient to append the actual strings after
every chord, hence:
c c'\5\3 d d'\5\3 e e'\5\3 f f'\5\3
g g'\5\3 a a'\5\3 b b'\5\3 c c'\5\3
Why not
c\5 c'\3
Why do you want to put the string numbers *after* the chords, even when
you're putting finger numbers inside the chords?
Putting them after the chords is how you prevent printing string numbers.
It's the documented technique for giving override instructions to the tab
calculator. You can even put some inside the chord, thus printing them,
and move others outside in the same chord.
It is a nice feature. Tabulature would in fact be nigh-unusable without
it,
because the tab calculator is often wrong. For example, consider:
\include english.ly
music = \relative c {
a' e' a cs a'1
}
\score {
\new Staff {
\music
}
\new TabStaff {
\transpose c c, { \music }
}
}
In this example, the low A is placed on the 5th fret, 6th string.
The minimum fret is the default (zero), but the tab calculator
does not choose the open-A string, even though it would be
far more convenient to play it that way. If you annotate it with
fingerings:
a'-0 e'-1 a-1 cs-1 a'-41
it becomes doubly clear to the guitarist that the open-A string is
intended here, both because of the -0 fingering notation and
because it is the only physically reasonable configuration.
There are actually _two_ signals here that the tab calculator
should be picking up but is not. They are separate issues.
One is that even though the TabStaff.minimumFret is zero, the
calculator is not actually using the minimum fret. The other is
my #2 feature request, which is that it should respect open
string fingering requests, because they are unambiguous.
The workaround is to use string numbers external to the chord.
Putting them next to their notes merely creates redundant and
possibly irritating text for the guitarist to parse. It's already clear
that it's an open A, so having a circled string number at that
note is pointless. Instead you do this:
a' e' a cs a'1\5
And then you recompile and discover that even though extra
strings are processed from left to right, so the \5 logically should
go with the low a' note, the tab calculator has given up in despair
and is now showing only two strings, both incorrect. So you wind
up with this:
a' e' a cs a'1\5\4\3\2\1
and everything is magically solved.
I feel obliged to point out at this juncture that one of the primary
reasons for LilyPond's awesomeness -- perhaps the single biggest
reason -- is that it provides you with enough flexibility to work around
the default behavior if you're willing to dig deep enough.
2) Have the automatic tab calculator understand the -0 fingering.
Currently if you do something like this:
\relative c' {
\set TabStaff.minimumFret = #2
d'-0 a'-2 d-3 f-1
}
I would not be in favor of this -- all other fingerings except 0 indicate
a
finger number, but zero indicates a fret number.
Um, no. Think of it from a set-theoretic perspective. You have 4 fingers
and can choose up to four of them. There are sixteen possibilities, not
fifteen, because your choice can include the empty set.
I think it's much better
to have you write:
d'\4 a'-2 d-3 f-1
This will get you just what you want.
I believe you are mistaken. I do not necessarily want a printed string
number.
I would have to set the stencil to ##f with tweaks in order for it to work
this way.
It would be the very pinnacle of inconvenience, and a step backward from
the
current functionality.
It will choose strings 5, 4, 3, 2. Obviously in this case you could
just set the minimum fret to #0, but this may be an exception
Re: TabStaff feature requests
Hi Marc,
On Tue, Nov 23, 2010 at 11:28 PM, Marc Hohl m...@hohlart.de wrote:
Just for clarification: as the guitar is notated one octave above its
sounding pitch,
I use the following template:
\score {
\new StaffGroup
\new Staff {
\new Voice { \global \clef treble_8
\override Voice.StringNumber #'transparent = ##t
\music }
}
\new TabStaff {
\new TabVoice { \global \clef moderntab \music }
}
}
The octavated treble clef just does the right thing, and with the override,
you
remove the unneccesary string numbers.
Thanks; I'll try it. How do I turn off the little 8 symbol by the clef?
In this example, the low A is placed on the 5th fret, 6th string.
The minimum fret is the default (zero), but the tab calculator
does not choose the open-A string, even though it would be
far more convenient to play it that way. If you annotate it with
fingerings:
a'-0 e'-1 a-1 cs-1 a'-41
it becomes doubly clear to the guitarist that the open-A string is
intended here, both because of the -0 fingering notation and
because it is the only physically reasonable configuration.
I see your point, but I have no idea whether a suitable algorithm
can be found to cope all possible fingerings.
Oh, I didn't mean to suggest that there is such an algorithm, although
it seems like it would make a cool research project. I was just using
this example to illustrate the need for the tab-understands-(-0) workaround.
There are actually _two_ signals here that the tab calculator
should be picking up but is not. They are separate issues.
One is that even though the TabStaff.minimumFret is zero, the
calculator is not actually using the minimum fret.
IIUC, the calculator tries to put all fret positions within a four fret
interval,
so d\5 g would show up as
e---
b---
g---
D-5-
A-5-
E---
That makes sense. It's a really good heuristic, actually -- I've been
rather amazed at how often simply setting the minimum fret results in
generating optimal fingerings for a passage, even for relatively complex
music.
Regards,
-steve
Regards,
Marc
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
On 11/24/10 7:51 AM, Steve Yegge steve.ye...@gmail.com wrote: After reading Marc's responses I think I see where I may have sewn some confusion. I have conventional string numbers in the non-tab staff, since my audience is partly classical guitarists who cannot (or do not) read tab. So the information I'm providing is redundant -- it's for two separate audiences. At some point I'll be looking into compiling them separately, but for now I show both staffs on each page. So I can't just turn off string numbers as a workaround for this issue. I'm looking into this issue. The patch may be relatively simple to implement. I'm currently thinking of a context property defaultStrings that would specify the strings to be used in calculating a tab when no string information is given for a particular note or chord. I'm also using a fingering of 0 to be an open string. I'm thinking that the fingering of 0 should not show up as a fingering anywhere. If that is not correct, where should a fingering of 0 be displayed? Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
On Wed, Nov 24, 2010 at 7:00 AM, Carl Sorensen c_soren...@byu.edu wrote: On 11/24/10 7:51 AM, Steve Yegge steve.ye...@gmail.com wrote: After reading Marc's responses I think I see where I may have sewn some confusion. I have conventional string numbers in the non-tab staff, since my audience is partly classical guitarists who cannot (or do not) read tab. So the information I'm providing is redundant -- it's for two separate audiences. At some point I'll be looking into compiling them separately, but for now I show both staffs on each page. So I can't just turn off string numbers as a workaround for this issue. I'm looking into this issue. The patch may be relatively simple to implement. I'm currently thinking of a context property defaultStrings that would specify the strings to be used in calculating a tab when no string information is given for a particular note or chord. This sounds very nice. I'm also using a fingering of 0 to be an open string. I'm thinking that the fingering of 0 should not show up as a fingering anywhere. If that is not correct, where should a fingering of 0 be displayed? As far as I know, the number 0 is used by convention in both guitar and violin music to indicate an open string. It's in the same font and positioned using the same rules as fingers 1 through 4 -- at least it is in the music I've looked at recently. Maybe I'm misunderstanding your question, though? -steve Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
Hi Marc,
I've tried out your patch and it works like a charm!
Unfortunately it seems to be happiest in absolute pitch mode.
When I switch to relative mode it yields unexpected results.
I've modified your harmonic-test.ly to demonstrate the issue.
\include ./harmonic.ly
test = {
e,4
\harmonicByRatio #1/2 e,\6
\harmonicByRatio #1/3 a,\5
\harmonicByRatio #2/3 d,\4 |
\harmonicByRatio #1/4 { g8\3 b\2 e'\1 b\2 g b e 2 } |
e,1 | % check whether tab note head is restored
\harmonicByFret #12 e'4\1
\ottava #1
\harmonicByFret #7 e'4\1
\harmonicByFret #5 e'4\1
\ottava #2
\harmonicByFret #4 b\2 e'\1 4 |
\harmonicByFret #3 g\3 b\2 e'\1 4
\harmonicByFret #2.7 g\3 b\2 e'\1 4
\harmonicByFret #2.3 g\3 b\2 e'\1 4
\harmonicByFret #2 g\3 b\2 e'\1 4 |
\ottava #0
e,1 | % check whether tab note head is restored
}
reltest = \relative c {
b'8\2 [ e\1 ] % verify pitch for open strings
\harmonicByFret #12 b\2 [
\harmonicByFret #12 e\1 ]
\harmonicByFret #7 b\2 [
\harmonicByFret #7 e\1 ]
\harmonicByFret #5 b\2 [
\harmonicByFret #5 e\1 ]
}
\paper {
ragged-right = ##f
}
\score {
\new Staff {
\new Voice {
\clef treble_8
\override Voice.StringNumber #'transparent = ##t
\test
\break
\reltest
}
}
\new TabStaff {
\new TabVoice {
\test
\break
\reltest
}
}
}
At first glance it appears to be adding an octave to the current base
pitch each time a harmonic is created.
-steve
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
Sigh... please disregard this. It works fine. I just had the wrong
expectations. I assumed incorrectly that for purposes of relative
pitch calculation, the harmonics would be ignored, allowing you
to focus on the base string pitches.
It requires a bit more arithmetic this way, but it's logical enough.
Thanks for the patch -- you've fixed the biggest problem in my
150-page pile of arrangements!
-steve
On Wed, Nov 24, 2010 at 7:56 AM, Steve Yegge steve.ye...@gmail.com wrote:
Hi Marc,
I've tried out your patch and it works like a charm!
Unfortunately it seems to be happiest in absolute pitch mode.
When I switch to relative mode it yields unexpected results.
I've modified your harmonic-test.ly to demonstrate the issue.
\include ./harmonic.ly
test = {
e,4
\harmonicByRatio #1/2 e,\6
\harmonicByRatio #1/3 a,\5
\harmonicByRatio #2/3 d,\4 |
\harmonicByRatio #1/4 { g8\3 b\2 e'\1 b\2 g b e 2 } |
e,1 | % check whether tab note head is restored
\harmonicByFret #12 e'4\1
\ottava #1
\harmonicByFret #7 e'4\1
\harmonicByFret #5 e'4\1
\ottava #2
\harmonicByFret #4 b\2 e'\1 4 |
\harmonicByFret #3 g\3 b\2 e'\1 4
\harmonicByFret #2.7 g\3 b\2 e'\1 4
\harmonicByFret #2.3 g\3 b\2 e'\1 4
\harmonicByFret #2 g\3 b\2 e'\1 4 |
\ottava #0
e,1 | % check whether tab note head is restored
}
reltest = \relative c {
b'8\2 [ e\1 ] % verify pitch for open strings
\harmonicByFret #12 b\2 [
\harmonicByFret #12 e\1 ]
\harmonicByFret #7 b\2 [
\harmonicByFret #7 e\1 ]
\harmonicByFret #5 b\2 [
\harmonicByFret #5 e\1 ]
}
\paper {
ragged-right = ##f
}
\score {
\new Staff {
\new Voice {
\clef treble_8
\override Voice.StringNumber #'transparent = ##t
\test
\break
\reltest
}
}
\new TabStaff {
\new TabVoice {
\test
\break
\reltest
}
}
}
At first glance it appears to be adding an octave to the current base
pitch each time a harmonic is created.
-steve
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
On 11/24/10 8:22 AM, Steve Yegge steve.ye...@gmail.com wrote: On Wed, Nov 24, 2010 at 7:00 AM, Carl Sorensen c_soren...@byu.edu wrote: On 11/24/10 7:51 AM, Steve Yegge steve.ye...@gmail.com wrote: After reading Marc's responses I think I see where I may have sewn some confusion. I have conventional string numbers in the non-tab staff, since my audience is partly classical guitarists who cannot (or do not) read tab. So the information I'm providing is redundant -- it's for two separate audiences. At some point I'll be looking into compiling them separately, but for now I show both staffs on each page. So I can't just turn off string numbers as a workaround for this issue. I'm looking into this issue. The patch may be relatively simple to implement. I'm currently thinking of a context property defaultStrings that would specify the strings to be used in calculating a tab when no string information is given for a particular note or chord. This sounds very nice. I'm also using a fingering of 0 to be an open string. I'm thinking that the fingering of 0 should not show up as a fingering anywhere. If that is not correct, where should a fingering of 0 be displayed? As far as I know, the number 0 is used by convention in both guitar and violin music to indicate an open string. It's in the same font and positioned using the same rules as fingers 1 through 4 -- at least it is in the music I've looked at recently. Ah -- so it is. I haven't had any 0 fingerings in the music I've been playing recently, so I'd forgotten that. Maybe I'm misunderstanding your question, though? No, you exactly understood my question. Thanks for the answer. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
Am 24.11.2010 17:16, schrieb Steve Yegge: Sigh... please disregard this. It works fine. I just had the wrong expectations. I assumed incorrectly that for purposes of relative pitch calculation, the harmonics would be ignored, allowing you to focus on the base string pitches. It has to be properly documented, but at the moment I am very busy, but I hope I'll get this stuff into a better shape soon. It requires a bit more arithmetic this way, but it's logical enough. Thanks for the patch -- you've fixed the biggest problem in my 150-page pile of arrangements! You're welcome! Regards, Marc ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TabStaff feature requests
Am 24.11.2010 15:59, schrieb Steve Yegge:
Hi Marc,
On Tue, Nov 23, 2010 at 11:28 PM, Marc Hohl m...@hohlart.de
mailto:m...@hohlart.de wrote:
Just for clarification: as the guitar is notated one octave above
its sounding pitch,
I use the following template:
\score {
\new StaffGroup
\new Staff {
\new Voice { \global \clef treble_8
\override Voice.StringNumber #'transparent = ##t
\music }
}
\new TabStaff {
\new TabVoice { \global \clef moderntab \music }
}
}
The octavated treble clef just does the right thing, and with the
override, you
remove the unneccesary string numbers.
Thanks; I'll try it. How do I turn off the little 8 symbol by the clef?
Why do you want to remove it? This is the standard way of guitar notation.
But if you *really* want to get rid of it, an
\override OctavateEight #'stencil = ##f
should do the job (untested).
[...]
Oh, I didn't mean to suggest that there is such an algorithm, although
it seems like it would make a cool research project. I was just using
this example to illustrate the need for the tab-understands-(-0)
workaround.
Ah, I see. I was in fact thinking about such an algoritm long time ago,
but I got stuck very quickly.
[...]
That makes sense. It's a really good heuristic, actually -- I've been
rather amazed at how often simply setting the minimum fret results in
generating optimal fingerings for a passage, even for relatively complex
music.
Yes, lilypond does a very decent job already in this case.
Regards,
Marc
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
How to create a coda with a gap?
Hi,
I want to produce a special Coda which does not reside on a new line but is
separated by a gap. You can find the original in the attached file
examplecoda.jpg.
I already tried for a long time but the result isn´t exactly what I want.
Below you can find a minimal example code which I used to create the attached
file codalilypond.jpg.
Maybe there is an easy command for creating such a coda gap, but I couldn´t
find it.
There are still some problems:
1. The second clef is smaller than the first one.
2. The second time signature has a natural symbol in it which should not be
there.
3. The segno sign is for too high.
4. The first volta bracket doesn´t have an end line.
Can you please help me with that?
Thanks
Dominic
LILYPOND CODE:
\version 2.12.3
voltaI = \markup { \text \fontsize #2 \sans 1.+2. }
voltaII = \markup { \text \fontsize #2 \sans letzt }
\score {
\new ChordNames \chordmode { es1. c2:sus4 r1 es f g }
\new Staff
\relative c'' {
\key g \major
\time 4/4
\set Score.repeatCommands = #(list(list 'volta voltaI) 'end-repeat)
g8 a g g~ g2~ | g r |
\set Score.repeatCommands = #'((volta #f))
\bar ||
\once \override Score.RehearsalMark #'font-size = #-2
\mark \markup { \musicglyph #scripts.segno }
\key f \major
\stopStaff
s1
\set Score.repeatCommands = #(list(list 'volta voltaII))
\startStaff
\key g \major
\clef treble
\bar
g8 a g g~ g2~ | g1~ | g^\fermata |
\set Score.repeatCommands = #'((volta #f))
\bar |.
}
}
attachment: codalilypond.jpgattachment: examplecoda.jpg___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to create a coda with a gap?
On Wed, 24 Nov 2010 21:17:46 +0100, Dominic Neumann
m...@dominicneumann.de wrote:
Hi,
I want to produce a special Coda which does not reside on a new line but
is separated by a gap. You can find the original in the attached file
examplecoda.jpg.
I already tried for a long time but the result isn´t exactly what I want.
Below you can find a minimal example code which I used to create the
attached file codalilypond.jpg.
Maybe there is an easy command for creating such a coda gap, but I
couldn´t find it.
you could just attach the segno to the skip instead to the barline:
[...]
\stopStaff
s1^\markup { \musicglyph #scripts.segno }
[...]
There are still some problems:
1. The second clef is smaller than the first one.
use:
\override Staff.Clef #'full-size-change = ##t
before your \clef
2. The second time signature has a natural symbol in it which should not
be there.
see:
http://lilypond.org/doc/v2.12/input/lsr/lilypond-snippets/Pitches#Preventing-natural-signs-from-being-printed-when-the-key-signature-changes
3. The segno sign is for too high.
does the above solution for the segno placement help? you can use also
#'extra-offset to finetune the position
4. The first volta bracket doesn´t have an end line.
can't figure that out ATM...
Can you please help me with that?
Thanks
Dominic
HTH
greetings,
Vicente
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to create a coda with a gap?
Hi.
3. The segno sign is for too high.
Maybe the attached file helps somewhat for this item.
4. The first volta bracket doesn´t have an end line.
I noticed that using
\bar |.
prints the vertical end line, while
\bar ||
does not.
Best,
Gilles
\version 2.12.0
\paper {
ragged-last = ##f
}
\score {
\new Staff {
\time 4/4
\relative c''' {
\repeat volta 1 {
s1*0 |
} \alternative {
{ g,8 a g g~ g2~ |
g2 r |
\bar || }
}
\stopStaff
\override Score.RehearsalMark #'break-visibility =
#begin-of-line-invisible
\once \override Score.RehearsalMark #'self-alignment-X = #LEFT
\mark \markup {\musicglyph #scripts.segno}
s1 |
\repeat volta 1 {
s1*0 |
\bar
} \alternative {
{ \revert Score.VoltaBracket #'stencil
\override Staff.Clef #'full-size-change = ##t
\startStaff
\clef G
g8 a g g~ g2~ |
g1~ |
g1\fermata |
\bar |. }
}
}
}
\layout {}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
