On Mon, 24 Sep 2012 08:40:50 -0700, Janek Warchoł
wrote:
I imagine that we could have arbitrary integer durations intended for
use with straightforward tuplets, while continue using explicit \times
command for complicated (for example nested) ones.
Try it out. Enter some Debussy using 12th-
2012/9/24 Janek Warchoł :
> I also think that it will take more than a week to collect all user feedback.
Likely.
> Also, are we going to do something like this on general user list?
Why not?
2012/9/24 Xavier Scheuer :
> IMHO the discussion should not focus only on "beginners", as there are
2012/9/24 Janek Warchoł :
> Good idea. For starters:
>
> 1) what do you find confusing in LilyPond syntax? For example, are
> you sometimes uncertain in what order should you write code elements,
> or what capitalization to use?
> 2) is there anything particularly unreadable or cryptic in LilyPon
2012/9/24 Janek Warchoł :
> Seriously though, i think this syntax would be very useful for
> algorithmic composers and computer programs manipulating Lily code.
> Another advantage is code readability and ease of copying it (shall i
> elaborate?)
>
> Besides, it's not like we would loose any functi
On 23/09/12 15:58, David Kastrup wrote:
With the separately discussed "isolated durations are pitch-less
NoteEvent in noteentry", you could use arguments like
{ 8 ~ 8. } = { 4 }
and such music arguments would get passed through a \score markup using
a specific TempoStaff without stafflines and wi
Hi all,
On Mon, Sep 17, 2012 at 11:28 PM, Janek Warchoł
wrote:
> James,
>
>> [...]
>
> Now i feel offended, both as a user and a developer.
> At first i was going to write a long reply to your email, but then i
> thougt that it would only result in more misunderstandings. Can we
> chat, either u
On Mon, Sep 24, 2012 at 6:27 PM, David Kastrup wrote:
> Janek Warchoł writes:
>
>> Interesting. Apart from which one would produce tuplet brackets,
>> maybe *x/y notation would allow us to distinguish between
>>
>> \times 2/3 { b16 b b }
>> \times 2/3 { b16 b b }
>>
>> and
>>
>> \times 4/6
David,
On Monday, September 24, 2012, David Kastrup wrote:
>
> "Phil Holmes" writes:
> > Not necessarily. An alternative would be:
> >
> > \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
> > \beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
> >
> > which would set the beam patterns for both the current time signatu
On Monday, September 24, 2012, David Kastrup wrote:
> We get about 1 request per month of the kind in
> http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00600.html>
> "I can't get the automated beams to look like the manual beams in
> measure 1".
>
> Can we just get a command
> \beaming {
On 24 September 2012 08:02, David Kastrup wrote:
>
> We get about 1 request per month of the kind in
> http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00600.html>
> "I can't get the automated beams to look like the manual beams in
> measure 1".
>
> Can we just get a command
> \beaming {
On 23 September 2012 19:18, Thomas Morley wrote:
> Hi Xavier,
>
> Eluze suggested to contact you, being a native french-speaker.
>
> Would you like to open a thread or start a poll on the
> french-user-list about the topic described below in the quoted
> section?
Hi everyone,
Yes, I saw this thr
Am 24.09.2012 12:55, schrieb David Kastrup:
Marc Hohl writes:
Am 24.09.2012 12:04, schrieb lilyp...@googlecode.com:
Status: New
Owner:
Labels: Type-Enhancement Patch-new
New issue 2856 by d...@gnu.org: Patch: Get along with use of
grob-property instead of grob-property-path in overrides
Werner LEMBERG writes:
> \beaming 5/16 { 16[ 16] 16[[ 16] 16] }
>>
>> The original intent was for duplicate requests in most of these
>> cases to be ignored, so you could combine multiple identifiers into
>> chords, eg.
>>
>> vOne = { c8[ d] }
>> vTwo = { e8[ f] }
>>
>> forScore = \new Vo
Am 24.09.2012 13:49, schrieb David Kastrup:
"Phil Holmes" writes:
From: "Werner LEMBERG"
Again, with the suggestion above, this is not needed. This part of
the rule is that the bracketed note lengths must form a complete bar
in the current time signature. If not, an error is thrown.
Here
When you say "paper of all available sizes" I don't understand
why changing the paper size should have any effect.
Could you explain?
Sorry, bad wording. I mean the appearance of all available sizes
printed out on paper.
Is there guidance on the the correct way to calculate
the parameters to
- Original Message -
From:
To: ; ; ;
;
Cc: ;
Sent: Monday, September 24, 2012 6:34 PM
Subject: Re: Fixes position of mensural c clef (issue 6503091)
The glyph shape is OK, thanks. Have you tested the appearance on paper
of all available sizes, using a 300 or 600dpi printer?
No.
The glyph shape is OK, thanks. Have you tested the appearance on paper
of all available sizes, using a 300 or 600dpi printer?
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (left):
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-cle
\beaming 5/16 { 16[ 16] 16[[ 16] 16] }
>
> The original intent was for duplicate requests in most of these
> cases to be ignored, so you could combine multiple identifiers into
> chords, eg.
>
> vOne = { c8[ d] }
> vTwo = { e8[ f] }
>
> forScore = \new Voice {
> << \vOne \vTwo >>
> }
>
>
Graham Percival writes:
> On Sat, Sep 22, 2012 at 07:32:20AM +, d...@gnu.org wrote:
>> Nobody can be bothered enough to even comment.
>
> Yes, that is a problem. I wish that more developers looked at the
> countdown and did reviews. For example, many of Keith's changes
> in the past month h
On Mon, Sep 24, 2012 at 3:33 PM, Werner LEMBERG wrote:
>>> \beaming 5/16 { 16[ 16] 16[[ 16] 16] }
>>>
>>> +++++
>>> ++++ -+
>>> |||||
>>>
>>
>> First we would need to get this manner of specifying subbeams work
>> properly in manually beamed m
"Sue Daniels" writes:
> Graham Percival wrote Sunday, September 23, 2012 7:50 AM
>
>> On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
>>
>>> So I repeat my proposal again: a developer *must* include
>>> regression tests, he *should* do the doc work, but if he feels
>>> not very comfort
Janek Warchoł writes:
> Interesting. Apart from which one would produce tuplet brackets,
> maybe *x/y notation would allow us to distinguish between
>
> \times 2/3 { b16 b b }
> \times 2/3 { b16 b b }
>
> and
>
> \times 4/6 { b16 b b b b b }
>
> by writing { b16*2/3 b b b b b } and { b16*4
On Mon, Sep 24, 2012 at 3:24 PM, David Kastrup wrote:
> James writes:
>> Is that you on the right?
>
> I can't possibly answer that question without having to remove the
> [talk] tag.
You mean that the answer would have the implied consequence of leading
to changes in LilyPond? Or that you need
Please review, including image on the tracker.
http://codereview.appspot.com/6503091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Mon, Sep 24, 2012 at 2:24 PM, Francisco Vila wrote:
> 2012/9/24 Janek Warchoł :
>> I also think that it will take more than a week to collect all user feedback.
>
> What about making a short survey in English which we'll translate for
> our lists? That would give coherency to the responses.
Go
Hi all,
First thing that i'd like to say about Graham's proposal is that
supporting arbitrary integer durations doesn't mean we have to abolish
\times (or \tuplet, if we decide to rename it).
I imagine that we could have arbitrary integer durations intended for
use with straightforward tuplets, w
Sorry - i've misclicked something. First part of my message should read:
I think that i'm best at analyzing stuff and making good bug reports,
but if necessary, i'm willing to learn how to improve parser myself.
I'd just like us to finish the big picture/plan before i start
learning.
apologies,
On Sun, Sep 23, 2012 at 8:54 AM, Graham Percival
wrote:
> There is some concern about users without technical knowledge
> talking about the language. To those concerns, I quote
>
> If you want to build a ship, don’t drum up the men to gather
> wood, divide the work and give orders. Instead, te
Graham Percival wrote Sunday, September 23, 2012 7:50 AM
> On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
>
>> So I repeat my proposal again: a developer *must* include
>> regression tests, he *should* do the doc work, but if he feels
>> not very comfortable at writing some paragraphs
Graham Percival wrote Sunday, September 23, 2012 3:20 AM
> On Sat, Sep 15, 2012 at 10:25:17PM +0200, David Kastrup wrote:
>
>> I don't want to differentiate between predefined and user-defined
>> commands.
>
> That's certainly a consistent view to take, but it might be worth
> discussing that f
- Original Message -
From:
To: ; ; ;
;
Cc: ;
Sent: Monday, September 24, 2012 2:30 PM
Subject: Re: Fixes position of mensural c clef (issue 6503091)
Well done! It's not there yet due to some bugs I believe, but besides
this the code looks OK.
http://codereview.appspot.com/650309
Werner LEMBERG writes:
>>> Yes. I would go even one step further, defining subbeams also.
>>>
>>> Example:
>>>
>>> \beaming 5/16 { 16[ 16] 16[[ 16] 16] }
>>>
>>> +++++
>>> ++++ -+
>>> |||||
>>>
>>
>> First we would need to get this manner of
>> Yes. I would go even one step further, defining subbeams also.
>>
>> Example:
>>
>> \beaming 5/16 { 16[ 16] 16[[ 16] 16] }
>>
>> +++++
>> ++++ -+
>> |||||
>>
>
> First we would need to get this manner of specifying subbeams work
> properly
Well done! It's not there yet due to some bugs I believe, but besides
this the code looks OK.
http://codereview.appspot.com/6503091/diff/10001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):
http://codereview.appspot.com/6503091/diff/10001/mf/parmesan-clefs.mf#newcode764
mf/parmesan-cl
James writes:
> On 24 September 2012 13:00, David Kastrup wrote:
>>
>> Seemed too fitting somehow to pass up.
>>
>> http://xkcd.com/1112/>
>
> Is that you on the right?
I can't possibly answer that question without having to remove the
[talk] tag.
--
David Kastrup
___
Werner LEMBERG writes:
This could probably be
\beaming {8[ 8] 8 8 8[ 8 8 8] }
So we have another result of GLISS.
>>>
>>> Actually, I like David's original proposal better if the semantics
>>> of the construction is to both typeset the particular music and to
>>> use i
On Mon, Sep 24, 2012 at 3:00 PM, James wrote:
> On 24 September 2012 13:00, David Kastrup wrote:
>> Seemed too fitting somehow to pass up.
>> http://xkcd.com/1112/>
>
> Is that you on the right?
>
> ;)
I was going to ask the same question!
Janek
___
On 24 September 2012 13:00, David Kastrup wrote:
>
> Seemed too fitting somehow to pass up.
>
> http://xkcd.com/1112/>
>
> --
> David Kastrup
Is that you on the right?
;)
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.
>>> This could probably be
>>>
>>>\beaming {8[ 8] 8 8 8[ 8 8 8] }
>>>
>>> So we have another result of GLISS.
>>
>> Actually, I like David's original proposal better if the semantics
>> of the construction is to both typeset the particular music and to
>> use it as a template for a beaming rul
Please review. I can provide an image on the tracker if required.
http://codereview.appspot.com/6503091/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
>> This could probably be
>>
>>\beaming {8[ 8] 8 8 8[ 8 8 8] }
>>
>> So we have another result of GLISS.
>
> Actually, I like David's original proposal better if the semantics
> of the construction is to both typeset the particular music and to
> use it as a template for a beaming rule.
Hmm, n
Mats Bengtsson writes:
> On 09/24/2012 10:55 AM, lilypond-devel-requ...@gnu.org wrote:
\beaming { c8[ c] c r c[ c c c] }
>>> >
>>> >Ouch. Of course.
>>> >
>>but yes, that would be great.
>> This could probably be
>>
>>\beaming {8[ 8] 8 8 8[ 8 8 8] }
>>
>> So we have another resu
On 09/24/2012 10:55 AM, lilypond-devel-requ...@gnu.org wrote:
\beaming { c8[ c] c r c[ c c c] }
>
>Ouch. Of course.
>
>>but yes, that would be great.
This could probably be
\beaming {8[ 8] 8 8 8[ 8 8 8] }
So we have another result of GLISS.
Actually, I like David's original proposal
Janek Warchoł writes:
> On Sun, Sep 23, 2012 at 11:21 PM, Graham Percival
> wrote:
>> Nothing's stopping us from having the normal \commands (including
>> both predefs and user-created and user-redefined), along with
>> $commands (which is completely empty and available for any user
>> definitio
2012/9/24 Janek Warchoł :
> I also think that it will take more than a week to collect all user feedback.
What about making a short survey in English which we'll translate for
our lists? That would give coherency to the responses.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadaj
On Sun, Sep 23, 2012 at 11:21 PM, Graham Percival
wrote:
> Nothing's stopping us from having the normal \commands (including
> both predefs and user-created and user-redefined), along with
> $commands (which is completely empty and available for any user
> definitions).
I see one thing that might
On Sun, Sep 23, 2012 at 3:08 PM, Thomas Morley
wrote:
> So I thought it might be an idea to start threads on national
> lists/forums about it and after same time (a week?) collect and list
> the complains, ideas, proposals.
I think this is a good idea.
I suggest to ask more for complaints than f
Seemed too fitting somehow to pass up.
http://xkcd.com/1112/>
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
"Phil Holmes" writes:
> From: "Werner LEMBERG"
>
>>> Again, with the suggestion above, this is not needed. This part of
>>> the rule is that the bracketed note lengths must form a complete bar
>>> in the current time signature. If not, an error is thrown.
>>
>> Here, I go with David. Just thi
"Phil Holmes" writes:
> From: "David Kastrup"
>
>> Werner LEMBERG writes:
>>
> \beaming { c8[ c] c r c[ c c c] }
Ouch. Of course.
> but yes, that would be great.
>>>
>>> This could probably be
>>>
>>> \beaming {8[ 8] 8 8 8[ 8 8 8] }
>>
>> Uh no. You need the rest, o
On Mon, Sep 24, 2012 at 12:59 PM, David Kastrup wrote:
> Janek Warchoł writes:
>> whoah, that's quite a difference.
>> +1 for getting rid of this strange behavior.
>
> Actually, I was proposing extending "this strange behavior" (processing
> music as a whole when it gets added to a score, inciden
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Monday, September 24, 2012 12:24 PM
Subject: Re: Feature request
Again, with the suggestion above, this is not needed. This part of
the rule is that the bracketed note lengths must form a complete bar
in the current time s
>>> \beaming {8[ 8] 8 8 8[ 8 8 8] }
>>
>> Uh no. You need the rest, or you need to write something like
>> \beaming {4 8[ 8] 8[ 8 8 8]}
>
> Don't think so. With this command, it would seem that the rule is
> "delete all previous autobeaming rules and only autobeam in the
> pattern set with manu
Janek Warchoł writes:
> On Sun, Sep 23, 2012 at 2:54 PM, David Kastrup wrote:
>> Janek Warchoł writes:
>>> I think David doesn't meant that we should remove \addlyrics
>>> whatsoever. I suppose that \addlyrics would just have to be
>>> redesigned. David, am i right?
>>
>> It would make some s
Marc Hohl writes:
> Am 24.09.2012 12:04, schrieb lilyp...@googlecode.com:
>> Status: New
>> Owner:
>> Labels: Type-Enhancement Patch-new
>>
>> New issue 2856 by d...@gnu.org: Patch: Get along with use of
>> grob-property instead of grob-property-path in overrides
>> http://code.google.com/p/
Hello,
On 24 September 2012 09:22, Jan Nieuwenhuizen wrote:
> David Kastrup writes:
>
>> I think it was during the documentation of the footnote stuff that we
>> came up with several examples (including use of s1*0/<>) that made clear
>> that we were better off refining the code rather than the d
On Sun, Sep 23, 2012 at 2:54 PM, David Kastrup wrote:
> Janek Warchoł writes:
>> I think David doesn't meant that we should remove \addlyrics
>> whatsoever. I suppose that \addlyrics would just have to be
>> redesigned. David, am i right?
>
> It would make some sense. At the current point of t
- Original Message -
From: "David Kastrup"
To: "Werner LEMBERG"
Cc:
Sent: Monday, September 24, 2012 8:44 AM
Subject: Re: Feature request
Werner LEMBERG writes:
\beaming { c8[ c] c r c[ c c c] }
Ouch. Of course.
but yes, that would be great.
This could probably be
\be
Am 24.09.2012 12:04, schrieb lilyp...@googlecode.com:
Status: New
Owner:
Labels: Type-Enhancement Patch-new
New issue 2856 by d...@gnu.org: Patch: Get along with use of
grob-property instead of grob-property-path in overrides
http://code.google.com/p/lilypond/issues/detail?id=2856
Get al
Werner LEMBERG writes:
>>> \beaming { c8[ c] c r c[ c c c] }
>>
>> Ouch. Of course.
>>
>>> but yes, that would be great.
>
> This could probably be
>
> \beaming {8[ 8] 8 8 8[ 8 8 8] }
Uh no. You need the rest, or you need to write something like
\beaming {4 8[ 8] 8[ 8 8 8]}
And where th
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Sunday, September 23, 2012 8:03 PM
Subject: Re: GUB commands not running
On Sun, Sep 23, 2012 at 11:55:51AM +0100, Phil Holmes wrote:
but if someone who is familiar with GUB could make a guess as to wh
Am 24.09.2012 08:25, schrieb Werner LEMBERG:
\beaming { c8[ c] c r c[ c c c] }
Ouch. Of course.
but yes, that would be great.
This could probably be
\beaming {8[ 8] 8 8 8[ 8 8 8] }
+1
So we have another result of GLISS.
Werner
___
2012/9/24 David Kastrup :
> Benkő Pál writes:
>> does anybody has a similar way (not a function) of marking just the first
>> note with a cautionary accidental?
>
> This is probably somewhat tongue-in-cheek, but try
>
>
> {
> \key fis\major
> dis4
> \once\accidentalStyle teaching
> \repeat
Benkő Pál writes:
> 2012/9/24 Keith OHara :
>> Graham Percival percival-music.ca> writes:
>>
>>> Although mathematicians and programmers are quite
>>> comfortable with contains with 0 items inside them, this is not a
>>> particularly intuitive concept (just look at the concept of zero
>>> in t
2012/9/24 Keith OHara :
> Graham Percival percival-music.ca> writes:
>
>> Although mathematicians and programmers are quite
>> comfortable with contains with 0 items inside them, this is not a
>> particularly intuitive concept (just look at the concept of zero
>> in the history of mathematics!)
Reviewers: Keith,
Message:
On 2012/09/24 06:34:00, Keith wrote:
Works well for me.
You mis-typed something in the description because
> so you can use things like \single\voiceOne c4 .
is not true.
But it is _intended_ to be true. It is just that LilyPond is an
inconsistent heap of g
David Kastrup writes:
> I think it was during the documentation of the footnote stuff that we
> came up with several examples (including use of s1*0/<>) that made clear
> that we were better off refining the code rather than the documentation.
>
> And that's fine. Changing code because it would b
67 matches
Mail list logo
