Sven Axelsson writes:
> On 3 March 2017 at 11:53, Andrew Bernard wrote:
>
>> Hi Sven,
>>
>> Graces are a bit subtle. Try this:
>>
>> \version "2.19.56"
>>
>> \relative c'' {
>> \repeat volta 2 {
>> c8. c16 c4 c2 |
>> }
>> \alternative {
>> { \grace { c32 } c8. c16 c4 c2 | }
>>
On 3 March 2017 at 11:53, Andrew Bernard wrote:
> Hi Sven,
>
> Graces are a bit subtle. Try this:
>
> \version "2.19.56"
>
> \relative c'' {
> \repeat volta 2 {
> c8. c16 c4 c2 |
> }
> \alternative {
> { \grace { c32 } c8. c16 c4 c2 | }
> { \grace { s32 } c8. c16 c4 c2 | }
> }
2017 at 21:48, Sven Axelsson wrote:
>
> Surely this is a bug? The leading gracenote in the first alternative
> breaks autobeaming for the rest of the piece. I know that gracenotes are a
> little strange in regards to timing, bu
Hi list.
Surely this is a bug? The leading gracenote in the first alternative breaks
autobeaming for the rest of the piece. I know that gracenotes are a little
strange in regards to timing, but this looks simple enough to me.
\version "2.19.56"
\relative c'' {
\repeat vol
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc#newcode361
lily/beaming-pattern.cc:361: }
On 2012/03/21 10:51:29, MikeSol wrote:
My comment has nothing to do wit
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc#newcode361
lily/beaming-pattern.cc:361: }
My comment has nothing to do with your patch but with this function - it
.lowe=datacore@gnu.org] on behalf of
pkx1...@gmail.com [pkx1...@gmail.com]
Sent: 23 April 2011 17:38
To: pkx1...@gmail.com
Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org
Subject: Re: Added @knownissue for cross staffs and autobeaming (issue4440041)
http://codereview.appspot.com/44
http://codereview.appspot.com/4440041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
This is in response to Mike's last entry
http://code.google.com/p/lilypond/issues/detail?id=1612
Please review this at http://codereview.appspot.com/4440041/
Affected files:
M Documentation/notation/rhythms.itely
Index: Documentation/notation/rhythms.itely
diff --
Carl, just wanted to echo Trevor's appreciation for your work. Thanks. :)
Jon
On Sun, Jul 18, 2010 at 8:07 PM, Carl Sorensen wrote:
> On 7/18/10 12:33 PM, "Trevor Daniels" wrote:
>
>> Carl,
>>
>> Just to congratulate you on finally succeeding with this.
>> This will be a great improvement in th
On 7/18/10 12:33 PM, "Trevor Daniels" wrote:
> Carl,
>
> Just to congratulate you on finally succeeding with this.
> This will be a great improvement in the next release.
Thanks, Trevor. It's been fun, but I'm ready to be done with it.
Next step, Issue # 11.
Carl
__
Carl,
Just to congratulate you on finally succeeding with this.
This will be a great improvement in the next release.
Trevor
- Original Message -
From: "Carl Sorensen"
To: "Lily devel"
Sent: Sunday, July 18, 2010 5:39 AM
Subject: Autobeaming code pushed --
On 7/18/10 1:17 AM, "David Kastrup" wrote:
> Writing `/usr/local/tmp/lilypond/Documentation/out/pitches.texi'...
> Processing include: rhythms.itely
> Reading /usr/local/tmp/lilypond/Documentation/out/rhythms.itely...
> Dissecting...lilypond-book.py: error: file not found: subdividing-beams.ly
Carl Sorensen writes:
> I have pushed the new autobeaming code to master.
>
> The build will fail due to old .o files that have been removed.
>
> You will need to do
>
> make bin-clean
>
> or
>
> rm lily/out/*
>
> before compiling.
Processing includ
I have pushed the new autobeaming code to master.
The build will fail due to old .o files that have been removed.
You will need to do
make bin-clean
or
rm lily/out/*
before compiling.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel
On Sat, Jan 02, 2010 at 09:37:55AM -0700, Carl Sorensen wrote:
>
> On 1/2/10 1:51 AM, "Graham Percival" wrote:
>
> > Sorry, I was thinking about \overrideBeamSettings, which has been
> > around for a few months (a year?). You're quite right; there's no
> > reason not to change \overrideTimeSign
Carl Sorensen writes:
> I have received unambiguous guidance from Han-Wen that I should *not*
> add a general capability for doing override/revert for context
> properties, even though that's what you want to be able to do.
>
> I've asked for suggestions for a music function name that would
> acc
On 1/2/10 3:04 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 1/1/10 10:27 AM, "David Kastrup" wrote:
>>
>>> Carl Sorensen writes:
>>>
In my defense, it's because timeSignatureSettings is a special case
of a context property that wants \override and \revert behavior
On 1/2/10 1:51 AM, "Graham Percival" wrote:
> On Sat, Jan 2, 2010 at 8:34 AM, David Kastrup wrote:
>> Graham Percival writes:
>>
only with \overrideTimeSignatureSettings, but not with
\override timeSignatureSettings.
>>>
>>> Yes, it is. Fixing this has been planned for a year.
Carl Sorensen writes:
> On 1/1/10 10:27 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> In my defense, it's because timeSignatureSettings is a special case
>>> of a context property that wants \override and \revert behavior.
>>
>> Which just goes to show that people associate the
On Sat, Jan 2, 2010 at 8:34 AM, David Kastrup wrote:
> Graham Percival writes:
>
>>> only with \overrideTimeSignatureSettings, but not with
>>> \override timeSignatureSettings.
>>
>> Yes, it is. Fixing this has been planned for a year.
>>
>> Why not "just do it" now? Well, we don't have a defi
Reinhold Kainhofer writes:
> Am Samstag, 2. Januar 2010 00:35:16 schrieb Carl Sorensen:
>> On 1/1/10 10:27 AM, "David Kastrup" wrote:
>> > Carl Sorensen writes:
>> >> OK, point taken. I'll come up with a different name for the music
>> >> function. Do you have any suggestions?
>> >>
>> >> How
Graham Percival writes:
> On Fri, Jan 01, 2010 at 02:13:51PM +0100, David Kastrup wrote:
>> "Trevor Daniels" writes:
>>
>> > For varying time signatures changes could still
>> > be made via \overrideTimeSignatureSettings.
>>
>> I consider it a grave user interface mistake to have some things w
Am Samstag, 2. Januar 2010 00:35:16 schrieb Carl Sorensen:
> On 1/1/10 10:27 AM, "David Kastrup" wrote:
> > Carl Sorensen writes:
> >> OK, point taken. I'll come up with a different name for the music
> >> function. Do you have any suggestions?
> >>
> >> How about \pushTimeSignatureSetting and
On 1/1/10 10:27 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 1/1/10 6:13 AM, "David Kastrup" wrote:
>>
>>> "Trevor Daniels" writes:
>>>
For varying time signatures changes could still
be made via \overrideTimeSignatureSettings.
>>>
>>> I consider it a grave user
On Fri, Jan 01, 2010 at 02:13:51PM +0100, David Kastrup wrote:
> "Trevor Daniels" writes:
>
> > For varying time signatures changes could still
> > be made via \overrideTimeSignatureSettings.
>
> I consider it a grave user interface mistake to have some things work
> only with \overrideTimeSigna
Carl Sorensen writes:
> On 1/1/10 6:13 AM, "David Kastrup" wrote:
>
>> "Trevor Daniels" writes:
>>
>>> For varying time signatures changes could still
>>> be made via \overrideTimeSignatureSettings.
>>
>> I consider it a grave user interface mistake to have some things work
>> only with \over
On 1/1/10 6:13 AM, "David Kastrup" wrote:
> "Trevor Daniels" writes:
>
>> For varying time signatures changes could still
>> be made via \overrideTimeSignatureSettings.
>
> I consider it a grave user interface mistake to have some things work
> only with \overrideTimeSignatureSettings, but
perty
>> (probably 'details to avoid namespace pollution, but maybe
>> timeSignatureDefaults) to the TimeSignature grob.
>>
>> Then I can use standard /override and /revert to set the
>> autobeaming rules.
>>
>> What do you think of that idea?
>
&
"Trevor Daniels" writes:
> For varying time signatures changes could still
> be made via \overrideTimeSignatureSettings.
I consider it a grave user interface mistake to have some things work
only with \overrideTimeSignatureSettings, but not with
\override timeSignatureSettings.
It is already b
re grob.
Then I can use standard /override and /revert to set the
autobeaming rules.
What do you think of that idea?
Joe pointed out that TimeSignature was unsuitable as
the beam settings had nothing to do with the appearance
of the time signature. Perhaps a better alternative
would be to defi
e.
>
>> And IIUC, the time signature properties are part of the Timing context, not
>> a Voice context.
>
> yes, I left out the context out of laziness.
>
>>> then you can be as flexible as you want. Are these settings
>>> intrinsically part of the mu
time signature properties are part of the Timing context, not
> a Voice context.
yes, I left out the context out of laziness.
>> then you can be as flexible as you want. Are these settings
>> intrinsically part of the music or part of the translation process?
>
> The time signat
are used in contexts
or grobs that is a smaller price to pay than requiring two different
user level _explanations_.
If you can save yourself the trouble of making your _users_ smarter by
instead making the _code_ smarter, that is well-invested time.
Because user stupidity is diversified and unreliable,
parsing stage, ie. have \time 2/4 expand to
>
> \set timeSigFraction = ..
> \set measureGrouping = ..
> #(set-auto-beaming .. )
Hmm -- I plan to do that. But I need to have per-Voice beaming rules, so I
think the rules need to be a context property.
And IIUC, the time sig
On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen wrote:
Why have we decided that context properties can only be \set, and grob
properties can only be \overridden? In version 2.0 we had two kinds of
properties, layout properties and translation properties. I think that
translat
tead was to have the default be at a higher level context
> (eg. Score), and doing \unset at a lower level (eg. Staff) to restore
> the default.
OK. When I was using 2.0 I didn't understand the internals well enough to
appreciate these nuances. But when I read the docs yesterday, th
ever was a stack-like
behavior for context/translation properties. The suggested mechanism
for this instead was to have the default be at a higher level context
(eg. Score), and doing \unset at a lower level (eg. Staff) to restore
the default.
Of course, the \set \unset model falls apart for autoBeami
Carl Sorensen writes:
> On 12/31/09 5:18 AM, "Joe Neeman" wrote:
>
>> I don't know the reason; I don't think I was even using LilyPond back
>> in the 2.0 days. But it does sound perfectly reasonable to have
>> context (or translation, if you prefer) properties that can be
>> overridden and reve
On 12/31/09 5:18 AM, "Joe Neeman" wrote:
> On Tue, 2009-12-29 at 15:48 -0700, Carl Sorensen wrote:
>> On 12/29/09 2:14 PM, "Joe Neeman" wrote:
>>> I much prefer leaving it as a context property. Grob properties of the
>>> TimeSignature grob should be things that affect the appearance of the
>
On Tue, 2009-12-29 at 15:48 -0700, Carl Sorensen wrote:
> On 12/29/09 2:14 PM, "Joe Neeman" wrote:
> > I much prefer leaving it as a context property. Grob properties of the
> > TimeSignature grob should be things that affect the appearance of the
> > TimeSignature grob, not the creation of beams.
On 30 Dec 2009, at 12:53, Reinhold Kainhofer wrote:
Am Mittwoch, 30. Dezember 2009 12:27:25 schrieb David Kastrup:
Hans Aberg writes:
Take tuplets. If there are quintuplets, then it should be a 5'
unless
specified as typically 2'+3' or 3'+2'.
For sextuplets, there is a convention that the
On 30 Dec 2009, at 12:27, David Kastrup wrote:
Hans Aberg writes:
Take tuplets. If there are quintuplets, then it should be a 5' unless
specified as typically 2'+3' or 3'+2'.
For sextuplets, there is a convention that the should be in 3, so
there is an implicit rule 3'+3' - there should be n
Am Mittwoch, 30. Dezember 2009 12:27:25 schrieb David Kastrup:
> Hans Aberg writes:
> > Take tuplets. If there are quintuplets, then it should be a 5' unless
> > specified as typically 2'+3' or 3'+2'.
> >
> > For sextuplets, there is a convention that the should be in 3, so
> > there is an implici
Hans Aberg writes:
> Take tuplets. If there are quintuplets, then it should be a 5' unless
> specified as typically 2'+3' or 3'+2'.
>
> For sextuplets, there is a convention that the should be in 3, so
> there is an implicit rule 3'+3' - there should be no subbeaming of the
> 3'. But a compose mi
e a time signature like 4/4. It has i fact two common
interpretations:
(2'+2') x 1/4
4 x 1/4
Now one might also use tuplets tied to the metric. For example, in
Macedonian 7/16, one may normally play as
(3'+(2'+2')) x 1/16
But one may shift to using quadruplets on the 3s
t;4 x 1/4
>
> Now one might also use tuplets tied to the metric. For example, in
> Macedonian 7/16, one may normally play as
>(3'+(2'+2')) x 1/16
> But one may shift to using quadruplets on the 3s divided as 2'+2',
> which one might want to expr
On 12/29/09 2:14 PM, "Joe Neeman" wrote:
> On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote:
>>
>>
>> On 12/29/09 8:41 AM, "Carl Sorensen" wrote:
>>
>>>
>>>
>>>
>>>
>>> On 12/29/09 4:48 AM, "Trevor Daniels" wrote:
>>>
Hi Carl
This looks like a much better approa
On 29 Dec 2009, at 22:00, Carl Sorensen wrote:
Does this seem like a feasible architecture?
I think a system that determines the [meter] from the time signature
is fundamentally flawed. I think in terms of a \meter that can be
used
to define the beaming structure. I substructure of that is
On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote:
>
>
> On 12/29/09 8:41 AM, "Carl Sorensen" wrote:
>
> >
> >
> >
> >
> > On 12/29/09 4:48 AM, "Trevor Daniels" wrote:
> >
> >> Hi Carl
> >>
> >> This looks like a much better approach. It means the
> >> special \overrideTimeSignatur
On 12/29/09 12:31 PM, "Hans Aberg" wrote:
> On 29 Dec 2009, at 03:11, Carl Sorensen wrote:
>
>> Does this seem like a feasible architecture?
>
> I think a system that determines the measure from the time signature
> is fundamentally flawed. I think n terms of a \meter that can be used
> to d
On 29 Dec 2009, at 03:11, Carl Sorensen wrote:
Does this seem like a feasible architecture?
I think a system that determines the measure from the time signature
is fundamentally flawed. I think n terms of a \meter that can be used
to define the beaming structure. I substructure of that is
ature.
>
I think I've got a consistent idea now. I think I can add a property
(probably 'details to avoid namespace pollution, but maybe
timeSignatureDefaults) to the TimeSignature grob.
Then I can use standard /override and /revert to set the autobeaming rules.
What do you t
On 12/29/09 1:40 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> Then, if desired, the user can change the values of beatLength,
>> measureGrouping, or autoBeamRules, they can do so directly by means of
>> the \set command.
>>
>> If a user wants to change the timeSignatureSettings v
On 12/29/09 4:48 AM, "Trevor Daniels" wrote:
> Hi Carl
>
> This looks like a much better approach. It means the
> special \overrideTimeSignatureSettings will be required
> only rarely, and setting autoBeamRules for just the
> current time signature should have a much simpler
> format as the
- Original Message -
From: "Carl Sorensen"
To: "lilypond-devel"
Sent: Tuesday, December 29, 2009 2:11 AM
Subject: Autobeaming
I've been continuing to work on the logical structure of autobeaming
rules,
because the rules aren't right yet. There are still some rules
Carl Sorensen writes:
> Then, if desired, the user can change the values of beatLength,
> measureGrouping, or autoBeamRules, they can do so directly by means of
> the \set command.
>
> If a user wants to change the timeSignatureSettings values for beatLength,
> measureGrouping, or autoBeamRules,
Le lundi 28 décembre 2009 à 19:11 -0700, Carl Sorensen a écrit :
> I've been continuing to work on the logical structure of autobeaming rules,
> because the rules aren't right yet. There are still some rules that don't
> make sense, and in trying to make things make s
I've been continuing to work on the logical structure of autobeaming rules,
because the rules aren't right yet. There are still some rules that don't
make sense, and in trying to make things make sense, I've run into some
philosophical issues.
I'm starting to belie
/18/09 2:49 AM, "Trevor Daniels"
>>>> wrote:
>>>>>
>>>>> A question. Does your code require autobeaming
>>>>> rules to be defined for beams of every possible
>>>>> duration? I ask because the following example
Carl Sorensen writes:
> On 12/18/09 9:52 AM, "Trevor Daniels" wrote:
>
>>
>>
>> Carl, you wrote Friday, December 18, 2009 4:21 PM
>>
>>> On 12/18/09 2:49 AM, "Trevor Daniels"
>>> wrote:
>>>>
>>>>
On 12/18/09 10:13 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 12/18/09 3:58 AM, "David Kastrup" wrote:
>>
>>> I think that if we establish the rule "a broken beam decision is
>>> never reconsidered" we can abolish the '* rule for beaming patterns
>>> and instead let a non-sp
Carl Sorensen writes:
> On 12/18/09 3:58 AM, "David Kastrup" wrote:
>
>> I think that if we establish the rule "a broken beam decision is
>> never reconsidered" we can abolish the '* rule for beaming patterns
>> and instead let a non-specified minimal duration always be broken
>> according to th
On 12/18/09 9:52 AM, "Trevor Daniels" wrote:
>
>
> Carl, you wrote Friday, December 18, 2009 4:21 PM
>
>> On 12/18/09 2:49 AM, "Trevor Daniels"
>> wrote:
>>>
>>> A question. Does your code require autobeaming
>>&g
Carl, you wrote Friday, December 18, 2009 4:21 PM
On 12/18/09 2:49 AM, "Trevor Daniels"
wrote:
A question. Does your code require autobeaming
rules to be defined for beams of every possible
duration? I ask because the following example beams
inconsistently, and I'm not sure
On 12/18/09 2:49 AM, "Trevor Daniels" wrote:
> Carl,
>
> A question. Does your code require autobeaming
> rules to be defined for beams of every possible
> duration? I ask because the following example beams
> inconsistently, and I'm not sure if this is due
On 12/18/09 3:58 AM, "David Kastrup" wrote:
> "Trevor Daniels" writes:
>
>> Carl,
>>
>> A question. Does your code require autobeaming
>> rules to be defined for beams of every possible
>> duration? I ask because the following exam
"Trevor Daniels" writes:
> Carl,
>
> A question. Does your code require autobeaming
> rules to be defined for beams of every possible
> duration? I ask because the following example beams
> inconsistently, and I'm not sure if this is due to your
> code or
Carl,
A question. Does your code require autobeaming
rules to be defined for beams of every possible
duration? I ask because the following example beams
inconsistently, and I'm not sure if this is due to your
code or differences in the autobeaming rules for 4/4 and
2/2 time signatures.
: "Lily devel"
Sent: Thursday, December 17, 2009 8:29 PM
Subject: Re: PATCH: Issue 638 Autobeaming
On 12/17/09 11:39 AM, "Carl Sorensen" wrote:
That bug has now been fixed, and your example now beams the whole
measure (as
expected). Patch update soon
Carl Sorensen writes:
> On 12/17/09 9:53 AM, "David Kastrup" wrote:
>
>> Of course, the results were quite different from what I half expected
>> to see.
>
> Yes. That difference is due to a pre-existing bug in the code. The
> consider_end check used the current duration, not the shortest
> du
On 12/17/09 11:39 AM, "Carl Sorensen" wrote:
>
> That bug has now been fixed, and your example now beams the whole measure (as
> expected). Patch update soon to arrive.
Patch set 2 is now on Rietveld.
http://codereview.appspot.com/179083
Thanks,
Carl
___
On 12/17/09 9:53 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> With the revised code and adding an autobeaming rule for 1/64 notes to
>> the default beam settings, the beaming is consistent.
>>
>> Without the addition of an autobeaming ru
Carl Sorensen writes:
> With the revised code and adding an autobeaming rule for 1/64 notes to
> the default beam settings, the beaming is consistent.
>
> Without the addition of an autobeaming rule for 1/64 notes the beaming
> appears to be inconsistent. I will investigate this
en I guess the programmer isn't very well qualified. But just in case I
can add a comment to the code that mentions that ending decisions are
permanent, but continue decisions are provisional.
>
> Let me take an example: the following code is by default set
> inconsistently (I have no
Carl Sorensen writes:
> On 12/17/09 1:25 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 12/16/09 10:23 PM, "Frédéric Bron" wrote:
>>>
>>
>> Deep breath.
>>
>> So it would appear that no terminal/irreversible decision based on the
>> minimum duration has been done yet at th
On 12/17/09 1:25 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 12/16/09 10:23 PM, "Frédéric Bron" wrote:
>>
>
> Deep breath.
>
> So it would appear that no terminal/irreversible decision based on the
> minimum duration has been done yet at this point of time.
>
> If that is
circumstances where the recalculation
> based on the new minimum-duration may not be able to revert some
> decision based on the old assumption, which might be a bug.
>
> It is quite possible that I am missing some detail here (actually, I am
> missing _all_ details right now becau
Carl Sorensen writes:
> On 12/16/09 10:23 PM, "Frédéric Bron" wrote:
>
>>> At last, thanks to help above and beyond the call of duty by Neil, I
>>> have finally got the autobeam engraver fixed so it beams 4 4 right
>>> when there are 16th notes in the 2nd or 4th beat of the measure.
>>
>> Very
On 12/16/09 10:23 PM, "Frédéric Bron" wrote:
>> At last, thanks to help above and beyond the call of duty by Neil, I have
>> finally got the autobeam engraver fixed so it beams 4 4 right when there are
>> 16th notes in the 2nd or 4th beat of the measure.
>
> Very nice job. That's now a good r
> At last, thanks to help above and beyond the call of duty by Neil, I have
> finally got the autobeam engraver fixed so it beams 4 4 right when there are
> 16th notes in the 2nd or 4th beat of the measure.
Very nice job. That's now a good reason for me to upgrade to 2.13.X.
Does this apply only t
On Wed, Dec 16, 2009 at 1:20 PM, Carl Sorensen wrote:
> At last, thanks to help above and beyond the call of duty by Neil, I have
> finally got the autobeam engraver fixed so it beams 4 4 right when there are
> 16th notes in the 2nd or 4th beat of the measure.
Bravo, Carl! I can't really comment
id earlier that this is a more fundamental problem.
Trevor
- Original Message -
From: "Carl Sorensen"
To: "Trevor Daniels" ; "Neil Puttock"
; "Patrick McCarty"
Cc: "lilypond-devel"
Sent: Monday, August 10, 2009 11:25 PM
Subject:
y two parts to a beat, but as
> soon as two 16th notes are introduced we have
> (at least) three parts to a beat, and rule 2
> kicks in, forcing beams to be limited to
> single beats.
>
Thanks, Trevor. Now I just need to figure out how to get autobeaming to
work properly.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
OK, I've found a setting that works *pretty well*, with one bad case:
\relative c'' {
\overrideBeamSettings #'Score #'(4 . 4) #'end
#'((* . (1 1 1 1))
((1 . 8) . (4 4)))
a8 a a a a a a a | % OK
\break
a16 a a8 a a
a a16 a a8 a | % OK now, was wrong, should be ...
a16[ a a8] a a
a[
ibes why
a8 a a16[ a a8] a a a[ a16 a16]
is better than
a8[ a a16 a a8] a8[ a a a16 a]
? It seems to me that something has triggered a desire to break
the beam on
the beats, when
a8[ a a a] a[ a a a]
is desired to break at 1/2.
Perhaps if you can explain this, I can figure out what is mis
> 1/4, 1/2 and 3/4 AFAICS.
OK, so now I can see the differences. Thanks, Trevor.
Can you express in words a rule that describes why
a8 a a16[ a a8] a a a[ a16 a16]
is better than
a8[ a a16 a a8] a8[ a a a16 a]
? It seems to me that something has triggered a desire to break the beam on
t
Trevor Daniels wrote Monday, August 10, 2009 8:49 AM
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty :
I wonder why we are seeing different beaming patterns? I think
all of
your manually-beamed patterns are correct though.
Trevor's using the MinGW build I pos
Neil Puttock wrote Monday, August 10, 2009 12:31 AM
2009/8/10 Patrick McCarty :
I wonder why we are seeing different beaming patterns? I think all
of
your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing Carl's last change
2009/8/10 Patrick McCarty :
> I wonder why we are seeing different beaming patterns? I think all of
> your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing Carl's last changes to beam-settings.scm.
Regards,
Neil
_
On Sun, Aug 09, 2009 at 11:38:22PM +0100, Trevor Daniels wrote:
>
> Carl Sorensen wrote Sunday, August 09, 2009 10:59 PM
>
> >Could the two of you please take some of these examples and beam
> >them
> >manually so that I can see what they *should* do? I'll then try
> >to figure
> >out why the au
Carl Sorensen wrote Sunday, August 09, 2009 10:59 PM
Could the two of you please take some of these examples and beam
them
manually so that I can see what they *should* do? I'll then try
to figure
out why the autobeam engraver doesn't do it.
Some explanation as to *why* it should work the w
gt;
> Yes, the basic problem still remains. The look-ahead is
> only to the next note. When this is a quaver there is no
> rule which dictates a beam break of quavers at 1/4 and 3/4.
> Fixing this goes rather deeper than the autobeaming rules.
> There is an analogous effect with 16
a a
a8 a16 a a8 a
a8 a a16 a a8
a8 a a a16 a % beaming is different
}
Yes, the basic problem still remains. The look-ahead is
only to the next note. When this is a quaver there is no
rule which dictates a beam break of quavers at 1/4 and 3/4.
Fixing this goes rather deeper than the au
ided into
> sixteenth notes, all of the notes are still beamed together.
> This is different from the current behavior in 2.12.
>
>
> The pre-2.13 version of the autobeaming code required a workaround to
> achieve the behavior of 1). But now, no workarounds are re
Hello,
First of all, thanks go out to Carl and Trevor for reworking the
autobeaming implementation. The new way of working with beam
settings is greatly simplified now.
However, one of the most common complaints we've had is about the
default groupings for 4/4 time. Let me outlin
2009/7/24 Carl Sorensen :
>> type check also for settings?
>
> Settings needs a list? type check, and I haven't seen one available
> in c++. It shouldn't segfault, because we do a pair check before we
> use it.
ly_is_list (which is a wrapper for scm_list_p) (but see below)
>
> I can't use a pai
On 7/22/09 4:15 PM, "joenee...@gmail.com" wrote:
> I think this is pretty much ready to commit
>
>
> http://codereview.appspot.com/88155/diff/3101/4032
> File lily/beam-scheme.cc (right):
>
> http://codereview.appspot.com/88155/diff/3101/4032#newcode2
> Line 2: beam-scheme.cc -- Retrieving
http://codereview.appspot.com/88155/diff/3101/4027
File input/new/grouping-beats.ly (right):
http://codereview.appspot.com/88155/diff/3101/4027#newcode7
Line 7: Beaming patterns may be altered with the @code{beatGrouping}
property:
new texidoc using \overrideBeamSettings
http://codereview.appsp
I think this is pretty much ready to commit
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode2
Line 2: beam-scheme.cc -- Retrieving beam settings
could you call this beam-grouping-scheme.cc or somethin
1 - 100 of 154 matches
Mail list logo
