gt; altered to match the system I'm using. The pitch of each note and string
> remains the same but my system avoids the fret number problem on the
> violin/viola/cello; one where the TAB fret numbers have no practical
> reference for students gaining accuracy in finger placement.
&
answer your question directly. But if things like
Clairnote <https://clairnote.org/> are possible with LilyPond, it seems
like special tab staffs also should be.
--
Karlin High
Missouri, USA
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
but my system avoids the fret number problem on the
violin/viola/cello; one where the TAB fret numbers have no practical reference
for students gaining accuracy in finger placement.
The numbering system for the violin/viola, treble/alto clefs I've developed
uses 0-4 to indicate what fingers
Am 22.10.2016 um 16:29 schrieb Simon Albrecht:
On 22.10.2016 10:00, Thomas Morley wrote:
Hi,
I recently mentioned my work to create the very special notation for
Akkordzither.
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00349.html
I consider to put it in the source, probably in
Am 22. Oktober 2016 16:29:10 MESZ, schrieb Simon Albrecht
:
>On 22.10.2016 10:00, Thomas Morley wrote:
>> Hi,
>>
>> I recently mentioned my work to create the very special notation for
>> Akkordzither.
>> http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00349.html
>>
>> I consider to p
On 22.10.2016 10:00, Thomas Morley wrote:
Hi,
I recently mentioned my work to create the very special notation for
Akkordzither.
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00349.html
I consider to put it in the source, probably in the same way we have
gregorian.ly.
I think Gre
Am 22.10.2016 um 10:00 schrieb Thomas Morley:
Hi,
I recently mentioned my work to create the very special notation for
Akkordzither.
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00349.html
I consider to put it in the source, probably in the same way we
have gregorian.ly.
What do
Hi,
I recently mentioned my work to create the very special notation for
Akkordzither.
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00349.html
I consider to put it in the source, probably in the same way we have
gregorian.ly.
What do you think?
Cheers,
Harm
https://codereview.appspot.com/13612043/diff/6001/scm/parser-clef.scm
File scm/parser-clef.scm (right):
https://codereview.appspot.com/13612043/diff/6001/scm/parser-clef.scm#newcode23
scm/parser-clef.scm:23: (define-session-public supported-clefs
Huh. I though we had that already.
https://code
blature.scm
File scm/tablature.scm (right):
https://codereview.appspot.com/13612043/diff/6001/scm/tablature.scm#newcode44
scm/tablature.scm:44: ;; The 'text'-variable is optional. If not set, it
will be valuated by
;; ... If not set, a default value will be provided in markup-command
'custom-t
Hi,
please review.
https://codereview.appspot.com/13612043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I messed up something, the new patchset is at
http://codereview.appspot.com/6506090
http://codereview.appspot.com/6488097/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Anybody else annoyed just how hard it is to get simple things like that
right, when they probably weren't thought through before anyhow?
In any case, is there a "natural" already existing override for
hand-tweaking dot distance? With vertical time signature position, the
user would always have t
plainchant definitely has no bar lines; I guess it has no repeat signs as well,
but if it has, it's (still guessing) another glyph LilyPond doesn't know.
I'm fine with not distinguishing four-line plainchant and four-line tablature.
___
lilypond-devel m
Stupid question: anybody have an idea where the dots are to fall in
four-line plainchant? Is this compatible to where we want to see them
in six-line and four-line tablature?
http://codereview.appspot.com/6488097/
___
lilypond-devel mailing list
lilyp
On Sun, 09 Sep 2012 00:22:43 -0700, Benkő Pál wrote:
On Sat, 08 Sep 2012 15:26:21 -0700, wrote:
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-cou
2012/9/9 Keith OHara :
> On Sat, 08 Sep 2012 15:26:21 -0700, wrote:
>
>> do we want to support
>> - NR 2.5.1 style 2-line percussion staves (setting both line-count and
>> staff-space to 2 instead of setting just line-positions to (-2 2))?
>> - default TabStaff's (even line-count, 1.5 staff-space)
On Sat, 08 Sep 2012 15:26:21 -0700, wrote:
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-count, 1.5 staff-space)?
if we want to support both of tho
sorry, I'm confused.
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-count, 1.5 staff-space)?
if we want to support both of those without changing dot s
I guess you are thinking we bring the dots inside the staff if there is at
least one staff-postion of space for each dot (as in 2-line percussion staves)
and continue to move them closer to the center if we find locations with at
least two-staff-positions of space for each dot, or more space th
ok, thinking about a new patch.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/09/08 18:54:07, Keith wrote:
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178
scm/bar-line.scm:178: ;; the default distance between centre of dots
is composed
o
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178
scm/bar-line.scm:178: ;; the default distance between centre of dots is
composed of
Have you considered working entirely in
#(set-global-staff-size 5)
{ R1 \repeat volta 2 R1 }
http://codereview.appspot.com/6488097/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Jun 24, 2011 at 07:49:02PM +0200, Matthias Kilian wrote:
> [slightly offtopic tab size rant ;-)]
>
> On Fri, Jun 24, 2011 at 04:44:21PM +0100, Graham Percival wrote:
> > In the old/bad style that emacs produced, one tab was used to
> > represent 8 spaces. Yes, it
[slightly offtopic tab size rant ;-)]
On Fri, Jun 24, 2011 at 04:44:21PM +0100, Graham Percival wrote:
> In the old/bad style that emacs produced, one tab was used to
> represent 8 spaces. Yes, it was doubly confusing.
Well, no. People and/or editors who used one tab per indentation
leve
On Fri, Jun 24, 2011 at 01:38:21PM +, Benjamin Peterson wrote:
> oco.net> writes:
>
> > The bad news is, you replaced tabs by 4 columns when we needed 8 column.
> > The good news is, so far as I can see, there were no un-wanted changes
> > (no cases were we need
Am Freitag, 24. Juni 2011, 15:38:21 schrieb Benjamin Peterson:
> oco.net> writes:
> > The bad news is, you replaced tabs by 4 columns when we needed 8 column.
> > The good news is, so far as I can see, there were no un-wanted changes
> > (no cases were we needed a litera
oco.net> writes:
>
> The bad news is, you replaced tabs by 4 columns when we needed 8 column.
> The good news is, so far as I can see, there were no un-wanted changes
> (no cases were we needed a literal tab).
But the GOP says "use 4 spaces per indentatio
Thanks Keith and Carl.
Pushed as
20596e17d6f8026f7199c9ae0e5f03517631a66c
Closing this issue
http://codereview.appspot.com/4627062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/4627062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Keith,
Message:
Second go. Thanks Keith.
Description:
Replace Tab with 8 Spaces for .py files
As per GOP Prop 1 - Python formatting.
All files in /python/ and /scripts/ were checked.
Please review this at http://codereview.appspot.com/4627062/
Affected files:
M python
The bad news is, you replaced tabs by 4 columns when we needed 8 column.
The good news is, so far as I can see, there were no un-wanted changes
(no cases were we needed a literal tab).
http://codereview.appspot.com/4627062/
___
lilypond-devel mailing
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
es 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 the tab note heads to the right, because
>> they were slightly too far to the left, in
et, but it wasn't part of this patch.
I have deliberately shifted the tab note heads to the right, because
they were slightly too far to the left, in my opinion.
I don't know why, but in the .png it looks as if they were almost
right-aligned to the
note heads, but in fact, they are ce
erately shifted the tab note heads to the right, because
they were slightly too far to the left, in my opinion.
I've now put the new offsets in the latest patch sets.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing
erately shifted the tab note heads to the right, because
they were slightly too far to the left, in my opinion.
I've now put the new offsets in the latest patch sets.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing
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 p
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-engrav
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
other staves.
I've now added code that sets an offset the size of an "8" in the
current tab-note-head grob context. This actually lines things up
better than it used to be lined up, in my opinion.
Is it too much of a hack?
http://codereview.apps
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 twea
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 ",
Thi
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
-markup grob
(make-customFretLabel-markup fret)))
On 2010/11/27 09:05:58, marc wrote:
I think you reverted my corrected patch here, at least partly.
customFretLabel-markup isn't defined any more.
Oops, I'm sorry. I handled the merge conflict inappropriately.
I've now changed it to re
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
hanks,
Carl
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 ();
On
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
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
7;t yet been able to get it to work
properly.
However, we can't do the whole display-cautionary thing in the engraver,
because the engraver doesn't know about such things as split ties. That has
to be dealt with in the tab note head callback.
Yes, I know, because the line break
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
er, but I haven't yet been able to get it to work
properly.
However, we can't do the whole display-cautionary thing in the engraver,
because the engraver doesn't know about such things as split ties. That has
to be dealt with in the tab note head callback.
The problem with the harmoni
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
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
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
of doing it
without making the code more complex).
Why can't we use the mechanism we already had instead?
The engraver sets tie-follow *only* for tab-note-heads which are
right bounds of a tie *and* left bounds of either a slur or a glissando -
then the callback code works properly, a
set the desired properties there.
>
> Which properties?
Well, it would seem that in order to know how to display a tab note head
properly we need to know the following:
1. Is it on the right hand end of a tie ('tie-follow property)
2. Is it on the left hand end of a slur, glissando,
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/ta
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:
>>
>>> 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 fo
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:
>>&
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&
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.
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
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
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 w
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
d be no need to acknowledge
glissandos and slurs in the engraver: we only need to check whether the
tie's right bound is one of the acknowledged noteheads.
Cheers,
Neil
http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-follow-engrav
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-engrav
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/ta
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
On 1/30/10 11:44 AM, "n.putt...@gmail.com" wrote:
> Hi Carl,
>
> I've just tested this, and it breaks two regtests:
>
> 1) dead-notes.ly
>
> The \deadNote command inside a chord is ignored (i.e., the tabs appear
> as numbers rather than crosses). Replacing \deadNote with \tweak also
> fail
1 - 100 of 173 matches
Mail list logo
