Reviewers: Keith,
Message:
On 2012/09/01 23:58:37, Keith wrote:
I might have a test case for you at
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1776
It seems you copy each slur into a "slur-stub", and from those keep
only the
ones with "cross-staff" set. Then when figuring system
Janek Warchoł writes:
> On Sat, Sep 1, 2012 at 6:25 PM, Graham Percival
> wrote:
>> \postfix: c2 d\p is unchanged
>> /prefix: for music functions like c2 /parenthesize d
>> .neutral: for commands which aren't attached to notes
>
> there would be confusion with augmentation dots, and poss
On Fri, Aug 31, 2012 at 5:58 PM, Han-Wen Nienhuys wrote:
> On Fri, Aug 31, 2012 at 8:24 AM, Janek Warchoł
> wrote:
>> i can confirm that the beaming remained virtually
>> unchanged since LilyPond 2.6 (see attached "old vesions").
>> I've also checked LilyPond 2.16, and in some cases the beaming
On Sun, Sep 2, 2012 at 1:57 AM, Janek Warchoł wrote:
> - GOP-IDEA for posting food-for-thought,
> don't-discuss-yet-it's-just-to-let-you-know-what's-in-my-mind ideas,
> - GOP-DISC for discussing details in an orderly manner,
> - GOP-PROP for actual proposals (these emails should be read and voted
I might have a test case for you at
http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1776
It seems you copy each slur into a "slur-stub", and from those keep only
the ones with "cross-staff" set. Then when figuring system skylines you
insert all Grobs with the slur-stub-interface into the s
On Sat, Sep 1, 2012 at 9:39 PM, Graham Percival
wrote:
> On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
>> Frankly, the current syntax discussions are leading nowhere.
>> Brainstorming is fine, but pretty useless if there is no target or topic
>> other than "let's make things diffe
On Sat, Sep 1, 2012 at 6:25 PM, Graham Percival
wrote:
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attached to notes
there would be confusion with augmentation dots, and possibly with
rational numbers.
On S
On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup wrote:
> Graham Percival writes:
>> So far I don't feel that the discussion has been very fruitful.
>
> And it will not be fruitful in the near future. One reason is that I am
> basically the only one seriously working on the parser right now, and I
lgtm
http://codereview.appspot.com/6494071/diff/1/lily/time-signature.cc
File lily/time-signature.cc (left):
http://codereview.appspot.com/6494071/diff/1/lily/time-signature.cc#oldcode26
lily/time-signature.cc:26: #include "staff-symbol.hh"
no longer need "staff-symbol.hh"
http://codereview.ap
Han-Wen Nienhuys gmail.com> writes:
> I am actually supportive of allowing digits in identifiers, it has
> irked me for years that we could not get it to work. I vaguely recall
> you implemented this in 2.16 already, but I guess I am mistaken?
>
If we abuse the syntax, we can write
"vn1M4m34
Le 1 sept. 2012 à 18:25, Graham Percival a écrit :
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for c
On Thu, Aug 30, 2012 at 11:27 AM, David Kastrup wrote:
> With nereides, one problem actually is that the padding is vertical
> padding. This makes the following line pairs considered as having the
> same distance:
>
> -
> -
>
> \\
> \\
> \\
>
Am 01.09.2012 22:22, schrieb David Kastrup:
pls writes:
There must have been a change in default with regards to the
visibility of string numbers between 2.15.20 and the current
version. In 2.15.20 it was still possible to add string numbers to
notes (e.g. c'4\4) without them showing up in the
Am 01.09.2012 um 22:22 schrieb David Kastrup:
> pls writes:
>
>> There must have been a change in default with regards to the
>> visibility of string numbers between 2.15.20 and the current
>> version. In 2.15.20 it was still possible to add string numbers to
>> notes (e.g. c'4\4) without them
On 1 September 2012 18:25, Graham Percival wrote:
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for com
> info: $(INFO_FILES)
> @echo export LILYPOND_DATADIR=$(LILYPOND_DATADIR)
> @echo export PYTHONPATH=$(PYTHONPATH)
>
> which sends stuff to the terminal during a make doc run. I've read the make
> manual but still can't decide whether this actually does anything, or merely
> echoes information to t
Am 01.09.2012 22:02, schrieb pls:
There must have been a change in default with regards to the visibility of string
numbers between 2.15.20 and the current version. In 2.15.20 it was still possible to
add string numbers to notes (e.g. c'4\4) without them showing up in the score. This
was very
pls writes:
> There must have been a change in default with regards to the
> visibility of string numbers between 2.15.20 and the current
> version. In 2.15.20 it was still possible to add string numbers to
> notes (e.g. c'4\4) without them showing up in the score.
But they showed up when writin
Graham Percival writes:
> On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Continuing to brainstorm on the problem of it not being obvious to
>> > which note a particular \command refers to, what if we used:
>> >
>> > \postfix: c2 d\p is un
There must have been a change in default with regards to the visibility of
string numbers between 2.15.20 and the current version. In 2.15.20 it was still
possible to add string numbers to notes (e.g. c'4\4) without them showing up in
the score. This was very handy in order to automatically spec
Am 01.09.2012 21:39, schrieb Graham Percival:
[...]
At Waltrop, you only heard about one quarter of the ideas that Janek had.
I think that Janek has spent quite a lot of time collecting and formulating
his ideas. What about posting his ideas and use them as a discussion base
in terms of usabi
On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Continuing to brainstorm on the problem of it not being obvious to
> > which note a particular \command refers to, what if we used:
> >
> > \postfix: c2 d\p is unchanged
> > /prefix: for music fun
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>
>> You can also argue that people that know what a duration is, and how to
>> use it will be better served by writing Scheme directly. Because a
>> duration is complex enough in Scheme already.
>
> The whole idea
Graham Percival writes:
> Continuing to brainstorm on the problem of it not being obvious to
> which note a particular \command refers to, what if we used:
>
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attach
Han-Wen Nienhuys writes:
> it seems that we are still inventing our syntactically complex
> programming language, which ironically is implemented on top of GUILE
> Scheme.
There is no irony involved. Scheme's syntax is computer-friendly,
LilyPond's syntax is user-friendly. If they did not serv
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>
>>> Vectors don't make sense unless you give a mechanism to map/iterate
>>> over them, ie something along the lines of
>>>
>>> (make-parallel-music (vector->list
>>> (map (lambda (x) (add-new-context "Staff" x))
Il 28/08/2012 16:41, John Mandereau ha scritto:
2012/8/27 Federico Bruni:
I've stumbled again on this error while running make doc:
http://lilypond-translations.3384276.n2.nabble.com/make-doc-error-cannot-import-name-TexModule-td7467314.html
Here's the output:
cd ./out-www&& dblatex suffix-l
On Sat, Sep 01, 2012 at 05:47:39PM +0100, Phil Holmes wrote:
> This fixes the problem:
>
>progress (str(imp.load_source ("book_custom_package%s" % nr, i)))
>
> and makes sense to me: imp.load_source retutrns a ; str()
> converts that to a string which progress can handle. Print could
> p
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: ;
Sent: Saturday, September 01, 2012 4:56 PM
Subject: Re: Reduce output from scripts during make doc (issue 6499068)
On Sat, Sep 01, 2012 at 04:54:47PM +0100, Phil Holmes wrote:
Unfortunately it breaks make test. A
> What about this: A command used as a prefix needs to enclose its
> argument in braces (or whatever). Commands like \relative already
> look similar.
>
> postfix: c2 d\p
> prefix: c2 \parenthesize { d }
Uh, oh, please forget this. It would be great if it could be that
simple :-/
We
> \postfix: c2 d\p is unchanged
> /prefix: for music functions like c2 /parenthesize d
> .neutral: for commands which aren't attached to notes, such
> as .clef or .times.
I don't like that very much. What about this: A command used as a
prefix needs to enclose its argument in braces (o
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .time
Am 31.08.2012 02:05, schrieb thomasmorle...@googlemail.com:
http://codereview.appspot.com/6498052/diff/10001/Documentation/snippets/printing-a-repeat-sign-at-the-beginning-of-a-piece.ly
File
Documentation/snippets/printing-a-repeat-sign-at-the-beginning-of-a-piece.ly
(right):
http://coder
Hi Arnold, Phil and David,
thanks for your answers!
Just for the record: the image I sent is the actual Lilypond
output.
I think the easiest way to handle volta brackets
is either using the anchor calculated by bar-line::calc-anchor
or the left and right edge of the (span) bar, i.e. the bar ste
On Sat, Sep 01, 2012 at 04:54:47PM +0100, Phil Holmes wrote:
> Unfortunately it breaks make test. Apologies - I was sure I'd
> tested it with make doc, but must have omitted it with this one. Is
> the best option to revert the commit in staging, or is there a
> better way?
The way is to delete o
- Original Message -
From:
To:
Cc: ;
Sent: Saturday, September 01, 2012 4:30 PM
Subject: Reduce output from scripts during make doc (issue 6499068)
LGTM, please push directly to staging
http://codereview.appspot.com/6499068/
Unfortunately it breaks make test. Apologies - I was
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
>>
>>> It is reasonably easy to state "this will have to go". However, I have
>>> not so far attempted a replacement since I am still fuzzy on
>>> assignmen
Begin LilyPond compile, commit: ecf25f33aa4c02efda0694280e956c147f5006ae
Merged staging, now at: 5a3e62fdcaa01c295f2c5a5d1d47f81752ac7e7f
Success:./autogen.sh --noconfigure
Success:../configure --disable-optimising
Success:
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
>> Vectors don't make sense unless you give a mechanism to map/iterate
>> over them, ie something along the lines of
>>
>> (make-parallel-music (vector->list
>> (map (lambda (x) (add-new-context "Staff" x)) violin)))
>
> It would be easy eno
Am 31.08.2012 19:19, schrieb Jan Nieuwenhuizen:
Han-Wen Nienhuys writes:
Manual writers: can we make up our minds here? I've always been
against frivolous syntax for shortcuts (one example in particular is
the "q" for repetition). Why do we put in "q" for users to save some
keystrokes, and at
Graham Percival writes:
> 1. declare the 2.16.0 syntax absolutely frozen (possibly with the
> exception of property names and scheme). Reject absolutely all
> patches to lily/parser.yy
That does not make sense as long as we don't have a reasonably coherent
starting point for freezing.
> 2. hav
I've just realized that in this snippet the hidden notes, used to make
the grace slides, have a string number which is printed (and it shouldn't).
I think that we should just remove /3 from the notes in the grace blocks
(see file attached).
All the examples in the doc using Staff + TabStaff sho
On Sat, Sep 1, 2012 at 12:27 PM, David Kastrup wrote:
>>> And you don't want to have him remember different function names for
>>> each argument list variation.
>>
>> Here is another premise that hasn't been agreed on explicitly. I would
>> nowadays hold that it is actually better to have differen
LGTM, please push directly to staging
http://codereview.appspot.com/6499068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 5:37 AM, David Kastrup wrote:
>
>> As one example for an analogous use of optional arguments, consider
>>
>> \tweak Accidental #'color #red cis4
>>
>> \tweak has always been a music function. Being able to use a syntax
>> fairly analogous to tha
Am 31.08.2012 11:58, schrieb John Mandereau:
Il giorno gio, 30/08/2012 alle 09.29 +0200, Marc Hohl ha scritto:
Am 30.08.2012 06:46, schrieb lilyp...@googlecode.com:
Comment #6 on issue 2790 by grenoui...@lilynet.net: Patch: bar-line
interface part 2/2
http://code.google.com/p/lilypond/issues/de
On Sat, Sep 01, 2012 at 12:07:07PM -0300, Han-Wen Nienhuys wrote:
> This is also the danger of having broad discussions over syntax.
...
> on the basis of how "intuitive" it looks. See also
> http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
Yes, that was the whole reason why I wanted to
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
>
>> It is reasonably easy to state "this will have to go". However, I have
>> not so far attempted a replacement since I am still fuzzy on
>> assignments. Basically I want to have the equivalent of procedures with
Han-Wen Nienhuys writes:
> On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys wrote:
>
\tempo \markup{ Presto } 4. = 172 ~ 188
c1 c
}
>>>
>>> While this might be a mess for the parser to sort out it is perfectly
>>> understandable for a musician trying to write his/her music.
>
>
On Sat, Sep 1, 2012 at 5:37 AM, David Kastrup wrote:
>>> I had to let this sink in for a bit, since I had completely missed
>>> that a patch doing optional music arguments had went in. Had I noticed
>>> in time, I probably would have complained (and we might have ended up
>>> in a flamewar).
>>
>
Documentation: GNUmakefile has the following:
info: $(INFO_FILES)
@echo export LILYPOND_DATADIR=$(LILYPOND_DATADIR)
@echo export PYTHONPATH=$(PYTHONPATH)
which sends stuff to the terminal during a make doc run. I've read the make
manual but still can't decide whether this actually does anythin
On Sat, Sep 1, 2012 at 8:11 AM, Graham Percival
wrote:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group
On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys wrote:
>>> \tempo \markup{ Presto } 4. = 172 ~ 188
>>> c1 c
>>> }
>>
>> While this might be a mess for the parser to sort out it is perfectly
>> understandable for a musician trying to write his/her music.
This is also the danger of having broa
On Tue, Aug 28, 2012 at 08:17:58AM +0100, Graham Percival wrote:
> Let's make a list of tasks we want, then make sure that we're
> doing them on sensible computers.
I've moved this list to github:
https://github.com/gperciva/lilypond-extra/blob/master/misc/computing-power.txt
- Graham
__
On Fri, Aug 31, 2012 at 12:24:39PM +0200, John Mandereau wrote:
> Il giorno gio, 30/08/2012 alle 18.15 +0100, James ha scritto:
> > We have two of config files.
> > lilypond-patchy-config and .msmtp-patchy (used by patchy staging).
>
> I sent you a sample config file, if the instructions work for
On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>>> I have become convinced that optional, unnamed arguments are not a
>>> happy design decision, in any language. In Lily it's particularly
>>> pr
Han-Wen Nienhuys writes:
> I think "a musician" is red herring word. There are many people that
> think that Lily is too complex for "musicians" already, and many
> others (including me) that think that musicians are smart people and
> can learn rules, especially if they are simple and consistent
On Sat, Sep 1, 2012 at 8:57 AM, Trevor Daniels wrote:
>
> Graham Percival wrote Saturday, September 01, 2012 12:11 PM
>
>> I agree; it's a mess. Let's examine David's most hated example:
>>
>> \version "2.15.0"
>> {
>> \tempo 4 = 60
>> c1 c
>> \tempo 4. = 60 ~ 72
>> c1 c
>> \tempo "Andante"
On Mon, Aug 27, 2012 at 07:01:56PM +0200, Jan Nieuwenhuizen wrote:
> Graham Percival writes:
>
> > whoops, I hadn't thought about it -- at 19:00 UTC this Tuesday,
> > I'll be either at Heathrow airport or in the air flying to
> > Glasgow. Shall we start next week (in Sep)? or maybe if at least
>
On Thu, Aug 30, 2012 at 01:40:29AM +0200, John Mandereau wrote:
> If you don't include the "touch all manual pages" in your commit, GUB
> build of tools::texinfo shall fail for every system, whether help2man is
> available system-wide or not, as in this case Texinfo build does not
> look for binari
On Fri, Aug 31, 2012 at 11:18:54PM +0100, James wrote:
> On 31 August 2012 22:35, John Mandereau wrote:
> > I can change Patchy so that it compresses the show-XXX tree in a xz
> > file, send it to Grenouille via SFTP,
would it be possible to do this over rsync, to allow resuming a
broken connecti
Graham Percival writes:
> On Sat, Sep 01, 2012 at 01:27:23PM +0200, David Kastrup wrote:
>> 172 ~ 188 is an abomination anyway. It would be reasonably
>> straightforward to accept a pair here, like #(172 . 188) or
>> 172/188 which is equivalent.
>
> Straightforward from a programming perspective
Graham Percival wrote Saturday, September 01, 2012 12:11 PM
> I agree; it's a mess. Let's examine David's most hated example:
>
> \version "2.15.0"
> {
> \tempo 4 = 60
> c1 c
> \tempo 4. = 60 ~ 72
> c1 c
> \tempo "Andante"
> c1 c
> \tempo "Allegro" 4 = 120
> c1 c
> \tempo "Allegro" 4 =
On Sat, Sep 01, 2012 at 01:27:23PM +0200, David Kastrup wrote:
> 172 ~ 188 is an abomination anyway. It would be reasonably
> straightforward to accept a pair here, like #(172 . 188) or
> 172/188 which is equivalent.
Straightforward from a programming perspective, but as far as
printed music is c
Graham Percival writes:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> problematic, since we don't group function parameters.
>
> I ag
On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
> I have become convinced that optional, unnamed arguments are not a
> happy design decision, in any language. In Lily it's particularly
> problematic, since we don't group function parameters.
I agree; it's a mess. Let's examine D
On Fri, Aug 31, 2012 at 11:25:24PM +0100, James wrote:
> Just to reiterate, test-patchy is pretty dumb so when entering
> manually links to rietveld can you make sure there is no punctuation
> near or around the link to the code to download to test.
Yes.
Interested parties could work on
https://gi
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>>> Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in
>>> unreadability; these are the only two languages I know that can have
>>> functions look like statements.
>>
>> Hm? Scheme, C, C++, awk, Lua...
>
> C
David Kastrup writes:
>> Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in
>> unreadability; these are the only two languages I know that can have
>> functions look like statements.
>
> Hm? Scheme, C, C++, awk, Lua...
C Perl Ly
postfix: fo
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup wrote:
Is there a complete proposal of what is on the drawing board? Barring
that, is there a list of (perceived) problems in the current
syntax/parser?
>>>
>>> The possible value
70 matches
Mail list logo
