multiple input files

[lunar7]

Hello everyone,

I am prototyping a lilypond MIDI input tool in Max/MSP (to be later
implemented in C++) and am interested in how I might go about using seperate
input files that could be linked together at render-time to produce a single
pdf.

I noticed on Mutopia years ago a file that was able to do that, a Bach
keyboard work, I'm trying to find it again but that may take some time.

What I'd like to do is have seperate "header" and "body" files. The reason
for this is that for the "body" file, I'd like to be able to have the
program insert automatic carriage returns at what would be the end of each
complete measure, thus other features would be able to count on each measure
being on a certain line (I'm guessing the first line would be the open
bracket and clef, so each measure would be offset by one line).

Ideally I could have a global "header" file and two "body" files, one for
the right hand and one for the left hand. As that implies, this would be
entirely geared towards piano works.

Does anyone know how I might make a template along these lines?
Thanks
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

TabStaff feature requests

[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 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:

   
   

I've found it's most convenient to append the actual strings after
every chord, hence:

\5\3 \5\3 \5\3 \5\3
\5\3 \5\3 \5\3 \5\3

This is pretty verbose, and only gets worse with more notes:

4.\6\5\4\3
8\6\5\4\3
4.\6\5\4\3
8\6\5\4\3
4.\5\4\3\2
8\5\4\3\2
4.\5\4\3\2
8\5\4\3\2

Of course with aliases for setting the TabStaff minimumFret you
can make full chords less verbose, but there seems to be no good
way around specifying strings for octave runs.

2) Have the automatic tab calculator understand the -0 fingering.
Currently if you do something like this:

\relative c' {
  \set TabStaff.minimumFret = #2
  
}

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 to a
passage that is otherwise all in position 2.

Moreover the calculator gets confused by open chords in higher
positions, e.g.

\relative c {
  
}

It picks correct strings for all the notes except the open b, which
is ignored (and for which a warning is issued).  You can fix it
by specifying the remaining strings:

16\4\3\2\1

But it seems like having the tab calculator understand open string
fingerings would solve nicely a number of situations like this.

3) Being able to specify the frets for harmonics.  I know there's been
some talk about this, but it's a pretty big deal as there's no workaround.
Anyone planning on publishing in the next few months (e.g., me :)
is going to be out of luck.

Cheers,

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

Re: Lyric tie

[Francisco Vila]

2010/11/22 Federico Bruni :
> Il giorno lun, 22/11/2010 alle 22.46 +0100, Francisco Vila ha scritto:
>> > \addlyrics {
>> >  \override LyricText #'font-name = #"DejaVuLGC"
>> >  Buon gior -- no~al mon -- do.
>> > }
>> >
>>
>> Thank you, that works, but I like the default font for the lyrics and
>> I'd prefer to change only that of the lyric tie if necessary.
>
> What about using the undertie directly in your (utf-8) source file?
>
> Buon gior -- no‿al mon -- do.
>
> Does it look better?

Unfortunately not, see image.  I think this produces the same output
as the usual '~'.  Do you know a way of figuring out which font does a
glyph of the PDF belong to?

-- 
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

[Marc Hohl]

Am 23.11.2010 08:37, schrieb Steve Yegge:

Hi all,

Hi Steve,


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:

   
   

[...]

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.


2) Have the automatic tab calculator understand the -0 fingering.
Currently if you do something like this:

+1


3) Being able to specify the frets for harmonics.  I know there's been
some talk about this, but it's a pretty big deal as there's no workaround.
Anyone planning on publishing in the next few months (e.g., me :)
is going to be out of luck.

I wrote such a extension, which is still in some beta state, so it would 
be great if you
give it a try and tell me whether it works well in real-life situations. 
You can get it here:


http://lilypond-s-support-for-tablatures.3383434.n2.nabble.com/harmonics-in-tablature-tp5518526p5578089.html

By the way, there is a mailing list especially for tablature concerns:

http://lists.lilynet.net/tablatures

Regards,

Marc



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

Re: Lyric tie

[jakob lund]

Hi

you can change the font for a single character in \markup:

