Re: PATCH: Countdown to 20120925
Reviews done - thanks for waiting! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)
Do i understand correctly that grob-property-path is just a list of
properties, like '('thickness 'gap 'color)? If so, i find the name
misleading.
Anyway, i don't feel competent to give an LGTM to a Scheme patch i
don't understand - but i had certainly not noticed anything wrong.
http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newcode1073
ly/music-functions-init.ly:1073: (ly:music-property m
'grob-property-path)
Scheme syntax pwned me again, but i suppose this just uses either
grob-property or grob-property-path depending on need.
http://codereview.appspot.com/6544060/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Web: Add Elysium to Easier Editing section (issue 6546059)
lgtm http://codereview.appspot.com/6546059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web: Add Elysium to Easier Editing section (issue 6546059)
LGTM http://codereview.appspot.com/6546059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)
Reviewers: joeneeman, janek,
Message:
On 2012/09/26 05:24:37, janek wrote:
Do i understand correctly that this is something for Emacs' sake?
If so, please add this information to the commit message, so that
non-emacs
people like me will immediately know what's it about.
Oops. Sorry for the oversight, will do.
Description:
Set up indent-tabs-mode in lexer.ll and parser.yy
indent-tabs-mode has been switched off for C++ files with
directory-local variables.
However, for lack of working better indentation modes that cooperate
well with Bison and Flex files, lexer.ll and parser.yy are using a
tab-based indentation style oriented on the Linux kernel indentation
style. In order to not cause an even greater inconsistent mess, local
file variables are used for switching tab-based indentation back on in
those files.
Please review this at http://codereview.appspot.com/6551050/
Affected files:
M lily/lexer.ll
M lily/parser.yy
Index: lily/lexer.ll
diff --git a/lily/lexer.ll b/lily/lexer.ll
index
0d3f7599d899a09aab95f6800960c4e790ae6535..1caf8a5ee6f5fd8184d8ece280aaf8f5b024d04b
100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -1,4 +1,4 @@
-%{ // -*- mode: c++; c-file-style: linux -*-
+%{ // -*- mode: c++; c-file-style: linux; indent-tabs-mode: t -*-
/*
This file is part of LilyPond, the GNU music typesetter.
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index
981cf40bab5a40570601b3a2b517714b5755c88d..94227e8715ee5c72ac796ee00b1d65284539fa9a
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -1,4 +1,4 @@
-/* -*- mode: c++; c-file-style: linux -*- */
+/* -*- mode: c++; c-file-style: linux; indent-tabs-mode: t -*- */
/*
This file is part of LilyPond, the GNU music typesetter.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix vertical position of Kievan dots (issue 6570047)
LGTM http://codereview.appspot.com/6570047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)
On 2012/09/26 06:32:15, dak wrote: will do. thanks, and LGTM http://codereview.appspot.com/6551050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] facilitate changes of the (default-) drumStyleTable
Am 26.09.2012 02:25, schrieb Thomas Morley:
Hi,
sometimes I heard users complaining about the difficulty of changing
the appearance of customized percussion staves,
The NR Custom percussion staves
states: If you do not like any of the predefined lists you can define
your own list at the top of your file. and demonstrates the use of
\set DrumStaff.drumStyleTable = #(alist-hash-table mydrums)
http://lilypond.org/doc/v2.17/Documentation/notation-big-page#custom-percussion-staves
But if you only want to change _one_ value in the predefined lists you
have no other chance than to follow the method mentioned above, i.e.
_completely_ redefine the whole list.
What do you think about providing a music-function, faciltating this, perhaps:
I like the idea of giving the user the ability to change only parts of
the list
without having to rewrite the full list; I think that this concept could
be of
use in other parts of lilypond as well, so perhaps it would be more
general to
have something like
\changeTable 'drumStyleTable (...)
I'd like to avoid to have different commands with a different syntax; it
makes
it harder for the user to remember ...
Oh, but a git grep aslist-hash-table shows that only 'drumStyleTable
seems to have a hash-table structure, so my proposal is probably useless.
+1
Marc
%%
\version 2.17.0
changeDrumStyleTable =
#(define-music-function (parser location custom-style)(list?)
(make-music
'ApplyContext
'procedure
(lambda (x)
(let* ((ctx (ly:context-property-where-defined x 'drumStyleTable))
(dr-st-tab (ly:context-property ctx 'drumStyleTable)))
(if (list? (car custom-style))
(for-each (lambda (x) (hashq-set! dr-st-tab (car x) (cdr x)))
custom-style)
(hashq-set! dr-st-tab (car custom-style) (cdr custom-style)))
%--- Test
customChanges =
\with {
% changing single value:
\changeDrumStyleTable #'(lowtom () #t 30)
% changing a list of values:
\changeDrumStyleTable
#'(
(triangle doThin #f 16)
(bassdrum faThin #f -15)
(snare () #f 0)
)
}
\layout {
\context {
\DrumStaff
\customChanges
}
}
mus = \drummode {
bd4 sn bd toml8 tri
bd ssh ss ssl sna sn hh hh
hhc4 r sn tri
}
\new DrumStaff {
\mus
\new DrumVoice { \voiceOne \mus }
\new DrumVoice { \voiceTwo \mus }
}
%%
-Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replacing the r1 glyph
Hi Oscar, On Wed, Sep 26, 2012 at 2:30 AM, Oscar Dub oscar...@gmail.com wrote: I'm trying to typeset a score that uses the notation shown in the attached image to represent whole rests. As I see it there are two stages to achieving this in LilyPond: – Creating the necessary glyph (I assume the simplest way would be to edit scripts.ufermata from Feta, but am completely unsure where to start). – Writing and implementing a scheme function to engrave the glyph in place of the standard 'r1' output. As a relatively new LilyPond user, I'm struggling with both tasks. Any pointers would be appreciated! as you want to add something to LilyPond herself, i think this message will fit better on the developer list (lilypond-devel@gnu.org), so i'm forwarding it. Have you tried modifying LilyPond source code before, do you know how to access it? If not, take a look at http://lilypond.org/doc/v2.17/Documentation/contributor/overview-of-work-flow and then http://lilypond.org/doc/v2.17/Documentation/contributor/quick-start As for modifying Feta font, there is some introduction here: http://lilypond.org/doc/v2.17/Documentation/contributor/modifying-the-feta-font Let us know when you encounter any problems (as a rule of thumb, if you haven't found a solution after 20 minutes of searching, it's fine to ask. Developers may occasionally overlook some emails, but they are generally helpful when you ask specific questions). cheers :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)
Reviewers: lemzwerg, joeneeman, janek,
Message:
On 2012/09/26 05:35:16, janek wrote:
David wrote:
...and where the semantics indeed require a plain string,
an error is generated explicitly in the action instead
of leaving it to the parser to complain about bad grammar.
I'm not sure i understand. Does this mean that in some situations
there will be
errors that were not present before this change? I.e, will something
stop
working?
No. The error messages and recovery will just be different. When the
parser proper detects something that it can't use in its current state,
it throws a cryptic error message and starts throwing material away
until it thinks it can reasonably recover.
After the change, the parser proper accepts non-trivial markups where
only a string would be allowed, and the code executed on behalf of the
parser will throw the error instead without aborting.
In short, instead of a cryptic error message and dubious error recovery,
the user gets a human-understandable error message and a recovery more
likely not to cause follow-up errors.
This is for the case where things were working fine previously. As
mentioned in the issue description, there were several situations where
things broke totally counterintuitively (namely where markups were
accepted only when they consisted of non-trivial strings, but plain
strings were rejected).
In other words: after contemplating your review, I don't see that the
countdown should be affected, but if you want to suggest a rewording of
the commit message soonish, I can of course incorporate it.
A code comment to that effect does not make all that much sense in
comparison since there is little point in writing a comment for the
replacement of code that is not even there anymore when the replacement
is, in itself, quite self-explanatory.
Description:
parser.yy: remove STRING_IDENTIFIER token
A STRING_IDENTIFIER always was a special case of a MARKUP_IDENTIFIER
without being treated equally at top level. That led to craziness
like
xxx=\markup test
\xxx
being invalid, while
xxx=\markup \italic test
\xxx
was valid code. This change just removes the STRING_IDENTIFIER
category altogether. Where it was used previously, MARKUP_IDENTIFIER
is accepted now syntactically, and where the semantics indeed require
a plain string, an error is generated explicitly in the action instead
of leaving it to the parser to complain about bad grammar.
Please review this at http://codereview.appspot.com/6542057/
Affected files:
M lily/parser.yy
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index
94227e8715ee5c72ac796ee00b1d65284539fa9a..52640be0b80cfdf9f6722753e04d4d88df55c238
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -380,7 +380,6 @@ If we give names, Bison complains.
%token SCM_TOKEN
%token SCORE_IDENTIFIER
%token STRING
-%token STRING_IDENTIFIER
%token TONICNAME_PITCH
%left '-' '+'
@@ -473,7 +472,6 @@ embedded_scm_bare:
embedded_scm_bare_arg:
embedded_scm_bare
| STRING
- | STRING_IDENTIFIER
| full_markup
| full_markup_list
| context_modification
@@ -576,7 +574,6 @@ identifier_init:
| FRACTION
| string
| embedded_scm
- | full_markup
| full_markup_list
| context_modification
;
@@ -1859,10 +1856,16 @@ string:
STRING {
$$ = $1;
}
- | STRING_IDENTIFIER {
- $$ = $1;
- }
+ | full_markup
| string '+' string {
+ if (!scm_is_string ($1)) {
+ parser-parser_error (@1, (_ (simple string
expected)));
+ $1 = scm_string (SCM_EOL);
+ }
+ if (!scm_is_string ($3)) {
+ parser-parser_error (@3, (_ (simple string
expected)));
+ $3 = scm_string (SCM_EOL);
+ }
$$ = scm_string_append (scm_list_2 ($1, $3));
}
;
@@ -1873,8 +1876,23 @@ simple_string: STRING {
| LYRICS_STRING {
$$ = $1;
}
- | STRING_IDENTIFIER {
- $$ = $1;
+ | MARKUP_IDENTIFIER
+ {
+ if (scm_is_string ($1)) {
+ $$ = $1;
+ } else {
+ parser-parser_error (@1, (_ (simple string
expected)));
+ $$ = scm_string (SCM_EOL);
+ }
+ }
+ | LYRIC_MARKUP_IDENTIFIER
+ {
+ if (scm_is_string ($1)) {
+ $$ = $1;
+ } else {
+ parser-parser_error (@1, (_ (simple string
expected)));
+ $$ = scm_string (SCM_EOL);
+ }
}
;
@@ -2309,7 +2327,13 @@ gen_text_def:
t-set_property (text, $1);
$$ = t-unprotect ();
}
- | simple_string {
+ | STRING {
+ Music *t = MY_MAKE_MUSIC
Re: Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)
Reviewers: janek,
Message:
On 2012/09/26 06:14:04, janek wrote:
Do i understand correctly that grob-property-path is just a list of
properties,
like '('thickness 'gap 'color)?
Apart from overquoting (when quoting a list, its members are already
quoted), yes.
If so, i find the name misleading.
That terminology is employed in a number of places in the grammar and
code, and this patch does not invent any property but just deals
better with existing definitions and usage.
Anyway, i don't feel competent to give an LGTM to a Scheme patch i
don't
understand - but i had certainly not noticed anything wrong.
http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newcode1073
ly/music-functions-init.ly:1073: (ly:music-property m
'grob-property-path)
Scheme syntax pwned me again, but i suppose this just uses either
grob-property
or grob-property-path depending on need.
Not on need. If the property grob-property is defined, it calls
list on it to create a one-element list (which this code as well as
similar code elsewhere is expecting), otherwise it takes the property
grob-property-path as the source for that list.
This is the same way that lily/property-iterator.cc does it. I
consider this a rather awkward compatibility crutch (grob-property is
not used by any manually written overwrites, just by legacy Scheme
code), but it was not the scope of this patch to change that.
Description:
Get along with use of grob-property instead of grob-property-path in
overrides
LilyPond uses a willy-nilly mixture of grob-property and
grob-property-path when generating overrides programmatically (the
parser only uses grob-property-path). Several override-reinterpreting
commands and functionalities were not prepared to deal with this.
Please review this at http://codereview.appspot.com/6544060/
Affected files:
M ly/music-functions-init.ly
M scm/lily-library.scm
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index
e1dcd992e00bf66c60fa7e09e012632732fc7db6..0fa79af3ddb63acd68e1861710c29cfa6903ccf6
100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -1067,11 +1067,17 @@ a context modification duplicating their effect.)
(cons* 'push
(ly:music-property m 'symbol)
(ly:music-property m 'grob-value)
- (ly:music-property m 'grob-property-path)))
+ (cond
+ ((ly:music-property m 'grob-property #f) = list)
+ (else
+(ly:music-property m 'grob-property-path)
((RevertProperty)
(cons* 'pop
(ly:music-property m 'symbol)
- (ly:music-property m 'grob-property-path)
+ (cond
+ ((ly:music-property m 'grob-property #f) = list)
+ (else
+(ly:music-property m 'grob-property-path)))
(case (ly:music-property m 'name)
((ApplyContext)
(ly:add-context-mod mods
Index: scm/lily-library.scm
diff --git a/scm/lily-library.scm b/scm/lily-library.scm
index
ec1097a32b7ace1ae756e86f61fd5fa08f6cffd7..854980012cea5d3da40df5b955bfde86c4e87a97
100644
--- a/scm/lily-library.scm
+++ b/scm/lily-library.scm
@@ -275,11 +275,17 @@ bookoutput function
(cons* 'push
symbol
(ly:music-property m 'grob-value)
- (ly:music-property m 'grob-property-path)))
- ((RevertProperty)
+ (cond
+((ly:music-property m 'grob-property #f) = list)
+(else
+ (ly:music-property m 'grob-property-path)
+ ((RevertProperty)
(cons* 'pop
symbol
- (ly:music-property m 'grob-property-path))
+ (cond
+((ly:music-property m 'grob-property #f) = list)
+(else
+ (ly:music-property m 'grob-property-path
(case (ly:music-property m 'name)
((ApplyContext)
(ly:add-context-mod mods
@@ -326,11 +332,17 @@ bookoutput function
(cons* 'push
(ly:music-property m 'symbol)
(ly:music-property m 'grob-value)
-(ly:music-property m 'grob-property-path)))
+ (cond
+ ((ly:music-property m 'grob-property #f) = list)
+ (else
+ (ly:music-property m 'grob-property-path)
((RevertProperty)
(cons* 'pop
Re: [GLISS] basics
On Tue, Sep 25, 2012 at 8:21 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Actually, rather than what users find difficult (which I agree is important in and of itself), perhaps it's better to take a different tack: to try and prepare a systematic specification for the musical notations that Lilypond should support. Then, go through each one and identify the extent Lilypond supports that notation This is a good idea in itself, but i'm afraid we'll drown in the flood of suggestions if we ask this question now. Currently we want to focus on syntax alone. I mean, some things you mentioned don't need syntax changes, for example this slight horizontal and/or vertical offsets of dynamics, as is commonly found in many scores. See e.g. Janek's example of the Mozart Requiem http://news.lilynet.net/?The-LilyPond-Report-26#lilypond_output_analysis is just a (valid) feature request. There is no new syntax necessary, Lily should just do this automatically. EXAMPLE: arrowed quarter-tone notation. For details, see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think that this is more a matter of internal changes (i.e. how Lily should look at pitches) rather than syntax. Don't get me wrong - i agree with you that we need to check whether Lilypond syntax can be used to express all musical notations as effortlessly as possible. I just mean that this can be expressed in Lily syntax doesn't equal this notation is supported by LilyPond. My idea was to ask about this in fourth question: what do you find difficult to express in LilyPond syntax? For example, things that need to be done by moving something manually instead of describing the logic behind it. Probably the question could be formulated better. I don't have a copy of the Elaine Gould book you mentioned earlier, but that, together with Keith Stone and Gardner Read might be a good starting point. Yes. As i'm reading Behind Bars, i'm noticing things that can't be expressed in Lily syntax easily. I will make a report about this. I don't have other books, though. It's also probably worth taking a reflective sample of compositions from different periods and seeing how readily they can be engraved; from contemporary music, for example, I think that Boulez, Stockhausen and Ferneyhough will probably give a good reflection of what Lilypond's limits are. I don't think i have time to do the engraving myself. That's why we should ask users, who in their collective wisdom had encountered almost anything :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)
On Wed, Sep 26, 2012 at 8:58 AM, d...@gnu.org wrote: In short, instead of a cryptic error message and dubious error recovery, the user gets a human-understandable error message and a recovery more likely not to cause follow-up errors. Ok. I supposed this was the case, but wanted to be sure. I don't think commit message needs rewording. Thanks for explanation! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)
On Wed, Sep 26, 2012 at 9:10 AM, d...@gnu.org wrote: On 2012/09/26 06:14:04, janek wrote: i find the name misleading. That terminology is employed in a number of places in the grammar and code, and this patch does not invent any property but just deals better with existing definitions and usage. Sure, i didn't mean to blame you. Not on need. If the property grob-property is defined, it calls list on it to create a one-element list (which this code as well as similar code elsewhere is expecting), otherwise it takes the property grob-property-path as the source for that list. Ah! thanks for explanation. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] basics
Janek Warchoł janek.lilyp...@gmail.com writes: On Tue, Sep 25, 2012 at 8:21 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Actually, rather than what users find difficult (which I agree is important in and of itself), perhaps it's better to take a different tack: to try and prepare a systematic specification for the musical notations that Lilypond should support. Then, go through each one and identify the extent Lilypond supports that notation This is a good idea in itself, but i'm afraid we'll drown in the flood of suggestions if we ask this question now. Currently we want to focus on syntax alone. If all you have is a hammer, every problem looks like a nail. Hard to do is a large problem class, and it is not necessarily clear to users which problems could be diminuished by syntax changes, which are accessible nicely with the existing syntax, and which would warrant different mechanisms and frameworks. One thing to keep in mind is that every non-trivial snippet is an example of musical notation that LilyPond has no ready-made solution for. The text-based input of LilyPond makes it orders of magnitude better for swapping home-made recipes than WYSIWYG systems, but we should not lose sight of the value of tweak-free black-box solutions over that. The idea with a black-box approach is not necessarily that you _can't_ open the box and look inside, but that you in general don't need to do so. I am digressing. We can't really get developers to agree all that much about what problems should be tackled via syntactic means, so it would be a bit much to demand the same from users before offering feedback. So I think focusing on syntax alone is likely left to us when sifting through the reports. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Call for help with bar lines
Hello list,
I am quite frustrated – yesterday I managed to get the shift out of
input/regression/beam-feather-breaking.ly which was one of the
last problematic files for my patch.
Today, I looked at the new results: it seems to me that
*every* other regtest file is affected now, but the one mentioned above
is missing – that's not what the patch is supposed to do.
https://www.yousendit.com/download/TEhYa3ZMTEROQnpWUThUQw
(side note: I did not take a full test cycle, since the last
regtest results showed only major changes in a couple of files, most of them
were deliberate, and beam-feather-breaking.ly was the one with the biggest
optical difference, so I checked just this one and did a make all
make doc
afterwards, which went trough without complaining).
I double-checked the dimensions of the empty bar line: it is
(0.0 . 0.0) for the current master *and* my patch, so this cannot be
the culprit.
\version 2.17.4
#(define (my-bar-line::print grob)
(let ((stencil (ly:bar-line::print grob)))
(for-each display (list \n\nBar line extent:
(ly:stencil-extent stencil X) for bar line
(ly:grob-property grob 'glyph-name)))
stencil))
music = {
\override Staff.BarLine #'stencil = #my-bar-line::print
c4 c c c \bar
c c c c \bar |.
}
\score {
\new Staff {
\new Voice { \music }
}
}
Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each line,
but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...
Any hints are highly appreciated!
Regards,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
is there any particular reason why you created a new command (\single) and didn't reuse \once. IMO, using \once as an indicator that the next command applies only to the next item would make it more consistent. http://codereview.appspot.com/6495135/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
On 2012/09/26 09:05:18, Reinhold wrote: is there any particular reason why you created a new command (\single) and didn't reuse \once. IMO, using \once as an indicator that the next command applies only to the next item would make it more consistent. \once does something entirely different. It does not turn an override into a tweak but rather marks it at being active only at the current timestep. \once applies at a single time, \single applies on a single item. My first reaction was how can one not understand this? but then I reread the description, and it says \single can, like \once, translate larger override sets like \voiceOne into a tweak, so you can use things like \single\voiceOne c4. Uh, ouch. This is a rather sense-altering distortion/contraction of \single, like \once, can be applied to music consisting of one or more overrides. It translates such an override set, for example \voiceOne, into a tweak on the following music item, so you can use things like \single\voiceOne c4 inside of a chord and have it only affect a single notehead of the chord. Which does not make all that much sense musically since \voiceOne mostly applies to stuff like stems that are per-chord anyway. So I probably should rather use something like \single\easyHeadsOn for illustration. I'll alter the description accordingly. http://codereview.appspot.com/6495135/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] basics
On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Currently we want to focus on syntax alone. If all you have is a hammer, every problem looks like a nail. Hard to do is a large problem class, and it is not necessarily clear to users which problems could be diminuished by syntax changes, which are accessible nicely with the existing syntax, and which would warrant different mechanisms and frameworks. Sorry, i should've used the term ly language. What i mean: when asking users about their problems, i wouldn't differentiate between these two areas - i'd just ask for everythin. It would be our job to decide what could be done with a bit of syntactic sugar, and what needs changes in mechanisms and frameworks. In other words, i'd just ask users for things that need a change in ly language, where a change in ly language can be either a helper function or an actual change in how things work internally... I hope that's clear. (and it seems that we agree after all) The text-based input of LilyPond makes it orders of magnitude better for swapping home-made recipes than WYSIWYG systems, but we should not lose sight of the value of tweak-free black-box solutions over that. The idea with a black-box approach is not necessarily that you _can't_ open the box and look inside, but that you in general don't need to do so. Do i understand correctly that you mean it's good to have helper functions [1] that make code clean and tidy. It is also good to be able to look at the code of such function and create your own derivative function if necessary? If so, that's like +111 from me - couldn't agree more. [1] or other helper stuff, even if technically it's not a function cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
On 26 sept. 2012, at 11:01, Marc Hohl m...@hohlart.de wrote: Can anyone with more knowledge than me give me a hint what's wrong? IIUC correctly, lilypond draws a bar line at the beginning of each line, but in most cases, this is an invisible one. If you look at the results of input/regression/lyrics-spanbar.ly, the whole stuff is shifted that much to the right that lilypond moves the rightmost rest to a new line! I can't believe that a bar line with zero width can be the cause for this... Any hints are highly appreciated! Regards, Marc Hey Marc, I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. There are a couple classic things I use, most of which are in grob.cc. In Grob::pure_relative_y_coordinate, before the last return statement, you can put: if (name () == BarLine) print (RELATIVE COORDINATE for BARLINE at spanned rank %d: %4.4f\n, spanned_rank_interval ()[LEFT], out); You can put similar prints in the extent function (but this time printing the two extent values). Hopefully the difference will show up here. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] basics
Janek Warchoł janek.lilyp...@gmail.com writes: On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Currently we want to focus on syntax alone. If all you have is a hammer, every problem looks like a nail. Hard to do is a large problem class, and it is not necessarily clear to users which problems could be diminuished by syntax changes, which are accessible nicely with the existing syntax, and which would warrant different mechanisms and frameworks. Sorry, i should've used the term ly language. What i mean: when asking users about their problems, i wouldn't differentiate between these two areas - i'd just ask for everythin. It would be our job to decide what could be done with a bit of syntactic sugar, and what needs changes in mechanisms and frameworks. In other words, i'd just ask users for things that need a change in ly language, where a change in ly language can be either a helper function or an actual change in how things work internally... I hope that's clear. (and it seems that we agree after all) Not sure. To get back at the hammer analogy, users might ask for a heavier hammer if they have problems getting screws in place. Or for a more convenient way to enter/express xxx when they should not be required to bother with xxx at all. The text-based input of LilyPond makes it orders of magnitude better for swapping home-made recipes than WYSIWYG systems, but we should not lose sight of the value of tweak-free black-box solutions over that. The idea with a black-box approach is not necessarily that you _can't_ open the box and look inside, but that you in general don't need to do so. Do i understand correctly that you mean it's good to have helper functions [1] that make code clean and tidy. It is also good to be able to look at the code of such function and create your own derivative function if necessary? If so, that's like +111 from me - couldn't agree more. [1] or other helper stuff, even if technically it's not a function I would not call an interface to a musical concept a helper function just because it is reasonably easy to translate that concept into a graphical representation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request
2012/9/25 David Kastrup d...@gnu.org: But if I remember correctly, beam subdivision is a multi-level problem, not just two-level. yes, see the attachment to http://code.google.com/p/lilypond/issues/detail?id=2361 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: On 26 sept. 2012, at 11:01, Marc Hohl m...@hohlart.de wrote: Can anyone with more knowledge than me give me a hint what's wrong? IIUC correctly, lilypond draws a bar line at the beginning of each line, but in most cases, this is an invisible one. If you look at the results of input/regression/lyrics-spanbar.ly, the whole stuff is shifted that much to the right that lilypond moves the rightmost rest to a new line! I can't believe that a bar line with zero width can be the cause for this... Any hints are highly appreciated! Regards, Marc Hey Marc, I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... There are a couple classic things I use, most of which are in grob.cc. In Grob::pure_relative_y_coordinate, before the last return statement, you can put: if (name () == BarLine) print (RELATIVE COORDINATE for BARLINE at spanned rank %d: %4.4f\n, spanned_rank_interval ()[LEFT], out); This can be quite handy, thanks! But back to my original question: can someone please have a quick glimpse at the regtests? Perhaps he can spot the cuprit very easily ... Thanks in advance, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] basics
On Wed, Sep 26, 2012 at 11:53 AM, David Kastrup d...@gnu.org wrote: To get back at the hammer analogy, users might ask for a heavier hammer if they have problems getting screws in place. Or for a more convenient way to enter/express xxx when they should not be required to bother with xxx at all. Yes, that's a problem. Anyway, i think that we agree that we'll have to sort user responses and that not all of them will actually need language changes to solve. Do i understand correctly that you mean it's good to have helper functions [1] that make code clean and tidy. It is also good to be able to look at the code of such function and create your own derivative function if necessary? If so, that's like +111 from me - couldn't agree more. [1] or other helper stuff, even if technically it's not a function I would not call an interface to a musical concept a helper function just because it is reasonably easy to translate that concept into a graphical representation. I don't understand what you mean here...[1] Anyway, i should've provided an example. By helper stuff i mean things like your \at function, David Nalesnik's \shape, being able to write \compressFullBarRests instead of \set SkipBars = ##t etc. best, Janek [1] you don't have to explain (unless you care about it a lot) - i know that we can talk for hours ;) and there's so much other emails flying around that it's hard to keep up: i haven't done anything other than email since i've woken up, except for breakfast :P I'm trying to get my replies shorter... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Marc Hohl m...@hohlart.de writes: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... _I_ wouldn't dare competing against Mike in a purity test. Unless you know your way inside/out of pure/impure containers and stuff, it might really be worth a try to check out his debugging suggestion. In a different vein, I have the impression that we might need to revisit the programming model if we want to have a chance of more than 2 people ever being able to work successfully on/with the backend. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
On 26 sept. 2012, at 12:07, Marc Hohl m...@hohlart.de wrote: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: On 26 sept. 2012, at 11:01, Marc Hohl m...@hohlart.de wrote: Can anyone with more knowledge than me give me a hint what's wrong? IIUC correctly, lilypond draws a bar line at the beginning of each line, but in most cases, this is an invisible one. If you look at the results of input/regression/lyrics-spanbar.ly, the whole stuff is shifted that much to the right that lilypond moves the rightmost rest to a new line! I can't believe that a bar line with zero width can be the cause for this... Any hints are highly appreciated! Regards, Marc Hey Marc, I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... ly:bar-line::print is a registered pure-print-callback (line 2712 of define-grobs.scm), so when you use a custom callback, LilyPond stops finding pure heights of bar lines. To make sure that pure extents kick in, you'd need to do something like \override BarLine #'print = #my-print-callback \override BarLine #'Y-extent = #(ly:unpure-pure-container ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height grob))) You can check on the CG subchapter on pure properties for more examples. There are a couple classic things I use, most of which are in grob.cc. In Grob::pure_relative_y_coordinate, before the last return statement, you can put: if (name () == BarLine) print (RELATIVE COORDINATE for BARLINE at spanned rank %d: %4.4f\n, spanned_rank_interval ()[LEFT], out); This can be quite handy, thanks! But back to my original question: can someone please have a quick glimpse at the regtests? Perhaps he can spot the cuprit very easily ... I looked at them and my guess is that the pure extents (and maybe even unpure extents) are being changed, which is why I suggested doing prints to the command line for extents (both X and Y). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
- Original Message - From: m...@mikesolomon.org To: Marc Hohl m...@hohlart.de Cc: Lily-Devel List lilypond-devel@gnu.org Sent: Wednesday, September 26, 2012 11:34 AM Subject: Re: Call for help with bar lines On 26 sept. 2012, at 12:07, Marc Hohl m...@hohlart.de wrote: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: On 26 sept. 2012, at 11:01, Marc Hohl m...@hohlart.de wrote: Can anyone with more knowledge than me give me a hint what's wrong? IIUC correctly, lilypond draws a bar line at the beginning of each line, but in most cases, this is an invisible one. If you look at the results of input/regression/lyrics-spanbar.ly, the whole stuff is shifted that much to the right that lilypond moves the rightmost rest to a new line! I can't believe that a bar line with zero width can be the cause for this... Any hints are highly appreciated! Regards, Marc Hey Marc, I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... ly:bar-line::print is a registered pure-print-callback (line 2712 of define-grobs.scm), so when you use a custom callback, LilyPond stops finding pure heights of bar lines. To make sure that pure extents kick in, you'd need to do something like \override BarLine #'print = #my-print-callback \override BarLine #'Y-extent = #(ly:unpure-pure-container ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height grob))) You can check on the CG subchapter on pure properties for more examples. There are a couple classic things I use, most of which are in grob.cc. In Grob::pure_relative_y_coordinate, before the last return statement, you can put: if (name () == BarLine) print (RELATIVE COORDINATE for BARLINE at spanned rank %d: %4.4f\n, spanned_rank_interval ()[LEFT], out); This can be quite handy, thanks! But back to my original question: can someone please have a quick glimpse at the regtests? Perhaps he can spot the cuprit very easily ... I looked at them and my guess is that the pure extents (and maybe even unpure extents) are being changed, which is why I suggested doing prints to the command line for extents (both X and Y). I've no idea if this will help, so feel free to ignore it. However, my recollection is that running lily with -ddump-signatures gives information on extents in the output file? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
On 26 sept. 2012, at 12:46, Phil Holmes m...@philholmes.net wrote: I've no idea if this will help, so feel free to ignore it. However, my recollection is that running lily with -ddump-signatures gives information on extents in the output file? This is a great idea - you can get a lot of useful data from these files. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Project - Eliminating grob parents and outside-staff-priority
Hey all, As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. 2) A call to translate_axis in avoid_outside_staff_collisions would be eliminated, and translate_axis is bad: it goes against the callback model at the core of LilyPond layout. The disadvantage is that this results in the construction of many more skylines (one for each call to Side_position_interface::skyline_side_position). How this will impact performance is uncertain, but it'd probably require more optimization in skyline.cc and/or caching of skylines. Before I do this, which will take me several months, does anyone have any objections? Do people think it's a good idea? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
m...@mikesolomon.org m...@mikesolomon.org writes: As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. [...] performance is uncertain, but it'd probably require more optimization in skyline.cc and/or caching of skylines. It sounds to me like you consider caching a bad idea so you want to remove it, and to make this removal feasible you think you will be required to do caching. It sounds to me like it would make more sense that we improve our cache invalidation strategy where it goes wrong rather than shifting the problem around in increasingly complex manners. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 26 sept. 2012, at 13:39, David Kastrup d...@gnu.org wrote: m...@mikesolomon.org m...@mikesolomon.org writes: As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. [...] performance is uncertain, but it'd probably require more optimization in skyline.cc and/or caching of skylines. It sounds to me like you consider caching a bad idea so you want to remove it, and to make this removal feasible you think you will be required to do caching. You're right - I explained myself poorly. The caching of skylines would come from similar content. i.e. if Skyline X == Skyline A and Skyline Y == Skyline B and we have already measured the distance between A and B, use that as the distance between X and Y. Here, equality is defined as having buildings with the same start_, end_, slope_ and y_offset_. So it's a different type of caching than the caching of grob properties. It sounds to me like it would make more sense that we improve our cache invalidation strategy where it goes wrong There is currently no cache invalidation strategy. rather than shifting the problem around in increasingly complex manners. There is currently no way in LilyPond to trace what properties depend on what properties. So if we want to invalidate the cache of property X, it is very difficult to invalidate the caches of properties that depend on it. This is made considerably easier if side-positioning is streamlined. When a grob X's side position changes for a given axis, iterate over its side-position elements and recalculate their offsets. That's one of the main reasons I want to make this change. I think the change decreases complexity as it makes LilyPond more predictable and boring - objects side position based off of other objects and that's it. No need for side-position, parents and outside-staff-priority. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
m...@mikesolomon.org m...@mikesolomon.org writes: On 26 sept. 2012, at 13:39, David Kastrup d...@gnu.org wrote: It sounds to me like it would make more sense that we improve our cache invalidation strategy where it goes wrong There is currently no cache invalidation strategy. Sounds like we found the place where it goes wrong. rather than shifting the problem around in increasingly complex manners. There is currently no way in LilyPond to trace what properties depend on what properties. So if we want to invalidate the cache of property X, it is very difficult to invalidate the caches of properties that depend on it. This is made considerably easier if side-positioning is streamlined. When a grob X's side position changes for a given axis, iterate over its side-position elements and recalculate their offsets. That's one of the main reasons I want to make this change. What we need to arrive at is a situation where somebody without a clue starting to write stuff will more likely than not get a whole lot of things working right without realizing it, rather than getting a whole lot of things working wrong without realizing it. Which apparently is what is happening to Marc right now. He is working on a simple problem, and it fails for complex reasons. And that means the current design of our backend is bad. Conceptually simple problems need to map to conceptually simple solutions. If they don't, our APIs suck. I think the change decreases complexity as it makes LilyPond more predictable and boring - objects side position based off of other objects and that's it. No need for side-position, parents and outside-staff-priority. parents are used for a _lot_ of positioning, and for example the determination of a common grob parent is an _efficient_ operation. So it might make sense to solve the problem you are thinking of via artificial/grouping parents. I can't vouch for it, obviously, as the backend is mostly opaque to me right now. But it is a possibility. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 26 sept. 2012, at 14:13, David Kastrup d...@gnu.org wrote: What we need to arrive at is a situation where somebody without a clue starting to write stuff will more likely than not get a whole lot of things working right without realizing it, rather than getting a whole lot of things working wrong without realizing it. I completely agree. Which apparently is what is happening to Marc right now. He is working on a simple problem, and it fails for complex reasons. And that means the current design of our backend is bad. Conceptually simple problems need to map to conceptually simple solutions. If they don't, our APIs suck. We don't have APIs, which is a separate but equally problematic issue. The conceptually simple problem is that grobs are positioned with respect to other grobs. The conceptually simple solution is that grobs contain arrays of these other grobs and use them for the positioning. That's why I want to make this change - it provides one-stop-shopping for positioning changes. I think the change decreases complexity as it makes LilyPond more predictable and boring - objects side position based off of other objects and that's it. No need for side-position, parents and outside-staff-priority. parents are used for a _lot_ of positioning, and for example the determination of a common grob parent is an _efficient_ operation. So it might make sense to solve the problem you are thinking of via artificial/grouping parents. This is totally possible - you check the side-position-elements array, and if it has multiple members, you find their common refpoint. This can go all the way up to System and VerticalAlignment, both of which will have side-position-element arrays of size 0 for both the X and Y axes. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Improve documentation of \glissando. (issue 6529043)
This example shows a beam extending from a stem to the final note of the glissando. Is this correct, or would it be better to suppress the beam? I made some Bartók and Xenakis scans, see https://docs.google.com/folder/d/0B7AjGy5hUKtAeWtkdHdfN0l4bm8/edit such beams can be seen in 0162.jpeg and 0164.jpeg (the former has examples for avoiding such stems too, using flags). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
It would be tremendously helpful if you can show possible syntax
*alternatives* instead of just pretending to be a naysayer.
I've posted actual working definitions for that purpose.
It seems I've missed that, lost in the many examples you've given to
demonstrate what doesn't work.
They would definitely simplify the kind of entry you are asking for.
Please repeat.
Sigh.
at =
#(define-music-function (parser location time event music)
(ly:duration? ly:music? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ { \skip $time $event } $music #})
{
\at 4 \
\at 1*2/3 \!
c'1\p
}
[12 days later, and no followup again]
Let's just continue pretending me to be a naysayer then.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] basics
On 26/09/12 09:19, Janek Warchoł wrote: This is a good idea in itself, but i'm afraid we'll drown in the flood of suggestions if we ask this question now. Currently we want to focus on syntax alone. I do understand that, it's just that I think that proposals for syntax changes make more sense when considered in the broader context of the notation you want to support. I wasn't proposing asking it as a mailing-list question, more as a project that could probably be handled by relatively few people working from musical notation texts. The reason I think that's important is because without considering the notational scope, syntax proposals can easily exclude a range of desirable features. The existing \tempo command is a good example. It makes perfect sense for simple metronome marks, but excludes a whole host of widely-used tempo change indications. It turns out (as per David's earlier email) that it's possible to have a syntax which allows all of those possibilities, that isn't much more complex for the simple use-case, _and_ is easier on the parser. But without considering that broader scope of notation, it would be easy to say, Hey, this is just complicating the existing syntax for the sake of the parser, why not make the parser do the work and keep it simple for users? I mean, some things you mentioned don't need syntax changes, for example this Fair point, some of these things are best characterized as limits in the interpretation of syntax rather than in syntax per se. I don't think at this point it's useful for me to respond in detail on the particular examples, though I can do so if you like. Don't get me wrong - i agree with you that we need to check whether Lilypond syntax can be used to express all musical notations as effortlessly as possible. I just mean that this can be expressed in Lily syntax doesn't equal this notation is supported by LilyPond. Sure, but that's kind of what I was getting at -- you want to separate out the cases where the syntax is genuinely inadequate, where it's theoretically adequate but the internal data structures or engraving algorithms are inadequate, where the syntax is unnecessarily verbose, or where it's simply difficult to find out about the syntax. That info then gives you the basis to make rigorous changes to the syntax. For example, it lets you know that proposed changes to the \tempo command don't just benefit the parser -- they also expand the range of notation it can cover. My idea was to ask about this in fourth question: what do you find difficult to express in LilyPond syntax? For example, things that need to be done by moving something manually instead of describing the logic behind it. Probably the question could be formulated better. I think the question is a good one to ask. As per my examples, you'll surely find quite a few where the real issue is not syntax but the engraving process, or simply cases where users aren't aware of the existing solutions. But the real concern I have is that I don't think that members of the Lilypond user list are necessarily representative of the range of engraving activity that Lilypond needs to support. That's the other reason I suggested a systematic process of checking syntax/engraving support vs. a broad set of musical notation. I don't have a copy of the Elaine Gould book you mentioned earlier, but that, together with Keith Stone and Gardner Read might be a good starting point. Yes. As i'm reading Behind Bars, i'm noticing things that can't be expressed in Lily syntax easily. I will make a report about this. I don't have other books, though. I can send you a copy of the couple of papers Keith Stone wrote on contemporary notation -- these are a precursor to his book. They're less comprehensive but nevertheless useful. I don't think i have time to do the engraving myself. That's why we should ask users, who in their collective wisdom had encountered almost anything :) Well, I'm not suggesting engraving whole works. Selected snippets should be adequate. Besides the obvious contemporary composer complex stuff, there are also some surprisingly simple notations which show up here -- e.g. Ferneyhough frequently has hairpins which last until the end of the note and have a concluding dynamic value; that dynamic value falls at the end of the hairpin rather than the beginning of the subsequent note (if you get me). See e.g. http://soundandmusic.org/thecollection/files/scores/28724w.pdf in for example bar 4, Violin 3 (although there are plenty of other examples in the score). That seems to me a notation for which there genuinely isn't a solution in Lilypond syntax or internals, although you could probably fake it with careful use of parallel space notation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
2012/9/26 Marc Hohl m...@hohlart.de:
Hello list,
I am quite frustrated – yesterday I managed to get the shift out of
input/regression/beam-feather-breaking.ly which was one of the
last problematic files for my patch.
Today, I looked at the new results: it seems to me that
*every* other regtest file is affected now, but the one mentioned above
is missing – that's not what the patch is supposed to do.
https://www.yousendit.com/download/TEhYa3ZMTEROQnpWUThUQw
(side note: I did not take a full test cycle, since the last
regtest results showed only major changes in a couple of files, most of them
were deliberate, and beam-feather-breaking.ly was the one with the biggest
optical difference, so I checked just this one and did a make all make
doc
afterwards, which went trough without complaining).
I double-checked the dimensions of the empty bar line: it is
(0.0 . 0.0) for the current master *and* my patch, so this cannot be
the culprit.
\version 2.17.4
#(define (my-bar-line::print grob)
(let ((stencil (ly:bar-line::print grob)))
(for-each display (list \n\nBar line extent: (ly:stencil-extent
stencil X) for bar line
(ly:grob-property grob 'glyph-name)))
stencil))
music = {
\override Staff.BarLine #'stencil = #my-bar-line::print
c4 c c c \bar
c c c c \bar |.
}
\score {
\new Staff {
\new Voice { \music }
}
}
Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each line,
but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...
Any hints are highly appreciated!
Regards,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Marc,
an idea, don't know if it's really helpful:
From 2.16.0-bar-line.scm, bar-glyph-alist:
The old definition of bar empty was: (empty . (() . ()))
The old definition of bar was: ( . ( . ))
The new patch converts bar empty into bar
If I understand correctly than empty eliminates the stencil, whereas
prints a stencil with dimensions (0.0 . 0.0).
And if there is _no_ stencil lily doesn't reserve any space _after_
it, but if there is a stencil, even a point-stencil, some space _is_
inserted.
Look at this example:
m =
\relative c' {
\key ces\major
ces
\key cis \major
cis
}
\new Staff \with { \override KeyCancellation #'stencil = #'() } \m
\new Staff \with { \override KeyCancellation #'stencil = #point-stencil } \m
You will notice a small, but visible difference.
HTH,
Harm
BTW,
2012/9/21 Marc Hohl m...@hohlart.de:
I had some bad feelings that I grabbed
your ideas and modified it to my needs without some discussion
with you.
Rubbish! :)
I'm very happy that I had some ideas, you could run with. You managed
to improve the ideas and their coding in an enormous degree.
Great! :D
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
On 26/09/2012 11:26, d...@gnu.org wrote: \once does something entirely different. It does not turn an override into a tweak but rather marks it at being active only at the current timestep. \once applies at a single time, \single applies on a single item. To me as a user, \once\override is used to change the next note (or items attached to it) and \single\tweak is used to change the next item. That \once\override applies to the next timestep, and the following note incidentally happens at that timestep is an internal detail when I'm writing a score. From a developer's POV there is a different concept involved, but I doubt that a normal user really cares about this. To me it's basically the same as the \set / \override distinction. It might be a different concept to anyone who knows the internals, but to a user both are used to change the default. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
On 26/09/2012 14:34, David Kastrup wrote:
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
It would be tremendously helpful if you can show possible syntax
*alternatives* instead of just pretending to be a naysayer.
I've posted actual working definitions for that purpose.
It seems I've missed that, lost in the many examples you've given to
demonstrate what doesn't work.
They would definitely simplify the kind of entry you are asking for.
Please repeat.
Sigh.
at =
#(define-music-function (parser location time event music)
(ly:duration? ly:music? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ { \skip $time $event } $music #})
{
\at 4 \
\at 1*2/3 \!
c'1\p
}
[12 days later, and no followup again]
Let's just continue pretending me to be a naysayer then.
You demonstrated that a solution is possible, but quite inconsistent with
the lilypond language: You have to write the dynamic BEFORE the note,
although it should be printed AFTER the note...
In your example, what you want is note with p, hairpin start, hairpin
end. But what you have to write is hairpin start, hairpin end, note with
p.
So, yes, such hacks as workarounds are certainly possible, but IMO they
currently don't really fit well with the general concepts of the lilypond
language (i.e. all dynamics are written using postfix notation)...
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
Reinhold Kainhofer reinh...@kainhofer.com writes: On 26/09/2012 11:26, d...@gnu.org wrote: \once does something entirely different. It does not turn an override into a tweak but rather marks it at being active only at the current timestep. \once applies at a single time, \single applies on a single item. To me as a user, \once\override is used to change the next note (or items attached to it) and \single\tweak is used to change the next item. Both are only roughly equivalent when there is only one item per timestep. \once\override affects _everything_ happening at the same time. Your complaint amounts to I don't want to know about the difference between an override and a tweak, but that's not a problem that can be cured by not providing a method of converting one into the other. That \once\override applies to the next timestep, and the following note incidentally happens at that timestep is an internal detail when I'm writing a score. From a developer's POV there is a different concept involved, but I doubt that a normal user really cares about this. Shrug. Feel free to ignore the distinction until things break for you, but it is not like _I_ am responsible for it merely because I provide an additional tool making it easier to deal with that difference. To me it's basically the same as the \set / \override distinction. It might be a different concept to anyone who knows the internals, but to a user both are used to change the default. Code reviews are not the place for _unrelated_ LilyPond-bashing. I get blamed for enough things every day without the need to invent extra causes. http://codereview.appspot.com/6495135/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
Reinhold Kainhofer reinh...@kainhofer.com writes:
On 26/09/2012 14:34, David Kastrup wrote:
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
It would be tremendously helpful if you can show possible syntax
*alternatives* instead of just pretending to be a naysayer.
I've posted actual working definitions for that purpose.
It seems I've missed that, lost in the many examples you've given to
demonstrate what doesn't work.
They would definitely simplify the kind of entry you are asking for.
Please repeat.
Sigh.
at =
#(define-music-function (parser location time event music)
(ly:duration? ly:music? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ { \skip $time $event } $music #})
{
\at 4 \
\at 1*2/3 \!
c'1\p
}
[12 days later, and no followup again]
Let's just continue pretending me to be a naysayer then.
You demonstrated that a solution is possible, but quite inconsistent with
the lilypond language: You have to write the dynamic BEFORE the note,
although it should be printed AFTER the note...
It is conceivable to cook up stuff that would allow to write something
like
c'1\p-\at 4 \ -\at 1*2/3 \!
here.
In your example, what you want is note with p, hairpin start, hairpin
end. But what you have to write is hairpin start, hairpin end, note with
p.
So, yes, such hacks as workarounds are certainly possible, but IMO they
currently don't really fit well with the general concepts of the lilypond
language (i.e. all dynamics are written using postfix notation)...
If you don't even bother to reply, how am I supposed to guess what your
problem with my approach is?
In my opinion, dynamics are one case where using postfix syntax was a
mistake, exactly because they are not inherently associated with a
particular note but rather a moment of time. It is _that_ choice which
does not really fit well with the general concepts of the LilyPond
language, and in consequence dynamics are the _dominant_ example for use
of and/or s1*0. So my preferred path to a remedy would rather be to
un-postevent stuff that does not really fit the postevent category
rather than to mess with the timing relations of postevents.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
at =
#(define-music-function (parser location time event music)
(ly:duration? ly:music? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ { \skip $time $event } $music #})
{
\at 4 \
\at 1*2/3 \!
c'1\p
}
[12 days later, and no followup again]
Let's just continue pretending me to be a naysayer then.
Hehe. Sorry for not answering (I was busy, and then I forgot), and
thanks for resending the example. While I can see that this works,
I'm not getting comfortable with the notation. I still favor
something like
c'1-{...}
regardless of its impossibility :-) Maybe things change in the future,
and we can reconsider the whole issue then.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
Reinhold Kainhofer reinh...@kainhofer.com writes:
On 26/09/2012 14:34, David Kastrup wrote:
David Kastrup d...@gnu.org writes:
Werner LEMBERG w...@gnu.org writes:
It would be tremendously helpful if you can show possible syntax
*alternatives* instead of just pretending to be a naysayer.
I've posted actual working definitions for that purpose.
It seems I've missed that, lost in the many examples you've given to
demonstrate what doesn't work.
They would definitely simplify the kind of entry you are asking for.
Please repeat.
Sigh.
at =
#(define-music-function (parser location time event music)
(ly:duration? ly:music? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ { \skip $time $event } $music #})
{
\at 4 \
\at 1*2/3 \!
c'1\p
}
[12 days later, and no followup again]
Let's just continue pretending me to be a naysayer then.
You demonstrated that a solution is possible, but quite inconsistent with
the lilypond language: You have to write the dynamic BEFORE the note,
although it should be printed AFTER the note...
One can, of course, exchange the order of arguments. However, then
adding several arguments becomes more awkward:
at =
#(define-music-function (parser location music event time)
(ly:music? ly:music? ly:duration?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ \context Voice { \skip $time $event } $music #})
{
\at {
\at { c'1\p } \ 4
} \! 1*2/3
}
In this case, we might get the same result, however, by specifying the
second duration not in relation to the main event but to the already
delayed event:
after =
#(define-music-function (parser location music time event)
(ly:music? ly:duration? ly:music?)
Place @var{event} at a relative duration @var{time} in relation
to @var{music}.
#{ \context Voice { \skip $time $event } $music #})
{
\after { c'1\p } 4 \after \ 1*1/6 \!
}
This is now in time order but I am not really convinced that it is
less confusing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: document \time command fully (2807) (issue 6532055)
On Saturday, September 22, 2012, David wrote: 2.15.19: commit a512132fed73a94068b91fb0bab473**319e477b6e Author: David Kastrup d...@gnu.org Date: Wed Nov 9 11:37:39 2011 +0100 Fold set-time-signature into \time It may be instructional to look at the diff itself. That's the kind of thing possible just using music functions now, without the need of messing with the parser. I am not entirely sure that it would not have been more prudent to instead fold \compoundTime into \time, but as long as nobody bothers reviewing such changes, I need to make them without feedback David, i'm sorry that this had happened. Indeed this was a change both easy and short to review, and i wish i had reviewed it. I have missed many things during my absence in last year Autumn. I want to assure you that i believe this is a needed and useful change, and i will be happy to see more similar changes in the future. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: document \time command fully (2807) (issue 6532055)
On Saturday, September 22, 2012, David wrote: Nobody can be bothered enough to even comment. Yet when it comes to discussing things that will wreak havoc with the parser, everybody is fired up and inspired to throw his own spanner into the works. I am not saying that this is ill will. It is just a consequence of how we are organizing our work and information flow. The problem is that with regard to developer and user motivation, the consequences are indistinguishable from ill will and/or disregard. Users get GLISS discussions where they get the impression that developers don't care one bit for them, developers get reviews where they get the impression that users don't care one bit for them. I know both impressions to be far from the truth. But that's more by deduction rather than a direct feeling. I agree that we have a serious problem. Hopefully, you've presented the first step to solve it: realize that this is not ill will, but rather unfortunate coincidences and poor wording of emails. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] non-timed or non-musical events z y
\after { c'1\p } 4 \after \ 1*1/6 \!
This is now in time order but I am not really convinced that it is
less confusing.
You are right, it's worse. Your first solution is fine except that it
doesn't follow lilypond's suffix notation.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
2012/9/26 m...@mikesolomon.org m...@mikesolomon.org: On 26 sept. 2012, at 14:13, David Kastrup d...@gnu.org wrote: Conceptually simple problems need to map to conceptually simple solutions. If they don't, our APIs suck. We don't have APIs, Sounds like we found the reason they suck. Couldn't reseist, sorry. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org m...@mikesolomon.orgwrote: Hey all, As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. Are you proposing not to cache callbacks at all? That sounds like a real performance killer to me; we would probably end up re-typesetting each beam hundreds of times. By the way, the problem is not only in the caching of callbacks; there are also many other places with side effects (calls to set_property, translate_axis, suicide, etc). To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. If you get rid of unique parents, what would X-offset mean? Would it be relative to the System? The first element of side-position-elements array? 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. I think you'll have trouble making this fully callbacky/functional. For example, we lay out the outside-staff grobs in a very particular order (the left-to-right layout thing), which we don't know ahead of time. That is, until we get _all_ of the outside-staff grobs together, we don't know which grobs have to depend on which other grobs. That means it isn't really possible for each grob to determine its own position; there needs to be one grob that lays them out simultaneously. The same issue will come up, I think in laying out Accidentals and VerticalAxisGroups. At some point, I had grand plans to formalize this problem by having two distinct kinds of properties: one that is user-overridable using callbacks, and one that is internal and gets set by other grobs as a side-effect. Everything would have explicit dependencies so that caches could be invalidated. I even started to write a proof-of-concept in scala, but I never finished it... The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. Not all positioning is side-positioning. 2) A call to translate_axis in avoid_outside_staff_collisions would be eliminated, and translate_axis is bad: it goes against the callback model at the core of LilyPond layout. Agreed, but this is just one instance of translate_axis, which is just one example of a side-effect in lilypond. Is your eventual goal to remove them all? The disadvantage is that this results in the construction of many more skylines (one for each call to Side_position_interface::skyline_side_position). How this will impact performance is uncertain, but it'd probably require more optimization in skyline.cc and/or caching of skylines. I would suggest that you completely ignore performance in favor of a clean design. Performance can come later. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf File mf/feta-scripts.mf (right): http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf#newcode1781 mf/feta-scripts.mf:1781: fet_beginchar (snap pizzicato (Bartok pizzicato), snappizzicat); It would appear you renamed this glyph to snappizzicat instead of the previous snappizzicato. I can't imagine this being anything other than a mistake. http://codereview.appspot.com/6568055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds tick mark to scripts (issue 6568055)
Reviewers: lemzwerg, janek, Graham Percival,
Message:
Please review
Description:
As it says. A tick mark is a very common way of indicating a breath in
vocal music, but we have no good glyph for this. This is an attempt to
create one.
Please review this at http://codereview.appspot.com/6568055/
Affected files:
M mf/feta-scripts.mf
Index: mf/feta-scripts.mf
diff --git a/mf/feta-scripts.mf b/mf/feta-scripts.mf
index
83859dbe66fc2b4af51bd7bf63947d9700db6913..89ccc25370fa58c9d23e436dc4698630e2874a57
100644
--- a/mf/feta-scripts.mf
+++ b/mf/feta-scripts.mf
@@ -1736,8 +1736,49 @@ fet_beginchar (Straight
caesura, caesura.straight);
labels(1a, 1b, 2a, 2b, 3a, 3b, 4a, 4b);
fet_endchar;
+% A tick character to use instead of a comma or caesura as a breath mark,
+% Very common in vocal notation
-fet_beginchar (snap pizzicato (Bartok pizzicato), snappizzicato);
+fet_beginchar (Tick mark, tickmark);
+ save end_rad, bot_rad, pat, y_off;
+ end_rad = linethickness/2;
+ bot_rad = linethickness;
+ path pat;
+
+ y_off# := 0.2 staff_space#;
+ define_pixels (y_off);
+
+ pickup pencircle scaled end_rad;
+
+ lft x1 = 0;
+ y1 = 0.8 staff_space + y_off;
+
+ x2 = 0.6 staff_space;
+ y2l = 0 + y_off;
+
+ top rt z3 = (1.7 staff_space, 1.7 staff_space + y_off);
+ z4 = (0, staff_space + y_off);
+
+ penpos2(0.4 staff_space, 90);
+ penpos3(end_rad, angle(z4-z3)+90);
+ penpos1(end_rad, angle(z2-z1)+90);
+
+ pat = z1r..top z1..z1l{z2-z1}
+ ..{z2-(z1+(0.3 staff_space,0))}z2l+(-bot_rad, bot_rad)
+ ..z2l..z2l+(bot_rad, bot_rad){z3-(0.6 staff_space,
0)-z2}
+ ..{z3-z4}z3r..rt z3..{z4-z3}z3l
+ ..{z2-(z3-(0.6 staff_space,0))}rt z2r..{z1-z2}lft
z2r{z1-z2}
+ ..cycle;
+ fill pat;
+
+ set_char_box (0, 1.7 staff_space# + epsilon,
+ 0, y_off# + 1.7 staff_space#);
+
+
+ penlabels (1,2,3,4);
+fet_endchar;
+
+fet_beginchar (snap pizzicato (Bartok pizzicato), snappizzicat);
save height, width, thickness, superness;
height# = 4/15 staffsize#;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
Correct. Apologies - I did that to try an experiment and didn't reset it. Thanks for picking it up. Next patch set will correct that. http://codereview.appspot.com/6568055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Improve documentation of \glissando. (issue 6529043)
Benkő Pál wrote Wednesday, September 26, 2012 1:31 PM I made some Bartók and Xenakis scans, see https://docs.google.com/folder/d/0B7AjGy5hUKtAeWtkdHdfN0l4bm8/edit such beams can be seen in 0162.jpeg and 0164.jpeg (the former has examples for avoiding such stems too, using flags). Many thanks, Pál, very helpful! I now see the point of inserting these markers in long glissandi, and the need for beams and flags. I'll try to make realistic examples to show this. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 26 sept. 2012, at 17:38, Joe Neeman joenee...@gmail.com wrote: On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org m...@mikesolomon.org wrote: Hey all, As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. Are you proposing not to cache callbacks at all? That sounds like a real performance killer to me; we would probably end up re-typesetting each beam hundreds of times. No, I'm proposing to find way to mark things as dirty so that they are recalculated. By the way, the problem is not only in the caching of callbacks; there are also many other places with side effects (calls to set_property, translate_axis, suicide, etc). Exactly - the proposal here is to get rid of the call to translate_axis in axis-group-interface.cc, which is the biggest side effect in the code base in terms of the number and variety of grobs affected. This'll make it easier to mark things as dirty so that multiple passes can happen. To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. If you get rid of unique parents, what would X-offset mean? Would it be relative to the System? The first element of side-position-elements array? Relative to the skyline of the elements of the side-position-elements array. 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. I think you'll have trouble making this fully callbacky/functional. For example, we lay out the outside-staff grobs in a very particular order (the left-to-right layout thing), which we don't know ahead of time. That is, until we get _all_ of the outside-staff grobs together, we don't know which grobs have to depend on which other grobs. That means it isn't really possible for each grob to determine its own position; there needs to be one grob that lays them out simultaneously. The same issue will come up, I think in laying out Accidentals and VerticalAxisGroups. You're right that, in general, any time that a collecting grob does some type of organizing, this type of problem will come up. However, there are ways around it. For example, a grob can get the elements array from its vertical alignment or system, sort it from left to right, and trigger callbacks for all grobs to the left. This avoids an overarching positioning grob while still achieving the same effect. At some point, I had grand plans to formalize this problem by having two distinct kinds of properties: one that is user-overridable using callbacks, and one that is internal and gets set by other grobs as a side-effect. Everything would have explicit dependencies so that caches could be invalidated. I even started to write a proof-of-concept in scala, but I never finished it... My thinking is that in order to make dependencies easier to handle and maintain, we need to reduce the number of side effects like translate_axis and set_property. The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. Not all positioning is side-positioning. True - my goal is to see if all positioning can be articulated this way. For example, ScriptColumn could have used translate_axis, but whoever wrote it made the good decision to use side-position-interface. I think this grob could be eliminated entirely if all scripts in a script column had a function that calculated the side-position-elements grob-array using the sorting algorithm at the heart of script-column.cc. Another way to think of this is that, in general, we'd try to eliminate grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do traffic-coppery. Or, inversely, we'd say that positioning only happens via traffic-cop grobs
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: Another way to think of this is that, in general, we'd try to eliminate grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do traffic-coppery. Or, inversely, we'd say that positioning only happens via traffic-cop grobs and no grob has the right to position itself. But it seems like we need to pick one. The reason for trafic-coppery is that for many positioning schemes, there is no inherent order that can determine how two objects of the same type (and hence, with the same set of callbacks) should be typeset. A typical example of this is NoteCollision of N NoteColumns. The NoteColumns have to all move in a coordinated way, and the easiest way is to have a function (with local variables) that determines what has to happen. You might get around it, by having a bunch of properties instead, but you'd still have to store those somewhere, ie in the NoteCollision grob. Agreed, but this is just one instance of translate_axis, which is just one example of a side-effect in lilypond. Is your eventual goal to remove them all? Yes - that'd be great. That'll make explicit dependencies a lot easier to handle - everything can be calculated in terms of callbacks. I'm all for removing side effects, but you can pursue that separately without trying to rewrite the backend. To keep the main thing the main thing, the goal is to be able to wipe certain caches, restore the original callbacks, and know that all grobs properties that depended on the restored property will also be recalculated. My idea is an idea for simplifying LilyPond so that this work is easier, but there is no point in doing that if it won't help reach that goal. I'm open to any and all suggestions. Have you thought this through? In order to do cache invalidation, you will have to construct the reverse graph. If A.x depends on B.y, now A points to B. For proper cache invalidation, if B.y changes, then A.x becomes invalid. This means that A has to store a back-reference to B. Hence all pointers have to be stored both ways (including inverting 1-N relations into N-1 relations), and the both-way links have to be rewritten correctly during line breaking. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 14:45, schrieb Thomas Morley: [...] Hi Marc, an idea, don't know if it's really helpful: From 2.16.0-bar-line.scm, bar-glyph-alist: The old definition of bar empty was: (empty . (() . ())) The old definition of bar was: ( . ( . )) The new patch converts bar empty into bar You are great! I found the same possible error while being at work, teaching students ;-) The latest patch set has indeed no difference between empty and , that's why most of the regtests are wrong. I'll give it a try tomorrow, but I am 99.9% sure that after correcting this, everything will be ok. [...] Rubbish! :) I'm very happy that I had some ideas, you could run with. You managed to improve the ideas and their coding in an enormous degree. Great! :D Thanks! I'll have to include some credits to you, anyway. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 12:23, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... _I_ wouldn't dare competing against Mike in a purity test. Unless you know your way inside/out of pure/impure containers and stuff, it might really be worth a try to check out his debugging suggestion. Ok, ok. To be honest, the pure/impure stuff is not something I understand in full ... In a different vein, I have the impression that we might need to revisit the programming model if we want to have a chance of more than 2 people ever being able to work successfully on/with the backend. I am not sure whether I understand your proposal correctly, but I am working on this for quite a long time, so I don't have strong feelings about rewriting the whole interface again (to be honest: the first presentation of the idea had a very lively discussion whether the thick bar line should be represented by '.' or 'I', but nothing more – one may this read as the interface is ok, but not the glyph you use and that's how I understand it, because the other possibility is I don't care, and I *do* hope that people care about the bar line stuff). Furthermore, I tried to comment the whole stuff very carefully, so I don't think that the backend is not understandable at all. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 12:46, schrieb Phil Holmes: [...] I've no idea if this will help, so feel free to ignore it. However, my recollection is that running lily with -ddump-signatures gives information on extents in the output file? Thanks for this hint – I didn't know that such an option even exists. Great to know ... Regards, Marc -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 12:17 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: On 26 sept. 2012, at 17:38, Joe Neeman joenee...@gmail.com wrote: On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org m...@mikesolomon.org wrote: To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. If you get rid of unique parents, what would X-offset mean? Would it be relative to the System? The first element of side-position-elements array? Relative to the skyline of the elements of the side-position-elements array. If you want to construct one skyline for all the elements in that array, you need some way of finding their offsets relative to each other. How do you propose to do that without some notion of a common refpoint? 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. I think you'll have trouble making this fully callbacky/functional. For example, we lay out the outside-staff grobs in a very particular order (the left-to-right layout thing), which we don't know ahead of time. That is, until we get _all_ of the outside-staff grobs together, we don't know which grobs have to depend on which other grobs. That means it isn't really possible for each grob to determine its own position; there needs to be one grob that lays them out simultaneously. The same issue will come up, I think in laying out Accidentals and VerticalAxisGroups. You're right that, in general, any time that a collecting grob does some type of organizing, this type of problem will come up. However, there are ways around it. For example, a grob can get the elements array from its vertical alignment or system, sort it from left to right, and trigger callbacks for all grobs to the left. This avoids an overarching positioning grob while still achieving the same effect. For outside-staff positioning, I think you could achieve the same effect. For something more complicated, like TieColumn or AccidentalPlacement, I think it would be much more difficult (and more obfuscated) to do it with callbacks. The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. Not all positioning is side-positioning. True - my goal is to see if all positioning can be articulated this way. For example, ScriptColumn could have used translate_axis, but whoever wrote it made the good decision to use side-position-interface. I think this grob could be eliminated entirely if all scripts in a script column had a function that calculated the side-position-elements grob-array using the sorting algorithm at the heart of script-column.cc. Another way to think of this is that, in general, we'd try to eliminate grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do traffic-coppery. Or, inversely, we'd say that positioning only happens via traffic-cop grobs and no grob has the right to position itself. But it seems like we need to pick one. I gave this some thought a while ago, and concluded that it isn't possible to get rid of the traffic cops (however, I'd be happy to be proven wrong). My eventual decision was to have them everywhere. A grob could suggest its own position using a callback, and if no other grob wanted to override that, then the System grob would take the traffic cop role and set the grob's position to whatever its suggestion was. That way you could write a lot of the positioning code as callbacks, and the cops would only kick in where necessary. There were also explicit dependencies so you could figure out which grob was in charge of positioning for which other grob. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
Han-Wen Nienhuys hanw...@gmail.com writes: In order to do cache invalidation, you will have to construct the reverse graph. If A.x depends on B.y, now A points to B. For proper cache invalidation, if B.y changes, then A.x becomes invalid. This means that A has to store a back-reference to B. Hence all pointers have to be stored both ways (including inverting 1-N relations into N-1 relations), and the both-way links have to be rewritten correctly during line breaking. You can assign a generational count to properties. If the generational count of any dependency is higher than that of the dependent property, it needs to get regenerated. As long as the dependencies don't get lost (and we use arbitrary size integers, resetting for each session), this should be pretty straightforward and not require backwards links. It just requires double-checking your dependencies for change. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 26 sept. 2012, at 21:51, Han-Wen Nienhuys hanw...@gmail.com wrote: On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: Another way to think of this is that, in general, we'd try to eliminate grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do traffic-coppery. Or, inversely, we'd say that positioning only happens via traffic-cop grobs and no grob has the right to position itself. But it seems like we need to pick one. The reason for trafic-coppery is that for many positioning schemes, there is no inherent order that can determine how two objects of the same type (and hence, with the same set of callbacks) should be typeset. A typical example of this is NoteCollision of N NoteColumns. The NoteColumns have to all move in a coordinated way, and the easiest way is to have a function (with local variables) that determines what has to happen. You might get around it, by having a bunch of properties instead, but you'd still have to store those somewhere, ie in the NoteCollision grob. Not necessarily, it'd just make computation time longer. If each note column had other concurrent note columns in its side-position-elements grob-array and we kept the same function from note-column.cc but rewrote it such that instead of translating axes by values it returned the offset value for a given note column, the function would be called N times for N note columns. It's a tradeoff between efficiency and consistency - I'm not sure which one is better, but I'm sure it's possible to eliminate the NoteCollision grob at the cost of redundancy. Agreed, but this is just one instance of translate_axis, which is just one example of a side-effect in lilypond. Is your eventual goal to remove them all? Yes - that'd be great. That'll make explicit dependencies a lot easier to handle - everything can be calculated in terms of callbacks. I'm all for removing side effects, but you can pursue that separately without trying to rewrite the backend. My goal is not to rewrite the backend. My goal is to come up with a generalized way to do multiple passes at many places in the compilation process, and the best way seems to be deleting certain cached properties. I'm all for other ideas, though. To keep the main thing the main thing, the goal is to be able to wipe certain caches, restore the original callbacks, and know that all grobs properties that depended on the restored property will also be recalculated. My idea is an idea for simplifying LilyPond so that this work is easier, but there is no point in doing that if it won't help reach that goal. I'm open to any and all suggestions. Have you thought this through? In order to do cache invalidation, you will have to construct the reverse graph. If A.x depends on B.y, now A points to B. For proper cache invalidation, if B.y changes, then A.x becomes invalid. This means that A has to store a back-reference to B. Hence all pointers have to be stored both ways (including inverting 1-N relations into N-1 relations), and the both-way links have to be rewritten correctly during line breaking. I'm sure this is doable - it'd just be a royal pain. It'd meant that get_property would have to take the me grob as an argument and somehow make the grobs aware of each other. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Marc Hohl m...@hohlart.de writes: Am 26.09.2012 12:23, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... _I_ wouldn't dare competing against Mike in a purity test. Unless you know your way inside/out of pure/impure containers and stuff, it might really be worth a try to check out his debugging suggestion. Ok, ok. To be honest, the pure/impure stuff is not something I understand in full ... In a different vein, I have the impression that we might need to revisit the programming model if we want to have a chance of more than 2 people ever being able to work successfully on/with the backend. I am not sure whether I understand your proposal correctly, but I am working on this for quite a long time, so I don't have strong feelings about rewriting the whole interface again Not the backend of your patch. The backend of LilyPond itself. The thing juggling and arranging grobs on paper and working with their relations. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 22:43, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 26.09.2012 12:23, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... _I_ wouldn't dare competing against Mike in a purity test. Unless you know your way inside/out of pure/impure containers and stuff, it might really be worth a try to check out his debugging suggestion. Ok, ok. To be honest, the pure/impure stuff is not something I understand in full ... In a different vein, I have the impression that we might need to revisit the programming model if we want to have a chance of more than 2 people ever being able to work successfully on/with the backend. I am not sure whether I understand your proposal correctly, but I am working on this for quite a long time, so I don't have strong feelings about rewriting the whole interface again Not the backend of your patch. The backend of LilyPond itself. The thing juggling and arranging grobs on paper and working with their relations. Sorry then, I completely misunderstood you – I just read halfway through the grob-parents thread and found out that you obviously meant another backend than me ;-) Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Call for help with bar lines
Am 26.09.2012 12:34, schrieb m...@mikesolomon.org: On 26 sept. 2012, at 12:07, Marc Hohl m...@hohlart.de wrote: Am 26.09.2012 11:47, schrieb m...@mikesolomon.org: On 26 sept. 2012, at 11:01, Marc Hohl m...@hohlart.de wrote: Can anyone with more knowledge than me give me a hint what's wrong? IIUC correctly, lilypond draws a bar line at the beginning of each line, but in most cases, this is an invisible one. If you look at the results of input/regression/lyrics-spanbar.ly, the whole stuff is shifted that much to the right that lilypond moves the rightmost rest to a new line! I can't believe that a bar line with zero width can be the cause for this... Any hints are highly appreciated! Regards, Marc Hey Marc, I unfortunately don't have much time to help you out, but I can tell you that you are on the right track doing prints to the command line. I would not, however, stash them in lambda functions used as overrides, as this can sometimes interfere with pure properties. Thanks for the hint, but I assume that this is not the case here, where I wrap ly:bar-line::print into a callback ... ly:bar-line::print is a registered pure-print-callback (line 2712 of define-grobs.scm), so when you use a custom callback, LilyPond stops finding pure heights of bar lines. To make sure that pure extents kick in, you'd need to do something like \override BarLine #'print = #my-print-callback \override BarLine #'Y-extent = #(ly:unpure-pure-container ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height grob))) You can check on the CG subchapter on pure properties for more examples. I'll have to do that. On the other hand, it is the x extent that's wrong, and IIUC, this is not influenced by any pure/impure decision? But that's just for the record, because I am pretty sure that Harm found the culprit. Thanks for your help! Marc There are a couple classic things I use, most of which are in grob.cc. In Grob::pure_relative_y_coordinate, before the last return statement, you can put: if (name () == BarLine) print (RELATIVE COORDINATE for BARLINE at spanned rank %d: %4.4f\n, spanned_rank_interval ()[LEFT], out); This can be quite handy, thanks! But back to my original question: can someone please have a quick glimpse at the regtests? Perhaps he can spot the cuprit very easily ... I looked at them and my guess is that the pure extents (and maybe even unpure extents) are being changed, which is why I suggested doing prints to the command line for extents (both X and Y). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] facilitate changes of the (default-) drumStyleTable
2012/9/26 Marc Hohl m...@hohlart.de: I like the idea of giving the user the ability to change only parts of the list without having to rewrite the full list; I think that this concept could be of use in other parts of lilypond as well, Hi Marc, further testing showed a major-problem: Using `hashq-set!' here is too much force brute and will result in an unintended change of lily-internals. I.e. compiling all .ly files in a folder with lilypond *.ly will show the changes in _all_ files, even if \changeDrumStyleTable is _not_ used in a file. \set DrumStaff.drumStyleTable = #(alist-hash-table my-drums) is not that invasive. Nevertheless, IMHO the question about an easy, less intricate method how to change a single value in the predefined drumStyleTable stands as a valid request. -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)
On 2012-09-26 15:32, d...@gnu.org wrote: Reinhold Kainhofer reinh...@kainhofer.com writes: On 26/09/2012 11:26, d...@gnu.org wrote: \once does something entirely different. It does not turn an override into a tweak but rather marks it at being active only at the current timestep. \once applies at a single time, \single applies on a single item. To me as a user, \once\override is used to change the next note (or items attached to it) and \single\tweak is used to change the next item. Both are only roughly equivalent when there is only one item per timestep. \once\override affects _everything_ happening at the same time. Ah, thanks for the explanation. I didn't understand that \single is meant to fix the case where \once applies to multiple items at the same timestep! Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
