lilypond-user
[Top][All Lists]
Advanced

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

Re: Augmentation dot positioning


From: Carl Sorensen
Subject: Re: Augmentation dot positioning
Date: Wed, 26 Oct 2016 00:25:15 +0000
User-agent: Microsoft-MacOutlook/14.6.9.160926


On 10/25/16 8:57 AM, "Chris Yate" <address@hidden> wrote:

>Hi Carl,
>Firstly, thanks for your work on this!
>At a quick glance, the only two situations that need dots-limit =2 are
>#11 and #23.

Yes, those were my two cases as well.

>A side issue:
>An idea I've just had: would it be useful to have a more flexible
>positioning system similar to that for rests? (e.g. "f4/rest"). It might
>be useful to have the option of custom dot placement for special cases.
>I'm sure there's already a way to achieve this, but it's probably not
>easy. If anyone thinks it worthwhile, I will think more about a suggested
>syntax... Maybe something for the LSR rather than core functionality.

As far as I can see in the existing code (not including my changes) there
is no way to do this.

But, this could be easily added onto my current architecture. I had
actually planned for it earlier, but my planned architecture didn't work
out.  Butn now I can add it back in.

The grob property that defines which algorithm is to be used to determine
dot locations is currently a symbol.  I can change it to symbol or list,
and if it's a list, it's just a list of staff positions that should have
dots.  The Scheme code returns such a list, and it would be easy to check
in the C++ code for it being a list, and then do the right thing with the
list.

I don't think there's any new syntax needed.

Thanks for the good input!

Carl








reply via email to

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