\addlyrics {
  Buon gior --
  \markup\concat{no \override #'(font-name . "DejaVu Sans Bold"){‿} al}
  mon -- do.
}

(I tested with "DejaVu Sans Bold" because I'm not sure if the other
one exists on my computer)


Jakob.




2010/11/23 Francisco Vila :
> 2010/11/22 Federico Bruni :
>> Il giorno lun, 22/11/2010 alle 22.46 +0100, Francisco Vila ha scritto:
>>> > \addlyrics {
>>> >  \override LyricText #'font-name = #"DejaVuLGC"
>>> >  Buon gior -- no~al mon -- do.
>>> > }
>>> >
>>>
>>> Thank you, that works, but I like the default font for the lyrics and
>>> I'd prefer to change only that of the lyric tie if necessary.
>>
>> What about using the undertie directly in your (utf-8) source file?
>>
>> Buon gior -- no‿al mon -- do.
>>
>> Does it look better?
>
> Unfortunately not, see image.  I think this produces the same output
> as the usual '~'.  Do you know a way of figuring out which font does a
> glyph of the PDF belong to?
>
> --
> 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
>
>

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

Re: Lyric tie

[Werner LEMBERG]

> 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.

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.

> 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.

> \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"

It might be worth to extend the `~' feature so that a font can be
specified for this particular glyph, something like

  \override LyricText #'lyric-tie-font = #"..."

given that so many popular fonts are missing it...


Werner

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

Re: TabStaff feature requests

[Patrick Schmidt]

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 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:

   
   

I've found it's most convenient to append the actual strings after
every chord, hence:

\5\3 \5\3 \5\3 \5\3
\5\3 \5\3 \5\3 \5\3

This is pretty verbose, and only gets worse with more notes:

4.\6\5\4\3
8\6\5\4\3
4.\6\5\4\3
8\6\5\4\3
4.\5\4\3\2
8\5\4\3\2
4.\5\4\3\2
8\5\4\3\2

Of course with aliases for setting the TabStaff minimumFret you
can make full chords less verbose, but there seems to be no good
way around specifying strings for octave runs.

2) Have the automatic tab calculator understand the -0 fingering.
Currently if you do something like this:

\relative c' {
  \set TabStaff.minimumFret = #2
  
}

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 to a
passage that is otherwise all in position 2.

Moreover the calculator gets confused by open chords in higher
positions, e.g.

\relative c {
  
}

It picks correct strings for all the notes except the open b, which
is ignored (and for which a warning is issued).  You can fix it
by specifying the remaining strings:

16\4\3\2\1

But it seems like having the tab calculator understand open string
fingerings would solve nicely a number of situations like this.
I am working on a solution that will answer quite a few of your  
requests. You will be able to choose a certain chord shape for the  
chords you enter. You won't have to specify strings with string  
number indications or minimum frets. e.g. for ascending/descending  
octaves you will just have to enter:


\aShape
   

or

\eShape
   

With \aShape you will get chords with the root on the 5th string.  
With \eShape you will get chords/octaves with the root on the 6th  
string. I have already defined powerchords, quite a few of the four  
basic triads and some of the ten seventh chords including their  
inversions. I can add octaves and I might add open chords in higher  
positions later but it's going to take a while...




3) Being able to specify the frets for harmonics.  I know there's been
some talk about this, but it's a pretty big deal as there's no  
workaround.

Anyone planning on publishing in the next few months (e.g., me :)
is going to be out of luck.

see Marc Hohl's patch.

Cheers,

patrick


Cheers,

-steve
___
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: multiple input files

[James Bailey]

I think section 5.1.5, on style sheets in the learning manual for version 2.12 
might have tips on how to do what you're trying to do.
On Nov 23, 2010, at 7:59 AM, lunar7 wrote:

> Hello everyone,
> 
> I am prototyping a lilypond MIDI input tool in Max/MSP (to be later 
> implemented in C++) and am interested in how I might go about using seperate 
> input files that could be linked together at render-time to produce a single 
> pdf.
> 
> I noticed on Mutopia years ago a file that was able to do that, a Bach 
> keyboard work, I'm trying to find it again but that may take some time.
> 
> What I'd like to do is have seperate "header" and "body" files. The reason 
> for this is that for the "body" file, I'd like to be able to have the program 
> insert automatic carriage returns at what would be the end of each complete 
> measure, thus other features would be able to count on each measure being on 
> a certain line (I'm guessing the first line would be the open bracket and 
> clef, so each measure would be offset by one line). 
> 
> Ideally I could have a global "header" file and two "body" files, one for the 
> right hand and one for the left hand. As that implies, this would be entirely 
> geared towards piano works.
> 
> Does anyone know how I might make a template along these lines?
> Thanks
> 
> ___
> 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: Lyric tie

[Werner LEMBERG]

> you can change the font for a single character in \markup:
> 
> \addlyrics {
>   Buon gior --
>   \markup\concat{no \override #'(font-name . "DejaVu Sans Bold"){$(Q+X(B} 
> al}
>   mon -- do.
> }
> 
> (I tested with "DejaVu Sans Bold" because I'm not sure if the other
> one exists on my computer)

Indeed, the `DejaVu Sans' family contains uni203F, while it is lacking
in `DejaVu Serif'.  This is bd.  IMHO, all fonts from such a
package should contain the same glyph repertoire.


Werner

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

Text fonts

[Henrik Frisk]

Hi all,

I'm using a font all the time in LaTeX (Adobe's Frutiger) that I
select in my LaTeX documents with

\renewcommand{\rmdefault}{pfr}

Can I make this font selectable in Lilypond, and if so, how would I do
it? It doesn't show up in when I run:

$ lilypond -dshow-available-fonts x

I have to admit I know very little about fonts so please excuse me if
this is covered by the manual or is plain impossible. I'm running
Fedora13.

Thanks for any help,

/Henrik

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

Re: Text fonts

[Werner LEMBERG]

> I'm using a font all the time in LaTeX (Adobe's Frutiger) that I
> select in my LaTeX documents with
> 
> \renewcommand{\rmdefault}{pfr}
> 
> Can I make this font selectable in Lilypond, and if so, how would I do
> it?

You must put your fonts (PFB, TTF, OTF, etc.) into a directory
searched by FontConfig.  On a GNU/Linux box like yours, this would be,
for example, ~/.fonts.


Werner

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

Re: TabStaff feature requests

[Bernardo Barros]

May I append my feature request here?
I would support this fix if anyone would be interested in fixing it!
There is a bug in tablature when you choose a quarter tone scordatura,
the pitches are not always represented correctly.

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

Re: Lyric tie

[Francisco Vila]

2010/11/23 Werner LEMBERG :

> It might be worth to extend the `~' feature so that a font can be
> specified for this particular glyph, something like
>
>  \override LyricText #'lyric-tie-font = #"..."
>
> given that so many popular fonts are missing it...

Let's open an issue for this!
http://lists.gnu.org/archive/html/lilypond-user/2010-11/msg00494.html

-- 
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: What setup for a Pedagogy Book? - Lyx

[Henry Flurry]

I can't find the OS X binary for the new 2.0 Beta 1, whose feature set with 
lilypond interests me.  Is this integration being discussed using the 1.6.8 
version?

Thanks!
Henry


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

Re: TabStaff feature requests

[Carl Sorensen]

On 11/23/10 12:37 AM, "Steve Yegge"  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:
> 
>
>
> 
> I've found it's most convenient to append the actual strings after
> every chord, hence:
> 
> \5\3 \5\3 \5\3 \5\3
> \5\3 \5\3 \5\3 \5\3

Why not


Why do you want to put the string numbers *after* the chords, even when
you're putting finger numbers inside the chords?

> 
> 2) Have the automatic tab calculator understand the -0 fingering.
> Currently if you do something like this:
> 
> \relative c' {
>   \set TabStaff.minimumFret = #2
>   
> }

