Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

duration's position and something #69

Open
YesGH opened this issue Jan 29, 2025 · 5 comments
Open

duration's position and something #69

YesGH opened this issue Jan 29, 2025 · 5 comments

Comments

@YesGH
Copy link

YesGH commented Jan 29, 2025

The duration have two position now: less than 1/4th before the pitch and large, behind the pitch.

Put them all behind the pitch maybe better, and for efficiently note inputting by number pad, using the figure instead of alphabet. That is

whole note ->1, 2/4/8/16/32/64/128/256th -> 2 4 8 6 3 5 7 9....

example like: 11 12. 12 14 18 16 13 15 17 19 (need remember 6 ->1/16th, 3->1/32th, 5->1/64th, 7->1/128th...., easy for musicians)

or 2 simpler: 1--- 1-- 1- 1 1q 1s 1d 1h ( easy for english-speaking people)

or 3 simplest:1--- 1-- 1- 1 11 12 13 14 ( second digit 1 2 3 for the underline numbers . easy for most people)

@ssb22
Copy link
Owner

ssb22 commented Jan 29, 2025

Having both pitch and duration as numbers might be quicker to type in with a number pad, but what if we want to fix a mistake later? We have to think about not only the initial typing in but also how easy it is to fix things. I think I'd get really confused if every note was 2 digits, and the digit on the left meant something different from the digit on the right.

Also, how would it work with grace notes and chords, which already have more than one number in the same word?

I agree I don't really like q for quaver, s for semiquaver etc: it would be nice if the typed input looked as much as possible like the Chinese output, which is why it's using dashes for notes longer than 1 beat. But there's nothing in ASCII that can add underlines or double underlines easily, so I had to compromise for notes less than 1 beat.

There is an alternative notation you can use, and that's to add a \ at the end of notes: 3\ is the same as 3q (or q3, but you can't write \3 because \ at the start of a word introduces a Lilypond command). And 3\\ is the same as 3s (or s3), and so on. But this has not yet been documented (other than in a comment in the parseNote function) because I wasn't sure how to concisely explain that it matters where you put that \ (as it doesn't matter where you put the q or the s: it can go before or after the number, but the \ must go after if you use that style).

@YesGH
Copy link
Author

YesGH commented Jan 30, 2025

For p1&2:
For note, normally the first digit is pitch, following octave, accidental, duration... , the grace using the g[ #45], the chord can add the <135> like lilypond's. so the digit for pitch is easy to fix from other digit.

For p3:
If it can put after pitch q s d h for 8/16/32/64th is ok, or 1 2 3 4 for the underline numbers maybe easier for memory.

For p4:
That's good, the duration can put after pitch and can display more than 10 underlines using the ASCII code \ . That is

1--- 1-- 1- 1 1q 1s 1d 1h , 1\\ .... (using the \ for duration is less than 1/64th , need remomber "qsdh" for enter the note efficiently)

And, the duration figure put after not before the pitch, fix its position is better for reading and checking later.

@ssb22
Copy link
Owner

ssb22 commented Jan 30, 2025

Unfortunately we can't just make all chords look like <135> with angle brackets like Lilypond's, because there are already versions of jianpu-ly, which are already being used by people, where chords are like 135 (no angle brackets). If we now change it to require all these input files to be rewritten like <135>, that is going to cause a lot of headache when people upgrade to the new version. Lilypond has a \version tag and convert-ly to handle syntax changes during upgrades, but even then it doesn't always work. If possible I'd really rather try to make sure we keep "backward compatibility", i.e. whatever new things we add to the language, I'd like the input files people already have to still work.

We can still change the syntax if we make the new syntax optional. For example, there is currently a command KeepLength (not yet documented)—if KeepLength occurs in the input, the behaviour is changed so that the duration of a note persists for all subsequent notes until changed, so you need to say c to set it back to crotchet. This is completely incompatible with previous input files, but someone wanted it, so I said OK we can do that but you have to write KeepLength in your input files to get the new behaviour. That way, nobody else who has old input files will get a shock when they upgrade.

So in this case perhaps we could have NumericDurations or NumberDurations or similar in the input file to indicate that the new style should be used.

Unfortunately we can't use / because that's been taken by tremolo commands (unless we change that in the alternate syntax, but I'm a bit worried about how complicated a change this might become: it's almost as if it might be easier to write an extra translation layer before the input gets to jianpu-ly if we want to experiment with very different input types).

@YesGH
Copy link
Author

YesGH commented Jan 31, 2025

Using command to change the syntax is a good idea, it only add a command ahead the notes, that can "backward compatibility" the old file.

If using new syntax, writing the command accordingly only.

KeepLength, NumberDuration are for duration
mybe KeepLine, OmitSpace for lyrics line return and the slur etc. bracket near its note?

@suntong
Copy link
Collaborator

suntong commented Feb 2, 2025

I think I'd get really confused if every note was 2 digits, and the digit on the left meant something different from the digit on the right.

Me too. I think we'd better avoid that, IMHO.

There is an alternative notation you can use, and that's to add a \ at the end of notes: 3\ is the same as 3q...

So,

1--- 1-- 1- 1 1\ 1\ \ ...

Yeah, I like that. This is a very beautiful design. much better than 1s 1q to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants