Re: PATCH: Improved tablature support vs email
On Fri, Aug 14, 2009, Mark Polesky said: >> If all \foo were right-associative it would be easy to read them. Is it >> possible to make monadic operators right-associative so as to end this >> confusion? Yes, i realize this could have a nasty impact; if done at all >> it would mean devising a new set of right-associative operators and >> deprecating the old ones (never eliminating them of course, such being the >> fate of deprecated stuff). > > Imagine how convoluted the convert-ly rules would need to be... ugh. In an ideal world someone would have been thinking ahead from the start on how naive users perceptions were, but then, at first there was mainly one user, more concerned with his thesis deadline than anything else :-) > I was thinking about this earlier today, what are LilyPond's > "operators"? What distinguishes a function from an operator in the first place? http://www.answers.com/topic/operator#Operators_versus_functions had a discussion that surprised me. Wouldnt surprise me to find out that ly has implemented a private philosophy here tho. > * there are single and double angle-brackets here. Recently I've > noticed some e-mail clients and/or mailing list archives do > weird things with them (like removing them). thats a problem when we depend on this medium to communicate; ietf-822 etal define the packaging, not the content; leaving the world to its existing conventions and new ones to come. Luckily present email and list usage is for quotation, so only the characters beginning a line are at risk. We could employ MIME attachments and html or xml encoding as a work around. Used to be that signatures beginning a line with '--' was the only content convention, tho when usenet news decided to make quotes with lines prefaced by '>' and the block prefaced by a citation that set a trend which continues. Some client software employs other quotation markers in liu of seas of > some users have personal policys ... -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Mark Polesky schrieb: * there are single and double angle-brackets here. Recently I've noticed some e-mail clients and/or mailing list archives do weird things with them (like removing them). Just in case you think I accidentally left something out! Yes, the closing angled bracket is normally used to mark the original text when writing a reply. Thunderbird, for example, shows one or more colored lines instead of these brackets, so if you open a score with double << and close it in a line of its own, like this >> thunderbird will show a blue and a red line instead of the brackets :-( Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
"dem...@suffolk.lib.ny.us" wrote:
> a b c d\lefty e f g
>
> (above) \lefty has an intuitive association with the d.
>
> a b c \righty d e f g
>
> (above) \righty is intuitivly ambiguous,
> (below), \righty has a false intuitive association with the 'c'
>
> a b c\righty d
This is an interesting point.
> If all \foo were right-associative it would be easy to read them. Is it
> possible to make monadic operators right-associative so as to end this
> confusion? Yes, i realize this could have a nasty impact; if done at all
> it would mean devising a new set of right-associative operators and
> deprecating the old ones (never eliminating them of course, such being the
> fate of deprecated stuff).
Imagine how convoluted the convert-ly rules would need to be... ugh.
> BTW, the average user lumps functions and operators together in his mind
> as thingys with similar syntax (\foo) that 'affect' notes. Unless the
> documentation stresses this issue with ample illustrations which are
> commented to this point it will remain a confusing muddle (do you _recall_
> which C operator binds more strongly, left-shift, or prefix-increment?).
I was thinking about this earlier today, what are LilyPond's
"operators"? I thought they might be these*:
- -- / /+ : < << > >> \! \ \( \) \+ \< \> \[ \]
! ' ( ) * + , - . / : = ? [ ] ^ _ { | } ~
Anyone know?
- Mark
* there are single and double angle-brackets here. Recently I've
noticed some e-mail clients and/or mailing list archives do
weird things with them (like removing them). Just in case you
think I accidentally left something out!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Thu, Aug 13, 2009, Graham Percival said: > On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote: >> I mean, we code and read music from left to right, so >> it seems nore natural to me to have the command changing >> the behaviour of a note in front of it. Some like postscript and HP calculators (3 5 7 multiply swap divide), some , especially multi-lingual have trouble with operator precedence is (a & b | c & d). (a&b) | (c&d)) or (a & (b|c) & d) or (((a&b)|c)&d) or... Physical proximity provides an intuitive association that can be false, but is more easily seen than rule-based associativity. The use of '\' to preface both function tokens and operator tokens allows an omission of whitespace before the token, and this allows a left-associative operator to be adjacent to its operand. Both right-associative operators and functions must be setoff by whitespace from their operand(s) for the tokens to be distinguished. a b c d\lefty e f g (above) \lefty has an intuitive association with the d. a b c \righty d e f g (above) \righty is intuitivly ambiguous, (below), \righty has a false intuitive association with the 'c' a b c\righty d If all \foo were right-associative it would be easy to read them. Is it possible to make monadic operators right-associative so as to end this confusion? Yes, i realize this could have a nasty impact; if done at all it would mean devising a new set of right-associative operators and deprecating the old ones (never eliminating them of course, such being the fate of deprecated stuff). BTW, the average user lumps functions and operators together in his mind as thingys with similar syntax (\foo) that 'affect' notes. Unless the documentation stresses this issue with ample illustrations which are commented to this point it will remain a confusing muddle (do you _recall_ which C operator binds more strongly, left-shift, or prefix-increment?). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Graham Percival schrieb: On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote: Graham Percival schrieb: Yes, this is planned. It's been on my list of discussions to introduce when the website/build stuff is finished, for about two months now. Sorry to interrupt, but what's wrong with prefix notation? Nothing necessarily, but a mixture of prefix and postfix is confusing. I mean, consider this: c8([\f\[ \dynamicUp d--\harmonic\cr)-\startTrillSpan \slurUp e](\stopTrillSpan\] f\!) I see. A mixture is not the best. Definitely. Which notes does each element of notation affect? Granted, this is a confusing example... but if we standardized on either postfix or prefix notation, it would be simple. Everything from c8 to d affects the C, everything from d to e affects the D, etc. (shifted accordingly if we used prefix) I mean, we code and read music from left to right, so it seems nore natural to me to have the command changing the behaviour of a note in front of it. Well, -> changes the articulation of a note, \mf changes the dynamics of the note... why should things like \harmonic or \makeRed (if somebody invented one) come *before* the note, rather than *after* it? So, as \mf and -> are already postfix, it is reasonable to do so for the rest, with as little exceptions as possible. Thanks. Marc Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote: > Graham Percival schrieb: >> Yes, this is planned. It's been on my list of discussions to >> introduce when the website/build stuff is finished, for about two >> months now. > > Sorry to interrupt, but what's wrong with prefix notation? Nothing necessarily, but a mixture of prefix and postfix is confusing. I mean, consider this: c8([\f\[ \dynamicUp d--\harmonic\cr)-\startTrillSpan \slurUp e](\stopTrillSpan\] f\!) Which notes does each element of notation affect? Granted, this is a confusing example... but if we standardized on either postfix or prefix notation, it would be simple. Everything from c8 to d affects the C, everything from d to e affects the D, etc. (shifted accordingly if we used prefix) > I mean, we code and read music from left to right, so > it seems nore natural to me to have the command changing > the behaviour of a note in front of it. Well, -> changes the articulation of a note, \mf changes the dynamics of the note... why should things like \harmonic or \makeRed (if somebody invented one) come *before* the note, rather than *after* it? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Graham Percival schrieb: On Wed, Aug 12, 2009 at 08:51:42PM +0100, Trevor Daniels wrote: Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM And if we're ever going to move it to a postfix operator (which is one of the goals of the GLISS project), now is the time, before we get a strong codebase of music function applications. Yes, this is planned. It's been on my list of discussions to introduce when the website/build stuff is finished, for about two months now. Sorry to interrupt, but what's wrong with prefix notation? I mean, we code and read music from left to right, so it seems nore natural to me to have the command changing the behaviour of a note in front of it. Yes, I assume, every parser constructor will condemn me for this, but for readability, a line like c4 harmonic: d e f (without a leading backslash!) is easier to understand than c4 d\harmonic e f Again, I don't think this is the right time to introduce this discussion, but I guess we could do so anyway. Yes, that's right. Marc Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Wed, Aug 12, 2009 at 08:51:42PM +0100, Trevor Daniels wrote: > > Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM > >> And if we're ever going to move it to a postfix operator (which is one >> of >> the goals of the GLISS project), now is the time, before we get a >> strong >> codebase of music function applications. Yes, this is planned. It's been on my list of discussions to introduce when the website/build stuff is finished, for about two months now. > I'm beginning to wonder whether this is a > desirable objective, after all. There is > already a large set of pre-defs which by their > nature must be placed before the notes which > they affect - all the \twiddleOn \twiddleOff > pre-defs for example. > > Then all the commands > are pre-fix operators - \new, \relative, \clef, > etc. We can't change any of these. One of the general principles which I was going to propose during GLISS is that any tweak which affected multiple notes would go before the first note, whereas any tweak which affected a single note would go after the first note. Alternately, we could move to having everything postfix apart from basic stuff like \new, \relative, and \clef. > Now we see a great advantage in writing music > functions - they're easy to write and can be made > to work inside and outside chords. But they > have to be pre-fix from their nature. They don't "have to be". They currently "are". Again, I don't think this is the right time to introduce this discussion, but I guess we could do so anyway. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM And if we're ever going to move it to a postfix operator (which is one of the goals of the GLISS project), now is the time, before we get a strong codebase of music function applications. I'm beginning to wonder whether this is a desirable objective, after all. There is already a large set of pre-defs which by their nature must be placed before the notes which they affect - all the \twiddleOn \twiddleOff pre-defs for example. Then all the commands are pre-fix operators - \new, \relative, \clef, etc. We can't change any of these. \tweak and \override are pre-fix. Now we see a great advantage in writing music functions - they're easy to write and can be made to work inside and outside chords. But they have to be pre-fix from their nature. Is that really a bad thing? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 8/12/09 9:24 AM, "Trevor Daniels" wrote:
>
>
> Carl Sorensen Friday, August 07, 2009 2:49 PM
>>
>> The generic approach has now been pushed to git
>>
>> 247f0b6d46fd8f3253a99f95a70ce14345daa5f9
>>
>> There's a generic styledNoteHeads music function that applies a
>> note style
>> to music whether or not it's in a chord construct.
>
> Carl, I am part-way through documenting this, and
> in developing an example I realised this music
> function like all music functions is a prefix
> operator. Applied to a sequence of notes like
>
> \xNote { e f }
>
> it's fine, but
>
> c d\xNote e f
>
> causes the following e to take a crossed head, not
> the preceding d. Same in chords - in
>
> < g \xNote c f >
>
> it's the c note head that is crossed.
Yes, that is true. xNote is a music function, not an operator.
> Furthermore,
> in chords it's actually an error to enclose the c
> in braces.
Yes, it is. But the function still works properly without the braces.
>
> I don't have a suggestion to make, but I do think
> this might be confusing, especially as \harmonic
> in chords is postfix. It is, of course, identical
> in action to the \tweak command, which is also a
> prefix operator. What do you think? I'd welcome
> other comments too before I proceed with the
> documentation.
I agree that it might be confusing. I'd be fine to have a postfix operator
that would work, as well as a music function that takes a sequence of notes.
But I don't know how to make that happen. That would require changes to the
parser, and I've never been successful with trying to make changes to the
parser.
If there's somebody who could help talk me through the process, I'd be
willing to learn.
Otherwise, I think we're stuck with a music function, not a postfix
operator, for right now.
And if we're ever going to move it to a postfix operator (which is one of
the goals of the GLISS project), now is the time, before we get a strong
codebase of music function applications.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Wed, Aug 12, 2009, Trevor Daniels said:
> function like all music functions is a prefix
> operator. Applied to a sequence of notes like
>
> \xNote { e f }
>
> it's fine, but
>
> c d\xNote e f
> < g \xNote c f >
Conventions aside (...like all music functions...), my preference would be
for postfix rather than prefix, the space separating the prefix operator
from its argument also distances them visually; as the example points out,
that can be confusing; the postfix operator needs no space and can be
adjacent to its operand; concise and intuitive. Subtle point.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
Carl, I am part-way through documenting this, and
in developing an example I realised this music
function like all music functions is a prefix
operator. Applied to a sequence of notes like
\xNote { e f }
it's fine, but
c d\xNote e f
causes the following e to take a crossed head, not
the preceding d. Same in chords - in
< g \xNote c f >
it's the c note head that is crossed. Furthermore,
in chords it's actually an error to enclose the c
in braces.
I don't have a suggestion to make, but I do think
this might be confusing, especially as \harmonic
in chords is postfix. It is, of course, identical
in action to the \tweak command, which is also a
prefix operator. What do you think? I'd welcome
other comments too before I proceed with the
documentation.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Trevor Daniels treda.co.uk> writes: > > I've finally got around to looking at this. > It seems the \deadNote function works fine, > but \deadNotesOn and \deadNotesOff do not. > > I had a quick look at their definitions and > I think they should be > > deadNotesOn = > #(define-music-function (parser location) () > (override-head-style '(TabNoteHead NoteHead) 'cross)) Yes, that is exactly correct. I'm not sure what brain cramp led to my error, and how I missed it in the regression test files. > > since they do modify the music stream. Anyway, > after making that change it works - except it > seems not to work if placed before the very > first note in a score. Not sure why this is. It has something to do with instantiating the voices, particularly when the top-level expression in the staff is a parallel expression. I've changed the snippets in input/regression to include starting from the first note, along with a comment warning that explicit voice instantiation is necessary when deadNotesOn or palmMuteOn comes at the beginning of the piece. > > Could you check this out please, as I'm not > very sure of my ground here. Thanks. Thanks for the feedback, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
deadNotes and palmMute have been redefined to use the generic
functions
instead of a specific function.
I've finally got around to looking at this.
It seems the \deadNote function works fine,
but \deadNotesOn and \deadNotesOff do not.
I had a quick look at their definitions and
I think they should be
deadNotesOn =
#(define-music-function (parser location) ()
(override-head-style '(TabNoteHead NoteHead) 'cross))
rather than
deadNotesOn = {
#(override-head-style '(TabNoteHead NoteHead) 'cross)
}
since they do modify the music stream. Anyway,
after making that change it works - except it
seems not to work if placed before the very
first note in a score. Not sure why this is.
Could you check this out please, as I'm not
very sure of my ground here. Thanks.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: [...] The generic approach has now been pushed to git 247f0b6d46fd8f3253a99f95a70ce14345daa5f9 There's a generic styledNoteHeads music function that applies a note style to music whether or not it's in a chord construct. deadNotes and palmMute have been redefined to use the generic functions instead of a specific function. Wow, great job, thank you! Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM On 8/5/09 7:19 AM, "Trevor Daniels" wrote: Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads The generic approach has now been pushed to git 247f0b6d46fd8f3253a99f95a70ce14345daa5f9 There's a generic styledNoteHeads music function that applies a note style to music whether or not it's in a chord construct. deadNotes and palmMute have been redefined to use the generic functions instead of a specific function. Carl, that's great! Thanks! It would have taken me a month to work out how to do that. I'd be happy to document it, add aliases, and flesh out NR 2 wherever crossheads are used. Please feel free to add aliases and flesh out NR 2 wherever special music heads are used (crosses is one example; harmonics might be another). Fine. The changes are all in Scheme so I can easily update my copy of Lily without waiting for a GUB release. I've got family commitments over the weekend, but I'll get to this next week. But we're hoping to get one of the members of the tablature user community to develop the tablature documentation once 2.13.4 is released. OK - I'll leave tabs alone. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 8/5/09 7:19 AM, "Trevor Daniels" wrote: > > > Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM > >> If we decide to use this same function for the general case of >> switching to >> a cross-shaped notehead, then we will redefine it to either >> crossHead or >> xHead, but we will still keep deadNote (the semantically correct >> term for >> guitar tablature) as an alias for xHead. >> >> In the meantime, we can move forward on tablature. >> >> As I see it, the current decision causes problems only if we were >> to change >> to xHead in the future and eliminate deadNote. And I see no plans >> in the >> future to eliminate deadNote. >> >> Does this make sense to you? > > Thanks Carl and Marc for the explanations. > > I think it was a pity that the groundwork > for a more generic approach was not laid > down right away, so we could have easily > added the aliases for all the other uses > of crossheads, but I accept that no great > harm has been done by this parochial approach, > as long as future developers don't forget > this can be easily changed. Now it's documented > here there is less chance of that, but it > would be even better if you could do it > while it's fresh in your mind :) The generic approach has now been pushed to git 247f0b6d46fd8f3253a99f95a70ce14345daa5f9 There's a generic styledNoteHeads music function that applies a note style to music whether or not it's in a chord construct. deadNotes and palmMute have been redefined to use the generic functions instead of a specific function. > > I'd be happy to document it, add aliases, > and flesh out NR 2 wherever crossheads are > used. Please feel free to add aliases and flesh out NR 2 wherever special music heads are used (crosses is one example; harmonics might be another). But we're hoping to get one of the members of the tablature user community to develop the tablature documentation once 2.13.4 is released. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Wednesday, August 05, 2009 3:07 PM On 8/5/09 7:22 AM, "Trevor Daniels" wrote: I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads I'll try to get the fix taken care of in the next few days. Great! Thanks Carl. Then we can define aliases for particular instruments that will work with the particular needs of that instrument. Happy to help with this. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
dem...@suffolk.lib.ny.us schrieb: Please dont rename the cross head, it has a name, predating any usage stemming from rock musicians jargon. That name is further 'blessed' by the unicode standard, "Musical Symbol X Notehead", 1D143. I think Lilypond should propose both, the "official", somewhat abstract name for a glyph, a symbol, whatever, but the stuff should also be accessible via the musicians' term. When I read the ly source of a file, it is self-explaining if I read \deadNote ... , so as a guitarist, I know what to do. I know, a similar discussion has been on the mailing list, so I don't want to repeat everything. In my opinion, there should be as much synonyms for any given function as needed to allow easier music encoding (not engraving, as seen from the musicians' side). Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Wed, Aug 5, 2009, Carl Sorensen said: > > > > On 8/5/09 7:22 AM, "Trevor Daniels" wrote: > >>> >>> In the meantime, we can move forward on tablature. >>> >>> As I see it, the current decision causes problems only if we were >>> to change >>> to xHead in the future and eliminate deadNote. And I see no plans >>> in the >>> future to eliminate deadNote. >>> >>> Does this make sense to you? yes, it makes sense, but I perceive it as the wrong decision > I think it was a pity that the groundwork > for a more generic approach was not laid > down right away I concur with that. And I appologize for coming late to this discussion, jobhunting and speculative programming work has distracted me from following threads I should have taken more interest in. If dead-note marking was the only use for a cross-head symbol that would make this academic, but it isnt the only use. Percusion instruments are differentiated in condensed orchestral scores by a variety of note heads for each instrument shown on the common stave, and the cross head is used for that purpose (cymbals in the one illustration I saw online). Please dont rename the cross head, it has a name, predating any usage stemming from rock musicians jargon. That name is further 'blessed' by the unicode standard, "Musical Symbol X Notehead", 1D143. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 8/5/09 7:22 AM, "Trevor Daniels" wrote: >> >> In the meantime, we can move forward on tablature. >> >> As I see it, the current decision causes problems only if we were >> to change >> to xHead in the future and eliminate deadNote. And I see no plans >> in the >> future to eliminate deadNote. >> >> Does this make sense to you? > > Thanks Carl and Marc for the explanations. > > I think it was a pity that the groundwork > for a more generic approach was not laid > down right away, so we could have easily > added the aliases for all the other uses > of crossheads, but I accept that no great > harm has been done by this parochial approach, > as long as future developers don't forget > this can be easily changed. Now it's documented > here there is less chance of that, but it > would be even better if you could do it > while it's fresh in your mind :) > I'll try to get the fix taken care of in the next few days. I think we want a generic changer that applies to Voice contexts and can change a note either solo or in a chord context. We probably also want a generic changer that applies to TabVoice contexts that works the same way. Then we can define aliases for particular instruments that will work with the particular needs of that instrument. Having stated this, I hope to get it done in the next couple of days. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM On 8/5/09 2:44 AM, "Trevor Daniels" wrote: Carl, Marc After the long discussion about naming the new cross-head function and associated predefs I see you have retained deadNote as the base name. I thought the outcome of the discussion was to use xHead or crossHead for the base name with deadNote being defined to invoke the base function and predefs, so preparing the way for other musical functions and predefs to be defined to invoke the same base functions. Why did you decide not to do this? Given that the current usage is specifically designed for guitar tablature (as evidenced by the inclusion of TabNoteHead changes), it seemed the most semantically appropriate thing to do was to use deadNote. If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. In the meantime, we can move forward on tablature. As I see it, the current decision causes problems only if we were to change to xHead in the future and eliminate deadNote. And I see no plans in the future to eliminate deadNote. Does this make sense to you? Thanks Carl and Marc for the explanations. I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads, but I accept that no great harm has been done by this parochial approach, as long as future developers don't forget this can be easily changed. Now it's documented here there is less chance of that, but it would be even better if you could do it while it's fresh in your mind :) I'd be happy to document it, add aliases, and flesh out NR 2 wherever crossheads are used. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM On 8/5/09 2:44 AM, "Trevor Daniels" wrote: Carl, Marc After the long discussion about naming the new cross-head function and associated predefs I see you have retained deadNote as the base name. I thought the outcome of the discussion was to use xHead or crossHead for the base name with deadNote being defined to invoke the base function and predefs, so preparing the way for other musical functions and predefs to be defined to invoke the same base functions. Why did you decide not to do this? Given that the current usage is specifically designed for guitar tablature (as evidenced by the inclusion of TabNoteHead changes), it seemed the most semantically appropriate thing to do was to use deadNote. If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. In the meantime, we can move forward on tablature. As I see it, the current decision causes problems only if we were to change to xHead in the future and eliminate deadNote. And I see no plans in the future to eliminate deadNote. Does this make sense to you? Thanks Carl and Marc for the explanations. I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads, but I accept that no great harm has been done by this parochial approach, as long as future developers don't forget this can be easily changed. Now it's documented here there is less chance of that, but it would be even better if you could do it while it's fresh in your mind :) I'd be happy to document it, add aliases, and flesh out NR 2 wherever crossheads are used. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 8/5/09 2:44 AM, "Trevor Daniels" wrote: > Carl, Marc > > After the long discussion about naming the > new cross-head function and associated predefs > I see you have retained deadNote as the base > name. > > I thought the outcome of the discussion > was to use xHead or crossHead for the base > name with deadNote being defined to invoke > the base function and predefs, so preparing > the way for other musical functions and predefs > to be defined to invoke the same base functions. > > Why did you decide not to do this? Given that the current usage is specifically designed for guitar tablature (as evidenced by the inclusion of TabNoteHead changes), it seemed the most semantically appropriate thing to do was to use deadNote. If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. In the meantime, we can move forward on tablature. As I see it, the current decision causes problems only if we were to change to xHead in the future and eliminate deadNote. And I see no plans in the future to eliminate deadNote. Does this make sense to you? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Trevor Daniels schrieb: Carl, Marc After the long discussion about naming the new cross-head function and associated predefs I see you have retained deadNote as the base name. I thought the outcome of the discussion was to use xHead or crossHead for the base name with deadNote being defined to invoke the base function and predefs, so preparing the way for other musical functions and predefs to be defined to invoke the same base functions. Why did you decide not to do this? Hello Trevor, as the discussion about the name ran, the "Lilypond Syntax Development" discussion has not been started, and as Graham told that either name we will choose, there's a chance of 50% it will be the wrong one, I came to the conclusion that 1) my primary goal was (and still is) the improved tablature support, and therefore, \deadNote is the term guitarists and bassists will understand (I don't want to offend the woodwind players, though ;-) 2) the internal definition of \deadNote takes care of chord constructs and the right representation within normal staves /and/ tablature staves - these features will normally not be used by any other instrument, so I think it would be better to provide an additional command which covers that area. 3) the patch was created before the naming dicussion ever started; we need its functionality to play around with furter improvements (like bends and such), so it would be great to apply the patch soon, so the "tablature feature group" can use it as a basis for the next steps. This doesn't necessarily mean not to provide an additional \xHead... command, but then again, I would prefer a clear solution, so Carls proposal about defining a command so that it would be easy to define crossHead = \changeNoteHead #'cross whatsoeverHead = \changeNoteHead #'whatsoever This again would be a good starting point for an aliases.ly file, by the way. Marc Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl, Marc After the long discussion about naming the new cross-head function and associated predefs I see you have retained deadNote as the base name. I thought the outcome of the discussion was to use xHead or crossHead for the base name with deadNote being defined to invoke the base function and predefs, so preparing the way for other musical functions and predefs to be defined to invoke the same base functions. Why did you decide not to do this? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Tue, Jul 21, 2009 at 9:37 AM, wrote: > > If this were strictly a tablature issue, I'd say keep it at "dead notes", > > since that is the guitar term. > > but what of citterns, ukes, banjoes and other modern plucked instruments > who would (do) use tablature notation? > > BTW, its been several decades since I was actively consulting tutors on > classical guitar (my first serious instrument), but I do not recall any > mention of 'dead' notes, tho from my singing experience I am reminded of > In classical guitar parlance, notes that are damped by the right palm as they're being played are usually designated "pizzicato," since the resulting sound is similar to that of pizz on bowed string instruments. In the scores I have where this is desired, the composer writes "pizz." followed by a spanner like this --| to indicate how long to keep doing it. Maybe in more modern scores it's done by different noteheads, I don't know. If I saw "dead notes" written, I think I'd know what to do, but I'm leaning toward "muted" instead. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
> If this were strictly a tablature issue, I'd say keep it at "dead notes", > since that is the guitar term. but what of citterns, ukes, banjoes and other modern plucked instruments who would (do) use tablature notation? BTW, its been several decades since I was actively consulting tutors on classical guitar (my first serious instrument), but I do not recall any mention of 'dead' notes, tho from my singing experience I am reminded of 'morire', an instruction to bring the sound volume down to nothing (but not suddenly, not quite the same as damping a string). I should think harp would have terminology for playing dampened; maybe even harpsichord/piano pedaling instructions (or organ swell shade instructions) would be relevant. My druthers would be for 'muted' over 'dead' - more professional, and a better cognate. Also, lots more instruments gonna wanna be using modern tablature than just guitar - bass guitar, uke, cittern, bozouki, banjo. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: Wikipedia (in a poorly-cited article) uses the term "ghost note" for all instruments (including the string-muted and palm-muted notes). This entry seems to indicate that "ghost note" is a term widely used with drums. Following up on links to "ghost note" in the guitar world causes me to believe that ghost notes in guitar are different than ghost notes in wind instruments. So I don't think that "ghost note" is a good universal term either. After this little search, I'm inclined to lean toward the Virginia Tech answer -- use the "false note" term, since it's not used anywhere else, and point it to "dead notes" for guitar and "ghost notes" for woodwinds. The situation seems to be somewhat complicated. I didn't know the term "false notes" (yes, I do, but not in this case :-) but "ghost notes" on guitar are parenthesized notes which are played so that the can hardly be heard. The same goes for drums (I don't play very well, but my teacher once told me that ghost notes on the snare are so silent that the microphones on stage don't even transfer a signal, but you can still "feel" the ghost notes in the groove). I have no experience in woodwind notation, so I cannot speak for them. It is possible to use dead notes and ghost notes as aliases, but guitarists expect something else in both cases, and drummers will be confused by ghost notes, so perhaps it would be the best to stay with the term "dead notes" and add a line or two in the Documentation about woodwinds clarifying that dead notes can be used as a synonym for ghost notes. Another (much more complicated solution) would be do define some kind of "environments" for special instruments. By including "guitar.ly", you'll have \deadNotes and stuff, by including "woodwinds.ly", you have a command called \ghostNotes which provides the same functionality - and so on. But I don't know if this really makes sense...probably it will be more confusing rather than helping the users. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Mon, Jul 20, 2009 at 02:09:57PM -0700, Mark Polesky wrote: > > I prefer "muted" rather than "dead". Though, the LilyPond internals > can get kind of violent, especially with the Hara_kiri_engraver, We actually changed the name based on a complaint -- \removeStaffContext used to be called \haraKiriStaff (or something like that). The renaming didn't reach all of the internals, but I suppose this could be considered a code janitor task. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/20/09 3:09 PM, "Mark Polesky" wrote: > > > Marc Hohl wrote: >> Hm, sounds kind of morbid to me, calling a note "dead", but since >> I am not a native english speaker, I cannot judge this from a neutral >> point of view. >> Do you think that there will arise big problems with these commands? >> I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't >> believe to confuse potential users. > > I prefer "muted" rather than "dead". Though, the LilyPond internals > can get kind of violent, especially with the Hara_kiri_engraver, and > ly:grob-suicide! (whose docstring simply says "Kill grob"). I would > rule that more as a homicide. By the way, I killed a grob once, just > to watch him die. > > - Mark > ps. joking aside, I think "muted" is alot better. After my previous post, I thought that the term in LilyPond ought to reflect the most appropriate musical usage term, rather than what I think is the best non-musical english term. So I did a search for "dead note" and found that it is widely accepted in the rock guitar world (which is the largest market for tablatures, I think). The Virginia Tech Multimedia Music Dictionary http://www.music.vt.edu/musicdictionary/ has an entry for "dead note" that consists solely of a link to the entry for "false note"; both the guitar term "dead note" and the wind instrument term "ghost note" point to the term false note. But I can't find any other links in the first few pages of Google to indicate that this VT usage is commonly-accepted or widespread. Wikipedia (in a poorly-cited article) uses the term "ghost note" for all instruments (including the string-muted and palm-muted notes). This entry seems to indicate that "ghost note" is a term widely used with drums. Following up on links to "ghost note" in the guitar world causes me to believe that ghost notes in guitar are different than ghost notes in wind instruments. So I don't think that "ghost note" is a good universal term either. After this little search, I'm inclined to lean toward the Virginia Tech answer -- use the "false note" term, since it's not used anywhere else, and point it to "dead notes" for guitar and "ghost notes" for woodwinds. If this were strictly a tablature issue, I'd say keep it at "dead notes", since that is the guitar term. But Marc's excellent patch also applies to musical staffs, and those notating for woodwinds might want to use it as well (although that can be done with an override, since it's not part of a chord). Anyway, what do you think we should do for this notation? Thanks, Carl > > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/20/09 3:09 PM, "Mark Polesky" wrote:
>
>
> Marc Hohl wrote:
>> Hm, sounds kind of morbid to me, calling a note "dead", but since
>> I am not a native english speaker, I cannot judge this from a neutral
>> point of view.
>> Do you think that there will arise big problems with these commands?
>> I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't
>> believe to confuse potential users.
>
> I prefer "muted" rather than "dead". Though, the LilyPond internals
> can get kind of violent, especially with the Hara_kiri_engraver, and
> ly:grob-suicide! (whose docstring simply says "Kill grob"). I would
> rule that more as a homicide. By the way, I killed a grob once, just
> to watch him die.
grobicide, not homicide, I think! :)
>
> - Mark
> ps. joking aside, I think "muted" is alot better.
>
So perhaps we have
4
\muted{ c d e f g}
{
\mutedNotesOn
c d e f g
\mutedNotesOff
c d e f g
}
Or maybe it becomes
{
\mutedOn
c d e f
\mutedOff
c d e f
}
I think I prefer this to \deadNote, \deadNotesOn, \deadNotesOff.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Marc Hohl wrote: > Hm, sounds kind of morbid to me, calling a note "dead", but since > I am not a native english speaker, I cannot judge this from a neutral > point of view. > Do you think that there will arise big problems with these commands? > I think \deadNotesOn and \deadNote are rather self-explanatory, so I don't > believe to confuse potential users. I prefer "muted" rather than "dead". Though, the LilyPond internals can get kind of violent, especially with the Hara_kiri_engraver, and ly:grob-suicide! (whose docstring simply says "Kill grob"). I would rule that more as a homicide. By the way, I killed a grob once, just to watch him die. - Mark ps. joking aside, I think "muted" is alot better. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
On 7/17/09 10:16 AM, "Marc Hohl" wrote:
Carl Sorensen schrieb:
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
I prefer to offer both variants.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
Yes, I had that before, but I decided to remove the plural s, because
in chord constructs, it works only on the next note, and in normal
contexts,
c d \deadNote e f
influences only the e (\deadNotes would imply to influence e and f, in
my opinion).
When one uses { }, \deadNote works on a group of notes, so the meaning here
is clear. So personnally, I wouldn't change it ...
Thinking of similar functions, like \relative and \harmonic, perhaps we
should just name the function to \dead. Then we'd have
4 or \dead {c d e f g a b}
This also brings more distinction between \deadNotesOn and \dead; one of my
concerns was potential confusion between \deadNote and \deadNotesOn. What
do you think?
Hm, sounds kind of morbid to me, calling a note "dead", but since
I am not a native english speaker, I cannot judge this from a neutral
point of view.
Do you think that there will arise big problems with these commands?
I think \deadNotesOn and \deadNote are rather self-explanatory, so I
don't believe to confuse potential users.
Marc
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/17/09 10:16 AM, "Marc Hohl" wrote:
> Carl Sorensen schrieb:
>>
>> Right, so we *must* have the function mode. Do we need the setting mode as
>> well? I don't feel strongly about eliminating it, but I don't feel strongly
>> about keeping it either. I trust your judgment.
>>
> I prefer to offer both variants.
>> However, now that I think about it, for the function call, I would prefer
>> the name \deadNotes (plural) instead of \deadNote (singular), because it can
>> take multiple notes in its argument.
>>
> Yes, I had that before, but I decided to remove the plural s, because
> in chord constructs, it works only on the next note, and in normal
> contexts,
> c d \deadNote e f
> influences only the e (\deadNotes would imply to influence e and f, in
> my opinion).
> When one uses { }, \deadNote works on a group of notes, so the meaning here
> is clear. So personnally, I wouldn't change it ...
Thinking of similar functions, like \relative and \harmonic, perhaps we
should just name the function to \dead. Then we'd have
4 or \dead {c d e f g a b}
This also brings more distinction between \deadNotesOn and \dead; one of my
concerns was potential confusion between \deadNote and \deadNotesOn. What
do you think?
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
I prefer to offer both variants.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
Yes, I had that before, but I decided to remove the plural s, because
in chord constructs, it works only on the next note, and in normal
contexts,
c d \deadNote e f
influences only the e (\deadNotes would imply to influence e and f, in
my opinion).
When one uses { }, \deadNote works on a group of notes, so the meaning here
is clear. So personnally, I wouldn't change it ...
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
I don't want to blame others here, but this piece of code was 1:1 copied
from Neil's mail.
Shall I reformat it and send a new patch, or are there other
possibilities to correct it?
This kind of judgment is somewhat subjective. You can leave it as is, or
you can reformat it. If you reformat it, please send a new patch.
If this is the only thing to change, I will leave it as is until I had
to apply
changes (for parentheses or additional functions) - not because I'm
lasy, but because of my incomplete knowledge of git (it is still a kind
of a fight each time)
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
Great! This opens the possibilitiy of drawing parentheses around chords,
isn't it?
It will, but it may yet have its own problems. It will parenthesize any
stencil. I don't know if the set of noteheads forms its own stencil
(separate from the stem) or not. If it does, we'll be home free on
parenthesizing chords. If not, we'll still have to figure out how to get
the set of noteheads for parenthesizing.
Ok, let's wait and see.
Marc
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/17/09 2:13 AM, "Marc Hohl" wrote:
> Carl Sorensen schrieb:
>>
>> On 7/16/09 9:56 AM, "Carl Sorensen" wrote:
>>
>>
>> 3) Is it necessary (or desirable) to have both \deadNote and
>> \deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
>> DeadNotes, I can't imagine that it's better to write
>>
>> \deadNoteOn e e deadNoteOff
>>
>> than
>>
>> \deadNotes{e e}.
>>
>> If there's no value to the On..Off pairs, then it's probably best to
>> eliminate them. But if there is value, we can keep them. And I'm not the
>> judge of value. I'm just asking the question.
>>
> Hm, I introduced the ..On/..Off pairs first, because this syntax seemed
> to be
> "lilypondish" - and easier to read, especially if there are long
> passages played
> palm mute- or dead note-style. The latter construct looks more like a
> programming language to me (yes, in fact it is a programming language, but
> as there are many users not familiar with computer programming, we should
> avoid this in general - but this is rather philosophical here).
There are actually two different "lilypondish" constructs. One is a
setting, the other is a function.
For example, we do \relative c' {...} and \transpose e f { ... } which are
exactly equivalent to \deadNote { ... }.
But we also have lots of settings.
> On the other hand, for a single dead note
> \deadNoteOn e \DeadNoteOff
> is way too complicated, and furthermore
> < c \deadNoteOn e \deadNoteOff g > won't work, so there is need for the
> second syntax.
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
> >
>>
>> 4) Formatting nit on scm/tablature.scm
>>
>> line 125-128: I think it would look better to put all the arguments to
>> ly:stencil-combine-at-edge on line 124.
>>
>> line 129-131: I would like it better to have the last three arguments to
>> the first ly:stencil-combine-at-edge call on line 125, nested to the same
>> depth as the inner (ly:stencil-combine-at-edge call.
>>
>>
> I don't want to blame others here, but this piece of code was 1:1 copied
> from Neil's mail.
> Shall I reformat it and send a new patch, or are there other
> possibilities to correct it?
This kind of judgment is somewhat subjective. You can leave it as is, or
you can reformat it. If you reformat it, please send a new patch.
>> Other than that, things look good.
>>
>> Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
>> command that will be better than the current parentheses; it will draw the
>> parentheses as slurs. This may be something you want to use in the future.
>>
> Great! This opens the possibilitiy of drawing parentheses around chords,
> isn't it?
It will, but it may yet have its own problems. It will parenthesize any
stencil. I don't know if the set of noteheads forms its own stencil
(separate from the stem) or not. If it does, we'll be home free on
parenthesizing chords. If not, we'll still have to figure out how to get
the set of noteheads for parenthesizing.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: 2) Your regression test for the modernTab clef: Doc header should say "four- to seven- stringed instruments", which means instruments having four to seven strings. "four to seven stringed instruments" means four to seven instruments having strings. Isn't english fun? You should demonstrate in the regtest that it works for four strings and seven strings, and that it works with various staff sizes. You may want two different regtests -- one that shows variations in string numbers and one that shows variation in sizes. Here it is - gzipped for proper line endings. The first file, modern-tab-clef.ly shows tablature for four and seven strings, while the second, modern-tab-claf-scaled.ly demonstrates the scaling. Marc additional-regtests.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
On 7/16/09 9:56 AM, "Carl Sorensen" wrote:
Marc Hohl has completed a patch for improved tablature support. It is
available for review at:
http://codereview.appspot.com/95059
Please review and comment.
Thanks,
Marc,
Here are some comments.
1) All regression tests should be \version "2.13.4" -- I'll fix that.
Thank you!
2) Your regression test for the modernTab clef:
Doc header should say "four- to seven- stringed instruments", which means
instruments having four to seven strings. "four to seven stringed
instruments" means four to seven instruments having strings. Isn't english
fun?
Ah, I see. Yeah, english *is* fun, but sometimes I just stumble through
half-finished sentences in despite search of a missing word, but at least,
the work on lilypond seems to improve my english a bit.
You should demonstrate in the regtest that it works for four strings and
seven strings, and that it works with various staff sizes. You may want two
different regtests -- one that shows variations in string numbers and one
that shows variation in sizes.
Ok, I will provide additional regtests.
3) Is it necessary (or desirable) to have both \deadNote and
\deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
DeadNotes, I can't imagine that it's better to write
\deadNoteOn e e deadNoteOff
than
\deadNotes{e e}.
If there's no value to the On..Off pairs, then it's probably best to
eliminate them. But if there is value, we can keep them. And I'm not the
judge of value. I'm just asking the question.
Hm, I introduced the ..On/..Off pairs first, because this syntax seemed
to be
"lilypondish" - and easier to read, especially if there are long
passages played
palm mute- or dead note-style. The latter construct looks more like a
programming language to me (yes, in fact it is a programming language, but
as there are many users not familiar with computer programming, we should
avoid this in general - but this is rather philosophical here).
On the other hand, for a single dead note
\deadNoteOn e \DeadNoteOff
is way too complicated, and furthermore
< c \deadNoteOn e \deadNoteOff g > won't work, so there is need for the
second syntax.
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
I don't want to blame others here, but this piece of code was 1:1 copied
from Neil's mail.
Shall I reformat it and send a new patch, or are there other
possibilities to correct it?
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
Great! This opens the possibilitiy of drawing parentheses around chords,
isn't it?
Thank you.
Marc
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: On 7/16/09 5:54 PM, "Jonathan Kulp" wrote: Carl Sorensen wrote: So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. I've been looking more carefully at the regtests and think that the texidoc headers might be enough to get started on the new parts of fretted-strings.itely. Would you like me to prepare a patch based on these so that it can be applied at the same time as the program code, or should we just wait? Let's wait a bit -- I'd like to see if we can get somebody in the tablature group to do it. If they don't bite, then we'll have you do it. Of course I can write a documentation, but I had the same idea as Carl - there is a group of people interested in tablature features, and when the patch is applied and the features are availabe, I'll ask them if someone wants to work on the documentation. Marc Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 5:54 PM, "Jonathan Kulp" wrote: > Carl Sorensen wrote: >> >> So, while I asked Marc to provide documentation, I didn't require it. I >> did, however, require regtests. >> >> As soon as we get the patch applied, we can ask one of the people who is >> clamoring for improved tab support on -user to get involved in writing the >> documentation for it, working with you to get it in proper form. >> > > I've been looking more carefully at the regtests and think that > the texidoc headers might be enough to get started on the new > parts of fretted-strings.itely. Would you like me to prepare a > patch based on these so that it can be applied at the same time as > the program code, or should we just wait? Let's wait a bit -- I'd like to see if we can get somebody in the tablature group to do it. If they don't bite, then we'll have you do it. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. I've been looking more carefully at the regtests and think that the texidoc headers might be enough to get started on the new parts of fretted-strings.itely. Would you like me to prepare a patch based on these so that it can be applied at the same time as the program code, or should we just wait? Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 9:56 AM, "Carl Sorensen" wrote:
> Marc Hohl has completed a patch for improved tablature support. It is
> available for review at:
>
> http://codereview.appspot.com/95059
>
> Please review and comment.
>
> Thanks,
Marc,
Here are some comments.
1) All regression tests should be \version "2.13.4" -- I'll fix that.
2) Your regression test for the modernTab clef:
Doc header should say "four- to seven- stringed instruments", which means
instruments having four to seven strings. "four to seven stringed
instruments" means four to seven instruments having strings. Isn't english
fun?
You should demonstrate in the regtest that it works for four strings and
seven strings, and that it works with various staff sizes. You may want two
different regtests -- one that shows variations in string numbers and one
that shows variation in sizes.
3) Is it necessary (or desirable) to have both \deadNote and
\deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
DeadNotes, I can't imagine that it's better to write
\deadNoteOn e e deadNoteOff
than
\deadNotes{e e}.
If there's no value to the On..Off pairs, then it's probably best to
eliminate them. But if there is value, we can keep them. And I'm not the
judge of value. I'm just asking the question.
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
>
> Carl
>
>
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: I like the features, especially the "moderntab" clef. Is it best for "numbersOnly" to be default? I'm not saying it isn't best, I really don't know. I'm a classical guitarist and have never dealt with tablature except when working on the fretted-strings.itely and recently when doing another project. Is it most common for tab not to have any rhythmic indication? If tab is in a staffgroup with traditional notation, then no rhythmic indication is given, because the rhythm comes from the traditional notation. If tab is in a staff by itself, it has rhythmic indication, and that is when \tabFullTab would be used to include stems and flags. The folks who care about tab (which do not include me, BTW) think that numbers only should be the default. Thanks for the explanation. That's good enough for me. :) Yes, we need documentation for the new work. However, according to established policy (by Graham?), developers are not required to add documentation information. Documentation editors add documentation, using regtests as their templates. So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. Yes, I saw these and looked through them. They should be good for the docs. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. Excellent. I'm happy to put it into texinfo format and make the patch, but I'd prefer that actual tablature users write the text. Thanks, Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/16/09 4:00 PM, "Jonathan Kulp" wrote: > Carl Sorensen wrote: >> Marc Hohl has completed a patch for improved tablature support. It is >> available for review at: >> >> http://codereview.appspot.com/95059 >> >> Please review and comment. >> >> Thanks, >> >> Carl >> > > I like the features, especially the "moderntab" clef. Is it best > for "numbersOnly" to be default? I'm not saying it isn't best, I > really don't know. I'm a classical guitarist and have never dealt > with tablature except when working on the fretted-strings.itely > and recently when doing another project. Is it most common for tab > not to have any rhythmic indication? If tab is in a staffgroup with traditional notation, then no rhythmic indication is given, because the rhythm comes from the traditional notation. If tab is in a staff by itself, it has rhythmic indication, and that is when \tabFullTab would be used to include stems and flags. The folks who care about tab (which do not include me, BTW) think that numbers only should be the default. > > I think the patch set should include one for fretted-strings.itely > showing the tab clef and whatever other features should be shown, > as well as a brief paragraph about tab conventions. Yes, we need documentation for the new work. However, according to established policy (by Graham?), developers are not required to add documentation information. Documentation editors add documentation, using regtests as their templates. So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. Thanks for your review, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote: Marc Hohl has completed a patch for improved tablature support. It is available for review at: http://codereview.appspot.com/95059 Please review and comment. Thanks, Carl I like the features, especially the "moderntab" clef. Is it best for "numbersOnly" to be default? I'm not saying it isn't best, I really don't know. I'm a classical guitarist and have never dealt with tablature except when working on the fretted-strings.itely and recently when doing another project. Is it most common for tab not to have any rhythmic indication? I think the patch set should include one for fretted-strings.itely showing the tab clef and whatever other features should be shown, as well as a brief paragraph about tab conventions. Great work, though. thanks. :) Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Improved tablature support
Marc Hohl has completed a patch for improved tablature support. It is available for review at: http://codereview.appspot.com/95059 Please review and comment. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
