On 11 July 2016 at 22:44, Carl Sorensen wrote: > On 7/11/16 12:06 PM, "David Kastrup" wrote: > >>I think the fundamental question is how to provide the information. >> >>We have a similar choice to make with tablature: enter the musical >>information, or enter the playing instructions. >> >>With tablature, the choice ended up being notes, occasionally helped >>with string numbers. Where this "occasionally helped" is not present, >>you have the advantage of being able to _transpose_ and a new tablature >>falls out.
Except that this doesn't work with diatonic accordions at all. Except for some rare occasions it's impossible to get a tablature for a differently tuned accordion (and differently tuned ones cannot play together at all). Here's it's actually the reverse. I would say that it would be desirable to be able to get proper scores (so that for example a piano can accompany the accordion player) for a differently tuned accordion playing on the same buttons. And in this case entering the music with "buttons" rather than pitches helps. Anyway, if the user would decide to enter pitches, like <f' a'>, then this could be played with either <"A4" "A5"> or <"C2" "C3">. Since LilyPond doesn't have the capability to offer interactive help to the writer, the lilypond could at best write "either A4 or C2" for <f'> or the user would have to manually enter the button label. And once the button label is required, asking to do both becomes very error-prone. I probably wouldn't mind a mode where I would type <f' a'>, then LilyPond would provide me both alternatives and write the complete score for me in "button notation" with alternatives (that would probably help a lot in the beginning when one doesn't know which button is which and if one gets the usual scores from somewhere), but eventually one would have to enter the button names to create unambiguous tablatures. The best I could do would be something like <f'\useA a'\useA> or <f'\useFirst a'\useFirst> to give a hint to LilyPond that the outermost row should be used for that particular pitch and it would then use "A4" and "A5" instead of "C2" and "C3". Also: entering the usual pitches is already supported. Maybe the only thing that's missing is the ability to effortlessly add nicely aligned tablatures at some places only. But entering button names is not yet supported and it would be great if there was a way to do it. >> You can change the string tuning, and a new tablature falls >>out. This would be the same with diatonic accordions: you could change >>your instrument to one with a different tuning or transpose the melody, >>and you'd get a new score. And/or you could change your choice of when >>to push or pull (assuming notes are available) and you'd get a new score >>appropriately changed. I'm a total beginner, but I'm afraid that you think too much from a perspective of a player of a chromatic accordion :) :) :). What you are proposing is impossible (or at least very hard) to do most of the time. Or at least the one doing this must know very well what he or she is doing. And even then: what prevents LilyPond from checking whether the song is "transposable" to a differently tuned accordion even if the input stays in "button names"? (But yes, I agree, being able to spit the button name suggestions automatically would be a nice feature in any case.) > I know nothing about diatonic accordions, but given your comment on this > it seems that the best approach would be to define an diatonic accordion > engraver that could take a note together with an accordion description > (the equivalent of a StringTuning) and automatically spit out the symbol. > It could be consisted in a new context that is an alias for ChordNames, > but with the chord-namer function changed to an accordion namer function. > And if you need the push/pull information to help decide the button you > could use \downbow and \upbow (at least in the beginning). I looked at http://lilypond.org/doc/v2.19/Documentation/notation/displaying-chords and I like the syntax \chordmode { c d e } that automatically generates the whole chord and this seems nice. (I don't like the fact that one cannot easily do things like {c \chordmode {c} c d}, but that's ok.) I made some short "summary" of my type of accordion at https://github.com/mojca/frajtonarca/tree/master/uglasitve https://github.com/mojca/frajtonarca/blob/master/uglasitve/basi-crop.pdf and the same song that I already posted yesterday at https://github.com/mojca/frajtonarca/blob/master/tablature/ljudske/na-planincah.pdf (The question mark means that I'm not sure whether this is how the chord is properly written / how it actually sounds. I was just blind-guessing.) It might be easiest to start with the basses than with the melody basses though. If this feature gets properly supported, it would make sense to provide some defaults, but it should be straightforward to provide a definition for the tuning somewhere and then to be able to enter the basses either as numbers (1-11) or as names (see the files linked above). I can also imagine that some people would want to use different positions of chords (like <d f a> instead of <f a d'>), but once defined, they should hopefully(?) remain consistent for the song. If the basses are entered as numbers, they could easily be "transposed" to a differently tuned accordion (please note that two differently tuned accordions cannot play together at all, except perhaps C-F-B playing with B-Es-As in B major, but many bands simply bring four accordions with them to the concert). So similar to \chordmode { c d e } I would like to be able to enter the basses like perhaps \someothercommand { <4> <9> <7> <3 4> } and then be able to draw both chords and chord numbers from potentially the same list (copy-paste is also fine :) without having to manually specify the chords each time. I don't know how well such a syntax combines with durations. How could I specify that <3 4> should last for three quarters (2.)?. > I think such an approach would require no changes to the parser, and could > actually be done in Scheme (using Scheme engravers) as an initial approach. Thank you, Mojca _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user