[Feature Request] default note length & bar line

[suntong]

Trying to make the jianpu notation to be "aesthetics, flexibility and ease of use", I think the following is a good idea:

By default, notes in Alda are quarter notes. You can set the length of a note by adding a number after it. The number represents the note type, e.g. 4 for a quarter note, 8 for an eighth, 16 for a sixteenth, etc. When you specify a note length, this becomes the “new default” for all subsequent notes. o4 c4 c8 c c16 c c c c32 c c c c c c c | c1 You may have noticed the pipe | character before the last note in the example above. This represents a bar line separating two measures of music. Bar lines are optional in Alda; they are ignored by the compiler, and serve no purpose apart from making your score more readable.

IE, there are two things we can borrow from the above.

• Introducing the “new default” for all subsequent notes.

So, the jianpu-ly notation of

1 q1 q1 s1 s1 s1 s1 d1 d1 d1 d1 d1 d1 d1 d1

can be simplified as

1 q1 1 s1 1 1 1 d1 1 1 1 1 1 1 1

• I also like the idea of the pipe | character, which can be used to represent a bar line separating two measures of music, which can be made optional, and ignored by the compiler, and serve no purpose apart from making the score more readable (and help parsing when note crosses barline cases occurs)

I believe the above two are easily to adopt, do not conflict with existing jianpu-ly notation, and when introduced, will improve the usability with just minor changes.

What do you say?

[ssb22]

Hi, yes it's doable but there are two problems:

1. A lot of existing jianpu-ly input will have to be changed, because right now 1 always means a crotchet (quarter note), and if we change that to meaning "the same length as before", then we will have to look out for all the places where we really do want a quarter note, and put in whatever code we need to to say "yes I really do want this to be a quarter note and not the same length as the previous note". So it's not entirely backwards compatible. We could introduce some kind of "switch to the other way of doing it" option, but that might make jianpu-ly input more complicated than it needs to be.
2. When you cut and paste a section of music from one place to another, you might have to beware of what the current note length is. I've made mistakes along the lines of "forgot the current note length is wrong" when working in Lilypond directly, so I'm not sure about bringing that back. Jianpu music is normally quite simple, so I'm not sure if the benefits of having a "current note length" (save a few keystrokes) are really worth the disadvantages (have to be more careful about when it needs to be changed, especially when moving or copying a passage of music from one place to another).

[suntong]

Yes, indeed, I've foresee those two problems.

For #1, no, it's not my intention to break any backward compatibility. I think this is the key to answer both questions. I.e., the old way still works (and would still be prefered), and the "current note length" might need a new directive. IE provide people a choice, but not forcing them into anything.

For the 2nd point, the Lilypond's built-in limitation, and "1 always means a crotchet (quarter note)" my view on this is that, tools are there to assist people, but not to limit/restrict people. Just like in programming language, in C/C++, people need to be very aware of the differences between v.name vs v->name, whereas in moden Golang, both cases are specified as v.name and the interpreter will make the determination. IE, if a program/tool can bring simplicity for human being while it does a bit of extra work, it is worthwhile. For me, looking at 1 q1 q1 s1 s1 s1 s1 d1 d1 d1 d1 d1 d1 d1 d1 and 1 q1 1 s1 1 1 1 d1 1 1 1 1 1 1 1, I will find the latter more clearer and more easy to write.

Please consider, please, the changes to the source code is minimum.
Thanks

[suntong]

It'll make children songs like this to be very clean in the notes:

[suntong]

It'll make children songs like this to be very clean in the notes:

Thanks for the fix. I've prepared a demo for showing the differences -- add two ways to do demo-ssg