Feature request: 'line' articulation

[Michael Käppler]

Hi all,
after transcribing some baroque vocal and instrumental pieces I noticed 
that one articulation sign is used very often, but not provided by 
lilypond. It looks simply like a line, vertically placed above the note 
head. One could confuse it with the \staccatissimo symbol, which looks 
more than a small wedge. At this moment I achieve this with a simple 
markup: c^"|" but the line is too long. It would be far more elegant to 
have it in the font. (I know that adding new font items is a complicated 
task - but I think I could help with it)
The symbol's meaning can vary - mostly I found it above notes which 
shall have some "extra weight". The figure I attached is very common.
Unfortunately I don't have a scanner at this time, so I can't provide 
original images now. But if you're interested in implementing this, I 
could see where I can get images.


Cheers,
Michael
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Feature request: 'line' articulation

[Valentin Villenave]

2009/7/23 Michael Käppler :
> after transcribing some baroque vocal and instrumental pieces I noticed that
> one articulation sign is used very often, but not provided by lilypond. It
> looks simply like a line, vertically placed above the note head.

Greetings,
here is how to achieve what you're looking for (it has been added to
the documentation snippets as well, since this notation is indeed
common):
http://lsr.dsi.unimi.it/LSR/Item?id=620

Regards,
Valentin


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

Re: [PATCH] Markup commands \left-brace and \right-brace

[Valentin Villenave]

2009/7/15 Neil Puttock :
> A new patch set is available here:
>
> http://codereview.appspot.com/8874/show

Hi Neil,
do you want me to open a "Started" page in the tracker to keep track
of this patch?

Regards,
Valentin


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

Broken build on my system

[Carl Sorensen]

Somehow I've broken the build on my system.  It used to work, but now it
fails when it tries to build the lexer.

I've used git to go back to known-good source trees, e.g.

git checkout 062046e74d6995b99bb7669e4cd6490ba8b18656

which I have built before.

But now, 

make clean
make

exits with the following:

flex -Cfe -p -p -oout/lexer.cc lexer.ll
lexer.ll:595: multiple <> rules for start condition longcomment
lexer.ll:621: warning, rule cannot be matched
lexer.ll:624: warning, rule cannot be matched
lexer.ll:693: warning, -s option given but default rule can be matched
rm -f ./out/lexer.dep; DEPENDENCIES_OUTPUT="./out/lexer.dep ./out/lexer.o"
g++ -c -Woverloaded-virtual
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX
-I/usr/include/ffi -DENABLE_DTRACE  -DHAVE_CONFIG_H  -DNDEBUG -I./include
-I./out -I../flower/include -I../flower/./out -I../flower/include  -O2
-finline-functions -g -pipe -I/opt/local/include -I/opt/local/include
-D_THREAD_SAFE  -I/opt/local/include/freetype2 -I/opt/local/include
-I/opt/local/include/pango-1.0 -I/opt/local/include/freetype2
-I/opt/local/include -I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include   -Wno-pmf-conversions  -W -Wall
-Wconversion -o out/lexer.o out/lexer.cc
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
C/ObjC but not for C++
out/lexer.cc:384: error: no 'int yyFlexLexer::yywrap()' member function
declared in class 'yyFlexLexer'
make[1]: *** [out/lexer.o] Error 1
make: *** [all] Error 2


Any thoughts?

Thanks,

Carl



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

Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.

[demery]

On Wed, Jul 22, 2009, David Kastrup  said:

>  writes:
> 
>> On Wed, Jul 22, 2009, Trevor Daniels  said:

> There are instrument-dependent "thresholds of pain" involved: singers'
> clefs will just not change in midpiece.  ...

actually, speaking as a singer with decades experience, they do change for
male voices in both historical and choral editions.  Altos, tenors, and
baritones have to be experienced reading in three clefs, tho changes are
avoided, they are found at times.

> But today's available clef choice is much smaller.  

Only when you exclude scholarly editions; those involved in early music
must walk both sides of the fence.

But when commercial interests enter the picture, yes, challenging the
reading ability of the targeted customer is a nono.

Thankfully we are talking an option, good to have options.  I like the
concept of a list of clefs, and a set of penalties for different
situations suggesting a switch.

-- 
Dana Emery




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

Re: Feature request: 'line' articulation

[Mark Polesky]

Valentin Villenave wrote:

> Greetings,
> here is how to achieve what you're looking for (it has been added to
> the documentation snippets as well, since this notation is indeed
> common):
> http://lsr.dsi.unimi.it/LSR/Item?id=620

Wow,

an hour and a half from request to snippet. Nice work. I also notice
that you're silently adding old ideas from the mailing list into the
LSR. I even noticed one of my own...

http://lists.gnu.org/archive/html/lilypond-devel/2008-09/msg00100.html
http://lsr.dsi.unimi.it/LSR/Item?id=553

