lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Fret Diagram markup


From: Heikki Johannes Junes
Subject: RE: Fret Diagram markup
Date: Sat, 19 Jun 2004 14:46:03 +0300 (EEST)
User-agent: HUT webmail, IMP 2.2.6

On Mon, 14 Jun 2004 18:01:43 -0600 "Carl D. Sorensen" <address@hidden> wrote:

> So I suppose we could do as you propose, and have the note in Tablature
> be replaced by the fret in FretDiagrams.  That seems reasonable.  Under
> this scenario, things become position independent, because we have the
> following:
> No prefix => fret
> \ prefix => string
> - prefix => fingering
> -( and -) => start and end of barre

Good, this is then the way to go. File lily/tab-note-heads-engraver.cc has
something to do with the parser, maybe there should be something similar? I am
trying to give a little push (if I am even able to), shouldn't there be a new
file: lily/fret-diagram-engraver.cc ? Oops, this needs compiling the source.

I would recommend also to be verbose on telling what property is changed. In
this case, items
  (place-fret 6 2 1) 
  (barre 6 1 2)
  (place-fret 3 5)
would be something like
  (fret-on-string-numbered 2 6 1)
  (fret-barre 2 6 1)
  (fret-on-string 5 3)
such that the name of the property function matches with the given value of the
property.
>From the viewpoint of the "f\6-1" syntax, I prefer to give the fret-number to 
>be
given first also in the verbose syntax. This kind of syntax has its stress on
the musical content, as the note name is given first and only after that the
articulation attached to it. 

> BTW, I went ahead and implemented your last proposal, just to see how
> things worked.  It certainly made the definition strings shorter, but
> at the same time they were less descriptive. I think I like having the
> definition string solely for content, and using props for all
> formatting instructions.
> 
> Thanks again for your input.
> 
> Carl

Oh, you ment the terse syntax. I had in my mind that the terse syntax just
columnwise compresses two dimensional syntax into a one dimensional syntax, for
example:
 xo   o
 |||||| 
 ||234|
 ||||||
becomes just "x;o;2-2;2-3;2-4;o;". Somehow in this syntax the two dimensional
output can bee 'seen'.

I have still one proposal. Barre could have optionally two different types of
output. The first one, which is implemented, as slur, and the second one, which
would need to be implemented, as horizontal straight line between the attached
frets. The width of the horizontal line would match with the diameter of the
fret circles, or be something between the diameter and zero.

You are doing well. It seems like the changes you make find easily their way to
the CVS tree.

-- 
  Heikki Junes




reply via email to

[Prev in Thread] Current Thread [Next in Thread]