lilypond-devel
[Top][All Lists]
Advanced

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

Re: Idea for subdivide beams


From: Urs Liska
Subject: Re: Idea for subdivide beams
Date: Sun, 04 Aug 2019 14:50:46 +0000

Hi Kim,

thank you for the suggestion.

4. August 2019 16:14, "hs kim" <address@hidden> schrieb:

> Hi.
> I was making "la campanella". There was many subdivide beams but it was so
> confused that I can't make it anymore. That's why I decided to change the
> way subdivide beams are written.
> 
> In the stable branch, subdivide beams are too complicated to know. But my
> idea is (subdividing of four 32 note and four 16 note with 1/8)
> 
> \set subdividieBeams = #"8"
> a32[[ b c b] f16[ g a g]]

As I understand it this is a suggestion for an input syntax for manual beam 
subdivisions.
As such it would not be an approach to handle the beam subdivision problems on 
a fundamental level (https://sourceforge.net/p/testlilyissues/issues/5547/), 
but I think it would indeed be a good idea to have such a manual syntax - just 
as manual beaming is often necessary over automatic beaming.

However, the proposed syntax has two issues as far as I can tell:

* It changes the meaning of the single bracket, a well-established syntax,
  requiring really involved modifications for existing scores
* It would be somewhat inconsistent - as single brackets would mean something 
different
  in different contexts.
* I'm not sure about the issues for the actual parser.

Instead I would suggest to keep the meaning of the single [ ] as it is (=> 
manually beam the given group of notes), and add a new syntactic element for 
"beam subdivision" instead. A few suggestions (note that the following 
characters are already in use and should not be repurposed: . | - [ ] { } ( ) =

a32[ b c b ; f16 g a g]
a32[ b c b / f16 g a g]
a32[ b c b "]" f16 g a g]
a32[ b c b T f16 g a g]

To be clear: What this thread can achieve is a discussion about an *intent* for 
some new development. There would still have to be someone to actually take a 
look at it and implement it. And I think it's not totally trivial.

Urs



reply via email to

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