Thanks for being so helpful!
- Mark






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

visualizing grob ancestry

[Mark Polesky]

Does a grob-type always have the same set of parent-types?

For example, does an Accidental grob always have X-parent
AccidentalPlacement and Y-parent NoteHead? If so, could this
information be incororated into the IR? It took me a while
before I was able to figure this sort of thing out:

System__
   ||  |   ||
   ||  |   ||
   ||  NonMusicalPaperColumn|
   ||   \  \|
   ||\  VerticalAlignment
\\\ /
 PaperColumn   VerticalAxisGroup
/   \ //
   / X/
  / / \  /
 / /   NoteColumn
 \//\
AccidentalPlacement   |  |
  \\/
   \NoteHead
\  /
 Accidental


And that's the ancestry for just one grob!

I assume that a comprehensive visual "parent-web" demonstrating
all such relationships would be too convoluted to have any
practical value, and too difficult to generate to even justify
trying such a thing (although I've seen some impressive examples,
like http://www.visualthesaurus.com/). But, I imagine it should be
(at the very least) possible to have something like this near the
top of each node within IR 3.1 All layout objects:

   X and Y parents: AccidentalPlacement and NoteHead.

But I don't know if the parents can change in different contexts.
If not, then does anyone have an idea how this could be generated?

Thanks.
- Mark


  


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

Re: Broken build on my system -- SOLVED -- MAC OSX problem

[Carl Sorensen]

Carl Sorensen  byu.edu> writes:

> 
> Somehow I've broken the build on my system.  It used to work, but 
> now it
> fails when it tries to build the lexer.
> 


It turns out that somehow my config.make got rebuilt.  When that 
happened, the FLEXLEXER_FILE variable went back to 
/usr/include/FlexLexer.h instead of the OSX
darwin-specific /opt/local/include/FlexLexer.h.

Once I restored that line in config.make (as indicated in Nicolas
Sceaux's excellent instructions available at



or 

http://tinyurl.com/LilyPondMacBuild

the build proceeded normally.

Just wanted to get it out there for the record.

Carl

P.S. Of course, I tried make distclean first, so now I have to rebuild all
the font files!  I guess I've got an overnight job going now





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

Re: visualizing grob ancestry

[Patrick McCarty]

Hi Mark,

On Thu, Jul 23, 2009 at 02:11:47PM -0700, Mark Polesky wrote:
> 
> Does a grob-type always have the same set of parent-types?

No, I don't think so. [see below]

> For example, does an Accidental grob always have X-parent
> AccidentalPlacement and Y-parent NoteHead?

Yes, this appears to be true.

> If so, could this
> information be incororated into the IR? It took me a while
> before I was able to figure this sort of thing out:
> 
> System__
>||  |   ||
>||  |   ||
>||  NonMusicalPaperColumn|
>||   \  \|
>||\  VerticalAlignment
> \\\ /
>  PaperColumn   VerticalAxisGroup
> /   \ //
>/ X/
>   / / \  /
>  / /   NoteColumn
>  \//\
> AccidentalPlacement   |  |
>   \\/
>\NoteHead
> \  /
>  Accidental
> 
> 
> And that's the ancestry for just one grob!

This is *very* cool.  Thanks for posting it.

> I assume that a comprehensive visual "parent-web" demonstrating
> all such relationships would be too convoluted to have any
> practical value, and too difficult to generate to even justify
> trying such a thing (although I've seen some impressive examples,
> like http://www.visualthesaurus.com/). But, I imagine it should be
> (at the very least) possible to have something like this near the
> top of each node within IR 3.1 All layout objects:
> 
>X and Y parents: AccidentalPlacement and NoteHead.
> 
> But I don't know if the parents can change in different contexts.

Depending on the situation, grobs may change parents.

For example, consider Script_interface::calc_positioning_done.

This function first checks to see if the grob (me) has an X parent.
If so, then the grob may change parents if the other two conditional
tests pass.

Instead of documenting this in the IR, maybe it would be better to
write a section in the CG about how to find a grob's parent, the
parent's parent, etc. with GDB?  Plus, I can't think of a good way of
automatically documenting the parents (or the different possibilities
for parents) of grobs.

-Patrick


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

pushing to git question

[Mark Polesky]

Since I'm relatively new to the whole pushing to git thing, I've
been intentionally stepping cautiously, running every little patch
by you guys, so as not to break anything. I've attached a totally
trivial patch, and I'm wondering if you guys would rather I just
apply small things like this without asking.

One wrinkle is that compiling and testing things with "make doc"
is (at the moment) out of the question on the computer that I
currently have access to. Which means that I can't definitively
prove that my patches don't break anything, even though in some
cases (like fixing typos) there shouldn't be a problem.

Hopefully this will change soon, but for the moment I'm erring on
the side of caution.

Let me know if you guys would rather have me skip the proofreading
step for trivial patches, but until I hear otherwise, I'll
continue to run them through -devel.

- Mark


  

0001-Docs-IR-3.2.37-Update-grob-interface-docstring.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: visualizing grob ancestry

[Mark Polesky]

Patrick McCarty wrote:
> Depending on the situation, grobs may change parents.

Darn.

> Instead of documenting this in the IR, maybe it would be better
> to write a section in the CG about how to find a grob's parent,
> the parent's parent, etc. with GDB?

I know nothing about GDB...

> Plus, I can't think of a good way of automatically documenting
> the parents (or the different possibilities for parents) of
> grobs.

What about the children? (:

- Mark


  


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

Re: pushing to git question

[Patrick McCarty]

On Thu, Jul 23, 2009 at 07:16:24PM -0700, Mark Polesky wrote:
> Since I'm relatively new to the whole pushing to git thing, I've
> been intentionally stepping cautiously, running every little patch
> by you guys, so as not to break anything. I've attached a totally
> trivial patch, and I'm wondering if you guys would rather I just
> apply small things like this without asking.
> 
> One wrinkle is that compiling and testing things with "make doc"
> is (at the moment) out of the question on the computer that I
> currently have access to. Which means that I can't definitively
> prove that my patches don't break anything, even though in some
> cases (like fixing typos) there shouldn't be a problem.
> 
> Hopefully this will change soon, but for the moment I'm erring on
> the side of caution.
> 
> Let me know if you guys would rather have me skip the proofreading
> step for trivial patches, but until I hear otherwise, I'll
> continue to run them through -devel.

I think you're fine applying patches like this directly.

The most common mistake for these types of patches that will break
"make doc" is accidentally using mismatched braces, i.e.
@code{ly:grob-set-property!) instead of @code{ly:grob-set-property!}.
Whitespace issues won't break the compile, and they'll typically be
corrected eventually.

But your patch looks fine.

-Patrick


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

Please remove docs tags from snippets

[Carl Sorensen]

Dear LSR editors (Neil or Valentin, IIRC),

Please remove the docs tags from the following snippets:

Specifying context with beatGrouping

Using beatLength and beatGrouping

They will be obsolete for 2.13.4 and cause problems in making documentation.

This shows a very interesting problem.  We only have *one* LSR, which is
supposed to handle both the stable and the devel docs.  But when we change
syntax in devel, and it won't work any more, then we can't leave the docs
tag on, which, IIRC, will break makelsr.py for the stable release.  This is
not a problem, unless there is going to be an additional release of the
stable version.

Hmm -- I don't know how to fix this, but I know that I can't have those two
snippets in the docs anymore for 2.13.4.

Thanks,

Carl



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

Re: visualizing grob ancestry

[Patrick McCarty]

On Thu, Jul 23, 2009 at 07:21:54PM -0700, Mark Polesky wrote:
> 
> Patrick McCarty wrote:
> > Instead of documenting this in the IR, maybe it would be better
> > to write a section in the CG about how to find a grob's parent,
> > the parent's parent, etc. with GDB?
> 
> I know nothing about GDB...

It makes life easier.  ;-)

> > Plus, I can't think of a good way of automatically documenting
> > the parents (or the different possibilities for parents) of
> > grobs.
> 
> What about the children? (:

It seems like the "elements" internal grob property often stores the
children of grobs.  So if you see 

  extract_grob_set (me, "elements", elts);

in the C++ code, the grobs in "elements" might be the children of
"me".  I say *might* because I'm not positive this is always the case.

-Patrick


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

Re: Please remove docs tags from snippets

[Graham Percival]

On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
> Please remove the docs tags from the following snippets:
> 
>   Specifying context with beatGrouping
> 
>   Using beatLength and beatGrouping

See below.

> They will be obsolete for 2.13.4 and cause problems in making documentation.
> 
> This shows a very interesting problem.  We only have *one* LSR, which is
> supposed to handle both the stable and the devel docs.  But when we change
> syntax in devel, and it won't work any more, then we can't leave the docs
> tag on, which, IIRC, will break makelsr.py for the stable release.  This is
> not a problem, unless there is going to be an additional release of the
> stable version.

This is precisely why input/new/ was invented!

Copy those snippets (the two files from input/lsr/) into
input/new/.  Then either:
1) modify the input/new/ files to use the new syntax  (assuming it
isn't handled automatically by convert-ly)
2) modify the input/new/ file to say:
  \markup{ this snippet has been deprecated and will be removed in 2.14}
and delete the rest of the file.  (other than the header)


This should evidently be added to CG x.snippets, and linked to
remove CG x.programming.

Cheers,
- Graham


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

Re: Please remove docs tags from snippets

[Carl Sorensen]

On 7/23/09 9:47 PM, "Graham Percival"  wrote:

> On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
>> Please remove the docs tags from the following snippets:
>> 
>>   Specifying context with beatGrouping
>> 
>>   Using beatLength and beatGrouping
> 
> See below.
> 
>> They will be obsolete for 2.13.4 and cause problems in making documentation.
>> 
>> This shows a very interesting problem.  We only have *one* LSR, which is
>> supposed to handle both the stable and the devel docs.  But when we change
>> syntax in devel, and it won't work any more, then we can't leave the docs
>> tag on, which, IIRC, will break makelsr.py for the stable release.  This is
>> not a problem, unless there is going to be an additional release of the
>> stable version.
> 
> This is precisely why input/new/ was invented!
> 
> Copy those snippets (the two files from input/lsr/) into
> input/new/.  Then either:
> 1) modify the input/new/ files to use the new syntax  (assuming it
> isn't handled automatically by convert-ly)
> 2) modify the input/new/ file to say:
>   \markup{ this snippet has been deprecated and will be removed in 2.14}
> and delete the rest of the file.  (other than the header)

Thanks, Graham.  I didn't know about option 2).  I knew how to change a
snippet, but not how to delete it.

> 
> 
> This should evidently be added to CG x.snippets, and linked to
> remove CG x.programming.

I'll try to get this done.

Carl




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

Re: visualizing grob ancestry

[Werner LEMBERG]

> Instead of documenting this in the IR, maybe it would be better to
> write a section in the CG about how to find a grob's parent, the
> parent's parent, etc. with GDB?

Hmm.  Any chance to have this in Scheme?


Werner


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

Re: visualizing grob ancestry

[Mark Polesky]

Werner LEMBERG wrote:
> > Instead of documenting this in the IR, maybe it would be better to
> > write a section in the CG about how to find a grob's parent, the
> > parent's parent, etc. with GDB?
>
> Hmm.  Any chance to have this in Scheme?

Werner,
Here's one way of doing it (from within a music block).
- Mark

_

\version "2.13.2"

#(define (grob-name grob)
  (if (ly:grob? grob)
  (assoc-ref (ly:grob-property grob 'meta) 'name)
  #f))

#(define (get-ancestry grob)
(if (not (null? (ly:grob-parent grob X)))
(list (grob-name grob)
  (get-ancestry (ly:grob-parent grob X))
  (get-ancestry (ly:grob-parent grob Y)))
(grob-name grob)))

#(define (format-ancestry lst generation)
  (string-append
(symbol->string (car lst))
"\n"
(make-string (* generation 3) #\space)
"X: "
(if (list? (cadr lst))
(format-ancestry (cadr lst) (1+ generation))
(symbol->string (cadr lst)))
"\n"
(make-string (* generation 3) #\space)
"Y: "
(if (list? (caddr lst))
(format-ancestry (caddr lst) (1+ generation))
(symbol->string (caddr lst)))
"\n"))

#(define (display-ancestry grob)
  (display
(string-append
  (make-string 36 #\-)
  "\n"
  (format-ancestry (get-ancestry grob) 0

\relative {
  \once \override NoteHead #'before-line-breaking = #display-ancestry
  f
  %\once \override Accidental #'before-line-breaking = #display-ancestry
  %\once \override Arpeggio #'before-line-breaking = #display-ancestry
  \arpeggio
}


  


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

Re: Please remove docs tags from snippets

[Graham Percival]

On Thu, Jul 23, 2009 at 10:15:09PM -0600, Carl Sorensen wrote:
> 
> On 7/23/09 9:47 PM, "Graham Percival"  wrote:
> 
> > 2) modify the input/new/ file to say:
> >   \markup{ this snippet has been deprecated and will be removed in 2.14}
> > and delete the rest of the file.  (other than the header)
> 
> Thanks, Graham.  I didn't know about option 2).  I knew how to change a
> snippet, but not how to delete it.

I have to admit that I invented option 2)  half an hour ago.  :)

But I think it's a nice solution.  It's quick&easy, doesn't
require more infrastructure (LSR has been a huge time sink in this
respect!), and even fits into the general rule proposed by #1
(i.e., if a syntax change results in the snippets not compiling,
copy the offending snippet to input/new/ and change it in some
way).

Cheers,
- Graham


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

Re: Please remove docs tags from snippets

[Valentin Villenave]

2009/7/24 Graham Percival :
> On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
>> Please remove the docs tags from the following snippets:
>>
>>   Specifying context with beatGrouping
>>
>>   Using beatLength and beatGrouping

> Copy those snippets (the two files from input/lsr/) into
> input/new/.  Then either:

In the meantime, I have removed the "docs" tag and added the
"version-specific" tag instead.
(one day or another, I'll go through all version-specific snippets and
remove the ones that are no longer relevant)

Regards,
Valentin


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