I would not be in favor of this -- all other fingerings except 0 indicate a
finger number, but zero indicates a fret number.  I think it's much better
to have you write:



This will get you just what you want.

> 
> 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 to a
> passage that is otherwise all in position 2.
> 
> Moreover the calculator gets confused by open chords in higher
> positions, e.g.
> 
> \relative c {
>   
> }
> 
> It picks correct strings for all the notes except the open b, which
> is ignored (and for which a warning is issued).  You can fix it
> by specifying the remaining strings:
> 
> 16\4\3\2\1

I think it will work correctly if you just specify the string for the note
you want open:

16

HTH,

Carl


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

Re: Can lilypond do incipits?

[Margarethe Maierhofer-Lischka]

Hello there,

concerning incipits: at the moment I use an workaround-solution for this
that is also based on an adapted version of the snippet in the snippet
repo. I made up an "incipit template" file which contains the incipit´s
global settings and defines the contents of the single incipit lines
(instrument, ancient clef, pitch, text etc). This file I include into my
music file (both attached). Then it is enough to call \incipit and
\fooInstrumentIncipit in my music file in the \score block to generate
the incipit for the voice you want it to have. The width of the incipit
bar is controlled by the incipit-width parameter in the \layout block.
This workaround at least helps to keep the actual score file more simple
and separates the incipit content from the rest. Of course, it is no
perfect solution, but normally it works with some tweaking.
Concerning incipits in general:
> That being said, I'm sure it would be nice to have this music-function
> distributed within LilyPond, I do, however, wonder if it is
> standardized enough. (Neil just rejected a patch of my mine, and
> rightly so, because it used a stencil override and therefore could not
> be tweaked by the user.)
>   
Yes, incipits ARE a standard requirement for modern critical and
source-based editions! If lilypond offered an convenient way to create
incipits and use common editorial markings (such as are dotted or
bracketed slurs, bracketed or small-printed accidentals, footnotes or
comments...), this would hopefully encourage more professional editions
and musicologists to use lilypond.
In the documentation there are some things TBC in the section "working
with ancient music", not only concerning incipits but also editorial
markings. It would be great to have some more information there, at
least some hint or workaround. Is there any group out there that is
maybe working on this?
Greetings,
Margarethe

