Am 07.12.2010 00:56, schrieb Carl Sorensen:
[...]
I'm happy to go with 3/5, as you recommend.
I've added the head-offset property to TabNoteHead 'details, set its default
value to 3/5, and pushed the changes.
Thanks! It's great to see how older lilypond input files are now
compiled and
the
On 12/6/10 3:37 AM, "Marc Hohl" wrote:
> Am 05.12.2010 23:12, schrieb Carl Sorensen:
>>
>>
>> [...]
>>> Perhaps the left edge of a number should be aligned to the left edge of
>>> a note head
>>> when the fret number is a single digit, whereas fret numbers> 9 should
>>> be centered
>>> acco
Am 05.12.2010 23:12, schrieb Carl Sorensen:
[...]
Perhaps the left edge of a number should be aligned to the left edge of
a note head
when the fret number is a single digit, whereas fret numbers> 9 should
be centered
according to the center of the left-aligned single digits (I don't know how
On 12/5/10 12:22 PM, "Marc Hohl" wrote:
> Am 05.12.2010 02:19, schrieb carl.d.soren...@gmail.com:
>> On 2010/12/05 00:58:13, Neil Puttock wrote:
>>> I don't know, but they're consistently shifted to the right unless
>>> there are double-digit notes present.
>>
>> I wanted your opinion on the
Am 05.12.2010 02:19, schrieb carl.d.soren...@gmail.com:
On 2010/12/05 00:58:13, Neil Puttock wrote:
I don't know, but they're consistently shifted to the right unless
there are double-digit notes present.
I wanted your opinion on the spacing in the .png I sent. I adjusted the
offset, but it w
On 2010/12/05 00:58:13, Neil Puttock wrote:
I don't know, but they're consistently shifted to the right unless
there are double-digit notes present.
I wanted your opinion on the spacing in the .png I sent. I adjusted the
offset, but it wasn't part of this patch.
I have deliberately shifted th
On 2010/12/05 00:58:13, Neil Puttock wrote:
I don't know, but they're consistently shifted to the right unless
there are double-digit notes present.
I wanted your opinion on the spacing in the .png I sent. I adjusted the
offset, but it wasn't part of this patch.
I have deliberately shifted th
On 5 December 2010 00:35, Carl Sorensen wrote:
> How's this? To my eye it appears that the tab heads are centered on the
> regular notes now.
I don't know, but they're consistently shifted to the right unless
there are double-digit notes present.
Cheers,
Neil
<>
On 2010/12/03 16:32:07, Carl wrote:
Added an offset to get the column centered one character-width to the
right of
the paper column. I think it's even better than it used to be.
They look too far to the right to me.
http://codereview.appspot.com/2723043/
Thanks for the feedback. I've responded to the comments and posted a
new patch set.
http://codereview.appspot.com/2723043/diff/109001/lily/tab-harmonic-engraver.cc
File lily/tab-harmonic-engraver.cc (left):
http://codereview.appspot.com/2723043/diff/109001/lily/tab-harmonic-engraver.cc#oldcode
On 2010/11/28 15:42:47, marc wrote:
Just some remarks about the harmonic detection.
Thanks, Marc. I wrote a slightly different version of this (using
filter). It works great!
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
l
On 2010/11/28 22:24:05, Neil Puttock wrote:
http://codereview.appspot.com/2723043/diff/109001/scm/tablature.scm#newcode321
scm/tablature.scm:321: (centered-stencil output-grob)))
This has a nasty side-effect: it centres the noteheads on the
PaperColumn,
shifting them to the left of heads in oth
On 2010/11/28 22:24:05, Neil Puttock wrote:
http://codereview.appspot.com/2723043/diff/109001/lily/tab-harmonic-engraver.cc#newcode59
lily/tab-harmonic-engraver.cc:59: victim->set_property ("style",
ly_symbol2scm
("harmonic"));
This makes it difficult for users to tweak the appearance of the
http://codereview.appspot.com/2723043/diff/109001/lily/tab-harmonic-engraver.cc
File lily/tab-harmonic-engraver.cc (left):
http://codereview.appspot.com/2723043/diff/109001/lily/tab-harmonic-engraver.cc#oldcode83
lily/tab-harmonic-engraver.cc:83: "HarmonicParenthesesItem ",
This is never created
Just some remarks about the harmonic detection.
Regards,
Marc
http://codereview.appspot.com/2723043/diff/109001/scm/tablature.scm
File scm/tablature.scm (right):
http://codereview.appspot.com/2723043/diff/109001/scm/tablature.scm#newcode296
scm/tablature.scm:296: (harmonic (eq? (ly:grob-prope
Thanks, Marc. That was a mistake I made in resolving merge conflicts.
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm
File scm/tablature.scm (right):
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm#newcode291
scm/tablature.scm:291: (grob-interpret-marku
Hello Carl,
your code looks great (at least at a quick glance),
but it looks as you didn't rebase after my patch
correction concerning the custom fret label was applied.
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm
File scm/tablature.scm (right):
http://codereview.appspo
Thanks for the review, Neil.
I've responded to all your comments.
I've also defined a new print function for TabNoteHeads in Scheme. It
will take care of all of the necessary parentheses and harmonic
brackets, based on the settings of 'display-cautionary and 'style.
Thanks,
Carl
http://cod
http://codereview.appspot.com/2723043/diff/70001/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-follow-engraver.cc (right):
http://codereview.appspot.com/2723043/diff/70001/lily/tab-tie-follow-engraver.cc#newcode52
lily/tab-tie-follow-engraver.cc:52: void process_acknowledged ();
remove
http
Carl Sorensen writes:
> On 11/13/10 3:23 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 11/13/10 2:01 AM, "David Kastrup" wrote:
>>>
carl.d.soren...@gmail.com writes:
>
>>>
You sort the noteheads according to some criterion, and use the same
criterion f
Am 13.11.2010 15:29, schrieb Carl Sorensen:
On 11/13/10 3:18 AM, "Marc Hohl" wrote:
Am 13.11.2010 06:21, schrieb carl.d.soren...@gmail.com:
I can think of no way to simplify this code further. If you have any
ideas I'd be happy to hear them.
There was the idea to inclu
On 11/13/10 3:23 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 11/13/10 2:01 AM, "David Kastrup" wrote:
>>
>>> carl.d.soren...@gmail.com writes:
>>>
>>
>>> You sort the noteheads according to some criterion, and use the same
>>> criterion for sorting the other data structur
On 11/13/10 3:18 AM, "Marc Hohl" wrote:
> Am 13.11.2010 06:21, schrieb carl.d.soren...@gmail.com:
>> I can think of no way to simplify this code further. If you have any
>> ideas I'd be happy to hear them.
> There was the idea to include this into the Tab_note_heads_engraver, and
> if it were
>
Am 13.11.2010 06:21, schrieb carl.d.soren...@gmail.com:
Thanks for the help on the null pointer. I was thinking that it was
some *other* kind of variable than a Grob, and that I was casting it
wrong.
Got that all taken care of -- no scheme calls at all.
On 2010/11/12 17:40:42, Neil Puttock wro
Carl Sorensen writes:
> On 11/13/10 2:01 AM, "David Kastrup" wrote:
>
>> carl.d.soren...@gmail.com writes:
>>
>>> OK, so now I've eliminated the triple nested loop.
>>>
>>> There is what appears to me to be a required nested loop.
>>>
>>> One loop to loop through the note-heads.
>>> Then an i
On 11/13/10 2:01 AM, "David Kastrup" wrote:
> carl.d.soren...@gmail.com writes:
>
>> OK, so now I've eliminated the triple nested loop.
>>
>> There is what appears to me to be a required nested loop.
>>
>> One loop to loop through the note-heads.
>> Then an inner loop (with a break) through th
carl.d.soren...@gmail.com writes:
> OK, so now I've eliminated the triple nested loop.
>
> There is what appears to me to be a required nested loop.
>
> One loop to loop through the note-heads.
> Then an inner loop (with a break) through the ties looking for a tie on
> a note head.
> Followed by a
Thanks for the help on the null pointer. I was thinking that it was
some *other* kind of variable than a Grob, and that I was casting it
wrong.
Got that all taken care of -- no scheme calls at all.
On 2010/11/12 17:40:42, Neil Puttock wrote:
It's back to square one though, isn't it?
The tr
On 2010/11/12 04:12:48, Carl wrote:
Here's a new version of the patch that tries to eliminate any scheme
calls, and
demonstrates my problem.
I need to do a check on the left bound to see if it's a grob, because
if I take
the check out I get a Bus error.
I don't know how to do such a che
Am 12.11.2010 05:07, schrieb carl.d.soren...@gmail.com:
On 2010/11/07 09:21:45, marc wrote:
http://codereview.appspot.com/2723043/diff/57001/scm/define-grob-properties.scm#newcode1021
scm/define-grob-properties.scm:1021: (display-cautionary ,boolean?
"Display in
cautionary form.")
Hey, good
Here's a new version of the patch that tries to eliminate any scheme
calls, and demonstrates my problem.
I need to do a check on the left bound to see if it's a grob, because if
I take the check out I get a Bus error.
I don't know how to do such a check from C++ -- I think it's done by
casting,
On 2010/11/07 09:24:31, marc wrote:
Am 07.11.2010 08:47, schrieb carl.d.soren...@gmail.com:
> In this patch, the glissando, slur, tie, and repeat-tie callbacks
have
> been modified. The slur callback doesn't even check for the tie
status,
> since there's no change.
But it has to take the val
On 2010/11/07 09:21:45, marc wrote:
http://codereview.appspot.com/2723043/diff/57001/scm/define-grob-properties.scm#newcode1021
scm/define-grob-properties.scm:1021: (display-cautionary ,boolean?
"Display in
cautionary form.")
Hey, good choice - I like the name of the new property,
it's much be
Am 07.11.2010 08:47, schrieb carl.d.soren...@gmail.com:
This patch has revised the callbacks in scm/tablature.scm. It appears
to work properly.
The tab-tie-follow-engraver is still using SCM calls to analyze the
grobs. I will get that worked out soon, I hope (although I seem to have
gone backw
Hello Carl,
I didn't test the patch, but the general logic behind it
seems to be the right way to do.
Regards,
Marc
http://codereview.appspot.com/2723043/diff/57001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/2723043/diff/57001/sc
This patch has revised the callbacks in scm/tablature.scm. It appears
to work properly.
The tab-tie-follow-engraver is still using SCM calls to analyze the
grobs. I will get that worked out soon, I hope (although I seem to have
gone backward, not forward, today).
In this patch, the glissando,
On 2010/11/04 08:31:30, marc wrote:
No, I don't think we should it do more complicated that necessary.
Perhaps the name 'tie-follow is misleading, but the engraver (before
you
left out the slur and glissando bits) did the right job - marking
exactly
the tab-note-heads that have to be treated
Am 03.11.2010 20:33, schrieb Carl Sorensen:
On 11/3/10 10:15 AM, "Marc Hohl" wrote:
Am 03.11.2010 15:10, schrieb Carl Sorensen:
On 11/3/10 6:50 AM, "Marc Hohl" wrote:
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to only acknowledge tab-
Am 03.11.2010 21:22, schrieb Neil Puttock:
On 3 November 2010 19:33, Carl Sorensen wrote:
But the tie callback *should* make the notehead transparent if there's no
slur or gliss (or bend, in the future). In the absence of slur, gliss, or
split tie the notehead is transparent. In the pres
On 11/3/10 5:52 PM, "n.putt...@gmail.com" wrote:
> On 2010/11/03 23:14:47, Carl wrote:
>
>> I think I'd probably go a bit farther.
>
>> What if we acknowledged ties, slurs, and glissandos (glissandi?) in
> the
>> Tab_note_head_engraver and set the desired properties there.
>
> Which propert
On 2010/11/03 20:46:27, Neil Puttock wrote:
Hi Carl,
What do you think about folding this code into the
Tab_note_heads_engraver? We
could store the created TabNoteHead grobs and add an acknowledger for
Tie, then
set 'tie-follow in stop_translation_timestep ().
I think I'd probably go a
On 2010/11/03 23:14:47, Carl wrote:
I think I'd probably go a bit farther.
What if we acknowledged ties, slurs, and glissandos (glissandi?) in
the
Tab_note_head_engraver and set the desired properties there.
Which properties?
If it involves multiple nested loops (like the original patch)
Hi Carl,
What do you think about folding this code into the
Tab_note_heads_engraver? We could store the created TabNoteHead grobs
and add an acknowledger for Tie, then set 'tie-follow in
stop_translation_timestep ().
Cheers,
Neil
http://codereview.appspot.com/2723043/diff/31001/lily/tab-tie-f
On 3 November 2010 19:33, Carl Sorensen wrote:
> But the tie callback *should* make the notehead transparent if there's no
> slur or gliss (or bend, in the future). In the absence of slur, gliss, or
> split tie the notehead is transparent. In the presence of one of these,
> it's visible and par
On 11/3/10 10:15 AM, "Marc Hohl" wrote:
> Am 03.11.2010 15:10, schrieb Carl Sorensen:
>>
>>
>> On 11/3/10 6:50 AM, "Marc Hohl" wrote:
>>
>>
>>> Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
>>>
Updated to only acknowledge tab-note-head, not note-head.
>>>
On 11/3/10 12:43 PM, "Neil Puttock" wrote:
> On 3 November 2010 16:15, Marc Hohl wrote:
>> Am 03.11.2010 15:10, schrieb Carl Sorensen:
>>>
>>>
>>> On 11/3/10 6:50 AM, "Marc Hohl" wrote:
>>>
>>>
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
>
> Updated to
On Wed, Nov 3, 2010 at 7:43 PM, Neil Puttock wrote:
> It's a shame Carl's already pushed the patch; I don't think it's ready yet.
Nah, I think Carl pushed his patch too early just so I don't feel
alone anymore :)
Valentin.
___
lilypond-devel mailing l
On 3 November 2010 16:15, Marc Hohl wrote:
> Am 03.11.2010 15:10, schrieb Carl Sorensen:
>>
>>
>> On 11/3/10 6:50 AM, "Marc Hohl" wrote:
>>
>>
>>>
>>> Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
>>>
Updated to only acknowledge tab-note-head, not note-head.
>>>
>>> Makes
Am 03.11.2010 15:10, schrieb Carl Sorensen:
On 11/3/10 6:50 AM, "Marc Hohl" wrote:
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to only acknowledge tab-note-head, not note-head.
Makes perfect sense to me.
Thanks for your work!
You're welcome.
Pu
On 11/3/10 6:50 AM, "Marc Hohl" wrote:
> Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
>> Updated to only acknowledge tab-note-head, not note-head.
> Makes perfect sense to me.
> Thanks for your work!
You're welcome.
Pushed to git.
Thanks,
Carl
_
Am 02.11.2010 04:04, schrieb carl.d.soren...@gmail.com:
Updated to only acknowledge tab-note-head, not note-head.
Makes perfect sense to me.
Thanks for your work!
Marc
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mai
Updated to only acknowledge tab-note-head, not note-head.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 11/1/10 1:53 AM, "Marc Hohl" wrote:
>
> Sorry for causing so much trouble.
>
No trouble, Marc. You never need to apologize for working to improve
LilyPond!
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.o
Am 31.10.2010 23:24, schrieb n.putt...@gmail.com:
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme engraver).
Thank you, Neil, for pointing this out!
I was referring to your engraver example which checked for slurs, too,
and I overlooked the fact that the slu
Or perhaps the engraver should only listen to tab-note-heads, instead of
to note-heads, since the tie-follow property is part of the
tab-note-head interface.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond
Further thought about this causes me to think the engraver should just
be
Tie_follow_engraver
It doesn't change a TabNoteHead property, it changes a NoteHead
property. The only reason it applies to TabNoteHeads is because it is
in a TabVoice context.
Am I wrong in thinking this?
Thanks,
Carl
New patch set with simplified engraver -- it only acknowledges ties and
note-heads, and it still works.
Thanks, Neil!
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/lis
On 2010/10/31 22:40:57, Carl wrote:
This is going away, so it won't apply to this patch (because we don't
need to
acknowledge glissandos). But if we did, and we added a
glissando-interface,
then instead of Tab_tie_follow_engraver::acknowledge_line_spanner
wouldn't we
just use
Tab_tie_foll
On 2010/10/31 22:24:17, Neil Puttock wrote:
http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode69
lily/tab-tie-follow-engraver.cc:69: if (info.grob ()->name () ==
"Glissando")
If you needed to distinguish glissandos from other lines, it would be
more
idiom
On 2010/10/31 22:24:17, Neil Puttock wrote:
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme
engraver).
The point of using 'tie-follow is that it defers the decision to
parenthesize
TabNoteHead to the point where it matters: in the callbacks for
Gliss
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme engraver).
The point of using 'tie-follow is that it defers the decision to
parenthesize TabNoteHead to the point where it matters: in the callbacks
for Glissando and Slur. Thus there should be no need to acknow
I've updated the comments and the doc string,
and added a check for Glissando.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2010/10/31 09:29:29, Trevor Daniels wrote:
I may be missing something, but doesn't this assume all line spanners
are
glissandi?
I thought the same thing. I haven't investigated it carefully; I was
just translating Marc's Scheme engraver to C++.
Any comments, Mark?
Thanks,
Carl
http://
I may be missing something, but doesn't this assume all line spanners
are glissandi?
Trevor
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-follow-engraver.cc (right):
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc#ne
Hello Carl,
wow, you were fast ...
LGTM ;-)
As said before, I wouldn't be able to do this engraver myself, but I
think I understand now a tiny bit better how
c++ engraver work.
Thank you,
Marc
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-fo
Reviewers: carl.d.sorensen_gmail.com,
Message:
Here's a patch to Marc's tab stuff that has the engraver moved to a C++
engraver instead of a Scheme engraver. This should help get it into the
source tree before 2.14.
Thanks,
Carl
Description:
Add tab-tie-follow-engraver
Based on the Scheme en
66 matches
Mail list logo
