Closed jeetee closed 8 years ago
Sounds good. I didn't understand your scaling approach the first time you proposed it, and was surprised at the BPM and time stamp numbers that it generated the one time I had the time to try it out.
I see you've posted some more pull requests. I'll check them over and see about merging them.
I must apologize for taking so long to react to your first request. The combination of holidays, conversion to Voice over IP at home, and change of ISP at home made a complete mess of everything internet related. Things are straightened out now, so I'm trying to get caught up.
When using real BPM in the resulting file(see pull request, the smallest possible note-representation is 1/16th. Unfortunately this means that smaller notes -but also triplets- can not be rendered accurately.
The internet seems to suggest that most 'good' files have an artificial BPM scaling with a resulting BPM between 200-300. According to this page one of the more popular song editors automatically scales the BPM times 2. The Ultrastar Deluxe manual(pdf) mentiones that BPMs below 100 can be an indicator of a bad timing quality file.
So far I couldn't find any indication of a maximum value for the BPM. Performous reads it as a minimal 32bit floating point value (github::Performous::SongParser-txt). Therefor I would go for the lowest possible scaling that support the smallest note mentioned on the MuseScore TickValues page and keeps all the values as integers (exact accuracy). As a result, a song with a real BPM of 60, would in High Accuracy Mode be exported with a BPM of 1440
High Accuracy Mode would be a checkbox in the dialog, saved in the settings.
Reference Table for all the ticklengths:
This is how I envision this feature at the moment; please comment if you think a different approach would be more desired or have any other remarks.