Re: Augmentation dot positioning

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> 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.

Su why is a symbol needed?  Symbols always require some secret lookup
mechanism.  Why not just use a list here?  When the list needs to be
calculated, it can be a callback, right?

-- 
David Kastrup