%Incipit allgemeines

incipit =
#(define-music-function (parser location incipit-music) (ly:music?)
  #{
\once \override Staff.InstrumentName #'self-alignment-X = #RIGHT
\once \override Staff.InstrumentName #'self-alignment-Y = #UP
\once \override Staff.InstrumentName #'Y-offset = #4
\once \override Staff.InstrumentName #'padding = #0.1
\once \override Staff.InstrumentName #'stencil =
#(lambda (grob)
   (let* ((instrument-name (ly:grob-property grob 'long-text))
  (layout (ly:output-def-clone (ly:grob-layout grob)))
  (music (make-music 'SequentialMusic
  'elements (list (make-music 'ContextSpeccedMusic
'context-type 'Staff
'element (make-music 'PropertySet
   'symbol 'instrumentName
   'value instrument-name))
  $incipit-music)))
  (score (ly:make-score music))
  (mm (ly:output-def-lookup layout 'mm))
  (indent (ly:output-def-lookup layout 'indent))
  (width (ly:output-def-lookup layout 'incipit-width))
  (incipit-width (if (number? width)
 (* width mm)
 (* indent 0.5
 (ly:output-def-set-variable! layout 'indent (- indent incipit-width))
 (ly:output-def-set-variable! layout 'line-width indent)
 (ly:output-def-set-variable! layout 'ragged-right #f)
 (ly:output-def-set-variable! layout 'ragged-last #f)
 (ly:output-def-set-variable! layout 'system-count 1)
 (ly:score-add-output-def! score layout)
 (ly:grob-set-property! grob 'long-text
   (markup #:score score))
 (ly:system-start-text::print grob)))
  #})

%Incipits of single voices
%CHOIR


sopranoIncipit = <<
  \new Voice = "sopranoIncipit" <<
\repeat unfold 1 { s8 \noBreak }
{
  \clef soprano
  %\key f \major
  %\time 2/2
  
}
   >> 
  >>
  
  altoIncipit = <<
  \new Voice = "altoIncipit" <<
\repeat unfold 1 { c2 \noBreak }
{
  \clef alto
  %\key f \major
  %\time
  
}
  >>
  \new Lyrics \lyricsto altoIncipit { IV- }
>>

tenoreIncipit = <<
  \new Voice = "tenoreIncipit" <<
\repeat unfold 1 { c8 \noBreak }
{
  \clef tenor
  %\key f \major
  %\time 2/2
  
}
  >>
\new Lyrics \lyricsto tenoreIncipit { IV- }
>>

bassoIncipit = <<
  \new Voice = "bassoIncipit" <<
\repeat unfold 1 { d8 \noBreak }
{
  \clef bass
  %\key 
  %\time
  %% incipit
 
}
  >>
  \new Lyrics \lyricsto bassoIncipit { IV- }
>>

%INCIPITS ORCHESTER

violinoprimoIncipit = 
  \new Voice = "violinoprimoIncipit" <<
\repeat unfold 1 { s8 \noBreak }
{
  \clef soprano
  %\key f \major
  %\time 2/2
  
}
   >>
 
 violinosecondoIncipit = 
  \new Voice = "violinosecondoIncipit" <<
\repeat unfold 1 { s8 \noBreak }
{
  

Re: multiple input files

[lunar7]

Of course, it's "\include"! It must have been awhile to have forgotten that.

Thanks

On Tue, Nov 23, 2010 at 1:13 AM, James Bailey
wrote:

> I think section 5.1.5, on style sheets in the learning manual for version
> 2.12 might have tips on how to do what you're trying to do.
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Remove empty staves from PianoStaff

[Neil Puttock]

On 22 November 2010 12:37, TaoCG  wrote:

> And since the slashes are Rests they get removed as well.
> Is there a simple trick to keep specific measures with rests alive?

You can create a slash directly, instead of hacking a Rest stencil:

slash =
#(define-music-function (parser location note) (ly:music?)
   "Make a beat slash with the same duration as note."
   (make-music 'PercentEvent
   'length (ly:music-length note)))

% Macro to print single slash
rs = {
  \slash s4
}

% Function to print a specified number of slashes
comp = #(define-music-function (parser location count) (integer?)
  #{
\repeat unfold $count { \slash s4 }
  #})

Cheers,
Neil

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

Re: Can lilypond do incipits?

[Trevor Daniels]

Margarethe Maierhofer-Lischka wrote Tuesday, November 23, 2010 9:28 
PM


In the documentation there are some things TBC in the section 
"working
with ancient music", not only concerning incipits but also 
editorial
markings. It would be great to have some more information there, 
at
least some hint or workaround. Is there any group out there that 
is

maybe working on this?


Unfortunately not, at least AFAIK.  But we would always
welcome any submitted text to replace the TBCs, or indeed
improvements to any section of Ancient notation.  There
are a number of people who could format straight text
submitted by others for the documentation, but none at
present with spare time and sufficient expertise in
ancient music to originate specialist documentation for
this section.

Trevor



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

Re: TabStaff feature requests

[Steve Yegge]

On Tue, Nov 23, 2010 at 10:16 AM, Carl Sorensen  wrote:

> On 11/23/10 12:37 AM, "Steve Yegge"  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:
> >
> >
> >
> >
> > I've found it's most convenient to append the actual strings after
> > every chord, hence:
> >
> > \5\3 \5\3 \5\3 \5\3
> > \5\3 \5\3 \5\3 \5\3
>
> Why not
> 
>
> 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 {
  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:

  1

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:

  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:

  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
> >   
> > }
>
> 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:
>
> 
>
> 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 to a
> > passage that is otherwise all in position 2.
> >
> > Moreover the calculator gets confused by open chords in higher
> > positions, e.g.
> >
> > \relative c {
> >   
> > }
> >
> > It picks correct strings for all the notes except the open b, which
> > is ignored (and for which a warning is issued).  You can fix it
> > by specifying the remaining strings:
> >
> > 16\4\3\2\1
>
> I think it will work correctly if you just specify the string for the note
> you want open:
>
> 16
>
> HTH,
>
>
I'm afraid there is more going on here than meets the eye, so your
proposal doesn't address the problem.  Thanks for considering it,
though.  It helped me think about the problem more clearly.

-steve


> Carl
>
>
___
lilypond-user mailing list
lil

Re: TabStaff feature requests

[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:

   
   

Your patch for using chord shapes may not cover this whole passage
because they change shape!  The fingerings would be, for example:

   
   

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.)

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.

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:

...

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.

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, so I think having a more general mechanism would also be
very useful.

Thanks,

-steve

On Tue, Nov 23, 2010 at 1:09 AM, Patrick Schmidt  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 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:
>>
>>
>>
>>
>> I've found it's most convenient to append the actual strings after
>> every chord, hence:
>>
>> \5\3 \5\3 \5\3 \5\3
>> \5\3 \5\3 \5\3 \5\3
>>
>> This is pretty verbose, and only gets worse with more notes:
>>
>> 4.\6\5\4\3
>> 8\6\5\4\3
>> 4.\6\5\4\3
>> 8\6\5\4\3
>> 4.\5\4\3\2
>> 8\5\4\3\2
>> 4.\5\4\3\2
>> 8\5\4\3\2
>>
>> Of course with aliases for setting the TabStaff minimumFret you
>> can make full chords less verbose, but there seems to be no good
>> way around specifying strings for octave runs.
>>
>> 2) Have the automatic tab calculator understand the -0 fingering.
>> Currently if you do something like this:
>>
>> \relative c' {
>>  \set TabStaff.minimumFret = #2
>>  
>> }
>>
>> 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 to a
>> passage that is otherwise all in position 2.
>>
>> Moreover the calculator gets confused by open chords in higher
>> positions, e.g.
>>
>> \relative c {
>>  
>> }
>>
>> It picks correct strings for all the notes except the open b, which
>> is ignored (and for which a warning is issued).  You can fix it
>> by specifying the remaining strings:
>>
>> 16\4\3\2\1
>>
>> But it seems like having the tab calculator understand open string
>> fingerings would solve nicely a number of situations like this.
>>
> I am working on a solution that will answer quite a few of your

Re: TabStaff feature requests

[Steve Yegge]

On Tue, Nov 23, 2010 at 12:39 AM, Marc Hohl  wrote:

> Am 23.11.2010 08:37, schrieb Steve Yegge:
>
>> Hi all,
>>
> Hi Steve,
>
>>
>> 1) Setting fixed strings to use for ascending/descending chords.
>> Currently it's nontrivial to specify tab positions for something like:
>>
>>
>>
>>
>> [...]
>>
> 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?
>

Yes!  I think this is a great idea.  I've talked about it a bit in my reply
to
Patrick.  But it occurred to me after sending that arranging single- and
double-string hammering -- which accounts for about 90% of the metal
music of the 1980s -- would be a nightmare without this feature.  There
ought to be a way to express the notation for Van Halen's Eruption
succinctly in Lilypond, and I think you've hit on it.


> Sounds interesting, but I don't know how to implement it.
>
>
Me neither.  When I finish my current music project I'm hoping to dive
into LilyPond internals and figure out how to add features.


>
>>
>> 3) Being able to specify the frets for harmonics.  I know there's been
>> some talk about this, but it's a pretty big deal as there's no workaround.
>> Anyone planning on publishing in the next few months (e.g., me :)
>> is going to be out of luck.
>>
>>  I wrote such a extension, which is still in some beta state, so it would
> be great if you
> give it a try and tell me whether it works well in real-life situations.
> You can get it here:
>
>
> http://lilypond-s-support-for-tablatures.3383434.n2.nabble.com/harmonics-in-tablature-tp5518526p5578089.html
>
>
I will try it!


> By the way, there is a mailing list especially for tablature concerns:
>
> http://lists.lilynet.net/tablatures
>
>
Thanks,

-steve


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

Re: TabStaff feature requests

[Marc Hohl]

Am 24.11.2010 06:25, schrieb Steve Yegge:

[...]

\include "english.ly "
music = \relative c {
1
}

\score {
<<
\new Staff {
  \music
}
\new TabStaff {
  \transpose c c, { \music }
}
>>
}
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.




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:

1

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.


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  would show up as
e---
b---
g---
D-5-
A-5-
E---

 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.


As mentioned above, the simple override solves at least this problem.

Regards,

Marc


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