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

Add ability to set specific BPM #16

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

RastislavTuranyi
Copy link
Contributor

Description

Builds on #10. A new optional field has been added to GUI (next to the previous (karaoke) BPM field) and a new optional argument has been added to CLI, which allow users to specify the song BPM, i.e. the true BPM of the audio file. If provided, this is used to adjust all the notes such that they are of a length that is an integer multiple of the karaoke BPM, which should make the mapping easier if the OG singer sung the song accurately and precisely. This is because in most songs, to keep the rythm (or is it melod?), notes and breaks are usually evenly spaced. However, this option may cause some incorrect shifting, especially if the inputted BPM is off, or if the singer is off by a fraction of a beat, or if the kara.moe map is a bit off.

To test

  1. Map a song by inputting both of the BPM fields correctly. The #BPM field should be the inputted karaoke BPM, and all notes should have a length that is a multiple of the karaoke BPM.

A new box is added to GUI where the BPM multiplier can be provided. If it is provided, it is used to ensure that all the notes and gaps between notes are a multiple of the BPM multiplier. This makes mapping most songs easier, but it might mess up some songs where the notes are weird.
The term multiplier can be confusing as to the role of what it actually does etc. True BPM should be much more easily understandable, especially when contrasted with the term karaoke BPM, hopefully providing a better UX. The only issue is the requirement for the karaoke BPM to be an integer multiple of the true BPM, but that is enforced through an error message.
Sometimes, the first syllable would be moved to the previous line incorrectly. This was because the line break was being placed at the end of the last syllable of each line. However, if due to overlap the next line started before the previous line ended, the line break would end up being placed after the first syllable of the next line. This would result in all the syllables from the next line that start before the line break being placed into the previous line. This happened because the lines are sorted before being saved to disk. It has been fixed by placing the line break at the start of the next line's first syllable instead.
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

Successfully merging this pull request may close these issues.

1 participant