Idea for subdivide beams

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Idea for subdivide beams

hs kim
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]]

I'm sorry that I can't see you result of upper commands because I don't
know how to, but I think it is more intuitive and easier than normal
subdivide style.

I love lilypond very much and always wish your good luck. Thank you for
reading this long letter. And apologize for wrong grammars.
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Idea for subdivide beams

Urs Liska-3
Hi Kim,

thank you for the suggestion.

4. August 2019 16:14, "hs kim" <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel