Jonathan «puts the finger» on an interesting topic.
While most of the basic commands for note entry are quite intuitive (and that's a good thing!), there are some commands that the syntax seems counter-intuitive for a composer or a simple musician. For example, the command \times. Normally, we only write one number for tuplets, but in contemporary music, it is common to write a ratio to clarify the actual duration of the tuplet. For a triplet, we can write "3", but we can also write "3 : 2" over the note. It says "3 notes in the duration of 2" (I know most of you know that, but it is to explain the syntax. Also my English syntax might be bad). It is useful to make the difference between "7 : 8" and "7 : 4", for example. Some contemporary composers even write "7 : (quarter note figure)" to say "7 notes in a quarter note duration" But the \times function demands for a triplet to write "2/3". I know it might seem logical to ask for the fraction of the note. But in fact, for a composer, it is far more intuitive to write "3/2" or even better, "3:2" than "2/3" for a triplet. Writing "2/3" for a 3:2 tuplet is not a big problem, but what about 10:7? Also, for simple note entry, I think you should put MORE freedom for the possible order to write all the symbols. For example you want to put a eighth note at c# one octave higher, you want to make an octave check and make sure the sharp appears. We could write it in many ways cis'!=''8 cis'!8='' c8is!'='' cis8'=''! cis'8!='' etc. But LilyPond accepts only one way of writing it ... and I don't remember which one! And I didn't find any syntax rule about the exact order of the commands in the user manual. To put a syntax rule in the user manual would be good, but to make the compiler more flexible would be even better. Finally, it would be a good thing to revise the grammar of the functions in LilyPond by composers and musicians who are NOT programmers to make the LilyPond language more intuitive, so the learning curve would be less steep. That would be a great thing to do for an eventual LilyPond 3.0. And I would be willing to give some of my free time for that! Regards, Frédéric Chiasson 2006/12/18, Mats Bengtsson <[EMAIL PROTECTED]>:
Jonathan Henkelman wrote: > > Ay - I hear you there. I have been considering taking on this project, and I > still need to figure out if I have time before I get myself in over my head > and unable to keep up with the commitment others might have made to me. A > couple of questions I have been pondering in this regard: > > 1) Since I am fairly new to Lilypond, are there folks out there that would be > willing to aid me in the likely event of confusion (I assume this group will > do). > Of course! > 2) If/when inconsistencies in the language turn up - as I'm sure they will - > is there an interest amoung the programmers to correct these? > Since the parser is implemented using lex and bison, there shouldn't be any formal inconsistencies. At second thought, larger and larger parts of the syntax is now implemented as Scheme functions, but they too have a formal syntax check. However, I'm sure you can find lots of language constructs that are confusing. Note that the syntax and semantics has evolved over the years and still is. Many of these changes have in my opinion made the syntax more consequent and simpler. > 3) A complaint I have seen both commonly on this archive and also on > the "todo" list of the co-ordinators for lilypond, is to try and make the > learning curve a bit less steep. One logical outcome of a document of this > type is that it can be used to "clean up" the language - i.e. fulfilling this > last goal. Is there any interest on the part of the programmers/organizers to > undertake this task should I ever get this doc completed. I envision a > process whereby the basic notation of lilypond stays the same (obviously), but: > > - perhaps some command forms would be dropped, > - perhaps users would be forced into less freedom in the syntax > This is one concern I have raised a couple of times. There are lots of optional constructs, which often confuses new users. They certainly save some typing and perhaps lower the initial threshold a bit for new users. However, I think the reduced number of key strokes only is significant in small test examples (which is what the main developers mostly do, and myself and other who help on the mailing list) but not in any real world typesetting. > - perhaps come commands would be morphed to fit into a framework that more > closely matches other commands. > - any changes would idealy be changeable in input scripts using some sed/diff > routines to update routines would be automated (no point in unnecessarily > agravating the end user) > That's what convert-ly does. > Some examples: > As I can see it now, there are numerous ways to create contexts. In fact if I > understand correctly, most commands create contexts. One example I saw in the > archive explicly used the context command in all (most?) of these cases. > Perhaps either forcing the use of context everywhere a context is being > created, or eliminating its use altogether as it is basically implied > everywhere would be helpful > See "Creating contexts". Use \new if you want to make sure to get a new unique context. Use \context if you want to add on to an already existing one. However, you can use \context to create a new context if you manually make sure that the identifier is unique, so there's a flexibility that may cause confusion. > I have been banging my head against the \combineparts routine. Mats suggested > a different form using polyphonic notation which does the task just as > nicely. \combineParts does not (to my naive eyes seem to fit the same form as > the other commands (e.g. \new Staff, \new Voice etc.) Differences such as this > make the learning curve steeper. > If you search the mailing list archives, you will find lots of discussions on the \partcombine function. The general conclusion is that it often doesn't do what you want to do and that it's impossible to support since the implementation is too complex. However, there are plans to reimplement it from scratch. > I think in the end Lilypond would be a cleaner language, but as always happens > when trying to eliminate legacy code there is always someones toes being > stepped on... > > What do people think about this... > > [snip established and reported error] > > >>> Finally, is the web interface for posting to this archive the most >>> > straight > >>> forward method? I tried posting this yesterday, but it got lost in the >>> ether. Is there perhaps an email address I can send the post to, where it >>> will get sent back for validation etc. >>> >> I believe the email address is at the bottom of every message on the >> list: lilypond-user <at> gnu.org >> > > Not on my web based threaded client (Loom?). I feel like such a newbie, but I > can't find it on the FAQ or anywhere else... I can post to gmane.test, but > how would I post to followup without using the web interface (i.e. to avoid > the top-post checking in cases when I am not actually top-posting...) > See www.lilypond.org -> Documentation or www.lilypond.org -> About for links to the mailing list archives and administration pages where you can subscribe to the mailing lists and after that use your ordinary email client to send emails to the lists. /Mats _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
