Re: Improve implementation of dashed slurs
> An example of a useful dashed bezier-sandwich arpeggio would be when > indicating arpeggios presumed to have been accidentally omitted from > a manuscript, within an urtext edition. I don't think so. The proper way would be rather to use an arpeggio typeset with a smaller design size. IMHO a dashed arpeggio looks horrible. The more curves the object itself has, the uglier. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
On 4/17/09 1:47 PM, "joenee...@gmail.com" wrote: > Very pretty slurs! Thanks! > > > http://codereview.appspot.com/41099/diff/1021/59 > File lily/bezier.cc (right): > > http://codereview.appspot.com/41099/diff/1021/59#newcode275 > Line 275: Bezier::subdivide (Real t, Bezier &left_part, Bezier > &right_part) > We only use references if they are const (for clarity), so please change > the arguments to pointers. Also, this function can be marked as const. So, if I understand right, you want Bezier::subdivide (Real t, Bezier *left_part, Bezier *right_part) const and then in the code, instead of left_part.control_[i]= I do *left_part.control_[i]= Is this right? But when I try this, I get compile errors. Can you give me a summary of how this works properly with classes? The syntax I used previously is what I have used in the past. > > http://codereview.appspot.com/41099/diff/1021/59#newcode296 > Line 296: Bezier::extract (Real t_min, Real t_max) > const here too OK > > http://codereview.appspot.com/41099/diff/1021/59#newcode302 > Line 302: bez2.control_[i] = control_[i]; > bez2 = *this OK > > http://codereview.appspot.com/41099/diff/1021/62 > File lily/lookup.cc (right): > > http://codereview.appspot.com/41099/diff/1021/62#newcode347 > Line 347: SCM dash_details) > Since dash_details seems to just be a list of Reals, perhaps its better > to have a vector const& (with an empty vector to signify a solid > slur). No, dash_details is a list of lists of floating point numbers. There is one list for each segment of the slur; there can be as many segments as the user desires. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: adding snippets manually
On 4/17/09 9:16 PM, "Graham Percival" wrote: > On Fri, Apr 17, 2009 at 05:38:22PM -0600, Carl D. Sorensen wrote: >> >> In order to build my docs, I copied the file from input/new to input/lsr. >> >> I thought that the doc build process would get files from input/new if they >> didn't exist in input/lsr. >> >> Can you summarize the process for me? If I want to add a new snippet to >> the docs, how should I do it? > > With my trademarked "me-ness", the process is that you read the > bloody CG 5. > http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Fixing-snippe > ts-in-LilyPond-sources.html > http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/LSR-to-Git.ht > ml Perfect answer -- that's much better than rewriting it for me in an email! > > That said, I must admit that CG 5 doesn't go into details of how > to manually deal with input/new to input/lsr. The format changes > slightly. It's dealt with the python script, but I did it by hand > a few times for small fixes. The CG recommends using makelsr.py. But I thought than only Neil was authorized to use makelsr.py. So can I use makelsr.py on my machine, but not add the new lsr files to git? That doesn't sound particularly good to me. > > I can't remember exactly what it was, but I think it was a matter > of changing the "tags" line. Of course, stuff might have changed > since then (it was a year ago). Also, I'm not certain that we > *want* to encourage people to do this by hand. > > I'm also not certain that we want to encourage people to do the > lsr-to-git change. > > > What about stating that new features get an input/regression/ > test, but further snippets wait until the lsr-to-git person looks > at it? No wait, that's silly. > > Hmm... I think the best solution would be to allow input/lsr/ > snippets to be exact copies if input/regression/ stuff. If it > *is* an exact copy (i.e. misses the tags and whatnot), then the > build system should put it in an "other" section, which > lsr-handling people would deal with later. This way, it still > gets in the docs, but programmers don't need to deal with the > snippet suckage. What I did this time around (and I didn't like it well at all) was just put a copy in input/new, and copied it to input/lsr. That gave me a copy of the title and the texidoc in the snippet, which is *not* nice. But I think we need to have some way to get new snippets in the docs pretty quickly. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
adding snippets manually
On Fri, Apr 17, 2009 at 05:38:22PM -0600, Carl D. Sorensen wrote: > > In order to build my docs, I copied the file from input/new to input/lsr. > > I thought that the doc build process would get files from input/new if they > didn't exist in input/lsr. > > Can you summarize the process for me? If I want to add a new snippet to > the docs, how should I do it? With my trademarked "me-ness", the process is that you read the bloody CG 5. http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Fixing-snippets-in-LilyPond-sources.html http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/LSR-to-Git.html That said, I must admit that CG 5 doesn't go into details of how to manually deal with input/new to input/lsr. The format changes slightly. It's dealt with the python script, but I did it by hand a few times for small fixes. I can't remember exactly what it was, but I think it was a matter of changing the "tags" line. Of course, stuff might have changed since then (it was a year ago). Also, I'm not certain that we *want* to encourage people to do this by hand. I'm also not certain that we want to encourage people to do the lsr-to-git change. What about stating that new features get an input/regression/ test, but further snippets wait until the lsr-to-git person looks at it? No wait, that's silly. Hmm... I think the best solution would be to allow input/lsr/ snippets to be exact copies if input/regression/ stuff. If it *is* an exact copy (i.e. misses the tags and whatnot), then the build system should put it in an "other" section, which lsr-handling people would deal with later. This way, it still gets in the docs, but programmers don't need to deal with the snippet suckage. I might think about this more later. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
Carl D. Sorensen wrote: > On 4/17/09 1:34 PM, "n.putt...@gmail.com" wrote: > > http://codereview.appspot.com/41099/diff/1021/58 > > File lily/arpeggio.cc (right): > > > > http://codereview.appspot.com/41099/diff/1021/58#newcode168 > > Line 168: Stencil mol (Lookup::slur (curve, lt, lt, SCM_UNDEFINED)); > > add dash ability too? > > I thought about that. If we add it, I think it's the only arpeggio > indicator that can be dashed. I'm willing to add it if it's deemed > necessary, but it seemed to me that it would be best to leave it alone right > now. An example of a useful dashed bezier-sandwich arpeggio would be when indicating arpeggios presumed to have been accidentally omitted from a manuscript, within an urtext edition. I think it would even be preferable to the alternative of enclosing a solid bezier-sandwich arpeggio within a bracket or (ha ha) parentheses. I could easily see someone eventually asking for it. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
On 4/17/09 1:34 PM, "n.putt...@gmail.com" wrote:
Thanks for the review, Neil.
>
>
> http://codereview.appspot.com/41099/diff/1021/52
> File Documentation/user/expressive.itely (right):
>
> http://codereview.appspot.com/41099/diff/1021/52#newcode634
> Line 634: @lilypondfile[verbatim,lilyquote,texidoc,doctitle]
> @ignore this unless you're going to run makelsr.py (or create input/lsr
> file by hand)
In order to build my docs, I copied the file from input/new to input/lsr.
I thought that the doc build process would get files from input/new if they
didn't exist in input/lsr.
Can you summarize the process for me? If I want to add a new snippet to
the docs, how should I do it?
>
> http://codereview.appspot.com/41099/diff/1021/54
> File input/new/making-slurs-with-complex-dash-structure.ly (right):
>
> http://codereview.appspot.com/41099/diff/1021/54#newcode3
> Line 3: \header{
> space
Fixed, thanks.
>
> http://codereview.appspot.com/41099/diff/1021/54#newcode4
> Line 4: texidoc = "
> needs snippet directory tag otherwise makelsr.py will fail
>
> lsrtags = "rhythms, expressive"
Fixed, thanks. I wasn't sure what tags to use.
>
> http://codereview.appspot.com/41099/diff/1021/58
> File lily/arpeggio.cc (right):
>
> http://codereview.appspot.com/41099/diff/1021/58#newcode168
> Line 168: Stencil mol (Lookup::slur (curve, lt, lt, SCM_UNDEFINED));
> add dash ability too?
I thought about that. If we add it, I think it's the only arpeggio
indicator that can be dashed. I'm willing to add it if it's deemed
necessary, but it seemed to me that it would be best to leave it alone right
now.
>
> http://codereview.appspot.com/41099/diff/1021/59
> File lily/bezier.cc (right):
>
> http://codereview.appspot.com/41099/diff/1021/59#newcode277
> Line 277: Offset p[CONTROL_COUNT][CONTROL_COUNT];
> Offset is described in offset.hh as 2d vector, so should use a vector of
> Offsets
I read offset.hh as a one-d vector (in computer science terms), with two
elements; element [X_AXIS] and element[Y_AXIS], so it represents a point in
two-dimensional space (hence the 2-d vector).
I want a matrix of offsets here. The first index is the control point
number. The second index is the equation order (3 for the bezier, 2 for the
first interpolation, 1 for the second interpolation, and 0 for the third
interpolation). This usage is correct.
>
> http://codereview.appspot.com/41099/diff/1021/59#newcode296
> Line 296: Bezier::extract (Real t_min, Real t_max)
> ensure t_min and t_max stay within bounds?
>
> negative values and >1 produce outlandish curves
>
OK, so I think I need some help here. I'm perfectly willing to check the
bounds and give a warning message if the normal bounds aren't met. But I'm
not sure how to do that. Can you give me a pointer to how to do it, a place
in the code to look for an example, and/or an expression to grep?
> http://codereview.appspot.com/41099/diff/1021/59#newcode305
> Line 305: {
> no {}
>
> http://codereview.appspot.com/41099/diff/1021/59#newcode309
> Line 309: {
> no {}
Fixed, along with line 299.
>
> http://codereview.appspot.com/41099/diff/1021/62
> File lily/lookup.cc (right):
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode346
> Line 346: Lookup::slur (Bezier curve, Real curvethick, Real linethick,
> is passing SCM allowed in lookup.cc?
Why would it not be? lookup.hh has a prototype for slur:
static Stencil slur (Bezier controls, Real cthick, Real thick,
SCM dash_definition);
Is there a problem with this as a prototype?
The code works. Is it a time bomb waiting to explode on me?
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode351
> Line 351: /* calculate the offset for the two beziers that make the
> sandwich
> tidy comments
Is this right?
/*
calculate the offset for the two beziers that make the sandwich
for the slur
*/
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode363
> Line 363: if ((dash_details == SCM_UNDEFINED) || (dash_details ==
> SCM_EOL))
> !scm_is_pair ()
much better, thanks!
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode364
> Line 364: { /* solid slur */
> new line
Fixed
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode368
> Line 368: { /* dashed or combination slur */
> new line
Fixed.
>
> http://codereview.appspot.com/41099/diff/1021/62#newcode370
> Line 370: for (int i=0; i i < num_segments
>
> should print warning if segments overlap, or just silently ignore?
>
I thought about it, and decided to allow segments to overlap. I'm not
sure if that was just because I'm lazy, or if I really thought there might
be some use for overlapping segments.
I do think there is use for non-adjacent segments. So I decided to just let
the user be in charge of it. I don't think it will break the code, although
it may lead to some weird results.
> http://codereview.appspot.com/41099/diff/1021/62#newcode382
> Line 382: {
> no {}
Fixed.
>
Re: PATCH -- Dashed Slurs
On 4/17/09 1:58 PM, "Neil Puttock" wrote: > 2009/4/17 Carl D. Sorensen : > >> Does anybody *want* constant-thickness slurs or ties? I thought that >> variable thickness was clearly better. I think that keeping inferior output >> to avoid conversion problems is not a good decision. I'd rather force the >> user to make a simple manual change and get the benefit of the improved >> layout. It better presents the quality of LilyPond. If we allow inferior >> layout to hang around, it will be something that people can use to impugn >> LilyPond. > > I prefer variable thickness myself (so long as I remember to avoid > evince ;), but there's bound to be some user down the line who'll want > the option of constant thickness only to be told it's impossible. Ahh -- but it's not impossible. There is a slur offset parameter that can be changed (I don't think it's a user parameter yet, and I don't think I want to make it one right now. If it gets asked for we can fix it then. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix key signatures with accidentals in specific octave.
On 2009/04/17 19:25:31, joeneeman wrote: http://codereview.appspot.com/11052/diff/3409/2410 File scm/music-functions.scm (right): http://codereview.appspot.com/11052/diff/3409/2410#newcode1047 Line 1047: ((and (equal? ignore-octave #f) I think eq? is more appropriate here Done. http://codereview.appspot.com/11052/diff/3409/2410#newcode1048 Line 1048: (and use (and a b c) instead of (and a (and b c)) Done. http://codereview.appspot.com/11052/diff/3409/2410#newcode1073 Line 1073: (if (and (not (= (sign this-alt) 0)) Surely (= (sign x) 0) is the same as (= x 0) Of course! I should have thought a bit more about it rather than trying to duplicate the C++ code exactly. http://codereview.appspot.com/11052/diff/3409/2410#newcode1075 Line 1075: (< (sign (* prev-alt this-alt)) 0))) Surely (< (sign x) 0) is the same as (< x 0) Yes. :) http://codereview.appspot.com/11052 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
2009/4/17 Carl D. Sorensen : > Does anybody *want* constant-thickness slurs or ties? I thought that > variable thickness was clearly better. I think that keeping inferior output > to avoid conversion problems is not a good decision. I'd rather force the > user to make a simple manual change and get the benefit of the improved > layout. It better presents the quality of LilyPond. If we allow inferior > layout to hang around, it will be something that people can use to impugn > LilyPond. I prefer variable thickness myself (so long as I remember to avoid evince ;), but there's bound to be some user down the line who'll want the option of constant thickness only to be told it's impossible. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
Very pretty slurs! http://codereview.appspot.com/41099/diff/1021/59 File lily/bezier.cc (right): http://codereview.appspot.com/41099/diff/1021/59#newcode275 Line 275: Bezier::subdivide (Real t, Bezier &left_part, Bezier &right_part) We only use references if they are const (for clarity), so please change the arguments to pointers. Also, this function can be marked as const. http://codereview.appspot.com/41099/diff/1021/59#newcode296 Line 296: Bezier::extract (Real t_min, Real t_max) const here too http://codereview.appspot.com/41099/diff/1021/59#newcode302 Line 302: bez2.control_[i] = control_[i]; bez2 = *this http://codereview.appspot.com/41099/diff/1021/62 File lily/lookup.cc (right): http://codereview.appspot.com/41099/diff/1021/62#newcode347 Line 347: SCM dash_details) Since dash_details seems to just be a list of Reals, perhaps its better to have a vector const& (with an empty vector to signify a solid slur). http://codereview.appspot.com/41099 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Improve implementation of dashed slurs
http://codereview.appspot.com/41099/diff/1021/52
File Documentation/user/expressive.itely (right):
http://codereview.appspot.com/41099/diff/1021/52#newcode634
Line 634: @lilypondfile[verbatim,lilyquote,texidoc,doctitle]
@ignore this unless you're going to run makelsr.py (or create input/lsr
file by hand)
http://codereview.appspot.com/41099/diff/1021/54
File input/new/making-slurs-with-complex-dash-structure.ly (right):
http://codereview.appspot.com/41099/diff/1021/54#newcode3
Line 3: \header{
space
http://codereview.appspot.com/41099/diff/1021/54#newcode4
Line 4: texidoc = "
needs snippet directory tag otherwise makelsr.py will fail
lsrtags = "rhythms, expressive"
http://codereview.appspot.com/41099/diff/1021/58
File lily/arpeggio.cc (right):
http://codereview.appspot.com/41099/diff/1021/58#newcode168
Line 168: Stencil mol (Lookup::slur (curve, lt, lt, SCM_UNDEFINED));
add dash ability too?
http://codereview.appspot.com/41099/diff/1021/59
File lily/bezier.cc (right):
http://codereview.appspot.com/41099/diff/1021/59#newcode277
Line 277: Offset p[CONTROL_COUNT][CONTROL_COUNT];
Offset is described in offset.hh as 2d vector, so should use a vector of
Offsets
http://codereview.appspot.com/41099/diff/1021/59#newcode296
Line 296: Bezier::extract (Real t_min, Real t_max)
ensure t_min and t_max stay within bounds?
negative values and >1 produce outlandish curves
http://codereview.appspot.com/41099/diff/1021/59#newcode305
Line 305: {
no {}
http://codereview.appspot.com/41099/diff/1021/59#newcode309
Line 309: {
no {}
http://codereview.appspot.com/41099/diff/1021/62
File lily/lookup.cc (right):
http://codereview.appspot.com/41099/diff/1021/62#newcode346
Line 346: Lookup::slur (Bezier curve, Real curvethick, Real linethick,
is passing SCM allowed in lookup.cc?
http://codereview.appspot.com/41099/diff/1021/62#newcode351
Line 351: /* calculate the offset for the two beziers that make the
sandwich
tidy comments
http://codereview.appspot.com/41099/diff/1021/62#newcode363
Line 363: if ((dash_details == SCM_UNDEFINED) || (dash_details ==
SCM_EOL))
!scm_is_pair ()
http://codereview.appspot.com/41099/diff/1021/62#newcode364
Line 364: { /* solid slur */
new line
http://codereview.appspot.com/41099/diff/1021/62#newcode368
Line 368: { /* dashed or combination slur */
new line
http://codereview.appspot.com/41099/diff/1021/62#newcode370
Line 370: for (int i=0; ihttp://codereview.appspot.com/41099/diff/1021/62#newcode382
Line 382: {
no {}
http://codereview.appspot.com/41099/diff/1021/62#newcode408
Line 408: }/* end for num_segments */
don't need these comments
http://codereview.appspot.com/41099/diff/1021/66
File ly/property-init.ly (right):
http://codereview.appspot.com/41099/diff/1021/66#newcode13
Line 13: #(define (make-simple-dash-definition dash-fraction
dash-period)
this doesn't belong here
http://codereview.appspot.com/41099/diff/1021/66#newcode19
Line 19: slurDashPattern =
these should go in music-functions-init.ly
http://codereview.appspot.com/41099/diff/1021/67
File python/convertrules.py (right):
http://codereview.appspot.com/41099/diff/1021/67#newcode2903
Line 2903: if (re.search(r'\'dash-fraction', str) or
re.search(r'\'dash-period', str):
limit search to Slur/Tie/PhrasingSlur otherwise users will get this
message for other grobs
http://codereview.appspot.com/41099/diff/1021/68
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/41099/diff/1021/68#newcode174
Line 174: (dash-definition ,pair? "List of @code{dash-elements} defining
the
list?
http://codereview.appspot.com/41099
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix key signatures with accidentals in specific octave.
http://codereview.appspot.com/11052/diff/3409/2410 File scm/music-functions.scm (right): http://codereview.appspot.com/11052/diff/3409/2410#newcode1047 Line 1047: ((and (equal? ignore-octave #f) I think eq? is more appropriate here http://codereview.appspot.com/11052/diff/3409/2410#newcode1048 Line 1048: (and use (and a b c) instead of (and a (and b c)) http://codereview.appspot.com/11052/diff/3409/2410#newcode1073 Line 1073: (if (and (not (= (sign this-alt) 0)) Surely (= (sign x) 0) is the same as (= x 0) http://codereview.appspot.com/11052/diff/3409/2410#newcode1075 Line 1075: (< (sign (* prev-alt this-alt)) 0))) Surely (< (sign x) 0) is the same as (< x 0) http://codereview.appspot.com/11052 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
On 4/17/09 1:05 PM, "Neil Puttock" wrote: > Carl, these are brilliant; they look wonderful. Thanks for the compliment. > > I'm just looking through the patch at the moment, so I'll post > comments (mainly trivial things) at Rietveld. I can't really comment > on the implementation itself, since the only thing I know about bezier > sandwiches is that they produce nice slurs and ties in LilyPond. :) Great. I'll look forward to seeing your comments. This is my first big patch that involves the C++ side of LilyPond. I started to implement it in Scheme, and then realized that it would be way better to add the methods to the Bezier class in C++. So I did it, and got it to work, but I have *no* idea what kinds of standards or best practices I may have broken. > > The main thing I'm concerned about is the situation with the current > style. I've only tested the patch briefly, but it seems you can't > revert to constant-thickness curves. Could we not keep 'dash-fraction > and 'dash-period for users who don't want variable thickness? This > would obviate the need for a convert rule: any user wanting fancy > slurs or ties would set 'dash-definition, which would override 'dash-* > settings. Does anybody *want* constant-thickness slurs or ties? I thought that variable thickness was clearly better. I think that keeping inferior output to avoid conversion problems is not a good decision. I'd rather force the user to make a simple manual change and get the benefit of the improved layout. It better presents the quality of LilyPond. If we allow inferior layout to hang around, it will be something that people can use to impugn LilyPond. Of course, if there is a reason that users *want* constant-thickness slurs or ties, I could resurrect Lookup::dashed-slur as fixed-thickness-slur. And we could define a property \useFixedThicknessDashedSlurs that would allow the old interface to apply. But I think that's a lot of messiness for something I don't think anybody wants. Also, I think that there will be few (if any) users who will need to make this syntax change. The default way of getting dashed slurs and dotted slurs continues to work as it did before, with no change in the input syntax required. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
2009/4/17 Carl Sorensen : > Carl D. Sorensen byu.edu> writes: > >> >> Please review my patch for dashed slurs on rietveld: >> >> http://codereview.appspot.com/40122/show >> > > I've revised my patch to eliminate some debug garbage that was > left in the files, and to make the bezier subdivide routine work for > any degree of bezier curves (if the degree should shift from 3). I also > fixed some inconsistencies in tie support, and cleaned up the > documentation. > > I also added new commands \*DashPattern that will take > dash-fraction and dash-period and set slurs, phrasingSlurs, and ties > to have a consistent user-defined dash pattern. Carl, these are brilliant; they look wonderful. I'm just looking through the patch at the moment, so I'll post comments (mainly trivial things) at Rietveld. I can't really comment on the implementation itself, since the only thing I know about bezier sandwiches is that they produce nice slurs and ties in LilyPond. :) The main thing I'm concerned about is the situation with the current style. I've only tested the patch briefly, but it seems you can't revert to constant-thickness curves. Could we not keep 'dash-fraction and 'dash-period for users who don't want variable thickness? This would obviate the need for a convert rule: any user wanting fancy slurs or ties would set 'dash-definition, which would override 'dash-* settings. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lyrics for right-left writing systems such as hebrew or arabic
Dumb question, some (perverse?) writing systems are contrary to western music notation, assuming we allow full unicode lyrics, how does one set hebrew or arabic lyrics to western music? Only way I can think of is to (have the user) transliterate phonetically into the roman alphabet, as in - hava nagila, hava nagila... I realize this presents certain cultural issues, but what is a music typesetting program to do? I suppose it could be rewritten to set the music right-left, but that could be a bit challenging to the members of the band... -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 17. April 2009 schrieb Frédéric Bron: > > Attached is a sample file to show how the definition of spanners could > > work with my patch. I've also implemented two functions to give the text > > of the spanner directly in the postfix call. > > When I look at your dynamic_spanners_postfix.pdf file, it seems to me > that on the second line (with the functions that take the text as an > argument), the cresc starts on the following note, not on the previous > note. Am I wrong? Hmm, no you are right. It seems that when using a music-function, the scheme expression is: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0 (make-music 'CrescendoEvent 'crescendoText "blah.." 'crescendoSpanner 'text 'span-direction -1))) i.e. the CrescendoEvent is outside the EventChord, while with a simple definition like crxxx=#(make-music 'CrescendoEvent ...), it is inside the EventChord: (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'duration (ly:make-duration 2 0 1 1) 'pitch (ly:make-pitch 0 0 0)) (make-music 'CrescendoEvent 'crescendoText "cresc." 'crescendoSpanner 'text 'span-direction -1))) Does anyone have an idea how to create a function so that the return value is inserted into the note event? Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ6LYzTqjEwhXvPN0RAiHGAKCKE0zsPIvVcpzOPHdx0emX83UhgACeMgMQ RxOPUOWzVG0zSvtYIIVplWc= =/O8j -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
On Fri, Apr 17, 2009 at 10:57:57AM +0200, Jan Nieuwenhuizen wrote: > Op vrijdag 17-04-2009 om 00:29 uur [tijdzone -0700], schreef Patrick > McCarty: > > Hi Patrick, > > > I just tried doing a fresh build with > > > > $ bin/gub tools::bison && bin/gub tools::flex && bin/gub > > mingw::lilypond-installer > > > > and I get two configure errors for linux-x86::cross/binutils. I'm > > just attaching the one for configure-binutils; configure-gas also > > failed with the same error message. > > Hmm, you seem to be getting the weirdest of errors. I cannot reproduce > this. What kind of system are you running? I am running 64-bit Arch Linux, and I can also reproduce on 32-bit Arch Linux (on a 32-bit machine). I have a feeling that it is a distro problem, but I don't know where to begin looking. Since Arch Linux typically pushes the latest software releases (mostly unpatched), I could try selectively downgrading some of them. Any ideas? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (de)cresendi syntax
> Attached is a sample file to show how the definition of spanners could work > with my patch. I've also implemented two functions to give the text of the > spanner directly in the postfix call. When I look at your dynamic_spanners_postfix.pdf file, it seems to me that on the second line (with the functions that take the text as an argument), the cresc starts on the following note, not on the previous note. Am I wrong? Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
Carl D. Sorensen byu.edu> writes: > > Please review my patch for dashed slurs on rietveld: > > http://codereview.appspot.com/40122/show > I've revised my patch to eliminate some debug garbage that was left in the files, and to make the bezier subdivide routine work for any degree of bezier curves (if the degree should shift from 3). I also fixed some inconsistencies in tie support, and cleaned up the documentation. I also added new commands \*DashPattern that will take dash-fraction and dash-period and set slurs, phrasingSlurs, and ties to have a consistent user-defined dash pattern. In posting it on rietveld, I made some mistakes. Please review patch set 4 of http://codereview.appspot.com/41099/show Thanks, Carl > > > Attachment (DashedSlurs.png): application/octet-stream, 13 KiB > > ___ > lilypond-devel mailing list > lilypond-devel gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
>> Very nice! What do you think about making `dash-definition' either >> accept a list of four parameters or a list of lists (with four >> parameters each)? Then we could write >> >> #'(a b c d) >> >> and are not forced to use >> >> #'((a b c d)) >> >> if the slur is not split into different segments. > > If the slur is not split into different segments, a will be 0 and b > will be 1. So this proposal is still more complex than necessary. Indeed. So it could accept either two numbers or a list of quartuple lists. > What about just defining a function > > \setSlurDash dash-fraction dash-period > > that would create the appropriate entry for dash-definition? We > would also have \setPhrasingSlurDash. This is fine with me. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
On 4/16/09 10:50 PM, "Werner LEMBERG" wrote: >> Please review my patch for dashed slurs on rietveld: > > Very nice! What do you think about making `dash-definition' either > accept a list of four parameters or a list of lists (with four > parameters each)? Then we could write > > #'(a b c d) > > and are not forced to use > > #'((a b c d)) > > if the slur is not split into different segments. If the slur is not split into different segments, a will be 0 and b will be 1. So this proposal is still more complex than necessary. What about just defining a function \setSlurDash dash-fraction dash-period that would create the appropriate entry for dash-definition? We would also have \setPhrasingSlurDash. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op vrijdag 17-04-2009 om 00:29 uur [tijdzone -0700], schreef Patrick McCarty: Hi Patrick, > I just tried doing a fresh build with > > $ bin/gub tools::bison && bin/gub tools::flex && bin/gub > mingw::lilypond-installer > > and I get two configure errors for linux-x86::cross/binutils. I'm > just attaching the one for configure-binutils; configure-gas also > failed with the same error message. Hmm, you seem to be getting the weirdest of errors. I cannot reproduce this. What kind of system are you running? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Hi Jan, On Thu, Apr 16, 2009 at 01:43:07PM +0200, Jan Nieuwenhuizen wrote: > Op donderdag 16-04-2009 om 13:10 uur [tijdzone +0200], schreef Jan > Nieuwenhuizen: > > >* it should -C change directory to target/installer/..., > > I see no reason for . to exist, be writable, much less > > to be open()ed > >* "my" tools/root/usr/bin/tar does not seem to do this, > > so librestrict does not kick in. > > > > We should try to figure out why "your" tar reads CWD, ie, git/gub/. > > What does > >target/tools/root/usr/bin/tar --help > > say? You are not perchance using busybox's tar command? This is attached. I have GNU tar 1.22 installed locally (/bin/tar), and GNU tar 1.20 installed in GUB. I just tried doing a fresh build with $ bin/gub tools::bison && bin/gub tools::flex && bin/gub mingw::lilypond-installer and I get two configure errors for linux-x86::cross/binutils. I'm just attaching the one for configure-binutils; configure-gas also failed with the same error message. Thanks, Patrick Usage: tar [OPTION...] [FILE]... GNU `tar' saves many files together into a single tape or disk archive, and can restore individual files from the archive. Examples: tar -cf archive.tar foo bar # Create archive.tar from files foo and bar. tar -tvf archive.tar # List all files in archive.tar verbosely. tar -xf archive.tar # Extract all files from archive.tar. Main operation mode: -A, --catenate, --concatenate append tar files to an archive -c, --create create a new archive -d, --diff, --compare find differences between archive and file system --delete delete from the archive (not on mag tapes!) -r, --append append files to the end of an archive -t, --list list the contents of an archive --test-label test the archive volume label and exit -u, --update only append files newer than copy in archive -x, --extract, --get extract files from an archive Operation modifiers: --check-device check device numbers when creating incremental archives (default) -g, --listed-incremental=FILE handle new GNU-format incremental backup -G, --incremental handle old GNU-format incremental backup --ignore-failed-read do not exit with nonzero on unreadable files -n, --seek archive is seekable --no-check-device do not check device numbers when creating incremental archives --occurrence[=NUMBER] process only the NUMBERth occurrence of each file in the archive; this option is valid only in conjunction with one of the subcommands --delete, --diff, --extract or --list and when a list of files is given either on the command line or via the -T option; NUMBER defaults to 1 --sparse-version=MAJOR[.MINOR] set version of the sparse format to use (implies --sparse) -S, --sparse handle sparse files efficiently Overwrite control: -k, --keep-old-files don't replace existing files when extracting --keep-newer-files don't replace existing files that are newer than their archive copies --no-overwrite-dir preserve metadata of existing directories --overwriteoverwrite existing files when extracting --overwrite-diroverwrite metadata of existing directories when extracting (default) --recursive-unlink empty hierarchies prior to extracting directory --remove-files remove files after adding them to the archive -U, --unlink-first remove each file prior to extracting over it -W, --verify attempt to verify the archive after writing it Select output stream: --ignore-command-error ignore exit codes of children --no-ignore-command-error treat non-zero exit codes of children as error -O, --to-stdoutextract files to standard output --to-command=COMMAND pipe extracted files to another program Handling of file attributes: --atime-preserve[=METHOD] preserve access times on dumped files, either by restoring the times after reading (METHOD='replace'; default) or by not setting the times in the first place (METHOD='system') --delay-directory-restore delay setting modification times and permissions of extracted directories until the end of extraction --group=NAME force NAME as group for added files --mode=CHANGES force (symbolic)
